[c-nsp] Latest iteration of core upgrade - questions

[Zoe O'Connell]

Rick Ernst wrote:
>>> surrounded by
>>> a dual layer-2 sandwich, with various devices for
>>> customer aggregation below that.
>>>       
>> What are you looking at for the core switches? We've been
>> happy with the 6506|9/SUP720-3BXL with WS-X6724-SFP line
>> cards in there for Gig-E connectivity.
>>
>> As a pure Layer 2 platform, they're rock-solid. With Layer
>> 3, search the archives for numerous horror stories.
>>
>>     
>
> - 7600/Sup720-3BXL is the top (currently only) contender for core
> routing/switching.  Two concerns that keep showing up in threads about them
> are netflow and uRPF.  I use uRPF in conjunction with a BGP route-injector
> on the border for real-time blackholing.  Not really needed in the core, but
> the functionality would be nice to have.  Netflow is the bigger concern. I
> do a lot of traffic analysis with Netflow and we are currently pushing
> ~800Mbs aggregate (total in/out across all upstreams) at 200Kpps.
> Increasing demand for > 50Mbs access is driving the ugprade.
>   

We do both and the 7600s manage very well - in the case of the former,
even with "ip verify unicast reverse-path any" if the next-hop for the
reverse-path is Null0, it drops the packet in hardware. In the case of
the latter, it's just a case of making sure you have it enabled on the
right interfaces for ingress and being concious of what you are and are
not sampling when doing reports. (For example, we only have it on
ingress at the edge and access layer - not on internal links, where it
wouldn't work anyway due to MPLS.)

>>> The consensus I've seen for core routing/switching
>>> equipment is 7600s with Sup720-3BXL and various line
>>> cards.  I'm curious how integrated the switching fabric
>>> and routing engine are; e.g. if the switch fabric is
>>> provisioned and there is a Sup failure/failover, will the
>>> switch fabric continue to forward layer-2 traffic?
>>>       

If you don't have DFCs installed in your line cards, it certainly won't
carry on working during Supervisor failover. Generally I avoid dual
supervisors myself - I build resilience with multiple devices and would
rather something died totally than flap up and down.

> - Yup. Hardware control-plane policing is definitely on my list of required
> features.  uRPF and various peer groups are already in place to protect as
> much as I can with the current platforms.
>   

If you've not done this before, you may be surprised at how much work it
is - updating ACLs and tuning rate-limiters every time you alter a BGP
session or monitoring platform gets rather tedious.

> - I'm on the fence with IPv6.  Of our current "name brand" providers, only
> one of them even sort-of supports v6.  v6 is also on my feature requirements
> list, but I'm planning on going dual-stack later rather than earlier; both
> to change as little as possible while upgrading and also to give me more
> time to digest how v6 really works and what it means.
>   

In tandem with the last point - if you need IPv6 (Which would be
sensible if you're rebuilding it all now!) then IPv6 CoPP support is
lacking across the board. It also reacts in ways you would not expect -
an access-group on a VTY for example might be set to restrict IPv4
connections but it won't block IPv6 unless you explicitly add that.