Readers attending PLNOG and EURONOG conference this week (starting tomorrow!) I’d like to invite to my two lectures:
Later, on conferences sites presentations, audio and video recordings will be available for free.
PLNOG
EURONOG
Interface range command is quite widely used on Cisco switches to configure many physical interfaces at the same time. On 7600 routers it can be also used to configure many SVIs at the same time but you can use it only to configure existing SVIs within range. According to documentation this command cannot be used to create SVIs in that particular range which is not totally true.
Read More
Internal VLANs are used for services like MPLS, FCoE, Multicast over GRE, enhancement to SPAN, etc. Some Features have special requirements like which VLAN can be reserved for them. Example of such service are Multicast VLAN which can only start with VLAN id’s that is multiple of 64.
Prior to release 5.2(1) the reserved VLAN range was 3968 to 4048, and 4094, and it was not configurable. After the upgrade user-defined VLANs might fall within the new reserved range which now range from 3968 to 4095 and is configurable. If that occurs, switch fallback to old range but the features that need the additional reserved VLANs won’t work propely. What you have to do is change range of reserved VLANs using command:
switch(config)# system vlan 2000 reserve
This will delete all configs on vlans 2000-2127. Continue anyway? (y/n) [no] y
Note: After switch reload, VLANs 2000-2127 will be reserved for internal use.
This requires copy running-config to startup-config before
switch reload. Creating VLANs within this range is not allowed.
Now the disadvantage if this is you have to reboot whole chassis. Simple switchover between supervisors on Nexus 7000 won’t be enough. Also, if you are using vPC if one switch is using new VLAN range and other one is still configured to use old range switches will not forward those VLANs on vPC peer-link. Hence, those VLANs will get suspended on vPC port-channel. But this should not affect any other VLANs in vPC.
In some cases router running IOS XE might crash or produce traceback if we try to delete logical interface (like ie. port-channel) or subinterface that runs IPv6 EIGRP. This can occur mostly on XNE or older releaseses, has been fixed in new ones. Cisco have internal bug CSCtd63242 describing this problem (might be released into public).
Read More
It’s easy trick but I’m going to put it here anyway so anyone can use it and for me so I can easy find code when I need it 🙂 This is “snake” that is made traffic from generator go through all ports on line cards and between two line cards. It’s made for testing purposes in lab environment if you need to verify performance capability of ASR9K router (or any other runnin IOS XR in this case) for customer.
Read More
IPv6 is coming. You should already know that and get prepared. One of the step one should consider is performing IPv6 Readiness audit. This audit should consist of network and application checking with great care of network functionality and security. Results might be surprising but that’s not the main point of this post. Auditing process might be interesting and hard itself.
A little while ago I wrote about unsupported scenario of upgrading NX-OS on Nexus 7000. It’s a scenario I found few months ago and forgot to write about it, but my other customer had same problem few weeks ago which refreshed my memory. Back then we got information from Cisco TAC that this scenario is not supported but no official information is available about this.
I got mail from Andras Toth from Cisco TAC lately pointing me that this limitation has been documented in NX-OS 5.1 release notes. Thanks Cisco for making it clear. And remember it applies to all NX-OS releases, not just 5.1.
One of my customers told me that he can’t save configuration on Nexus 7000 switch. It has been working for over 6 months with no problems.
switch1# copy running-config startup-config Configuration update aborted: another request for config change is already in progress
It looks like a CSCtj44206 bug. In this case software switchover is not a solution as this request will be refused by system due to configuration lock. Solution, except full chassis reload, is performing hardware switchover by removing active supervisor from chassis. This will unlock configuration and let you perform ISSU to latest NX-OS where this bug is solved.
If you are using multiple VDCs on your Nexus 7000 switch and you create vPC between two of them you can forget about upgrading NX-OS via ISSU. This scenario is not supported, but there is no information about that in documentation. If you try to perform upgrade you will see following error message:
Notifying services about the switchover. [# ] 0% -- FAIL. Return code 0x401E007B (request was aborted by service). Please issue "show install all failure-reason" to find the cause of the failure. Failure recovery action:: "Standby will be rebooted to force netboot and image download". Install has failed. Return code 0x401E007B (request was aborted by service). Please identify the cause of the failure, and try 'install all' again. n7k-switch# show install all failure-reason Service "vpc" in vdc: 2 returned error: configuration lock can not be acquired for peer switch (x41B7004B) Service "vpc" in vdc: 3 returned error: configuration lock can not be acquired for peer switch (x41B7004B)
The only way to upgrade is to download new software, replace bootvar and reboot whole chassis.
UDLD is a nice mechanism detecting unidirectional transmission over fiber or copper link. But it tests only physical layer. Therefore if there is a problem with transmitting BPDUs over link UDLD won’t detect this problem which may cause loops in network.
IEEE 802.1D-2004 Rapid STP standard defines dispute mechanism that works similar to UDLD but on layer 2 of OSI model. Root bridge is sending Superiors BPDUs over it’s links and is waiting for replies from the neighbors. If an adjacent switch respond in a way suggesting it didn’t receive SBPDU, root bridge block its port, thus preventing the bridging loop.
Dispute mechanism works only for RSTP and MST BPDUs because those ones includes the role and state of the sending port.
Dispute can be found on Catalyst 6500 with IOS 12.2(33) SXI and above, Catalyst 4500 and 4900 since 12.2(52)SG release as well as on Nexus switches.