[nsp] 6509/sup720-3bxl capabilities

Andrew Fort afort at choqolat.org
Thu Mar 11 22:34:56 EST 2004


* Sven Huster <sven at huster.me.uk> [2004-03-10 15:46:41 +0000]:

> It needs to run BGP with 2-4 full views as well
> as 30-80 parital views, uRPF, ACL, PBR, OSPF, CAR.
> Also it'll run quite a few VLANs, possibly with
> VACLs on them.

cant comment on this scale.  i believe current software
means you can run ~500k prefixes in your FIB, though
the TCAM should support ~1 million.

> I'll try to find out what's supported of these
> list of things, especially about what it can do
> in hardware. I wonder what of the discussions
> uRPF on SUP2 and SUP720 applies to the 3BXL.

uRPF on Sup720 (PFC3A) doesn't suffer the same problem
that uRPF on Sup2 does (i.e., no FIB halving problem).

> Another interesting thing would be which IOS
> would be recommended.

You don't have much choice!  12.2(17a)SX* is where
most people are at currently, I believe this 17SX 
is the first release to support 3BXL.

> The last question is then how to secure the
> device, so control and manangment plane.

Apologies if I'm repeating what you already know. 

Here's what i do:

1.
mls ip cef rate-limit <x> <y>

to limit the rate of punts to the MSFC (i.e.,
stuff that could be eventually process switched)

This helps out alot but contention for good and
bad packets still deemed puntable will occur, so
packet filter stuff arriving at the box (done
in hardware), so that you only accept your BGP/IGP
from expected sources if you want to do things
well.  try to use a method which makes use of a
single ACL as much as possible (to conserve your
limited ACE resources).  

cisco: having a method of combining a 'generic'
packet filter for every interface as well as a per
interface (e.g. customer) ACL on this platform 
(where hey, it can be done behind the
scenes) would be great, to avoid having to configure
differing ACLs and chewing ACEs.

2. use.. 
ip spd <etc>

note SPD is just a priority queue for ip prec=6
packets, so attackers can just fill the SPD
queue if they like by flipping those bits.

3. on your SVI interfaces facing your BGP
or other protocol neighbors, use

int vlan x
hold-queue <x> in

x=1000 generally works well (combine this
with a reasonable SPD queue size).  Watch
for 'drops' on your input queue (meaning
you overflowed that <x>) and 'flushes'
(meaning SPD was enacted to flush its
queue).

In recent code (12.0(26)S, bit academic on
the 7600 ;-) this has very little impact 
now due to vast improvements in the BGP
process input queue code, so this should
filter out to SupX IOSes eventually.

Do all of that and you should be pretty much
laughing.  there's no "control-plane" QoS
feature (like 12.2S has) available on the 
Sup720x platforms.

> Thanks 
> Sven

-andrew


More information about the cisco-nsp mailing list