New site

I hosted my website and blog on a virtual machine that I rented.
After a power failure the virtual machine’s hard drive was corrupted and I lost some data.
Below this post are a few old articles I managed to save.
Unfortunately, among others, I lost a rather lengthy post on DMVPN.
I will re-write that post, and the others I lost, so please check back here again soon.

Posted in Generic | Comments Off on New site

VTP : Moving to another VTP domain

We use VTP to propagate VLAN defenitions to all of our switches. There are cons to the use of VTP but I feel the benfit of not having to configure the VLANs on dozens of switches (or more) can sometimes outway the risk that comes with using a protocol that can wipe your entire VLAN database in seconds when misconfigured. I felt like I needed to make that statement because there is a risk and you should know about it, make sure you know the pro’s and cons of this protocol before you implement it by reading the Cisco documentation.

As you may know you need to have your switches in the same VTP domain to have the VLAN defenitions propagated between your switches. At our company we normally create a seperate network for larger customers. The customer has its’ own dedicated switches, routers, firewalls, etc. This also means we use a unique VTP domain for the customer and normally there is no layer 2 link between us and the customer. But sometimes there are exceptions. Maybe a customer started small in a shared rack and grew to where a dedicated platform makes sense.
We’ve had one such case recently and one of the challenges we faced was dedicating some switches to the customer and moving them to their own VTP domain while keeping a layer 2 link to our network. The layer 2 link is needed temporary as an in-between solution untill the last shared vlan can be phased out.
So, we need to move some switches to their own VTP domain without loosing their existing VLAN defenitions and without downtime. A nice project to test in a lab.

Here is the lab we used (click for a larger image):

vtp_lab

SW1 is the current VTP master.

sw1#sh vtp st
VTP Version                     : 2
Configuration Revision          : 12
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 10
VTP Operating Mode              : Server
VTP Domain Name                 : Corp
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x90 0x10 0xAA 0x3C 0x56 0x94 0x8F 0x34
Configuration last modified by 0.0.0.0 at 3-1-93 00:10:41
Local updater ID is 0.0.0.0 (no valid interface found)

On a VTP client we see this:

sw4#sh vtp st
VTP Version                     : 2
Configuration Revision          : 12
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 10
VTP Operating Mode              : Client
VTP Domain Name                 : Corp
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x90 0x10 0xAA 0x3C 0x56 0x94 0x8F 0x34
Configuration last modified by 0.0.0.0 at 3-1-93 00:10:41

These are the VLANs we have:

sw4#sh vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
10 dmz active
20 office active
30 management active
40 cust1 active
50 cust2 active

The goal of this lab is to move sw3 and sw2 to the VTP domain “Cust” but keeping the existing VLANs in the process. The documentation states that to do so we need to first put the sw3 and sw2 in VTP transparant mode and then move them to another VTP domain.
Let’s test it.

First let’s move sw3 to another domain and make it a VTP server:

