Kevin Dorrell, CCIE #20765

27 May 2008

“Still to do” list

Filed under: EIGRP, General, HSRP, IP Routing Protocols, OSPF, Spanning-Tree Protocol, VTP — dorreke @ 10:00

Someone asked me recently what I was going to do now I have my digits … would I go for a second one?  Well, not just yet.  I may have got my digits, but there are still too many things in R&S that take me by surprise.  I have found out that you can be a CCIE and still not know everything yet. :-). So expect about a year of consolidation and blogging before I move to pastures new.

Knowing what
Thou knowest not
Is in a sense
Omniscience

Piet Hein, “Grooks”

Some of the stuff that Keith Tokash has been logging recently on the “CCIE Candidate” blog has pointed the way to some interesting investigations.  Furthermore, there have been a few questions on NetPro that have made me think.  It might even be the case to go to one of Narbik’s boot camps when he is in London.  (Or maybe I’m just looking for an excuse to go back to my home city. 😉  So this page will be a working list of things to do.  Pian piano.

EIGRP 

  1. EIGRP uses the metrics at which end of each link: the transmit end or the receive end.  Is it possible to provoke asymmetric routing by configuring different metrics at either end of a link?  Can this result in any unstable topologies?  See NetPro context.
  2. Someone on the NetPro forum tells me that EIGRP uneven load balancing is always process switched.  I thought it was handled by CEF using a weighted hash algorithm.  I have to lab this.  Here is a document I based my belief on.

OSPF

  1. OSPF uses the cost at which end of each link?  Actually, I already know the answer to this one: each router advertises an LSA for each network it is attached to, along with the outgoing metric of the link.  So, looking at the path of a packet from source to destination, the cost is the sum of the transmit costs on the path.
  2. There are two ways of putting a link into are area: with ip ospf 100 area 0 on the interface, and with network x.x.x.x area 0 in the router section.  In the event of a conflict, which takes precedence?
  3. Ask the same question of ip unnumbered interfaces.

HSRP and Routing protocols

  1. I still need to understand fully the interaction between HSRP and routing protocols.  Hereis a situation where HSRP appears to cause unexpected results from a routing protocol.

LAN Control Protocols

  1. When you have a dot1q trunk, which of the control protocols are send on VLAN 1 and which are sent on the native VLAN (assuming these are different).  I answered a question on NetPro about this and apparently got it wrong.  I need to lab it.

Spanning Tree

  1. Spanning-Tree.  I guess I should ask the same question for Spanning-Tree, which after all is a sort of Distance-Vector algorithm.  Which end of each link is significant.

VTP

  1. I keep telling people to beware that a VTP client can update a domain, and so it can.  But it is not as easy as I had once thought.  I need to write up the experiment properly.  I wonder whether the behavior is version dependant.
  2. Furthermore, I really want to investigate VTP transparent.  How transparent is VTP transparent?  Can a transparent switch pass through VTP information, and if so, does the domain name need to match?  How does VTP pruning react to encountering a VTP transparent switch?

There is a load of lab work to do on this.

Advertisements

19 Apr 2008

This, that, and the other

Filed under: IOS Bugs, LAN Switching, VTP — dorreke @ 13:27

Added the resolution to my posting a couple of weeks ago about a VTP pruning problem.  I came to the conclusion it was a bug in CatOS.  CatOS will quite happily prune the native VLAN of a trunk if it thinks it is not needed.  However, in doing so, it can screw up the VTP pruning (or more specifically, grafting) mechanisms for other VLANs.  I need to investigate this further to make a more coherent explanation, but I’m sure that it the basis of the problem.  Here is me discussing it on NetPro.

 

 

09 Apr 2008

VTP Pruning : Is this a bug?

Filed under: IOS Bugs, LAN Switching, VTP — dorreke @ 14:29

I recently introduced VTP pruning on a LAN, and now I have some connectivity problems on certain VLANs.  The more I look at the problems, the more I wonder whether there is some strange behavior in VTP pruning.  The questions I need to answer are:

  1. Is pruning based on whether the switch has any downstream clients; that is, whether there are any active access ports or unpruned downstream trunks on the VLAN?  Or is it based on whether there are any downstream CAM entries for the VLAN?
  2. Is it possible for a switch to prune a VLAN off a trunk that is the root port for that VLAN?

Here is my apparently anomalous situation.  I have four VLANs, 21-24, that serve as point-to-point links between remote sites to carry server heartbeats.  On each of these VLANs, there are only two hosts: one on each site.  Here is the spanning-tree for VLAN 21:

CC80#show spanning-tree vlan 21
 VLAN0021   Spanning tree enabled protocol rstp
   Root ID    Priority    24576
              Address     0007.4f62.a014
              Cost        15
              Port        72 (Port-channel1)
              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

   Bridge ID  Priority    32789  (priority 32768 sys-id-ext 21)
              Address     001b.2ae8.b280
              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
              Aging Time 300
 Interface        Role Sts Cost      Prio.Nbr Type
 ---------------- ---- --- --------- -------- --------------------------------
 Gi0/16           Desg FWD 4         128.16   Edge P2p
 Po1              Root FWD 3         128.72   P2p
 Po2              Desg FWD 3         128.80   P2p

Notice one or two things about this.  Firstly, Po1 is the root port.  Secondly, that G0/16 is an “up” access port on this VLAN.  Thirdly, I should mention that Po2 is a trunk to another access layer switch at the same level.  But Po2 spends its time in blocking state on the other switch except in an emergency.  That is why this switch prunes most VLANs off Po2, as we will see.

Now let us look at the trunks:

CC80#show int trunk
 Port        Mode         Encapsulation  Status        Native vlan
 Gi0/3       on           802.1q         trunking      2
 Po1         on           802.1q         trunking      12
 Po2         on           802.1q         trunking      12

 Port        Vlans allowed on trunk
 Gi0/3       1,169
 Po1         1-2,5,12,21-26,169
 Po2         1-2,5,12,21-26,169

 Port        Vlans allowed and active in management domain
 Gi0/3       1,169
 Po1         1-2,5,12,21-26,169
 Po2         1-2,5,12,21-26,169

 Port        Vlansin spanning tree forwarding state and not pruned
 Gi0/3       1,169
 Po1         1-2,5,12,22,24-26,169
 Po2         1

As expected, most of the VLANs are pruned off Po2 as te other end of Po2 is on STPblocking state.  Ignore G0/3; this is a server trunk.  The interesting thing is that the switch has pruned VLAN 21 from the root port trunk, Po1.  Why?  This has effectively cut this switch off from VLAN 21.

VLAN21 is pruned from both Po1 and Po2, and yet it has an access port on it.  Now, that access port, G0/16, is apparently not receiving any MAC traffic from its connected host.  There is nothing in the CAM table except the upstream switch.  But it is still isolated, so it cannot see any traffic from the remote part of the VLAN, so it does not respond:

CC80#show mac-address-table dyn vlan 21
           Mac Address Table
 -------------------------------------------
 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
   21    0016.c73d.a22b    DYNAMIC     Po1

 Total Mac Addresses for this criterion: 1

One last possible clue.  We have four VLANs, each with two host connections.  Two of them work, two of them don’t.  The difference is that they take different paths.  Two of them are rooted on a 4506 running IOS 12.2(25)EWA2, and they work; they are not pruned anywhere between the two sites.  The two that do not work are rooted on a 4003 running CatOS 8.4(5)GLX.

Update 19/04/2008:

I think I have sorted it out, and I think it is a bug in the root switch for VLAN 21. Unlike our other VLANs, VLAN 21 is rooted in a CatOS switch. Due to various circumstances in our network, it tripped over a bug.

The bug is related to one I found a couple of years ago. I found that in a CatOS switch, if you manually disallow the native VLAN (in my case VLAN 12) from a trunk, then it stops the trunk passing BPDUs for VLAN1 as well. At the time, that resulted in a 5-minute meltdown of my network.

Here are the notes I have made for this new bug. Sorry about the generalisations … I do not know the VTP protocol very well yet.

Normally, VTP signalling is carried on the native VLAN of each trunk. By default, the native VLAN is VLAN 1, but you are allowed other values. We use VLAN 12 as native, a VLAN that is unused anywhere on the network. Now, an IOS switch will never prune VLAN 1 from a trunk. Nor will it prune the native VLAN. However, CatOS has a bug: if the (non-1) native VLAN is unused, it will prune it from the trunk regardless of the fact that it is the native. Once the native VLAN is pruned, of course, the VTP signal cannot be propagated to other switches.

It happens that we have one CatOS switch in our core loop. That switch is the root for VLANs 21 and 23. (And fortunately only for VLANs 21 and 23.) Because that root switch had pruned the native VLAN from its trunks, it was no longer able to send VTP unprune signals for VLANs 21 and 23 to its neighbors. Its neighbors therefore pruned VLANs 21 and 23 from the trunks to the root. The result was that there was no connectivity in VLANs 21 and 23, and every switch pruned all ports on those VLANs.

I resolved the problem by rolling back the VTP pruning.

17 Feb 2008

NMC Lab 7.15 – Catalyst Specialties (VTP)

Filed under: VTP — Tags: — dorreke @ 04:42

The Answer Key (page 46) makes the statement:

NOTE: Make sure that client device don’t have VLAN.DAT with vlan information on  its flash, since this will prevent VTP domain from correct synchronisation.

AFAIK, this simply is not true.  So let’s try it.  Let us start with CAT1 as server and CAT2 as client, just like in the book.  We currently have a VLAN.DAT on the flash of CAT2.  BTW, don’t worry about  the fact that the last updater is 192.168.42.1; I keep an address on VLAN 1 at all times so I can synchronise to the NTP clock on my home network.

CAT1#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 4 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 12 
VTP Operating Mode              : Server 
VTP Domain Name                 : NMC 
VTP Pruning Mode                : Enabled 
VTP V2 Mode                     : Enabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0xBD 0xAF 0xE2 0xB8 0x8A 0x8E 0xD4 0x90 
Configuration last modified by 192.168.42.110 at 2-12-08 05:51:22 
Local updater ID is 192.168.42.110 on interface Vl1 (lowest numbered VLAN interface found) 
CAT1#

Here is CAT2’s view: 

CAT2#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 4 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 12 
VTP Operating Mode              : Client 
VTP Domain Name                 : NMC 
VTP Pruning Mode                : Enabled 
VTP V2 Mode                     : Enabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0xBD 0xAF 0xE2 0xB8 0x8A 0x8E 0xD4 0x90 
Configuration last modified by 192.168.42.110 at 2-12-08 05:51:22 
CAT2#

CAT2 has a VLAN.DAT in its flash at the moment. 

CAT2#show flash Directory of flash:/  

  : 
  414  drwx         128  Mar 01 1993 06:34:20 +01:00  Lab06 
  413  -rwx         984  Mar 01 1993 01:13:21 +01:00  vlan.dat 
  418  drwx         128  Mar 01 1993 01:39:18 +01:00  Lab04 
  415  drwx         128  Mar 01 1993 02:52:21 +01:00  Lab25 
  425  drwx         128  Mar 01 1993 10:08:23 +01:00  Lab03 
  428  drwx         128  Feb 03 2008 16:16:54 +01:00  Lab05 
  431  -rwx        4248  Mar 01 1993 01:16:10 +01:00  config.text 
  434  -rwx        1092  Mar 01 1993 01:16:10 +01:00  private-config.text 
  437  -rwx        1048  Mar 01 1993 01:16:10 +01:00  multiple-fs 15998976 bytes total (2173952 bytes free) 
CAT2#

 Now let us try adding a VLAN at CAT1:

CAT1#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT1(config)#vlan 42 
CAT1(config-vlan)#name Test 
CAT1(config-vlan)#exit 
CAT1(config)#exit 
CAT1# 
Feb 17 03:20:58.967: %SYS-5-CONFIG_I: Configured from console by console

Let us check it on CAT1: 

CAT1#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 5 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 13 
VTP Operating Mode              : Server 
VTP Domain Name                 : NMC 
VTP Pruning Mode                : Enabled 
VTP V2 Mode                     : Enabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0xC7 0xD4 0x08 0x2D 0xB6 0xC9 0xB0 0x15 
Configuration last modified by 192.168.42.110 at 2-17-08 03:20:57 
Local updater ID is 192.168.42.110 on interface Vl1 (lowest numbered VLAN interface found) 
CAT1#

Let us check it on CAT2:

CAT2#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 5 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 13 
VTP Operating Mode              : Client 
VTP Domain Name                 : NMC 
VTP Pruning Mode                : Enabled 
VTP V2 Mode                     : Enabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0xC7 0xD4 0x08 0x2D 0xB6 0xC9 0xB0 0x15 
Configuration last modified by 192.168.42.110 at 2-17-08 03:20:57 
CAT2#

Well, CAT2 seems to have updated OK despite having a VLAN.DAT in the flash.  Let us see what happens if we delete the VLAN.DAT:

CAT2#delete vlan.dat 
Delete filename [vlan.dat]? 
Delete flash:vlan.dat? [confirm]

Check it is gone: 

CAT2#show flash Directory of flash:/  

    2  -rwx     4968676  Mar 01 1993 01:11:43 +01:00  c3550-i5k2l2q3-mz.121-22.EA4.bin 
    3  drwx         192  Mar 01 1993 05:03:30 +01:00  Lab01 
    4  drwx          64  Mar 01 1993 02:54:02 +01:00  Lab24 
  412  drwx         128  Mar 01 1993 01:35:11 +01:00  Lab02 
    8  drwx         128  Aug 30 2007 14:00:06 +02:00  c3550-ipbasek9-mz.122-40.SE 
    6  -rwx           0  Mar 01 1993 01:14:32 +01:00  env_vars 
    7  -rwx          44  Mar 01 1993 01:14:32 +01:00  system_env_vars 
  411  -rwx        2637  Mar 01 1993 01:03:15 +01:00  default.cfg 
  414  drwx         128  Mar 01 1993 06:34:20 +01:00  Lab06 
  418  drwx         128  Mar 01 1993 01:39:18 +01:00  Lab04 
  415  drwx         128  Mar 01 1993 02:52:21 +01:00  Lab25 
  425  drwx         128  Mar 01 1993 10:08:23 +01:00  Lab03 
  428  drwx         128  Feb 03 2008 16:16:54 +01:00  Lab05 
  431  -rwx        4248  Mar 01 1993 01:16:10 +01:00  config.text 
  434  -rwx        1092  Mar 01 1993 01:16:10 +01:00  private-config.text 
  437  -rwx        1048  Mar 01 1993 01:16:10 +01:00  multiple-fs 15998976 bytes total (2174976 bytes free)

Now let us try updating the domain again on CAT1: 

CAT1#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT1(config)#no vlan 42 
CAT1(config)#^Z 
CAT1# 
Feb 17 03:23:40.846: %SYS-5-CONFIG_I: Configured from console by console

The change has propagated to CAT2: 

CAT2#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 6 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 12 
VTP Operating Mode              : Client 
VTP Domain Name                 : NMC 
VTP Pruning Mode                : Enabled 
VTP V2 Mode                     : Enabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0x7E 0xCC 0x4B 0x16 0x85 0x92 0xD5 0xF7 
Configuration last modified by 192.168.42.110 at 2-17-08 03:23:39

But here is an interesting thing: CAT2 has recreated the VLAN.DAT

CAT2#show flash Directory of flash:/ 
    2  -rwx     4968676  Mar 01 1993 01:11:43 +01:00  c3550-i5k2l2q3-mz.121-22.EA4.bin 
    3  drwx         192  Mar 01 1993 05:03:30 +01:00  Lab01 
    4  drwx          64  Mar 01 1993 02:54:02 +01:00  Lab24 
  412  drwx         128  Mar 01 1993 01:35:11 +01:00  Lab02 
    8  drwx         128  Aug 30 2007 14:00:06 +02:00  c3550-ipbasek9-mz.122-40.SE 
    6  -rwx           0  Mar 01 1993 01:14:32 +01:00  env_vars 
    7  -rwx          44  Mar 01 1993 01:14:32 +01:00  system_env_vars 
  411  -rwx        2637  Mar 01 1993 01:03:15 +01:00  default.cfg 
  414  drwx         128  Mar 01 1993 06:34:20 +01:00  Lab06 
  413  -rwx         984  Feb 17 2008 04:23:39 +01:00  vlan.dat 
  418  drwx         128  Mar 01 1993 01:39:18 +01:00  Lab04 
  415  drwx         128  Mar 01 1993 02:52:21 +01:00  Lab25 
  425  drwx         128  Mar 01 1993 10:08:23 +01:00  Lab03 
  428  drwx         128  Feb 03 2008 16:16:54 +01:00  Lab05 
  431  -rwx        4248  Mar 01 1993 01:16:10 +01:00  config.text 
  434  -rwx        1092  Mar 01 1993 01:16:10 +01:00  private-config.text 
  437  -rwx        1048  Mar 01 1993 01:16:10 +01:00  multiple-fs 15998976 bytes total (2173952 bytes free) 
CAT2#

Now that is interesting.  We deleted the VLAN.DAT from CAT2.  But as soon as we went back to CAT1 and modified the domain (deleting the extra VLAN we created), the VLAN.DAT was recreated on CAT2.

It is logical that a client should keep a copy of the VLAN.DAT.  Suppose the client got isolated from the rest of the network and then rebooted.  If it didn’t have a copy of the VLAN.DAT, then it would lose all its VLANs.

CAT2#show vtp status 
VTP Version                     : 2 
Configuration Revision          : 0 
Maximum VLANs supported locally : 1005 
Number of existing VLANs        : 5 
VTP Operating Mode              : Server 
VTP Domain Name                 : 
VTP Pruning Mode                : Disabled 
VTP V2 Mode                     : Disabled 
VTP Traps Generation            : Disabled 
MD5 digest                      : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD 
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00 
Local updater ID is 192.168.42.120 on interface Vl1 (lowest numbered VLAN interface found) 
CAT2#

Not only that, but it would not know the VTP password any more.  That means that it would not be able to connect to the VTP server any more.

Create a free website or blog at WordPress.com.