Remapping VLANs for a migration from one VLAN scheme to another
TWX
Member Posts: 275 ■■■□□□□□□□
in CCNA & CCENT
Figured I'd share this- I've got some sites that I'm migrating from one VLAN scheme to another without changing the User IP scheme during an equipment swap. Unfortunately many of my IDFs are not hanging directly off of the MDF, and with 20+ IDFs to swap, I was looking for a solution that would allow for the least amount of equipment reconfiguration possible, and without creating more than an intermittent outage while the switches themselves are replaced. This requires two VLANs to operate as one Broadcast Domain, and requires both VLANs to function across 802.1q trunks. It also requires some method to rewrite the old VLAN tag with the new VLAN tag.
The sites in question use the ME3600X as the distribution device and WAN router. Let's call the old VLAN scheme VLAN 1 for management, VLAN 500 for all users. Let's assume that the new scheme uses VLAN 200 for management and VLAN 10 for users, with new VLANs for future use for VOIP on 5, SCADA on 15, and security on 20.
To start, the feature on the ME3600X is called Ethernet Virtual Connection.
The old configuration for an interface on both the ME3600X and on the 2960S access switch would look something like the following:
Obviously only these two particular VLANs are allowed on the trunk. The end goal, once the migration is completed, would look more like the following:
The trouble is, with 20+ closets to physically change equipment in, there may be points when half of the site is on the old configuration and half is on the new configuration, and if one doesn't turn VLANs 500 and 10 into a single broadcast domain then one or the other portions will have no service.
First, establish the new VLAN scheme on the distribution device. Create all of the requisite VLANs, and create all of the SVIs (interface VLAN #), but for the moment skipping the IP configuration on the new USER vlan SVI. You'll end up with something like the following:
Now, we need to reprogram the physical interfaces, to separate the actual Ethernet 802.1q tags from how the switch process virtual LANs. To do this we need to change the way that the ME3600X physical interfaces work and to put them into an EVC mode. A downside, this has to be done per-interface, it cannot be done with an interface-range. Additionally I have not yet had an opportunity to experiment with it on etherchannel interfaces either, so you'll need to your own research. Anyway, first change the allowed VLANs on the trunk:
I found that "l2protocol peer" was required, and that functions as fundamental as CDP failed without it.
Now, create instances for each of the other new-scheme VLANs:
Now, create one for the legacy VLAN, but change the bridge-domain to match the new VLAN:
Notice no entry for VLAN 500, as dot1q tags marked 500 are associated with bridge-domain 10.
When you get down to the section of the running-configuration related to the physical interface that you've configured it should look as follows:
Repeat these physical interface reconfigurations on all of your campus-facing (ie, not WAN or L3 or service-entrance-facing) ports. As you do, users on VLAN 500 will stop working.
Next, down the legacy interface VLAN 500 and no-IP it to free its address, and apply that address to interface Vlan 10:
You should see your MAC and ARP tables start to fill. Note the new information in the MAC table:
That "Efp" number corresponds to the changes that we've made, note how Efp500 is associated with VLAN 10.
The ARP table entries reflect the VLANs as well, not the remapping as the packets pass through the physical interface:
Pinging should work perfectly across the two VLANs on the same broadcast domain as well.
When you're done, you can default-interface the ME3600X's interfaces and configure them as normal VLAN trunks and everything should be happy.
Just an FYI, I'm no expert at this, and I did not find any specific tutorial on how to do this anywhere, so I took the bits and pieces that I found that used this for different purposes (mostly to use a service provider's required VLAN when one's internal scheme was different) to apply it to my unique situation. I would be happy to hear any information from people more capable than I am that go into depth on this subject and any particulars that I've missed.
The sites in question use the ME3600X as the distribution device and WAN router. Let's call the old VLAN scheme VLAN 1 for management, VLAN 500 for all users. Let's assume that the new scheme uses VLAN 200 for management and VLAN 10 for users, with new VLANs for future use for VOIP on 5, SCADA on 15, and security on 20.
To start, the feature on the ME3600X is called Ethernet Virtual Connection.
The old configuration for an interface on both the ME3600X and on the 2960S access switch would look something like the following:
interface GigabitEthernet 0/1 switchport trunk allowed vlan 1,500 switchport mode trunk !
Obviously only these two particular VLANs are allowed on the trunk. The end goal, once the migration is completed, would look more like the following:
interface GigabitEthernet 0/1 switchport trunk allowed vlan 5,10,15,20,200 switchport mode trunk !
The trouble is, with 20+ closets to physically change equipment in, there may be points when half of the site is on the old configuration and half is on the new configuration, and if one doesn't turn VLANs 500 and 10 into a single broadcast domain then one or the other portions will have no service.
First, establish the new VLAN scheme on the distribution device. Create all of the requisite VLANs, and create all of the SVIs (interface VLAN #), but for the moment skipping the IP configuration on the new USER vlan SVI. You'll end up with something like the following:
! (VLAN 1 implied) vlan 5 name VOIP ! vlan 10 name USER ! vlan 15 name SCADA ! vlan 20 name SECURITY ! vlan 200 name MGMT ! vlan 500 name LEGACY ! ! ** SKIP THE PHYSICAL INTERFACES ** interface Vlan1 description legacy-mgmt ip address 10.8.139.1 255.255.255.0 ! interface Vlan 5 description VOIP ip address 10.200.5.1 255.255.255.0 ! interface Vlan 10 description USER ! interface Vlan 15 description SCADA ip address 10.200.15.1 255.255.255.0 ! interface Vlan 20 description SECURITY ip address 10.200.20.1 255.255.255.0 ! interface Vlan 200 description MGMT ip address 10.200.200.1 255.255.255.0 ! interface Vlan 500 description LEGACY-USER ip address 10.200.10.1 255.255.252.0 !
Now, we need to reprogram the physical interfaces, to separate the actual Ethernet 802.1q tags from how the switch process virtual LANs. To do this we need to change the way that the ME3600X physical interfaces work and to put them into an EVC mode. A downside, this has to be done per-interface, it cannot be done with an interface-range. Additionally I have not yet had an opportunity to experiment with it on etherchannel interfaces either, so you'll need to your own research. Anyway, first change the allowed VLANs on the trunk:
ME3600X(config-if)#switchport trunk allowed vlan nonethen start manually defining service instances; we'll start with VLAN 1 because as the native VLAN it's special and has to be handled uniquely compared to the rest. Note, we're NOT remapping VLAN 1 to the new management VLAN, we're going to assume that the old switches are on a legacy IP scheme for the switch management and we don't need to have that IP scheme correspond with the new configuration. The configuration is as follows:
ME3600X(config-if)#service instance 1 ethernet ME3600X(config-if-srv)#encapsulation untagged ME3600X(config-if-srv)#l2protocol peer ME3600X(config-if-srv)#bridge-domain 1 ME3600X(config-if-srv)#
I found that "l2protocol peer" was required, and that functions as fundamental as CDP failed without it.
Now, create instances for each of the other new-scheme VLANs:
ME3600X(config-if-srv)#service instance 5 ethernet ME3600X(config-if-srv)#encapsulation dot1q 5 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 5 ME3600X(config-if-srv)# ME3600X(config-if-srv)#service instance 10 ethernet ME3600X(config-if-srv)#encapsulation dot1q 10 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 10 ME3600X(config-if-srv)# ME3600X(config-if-srv)#service instance 15 ethernet ME3600X(config-if-srv)#encapsulation dot1q 15 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 15 ME3600X(config-if-srv)# ME3600X(config-if-srv)#service instance 20 ethernet ME3600X(config-if-srv)#encapsulation dot1q 20 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 20 ME3600X(config-if-srv)# ME3600X(config-if-srv)#service instance 200 ethernet ME3600X(config-if-srv)#encapsulation dot1q 200 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 200 ME3600X(config-if-srv)#
Now, create one for the legacy VLAN, but change the bridge-domain to match the new VLAN:
ME3600X(config-if-srv)#service instance 500 ethernet ME3600X(config-if-srv)#encapsulation dot1q 500 ME3600X(config-if-srv)#rewrite ingress tag pop 1 symmetric ME3600X(config-if-srv)#bridge-domain 10 ME3600X(config-if-srv)#Now, when you show running-config you'll see some new entries high in the configuration:
bridge-domain 1 bridge-domain 5 bridge-domain 10 bridge-domain 15 bridge-domain 20 bridge-domain 200
Notice no entry for VLAN 500, as dot1q tags marked 500 are associated with bridge-domain 10.
When you get down to the section of the running-configuration related to the physical interface that you've configured it should look as follows:
interface GigabitEthernet0/24 switchport trunk allowed vlan none switchport mode trunk service instance 1 ethernet encapsulation untagged l2protocol peer bridge-domain 1 ! service instance 5 ethernet encapsulation dot1q 5 rewrite ingress tag pop 1 symmetric bridge-domain 5 ! service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 10 ! service instance 15 ethernet encapsulation dot1q 15 rewrite ingress tag pop 1 symmetric bridge-domain 15 ! service instance 20 ethernet encapsulation dot1q 20 rewrite ingress tag pop 1 symmetric bridge-domain 20 ! service instance 200 ethernet encapsulation dot1q 200 rewrite ingress tag pop 1 symmetric bridge-domain 200 ! service instance 500 ethernet encapsulation dot1q 500 rewrite ingress tag pop 1 symmetric bridge-domain 10 !
Repeat these physical interface reconfigurations on all of your campus-facing (ie, not WAN or L3 or service-entrance-facing) ports. As you do, users on VLAN 500 will stop working.
Next, down the legacy interface VLAN 500 and no-IP it to free its address, and apply that address to interface Vlan 10:
ME3600X(config-if-srv)#exit ME3600X(config-if)#exit ME3600X(config)#interface Vlan 500 ME3600X(config-if)#no ip address ME3600X(config-if)#shutdown ME3600X(config-if)#exit ME3600X(config)#interface Vlan 10 ME3600X(config-if)#ip address 10.200.10.1 255.255.252.0 ME3600X(config-if)#no shutdown ME3600X(config-if)#exit ME3600X(config)#
You should see your MAC and ARP tables start to fill. Note the new information in the MAC table:
ME3600X#sh mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 1833.9d02.840a DYNAMIC Gi0/24+Efp1
1 1833.9d02.8440 DYNAMIC Gi0/24+Efp1
1 8890.8d8c.668a DYNAMIC Gi0/1+Efp1
5 8890.8d8c.668a DYNAMIC Gi0/1+Efp5
10 1833.9d02.8441 DYNAMIC Gi0/24+Efp500
10 204c.9e7e.2c88 DYNAMIC Gi0/24+Efp500
10 204c.9e7e.2cc2 DYNAMIC Gi0/24+Efp500
10 8890.8d8c.6288 DYNAMIC Gi0/1+Efp10
10 8890.8d8c.62c2 DYNAMIC Gi0/1+Efp10
10 8890.8d8c.668a DYNAMIC Gi0/1+Efp10
15 8890.8d8c.668a DYNAMIC Gi0/1+Efp15
20 8890.8d8c.668a DYNAMIC Gi0/1+Efp20
200 8890.8d8c.668a DYNAMIC Gi0/1+Efp200
Total Mac Addresses for this criterion: 13
ME3600X#
That "Efp" number corresponds to the changes that we've made, note how Efp500 is associated with VLAN 10.
The ARP table entries reflect the VLANs as well, not the remapping as the packets pass through the physical interface:
ME3600X#sh arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.8.139.1 - 0c68.03c6.8b40 ARPA Vlan1 Internet 10.8.139.10 3 1833.9d02.8440 ARPA Vlan1 Internet 10.200.5.1 - 0c68.03c6.8b40 ARPA Vlan5 Internet 10.200.10.1 - 0c68.03c6.8b40 ARPA Vlan10 Internet 10.200.10.10 28 204c.9e7e.2cc2 ARPA Vlan10 Internet 10.200.10.30 241 8890.8d8c.62c2 ARPA Vlan10 Internet 10.200.10.100 97 1833.9d02.8441 ARPA Vlan10 Internet 10.200.15.1 - 0c68.03c6.8b40 ARPA Vlan15 Internet 10.200.20.1 - 0c68.03c6.8b40 ARPA Vlan20 Internet 10.200.200.1 - 0c68.03c6.8b40 ARPA Vlan200 Internet 10.200.200.200 174 8890.8d8c.66c1 ARPA Vlan200 ME3600X#
Pinging should work perfectly across the two VLANs on the same broadcast domain as well.
When you're done, you can default-interface the ME3600X's interfaces and configure them as normal VLAN trunks and everything should be happy.
Just an FYI, I'm no expert at this, and I did not find any specific tutorial on how to do this anywhere, so I took the bits and pieces that I found that used this for different purposes (mostly to use a service provider's required VLAN when one's internal scheme was different) to apply it to my unique situation. I would be happy to hear any information from people more capable than I am that go into depth on this subject and any particulars that I've missed.
Comments
-
volfkhat
Member Posts: 1,072 ■■■■■■■■□□
I was able to follow up until:
service instance,
encapsulation untagged,
l2protocol peer,
bridge-domain.
lol
I hope this stuff is covered in the ccnp curriculum :] -
TWX
Member Posts: 275 ■■■□□□□□□□
Keep in mind that I'm only learning about this stuff now, and when I asked a CCIE consultant about EVCs even they had never used them...
As I understand it, the combination of "switchport trunk allowed vlan none" and "service instance # ethernet" change how frames from the physical port are handled. On the VLANs other than the native VLAN, as the frames are received for a given 802.1q tag, the switch changes that tag and assigns it to the bridge-domain associated with the VLAN that the network engineer wants to use. When the desire is to have the same VLAN handle traffic as the incoming 802.1q tag, the rewrite pops the tag and then assigning to the bridge-domain replaces it with the same as they have the same value, but when one wants the frame from one VLAN to be part of another VLAN at Layer 2, the rewrite strips the tag, and the different bridge-domain statement causes that alternate VLAN to be used.
On the native VLAN, since the frame has no tag, "encapsulation untagged" matches frames without 802.1q tags.
I'm thinking of this as an additional layer of abstraction between the hardware/protocol at the interface, and how the switch processes VLAN information.