sw3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw3(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
sw3(config)#vtp domain Cust
Changing VTP domain name from Corp to Cust
sw3(config)#vtp password qwe123
Setting device VLAN database password to qwe123
sw3(config)#vtp mode server
Setting device to VTP SERVER mode.

sw3#show vtp status 
VTP Version                     : 2
Configuration Revision          : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 10
VTP Operating Mode              : Server
VTP Domain Name                 : Cust
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x03 0x21 0x36 0x8E 0xD6 0xED 0xC9 0x39 
Configuration last modified by 0.0.0.0 at 3-1-93 00:10:41
Local updater ID is 0.0.0.0 (no valid interface found)

So sw3 is indeed a VTP server for the domain “Cust”. Immediately we get error messages like this:

00:21:41 %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/24 because of VTP domain mismatch.

This means that DTP (dynamic trunking protocoll) will not automatically form a trunk because of the domain name mismatch. Something to keep in mind. But because we hard coded the interface to be a trunk on both sides (with the “switchport mode trunk” command) this is not a problem for us. But let’s verify:

sw3#show interfaces trunk
Port        Mode         Encapsulation  Status        Native vlan
Fa0/1       on           802.1q         trunking      1
Fa0/24      on           802.1q         trunking      1

So, Fa0/24 is still a trunk. Good! On to sw2:

sw2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw2(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
sw2(config)#vtp domain Cust
Changing VTP domain name from Corp to Cust
sw2(config)#vtp password qwe123
Setting device VLAN database password to qwe123
sw2(config)#vtp mode client
Setting device to VTP CLIENT mode.

And here we also get the error message:

00:23:35 %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/1 because of VTP domain mismatch.

We know this not the be a problem, but I’d like to supress this error message. I will come back to that later in this posting. For now, let’s verify that sw2 is indeed a client and is moved to the domain “Cust”:

sw2#sh vtp st
VTP Version                     : 2
Configuration Revision          : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 10
VTP Operating Mode              : Client
VTP Domain Name                 : Cust
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x03 0x21 0x36 0x8E 0xD6 0xED 0xC9 0x39
Configuration last modified by 0.0.0.0 at 3-1-93 00:10:41

Good. sw2 is moved to the Cust domain and is a VTP client. The revision has been reset to “0″ as the documentation said it would. Let’s check if we still have all the VLANs:

sw2#sh vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
10   dmz                              active
20   office                           active
30   management                       active
40   cust1                            active
50   cust2                            active

Now let’s remove VLAN 10, 20, 30 and 50 from the Cust switches:

sw3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw3(config)#no vlan 10
sw3(config)#no vlan 20
sw3(config)#no vlan 30
sw3(config)#no vlan 50
sw3(config)#end
sw3#
%SYS-5-CONFIG_I: Configured from console by console
wr
Building configuration...
[OK]
sw3#

Two things left to do, check that sw2 also has learned about the removal of VLAN 10, 20, 30 and 50 and check that these VLANs do still exist in the Corp VTP domain:

sw2#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
40   cust1                            active
sw4#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
10   dmz                              active
20   office                           active
30   management                       active
40   cust1                            active
50   cust2                            active

Nice! We now have two seperate VTP domains and we only share VLAN 40 untill such time as we can replace the layer 2 link by a layer 3 link and put a firewall in between. No downtime was caused by the change. The one remaining problem is the syslog messages that show that DTP is complaining about the VTP domain mismatch. The solution is to turn off DTP by hard coding the interface as a trunk and using the “switchport nonegotiate” command on the interfaces that connect to the other VTP domain. As an example we will do this on the link between sw1 and sw3:

sw3#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
sw1          Fas 0/24         153                    3560        Fas 0/24
sw2          Fas 0/1          144                    3560        Fas 0/24
sw3#

sw3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
sw3(config)#interface fastEthernet 0/1
sw3(config-if)#switchport nonegotiate
sw3(config-if)#end
sw3#
%SYS-5-CONFIG_I: Configured from console by console
wr
Building configuration...
[OK]
sw3#

sw3#show interfaces trunk
Port        Mode         Encapsulation  Status        Native vlan
Fa0/1       on           802.1q         trunking      1
Fa0/24      on           802.1q         trunking      1

So the interface is still a trunk and the error messages have stopped. Remember to do this on both sides of the trunk.

I hope this post helps you when you find yourself in a simular situation. I’d like to thank Yasar Ertur for his help with this lab. Also, I must mention a blog that I found while refreshing my mind about turning off DTP, it is this CCIE Pursuit blog that helped me remember the “switchport nonegotiate” command.

Posted in Cisco, Networking | Comments Off on VTP : Moving to another VTP domain

DHCP Snooping

Recently I had to enable DHCP Snooping on the production network in our office. Although DHCP Snooping is a topic in my recent SWITCH studies, I found the documentation a bit less than desirable. It was easy finding an explanation on how to implement this on a single switch, but what if you have lots of switches? How do you configure the trunks? I decided to test this in a lab and write a blog post for future reference.

Here’s the lab I used (click for a larger image):
DHCP_Snooping

I used my laptop as a DHCP client and an ASA 5505 as the DHCP server. For the switches I used some 2950′s that we had lying around. Here is how everything is connected:

  • The ASA is connected to Fa0/24 of SW2
  • The Laptop is connected to Fa0/1 of SW1
  • SW1 and SW2 are connected via a cross cable between their Gi0/1 interfaces

The initial setup is not shown in the drawing. I wanted to test a single switch scenario to make sure a basic setup of DHCP Snooping worked before I stepped it up a notch and implemented the multi switch scenario. So I had the laptop temporary connected to Fa0/1 in SW2. First I setup DHCP Snooping for vlan 1 (normally vlan 1 is not used, but for this test I did not bother to create a vlan and just used the default):

SW2(config)#ip dhcp snooping
SW2(config)#ip dhcp snooping vlan 1

Then Fa0/24 on SW2 was set to be trusted by configuring the following:

SW2(config)#int fa0/24
SW2(config-if)#ip dhcp snooping trust

I did not get an IP address on the laptop. So why did I not get an ip address? Isn’t Fa0/24 trusted?
By using “debug ip dhcp snooping packet” and “debug ip dhcp snooping event” I found this error:

DHCP_SNOOPING_SW: bridlge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)

I did some google searching and it turns out that some clients don’t accept the insertion of dhcp option-82. This behaviour can be turned off by using this command;

SW2(config)#no ip dhcp snooping information option

Then I did get an IP address from the dhcp server, so on to the next step.
First step, basic setup and preventing the insertion of option-82 on SW1, just like we did on SW2:

SW1(config)#ip dhcp snooping

SW1(config)#ip dhcp snooping vlan 1
SW1(config)#no ip dhcp snooping information option

I connected the switches as shown in the drawing and connected my laptop to Fa0/1 on SW1. I did not get an ip address.
After some experimenting I found I needed to set the following on Gi0/1 on SW1, which is the trunk to SW2:

SW1(config-if)#ip dhcp snooping trust

It makes sense since Gi0/1 is the port on which the DHCPOFFER comes into SW1. After configuring “ip dhcp snooping trust” on Gi0/1 the lab was working as intended.

This led me to the conclusion that the ports that need to be set to trust are the port to which the dhcp server is connected and the trunk ports in the switch to which clients are connected. It is not needed to trust the trunk port on the switch to which the dhcp server is connected as the DHCPOFFER goes out of the switch on that port and the trust only needs to be set on interfaces where the DHCPOFFER comes into the switch.

I hope this helps you with the implementation of DHCP Snooping.

Posted in Networking, Systems | Comments Off on DHCP Snooping

Remote desktop to a Windows XP / 2003 machine over IPv6

Just a quick post to share a neat trick.
Some of my older systems still run XP and/or Windows 2003, and I’m probably not alone.
This is an older post that I saved from my old blog, I don’t run these old operating systems anymore but I will leave this post here for those who do and want to use IPv6.

Now the RDP client built-in to Windows XP / Windows 2003 supports IPv6 just fine.
But the built-in RDP server doesn’t listen on the IPv6 addresses.
This also applies to embedded versions of Windows that are often found on machines like cash registers.
I recently worked a case where there was a possible network problem that resulted in a cash register not being able to contact the central server that stores all the prices for the various goods being sold.
The company that manages the cash registers often logs in using remote desktop to check settings and research problems.
When running IPv6 this poses the problem that the RDP server doesn’t listen on the IPv6 addresses.
Here is a quick work around to be able to RDP to your machine over IPv6;

Open a command prompt and enter the following:

netsh interface portproxy add v6tov4 listenport=3389 connectaddress=127.0.0.1 connectport=3389

This basically creates a proxy that listens on the IPv6 addresses of your machine and forwards the requests to the IPv4 loopback address.
After using this command you will be able to connect using a recent version of Remote Desktop Client over IPv6 to a WinXP/Win2k3/WinXP-embedded machine.

Posted in Networking, Systems, Windows | Comments Off on Remote desktop to a Windows XP / 2003 machine over IPv6