CCIE Pursuit Blog

April 21, 2008

Beware The Man Of One Platform

Filed under: Cisco,IOS,Switching,Work — cciepursuit @ 3:26 pm
Tags: , , , ,

I vow to never be one of those guys that expects my word to be law once I am a CCIE.  This is not because I am humble (I’m not) or because the ‘Argument From Authority’ is a logical fallacy; it’s because I am wrong more often than I care to be and I will continue to be wrong more often than I care to be regardless of any digits or abbreviations after my name.  🙂

Case in point: I was troubleshooting an issue last week and was surprised to find that the VLAN interfaces (SVIs) on a 6500 series switch (an old piece of shit 6500 switch running DECNet….but I digress) each shared a single (virtual) MAC address.  I pointed this out to one of my co-workers and he said that this was normal.  I disagreed.  I jumped on a 3750 and showed him that each SVI had a unique MAC address.  I even labbed it up quickly on my 3560 to prove my point.

We noted that this might be an interesting anomaly, but it most likely was not our issue as we were troubleshooting a duplicate IP/HSRP/DECNet/STP loop issue.

Well it turns out that we were both right (and both wrong).  Depending on the platform (and IOS version?) Cisco switches may use the System MAC Address for each SVI or they may use a unique MAC Address (derived from the System MAC Address).  CCIE candidates can see this in their labs by noting the differences between the 3560s and 3550s:

3560 uses a unique MAC for each SVI:
sw1#sh ver | i IOS|emo
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
cisco WS-C3560-48PS (PowerPC405) processor (revision G0) with 118784K/12280K bytes of memory.
512K bytes of flash-simulated non-volatile configuration memory.

sw1(config-if)#do sh int | i Vlan|bia
Vlan1 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c0(bia 0012.018f.d5c0)
Vlan2 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c5(bia 0012.018f.d5c5)
Vlan3 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c6(bia 0012.018f.d5c6)
Vlan4 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c7(bia 0012.018f.d5c7)

3550 uses the same MAC for each SVI:
sw3#sh ver | i IOS|emo
Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
Cisco WS-C3550-24(PowerPC) processor (revision D0) with 65526K/8192K bytes of memory.

Vlan1 is administratively down, line protocol is down
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan2 is up, line protocol is up
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan3 is up, line protocol is up
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan4 is up, line protocol is down
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)

Scott Morris has an article on this issue.

Now you’ll notice that all of the VLAN interfaces have the same MAC address. This is the System MAC address. The reason this is OK has to do with where MAC addresses are used.

A MAC address must be unique within a Layer2 network, a broadcast domain or subnet. Each VLAN is a separate L2 network, broadcast domain and subnet. So there should be no possibility for overlap here and nothing to worry about.

If your configuration is creating some strange bridging or other cross-VLAN behavior, there may be the possibility of odd behavior, but that isn’t the normal issue at all!

So, in the grand scheme of things, you shouldn’t see any duplicate MAC addresses in any place that makes a difference.

Question Of The Day: 21 April, 2008

Topic: OSPF

Give two methods of introducing a default route into an OSPF NSSA.

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 18 April, 2008 

Topic: OSPF

Configure an OSPF dead-interval of 1 second on interface fa0/0 of r1.

Answer:  There are two ways to accomplish this.

Okay, I boned this question up due to being in a hurry as well as my own ignorance (a lethal combination).  I wrote the question thinking that the only answer would be to use OSPF Fast Hellos.  I assumed that the minimum OSPF dead timer that you could set without using Fast Hellos was 4 seconds.  I was wrong.

ip ospf dead-interval

r1(config)#int fa0/0
r1(config-if)#ip ospf dead-interval ?
  <1-65535>  Seconds
  minimal    Set to 1 second

So technically you can set the dead-interval to 1 second without using sub-second OSPF hellos.

Current OSPF Adjacencies:
r1(config-router)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:36    10.1.12.2       FastEthernet0/0
r1(config-router)#do sh ip route os
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/2] via 10.1.12.2, 00:09:36, FastEthernet0/0

So let’s set our dead-interval to 1 second on both sides of the link:

r1(config)#int fa0/0
r1(config-if)#ip ospf dead-interval 1

r2(config)#int fa0/0
r2(config-if)#ip ospf dead-interval 1

Technically you will be able to form an adjacency, but it’s going to be pretty short-lived:

r1(config-if)#do sh ip os nei

r1(config-if)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   INIT/DROTHER    00:00:00    10.1.12.2       FastEthernet0/0
r1(config-if)#
*Mar  1 00:23:55.043: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired
r1(config-if)#do sh ip os nei

r1(config-if)#

Your log is going to fill up with these error messages:

*Mar  1 00:24:55.027: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired
*Mar  1 00:25:05.071: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired
*Mar  1 00:25:15.075: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired
*Mar  1 00:25:25.047: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired
*Mar  1 00:25:35.071: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from INIT to DOWN, Neighbor Down: Dead timer expired

Notice that the timestamp on each error shows that they’re 10 seconds apart?  Here’s why:

r1(config-if)#do sh ip os int fa0/0 | i Type|interval
  Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 1, Wait 1, Retransmit 5

We send a hello packet every 10 sends.  They neighbors try to establish the adjacency (that’s why we briefly saw the neighbor in an INIT state), but after 1 second OSPF is declaring the neighbor down due to the dead timer expiring.

So….technically you would be correct if you used ‘ip ospf dead-interval 1’ in that the dead-interval would be set to 1 second, but you’d never get the neighbor adjacency to establish unless you make the hello timer less than the dead timer.  To set the hello timer to less than one second you need to use OSPF Fast Hellos.

Configure this on both sides of the link:
r1(config)#int fa0/0
r1(config-if)#ip ospf dead-interval minimal hello-multiplier 4

r1(config-if)#do sh ip os int fa0/0 | i Type|interval
  Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 250 msec, Dead 1, Wait 1, Retransmit 5

This sets the dead timer to 1 second but also sends out 4 hello packets per second.  As you can see our adjacency is up and we’re learning OSPF routes:

r1(config-if)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         964 msec    10.1.12.2       FastEthernet0/0
r1(config-if)#do sh ip route os
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/2] via 10.1.12.2, 00:05:28, FastEthernet0/0

 

 

Blog at WordPress.com.