policy routing and netflow (was Re: karl and paul, expostulating )

Mailman List Mirror (Read Only)
1

>
> doesn't matter. in production ios, policy routing (source based
> routing) is process switched. there is code in the works to make it
> fast switched. but there is a bug wherein if you do policy routing,
> and you enable flow or optimum switching on the interface you're
> doing pr on , it disables the policy routing.
>
> that bug may be fixed now but in any case enabling flow switching
> will *not* speed up policy routing. and if you're exporting the flow
> stats, you lose anywhere from 50kpps to 100Kpps of speed.

I have news for you; this isn't policy routing!

  you better tell cisoc that then :slight_smile: they call source based routing
"policy routing". bad choice of names i guess but that's what they
call it. it's an inbound route map applied to an interface and you
look at the *source* address of the packet, then use various "set"
clauses based on that address.

We aren't re-writting
any source or destination addresses (which is what policy routing
does).

  i have news for you, policy routing has nothing to do with
re-writing source or destination addresses.

We're just filtering based on source and destination
parameters (such as address, protocol, port, etc).

  if you're filtering based on source-anything, and you're using a
cisco, i'd like to know how you're doing it without policy
route-maps. please see:

www.cisco.com/warp/public/732/Tech/plicy_wp.htm

  i didn't imply that you were doing anything. i may have
misundestood justin but i thought he was implying that netflow
switching would increase the switching speed of policy based routing,
as cisco calls it, and it does not. that's all i was getting at.

Flow switching works very effectively (at least as of IOS 11.1.9).

  yes it does. i never said it didn't work well. who's mail were
you reading anyway?

-brett

2

you better tell cisoc that then :slight_smile: they call source based routing
"policy routing". bad choice of names i guess but that's what they
call it. it's an inbound route map applied to an interface and you
look at the *source* address of the packet, then use various "set"
clauses based on that address.

No, this is not source based _routing_, it's _filtering_. _BIG_
difference. The filters I speak of do examine the source address
(sometimes), but the decision of what interface to switch the packet
to is handled normally. The only thing the filter does do is dictate
whether or not to allow the packet to be switched in the first place.

  i have news for you, policy routing has nothing to do with
re-writing source or destination addresses.

You are correct, I misspoke on that count. What I meant to say was
that access-list filters (using the access-group parameter) do not
control where the packet is switched, whereas policy routing does do
this.

  if you're filtering based on source-anything, and you're using a
cisco, i'd like to know how you're doing it without policy
route-maps. please see:

I'm using extended access lists. I'd be happy to show you if you'd
like.

  i didn't imply that you were doing anything. i may have
misundestood justin but i thought he was implying that netflow
switching would increase the switching speed of policy based routing,
as cisco calls it, and it does not. that's all i was getting at.

I think you need to re-examine what policy routing really is.

  yes it does. i never said it didn't work well. who's mail were
you reading anyway?

Yours. I was just re-iterating how well it functioned.

Alec

3

they call source based routing
   "policy routing". bad choice of names i guess but that's what they
   call it.

My most profuse apologies. Just so I don't make the same mistake again,
what should I have called it?

:wink:

Tony