[afnog] Cisco 7609 sup32 password recovery

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20090811/b9037802/attachment.bin>