[afnog] Cisco 7609 sup32 password recovery

[Frank A. Kuse]

Hi Mark,

Thanks for the detail explanation on the various modules functionalities on
the system.
I really appreciate it.

Regards,

Frank

>-----Original Message-----
>From: Mark Tinka [mailto:mtinka at globaltransit.net]
>Sent: Tuesday, August 11, 2009 2:26 PM
>To: Frank A. Kuse
>Cc: kurup at afrinic.net; afnog at afnog.org
>Subject: Re: [afnog] Cisco 7609 sup32 password recovery
>
>On Tuesday 11 August 2009 06:32:45 pm Frank A. Kuse wrote:
>
>> Thanks you all for the explanation.
>>
>> I am up and running now.
>
>Great stuff!
>
>The link Hari posted alludes to an important point re: the 6500/7600
>supervisor engine architecture, which is worthy of consideration in
>circumstances such as password recovery, system configuration, system
>troubleshooting, e.t.c.
>
>If you may indulge me...
>
>The supervisor engine in this platform integrates two functions; control
>plane and data plane (in other platforms, Cisco or otherwise, these
>functions may be physically distributed).
>
>On the supervisor engine, the control plane is managed by the MSFC
>(Multilayer Switch Feature Card). The MSFC runs and maintains all
>software processes, handles the management interface to the
>router/switch, executes routing and switching protocol functions, e.t.c.
>
>The data plane is managed by the PFC (Policy Feature Card).
>The PFC provides centralized forwarding functions via a high-speed ASIC
>infrastructure, handling things such as route and MAC address look-ups,
>QoS, ACL's, Multicast packet replication, e.t.c.
>
>But the interesting bit here is the MSFC; the control plane.
>On the supervisor engine, the MSFC comprises two components, the RP
>(Route Processor) and the SP (Switch Processor). As their names suggest,
>the RP is responsible for Layer 3 functions, e.g., OSPF, IS-IS, BGP,
>e.t.c., while the SP handles Layer 2 functions, e.g., STP, 802.1Q, MAC
>address learning, e.t.c.
>
>When this platform had just debuted, it either run in Hybrid or Native
>mode. Hybrid mode meant running CatOS on the SP and IOS on the RP.
>Native mode means running IOS on both the RP and SP.
>
>Hybrid mode meant operators had to switch between the RP and SP in order
>to configure Layer 2 or Layer 3 features. Native mode is more
>transparent, however, although both the RP and SP are running
>independent copies of the IOS image. Native mode is what is mostly seen
>in the wild nowadays, and is the default mode in which Cisco ship these
>platforms.
>
>A new mode, Modular IOS, is based on a UNIX kernel to mitigate some of
>the shortcomings of the original IOS architecture, i.e., monolithic.
>Modular IOS is meant to offer benefits such as in-service updates,
>patching of individual processes, e.t.c., without having to reboot the
>router/switch. In actual practice, Modular IOS has had more kinks than
>features, and I wouldn't really recommend it to anyone at this stage,
>although some networks are running it, with pain.
>
>So coming back to why understanding a little bit about the 6500/7600
>supervisor engine architecture might be useful; the separation of the RP
>and SP may not be such a visible thing today, what with Native IOS and
>all, but in cases of troubleshooting, RP issues may not affect SP
>issues, and vice versa. In other cases, troubleshooting the RP may
>affect the SP, and vice versa. Furthermore, when troubleshooting certain
>issues, fixing the RP but not fixing the SP, and vice versa, may lead to
>problems.
>
>Keeping this in mind (even though these kinds of issues are generally
>few & far between), would be a good way to minimize pain.
>
>Cheers,
>
>Mark.