Just curious, do most vendors' hardware need to hit the
cpu when doing policy-based routing? I found one of my
border routers' cpu's on the bad end of a DDoS but once
I turned off a not necessarily required setup to force
some outbound traffic to take a specific outbound link
via PBR, the DDoS traffic was no longer an issue. It was
only about 200 Mbit so I hadn't expected it to be an issue
but apparently it was; I was surprised when support told
me the PBR was making traffic hit the cpu.
That is about the best answer you're going to get unless you can tell us
what hardware. Obviously policy-based routing uses a different lookup
mechanism (some user-defined policy) than traditional destination ip
longest prefix match. A cpu-based router is going to do it in cpu (duh),
but the lookup process isn't going to be as efficient. A lower end
hardware based/assisted router or L3 switch may just end up kicking policy
routed traffic down a slow path, which may or may not be CPU based. Many
higher end routers are perfectly capable of doing policy routing at the
same level of performance as regular IP routing. Most vendors make a
product that fits into each category.
As far as I know, the hardware that you are likely using from the major
company in the bay area is going to put all PBR traffic through the CPU.
Other vendors do it in different ways, but any vendor that only does the
standard destination address lookup in hardware will have to do exception
processing in the CPU. Most routers fall into this category. The
differences will be how efficiently the CPU handles the processing, and
that will determine the load.
Unfortunately, any more specific information of what vendors do would be a
violation of the NDAs.
As far as I know, the hardware that you are likely using from the
major company in the bay area is going to put all PBR traffic
through the CPU.
[...]
It's all dependent upon platform, as was stated previously. A Cisco
Catalyst 6500 with Sup720 can definitely preform hardware-based PBR.
On the other hand, your run-of-the-mill 2600 series (or even a Sup2
w/MSFC2, if memory serves) cannot.
Unfortunately, any more specific information of what vendors do
would be a violation of the NDAs.
I was. I nuked my peering about an hour ago. Word from the local ops manager was that it was a national issue that started just after 1pm Mountain time.
Just curious, do most vendors' hardware need to hit the cpu when doing
policy-based routing?
As far as I know, the hardware that you are likely using from the major
company in the bay area is going to put all PBR traffic through the CPU.
not quite true ...
for router platforms, in most cases PBR doesn't alter the 'path' of processing. PBR is available within CEF/fast paths & processing doesn't "drop out" of that processing path unless some of the more esoteric 'policy' options are used. this doesn't mean that PBR comes "for free" - but with careful planning it doesn't have to result in excessive CPU overhead either.
for many switch platforms, PBR remain in a h/w-switched path & essentially does come for 'free' (no impact on speed, no requirement to fallback to a s/w-based path). the price here is that not all 'policies' are necessarily available in the h/w-switching path.
i can provide more details off-list if you wish but i doubt folks want this to be a foobar-nsp list..
That's not at all surprising. PBR would be pretty hard to push into a hardware forwarding path.
Not impossible, but certainly challenging.
Doesn't the SUP-720(PFC3B) support (some forms of) PBR in hardware ?
As has been pointed out to me privately, the SUP-720 does flow cache PBR support. Now, if you consider a flow cache to be acceptable performance, and the flow descriptor fits within the policies that you wanna write and you fit within the performance boundaries of a SUP-720, well, that may be a suitable solution.
