Cisco – IOS for Cisco 6509/7609

ciscocisco-6500cisco-7600cisco-ios

Good morning,

I need to move one SUP7203bXL from a 6509 chassis to a 7609. Now the SUP has the IOS:
s72033-adventerprisek9_wan-mz.122-33.SXJ.bin

I would like to have the IOS: c7600s72033-advipservicesk9-mz.122-33.SRE1.bin running on the 7609 router. Is this IOS compatible with 6509, so I can update the IOS on the 6509 and then move the SUP?

What should I do?

Another question, does the IOS s72033-adventerprisek9_wan-mz.122-33.SXJ.bin allow mac access-lists? I can create them but can't apply it to an interface … Should I take into account something else?

Best Answer

I would like to have the IOS: c7600s72033-advipservicesk9-mz.122-33.SRE1.bin running on the 7609 router. Is this IOS compatible with 6509, so I can update the IOS on the 6509 and then move the SUP?

You're speaking about a subject which is very confusing, and I apologize. For years, you could mostly get away with saying the biggest difference between a Catalyst 6500 chassis and Cisco 7600 chassis was the paint.

Times changed, starting in IOS 12.2SRB. Now, you are strongly discouraged from running IOS 12.2SRB (or after) on a Catalyst 6500 chassis, because Cisco split support for Catalyst 6500 and Cisco 7600 chassis into different software images and business units. There were business reasons for splitting support for Catalyst 6500 and Cisco 7600 branded systems. If you feel that you must run 7600 12.2SRB or later on a Catalyst 6500, please speak with your Cisco account manager; he should be able to contact the 7600 BU and get discussions going.

does the IOS s72033-adventerprisek9_wan-mz.122-33.SXJ.bin allow mac access-lists? I can create them but can't apply it to an interface ... Should I take into account something else?

It should, with some linecard limitations. Quoting the LAN Switching command reference:

For the Cisco 7600 series platform when ES20 or ES40 line cards are used, only the {permit | deny} {src-mac mask | any} {dest-mac mask | any} part of the command syntax applies. If an extended MAC Access Control List is created using the [protocol [vlan vlan] [cos value]] options, these options are ignored.

These options apply to LAN cards. If you were using an OSM or other "WAN" card, the issues are different.

Related Solutions

Cisco active/standby FWSM pair went active/active after switch upgrade

THE PROBLEM:
It turns out we ran into a node limit on the FWSM. Evidently you can be within your rule limit but hit the node ceiling. This doc https://supportforums.cisco.com/docs/DOC-8786 details the compilation memory exhaustion issue that hit us. Quoting:

This command show np 3 acl stats in the context in question will show if the total nodes is reached. This limit may be reached even before the ACL limit is reached. Each ACE may take a minimum of 2 nodes to a maximum up to to 5 nodes depending on where the ACL is being called. The ACL that is tied to MPF (modular policy framework) may take up more nodes than the ACL that is tied to a NAT or to the access-group. There is no way to calculate the number of nodes. The best way to monitor this is to regularly look at the above output to make sure the node count is not exceeded.

RESOLUTION:
1. Power down the secondary FWSM and power on the primary.
2. Revise our configuration by examining which rules could be removed (stale rules and recent changes allowing certain Development environments access to Production) in order to bring down the rule and therefore node count.
3. Ensure the new config compiles then reset the primary FWSM.
4. Verify the FWSM comes up clean with no errors.
5. Power down the primary FWSM and power up the secondary FWSM.
6. Repeat steps 3 and 4 with the secondary FWSM then power it down.
7. Power on the primary, ensure it's clean, power on the secondary.
8. Ensure the primary's config is copied to the secondary and that the primary is Active and sees the secondary as Standby.

MITIGATION:
1. We upgraded our development environment (2 x 6509 with Active/Standby FWSM) to FWSM version 4.1(13) from 3.2(23). The upgrade to the 4.x train increased the maximum node count for us from 28,356 to 38,439. More information: http://www.cisco.com/en/US/prod/collateral/modules/ps2706/product_bulletin_c25-478751.html.
2. We will upgrade our Production FWSM during the next change window.
3. We implemented a Kiwi CatTools job to run the show np 3 acl stats command in our contexts and e-mail us a daily report. Whenever we make a rule change we also run this command to ensure we're within node and rule limits.

It's interesting behavior that the FWSM would allow us to continue adding rules. It only failed when it was power cycled and tried to compile the rule set. Lessons learned!

Cisco 7600 MUX-UNI on SRE IOS

MUX-UNI support:

It looks like you're trying to configure a MUX-UNI with:

A Layer3 interface on Vlan 556
A Vlan-mode PW on Vlan 920

The WS-X6516A is considered a Catalyst 6500 / Cisco 7600 LAN Card; LAN cards have some feature restrictions... one of the restrictions is how you configure a Layer3 interface on a LAN card with dot1q encapsulation.

When you're building a MUX-UNI combination of Pseudo-Wire services, and Layer3 services on a dot1q-trunked Catalyst 6500 LAN card, you must do the following:

Configure the Layer3 services on an SVI. Direct Layer3 subinterface configuration on the LAN switchports is not supported on Sup720
Configure the Pseudo-wire as a subinterface of the LAN card (omit the PW vlan from the dot1q trunk though.

I'll use your example...

interface GigabitEthernet8/1
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 556
 switchport mode trunk
 switchport nonegotiate
!
interface GigabitEthernet8/1.123
 ! Configure PW-ID 1026 on Vlan 920, note that vlan-920 is *not* explicitly trunked on Gi8/1
 encapsulation dot1q 920
 xconnect 172.16.25.25 1026 encapsulation mpls
  mtu 1500
!
interface Vlan556
 no shutdown
 ! insert optional VRF configuration here
 ip address 192.0.2.254

If you use this configuration as a template, MUX-UNI will work for you.

What was wrong with your configuration

You tried to use a Layer3 IP subinterface directly on the switchport, which is not supported on 6500 / 7600-series LAN cards and Sup720
The original MUX-UNI configuration on Gi8/3 was not made a switchport first.

Catalyst6500 LAN Card IP subinterfaces

Because Catalyst6500 Vlans have a global scope throughout the chassis, LAN cards on Sup720 support a routed dot1q subinterface, as long as you have not used that same vlan elsewhere... example:

! ensure vlan 100 is unused, so we can use it on a Gi4/1 subinterface
no vlan 100
interface GigabitEthernet4/1
 no switchport
interface GigabitEthernet4/1.100
 encapsulation dot1q 100
 ip address 192.0.2.1 255.255.255.0