Plesk's WordPress Toolkit allows server administrators, resellers and customers to manage their WordPress instances, enabling a variety of development workflows for WordPress admins of all skill levels, from beginners to pros.
See why 2/3 of Plesk servers use it.
Solved
L2 to EIGRP slow migration?
Posted on 2016-11-01
I have a network of 6 nodes connected via fiber. It is currently a layer2 network. The core switch is doing intervlan routing. To access the Internet, all sites have to go through the core before accessing the Internet via sw2 (see diagram). The STP root is at the core.
What I am trying to do is to figure out if I can slowly enable routed ports and enable EIGRP, two sites per day as they are far apart (~400 miles) from each other. It is quite risky to do it all remotely.
For the test, I enabled EIGRP between sw4 and sw5. I was able to ping the FW from sw4 and sw5. However, when I disabled fa0/2 on sw4, I lost the connection. It looks like there is only one way traffic (which is to go to the core and to the FW) and that will make my production network vulnerable to downtime. If the link between sw4 & core fails, users attached to sw4 cannot access the Internet or any servers attached to sw3.
Any thoughts? Thanks
What I am trying to do is to figure out if I can slowly enable routed ports and enable EIGRP, two sites per day as they are far apart (~400 miles) from each other. It is quite risky to do it all remotely.
For the test, I enabled EIGRP between sw4 and sw5. I was able to ping the FW from sw4 and sw5. However, when I disabled fa0/2 on sw4, I lost the connection. It looks like there is only one way traffic (which is to go to the core and to the FW) and that will make my production network vulnerable to downtime. If the link between sw4 & core fails, users attached to sw4 cannot access the Internet or any servers attached to sw3.
Any thoughts? Thanks
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
13
10-
4
27 Comments
Hi leblanc,
I suggest you overlay your existing connectivity, ie introduce another vlan on each of your trunk ports. Use different vlan number on all switch interlinks (keep them point to point only). Configure layer 3 SVIs and enable eigrp routing across those new interlinks.
That way you can maintain your existing topology intact until you are ready to slowly cutover to layer 3 (at this stage you should have layer 3 links everywhere).
Once you get to the stage where layer 2 is no longer needed start removing obsolete vlans. At the final stage reconfigure all trunks as routed ports reusing earlier created interlinks
I suggest you overlay your existing connectivity, ie introduce another vlan on each of your trunk ports. Use different vlan number on all switch interlinks (keep them point to point only). Configure layer 3 SVIs and enable eigrp routing across those new interlinks.
That way you can maintain your existing topology intact until you are ready to slowly cutover to layer 3 (at this stage you should have layer 3 links everywhere).
Once you get to the stage where layer 2 is no longer needed start removing obsolete vlans. At the final stage reconfigure all trunks as routed ports reusing earlier created interlinks
Active 2 days ago
Hi S C,
"introduce another vlan on each of your trunk ports", can you elaborate on this? Thx
"introduce another vlan on each of your trunk ports", can you elaborate on this? Thx
For the interlink between sw4 and sw5 create a new vlan, let's say VL201 and add to the trunk only there. Create SVI on either end. Configuration for the first interlink may look like this:
SW4
Vlan201
Int fa0/1
Switchport trunk allowed vlan add 201
Interface vlan 201
Ip address 10.200.200.1 255.255.255.252
no shut
Router eigrp 2
eigrp router-id x.x.x.x
Passive-interface default
No passive-interface vlan 201
Network 10.200.200.0 0.0.0.255
No auto-summary
SW5
Vlan201
Int fa0/1
Switchport trunk allow vlan add 201
Interface vlan 201
Ip address 10.200.200.2 255.255.255.252
no shut
Router eigrp 2
eigrp router-id x.x.x.x
Passive-interface default
No passive-interface vlan 201
Network 10.200.200.0 0.0.0.255
No auto-summary
Repeat on all interlinks using different vlans and subnets.
SW4
Vlan201
Int fa0/1
Switchport trunk allowed vlan add 201
Interface vlan 201
Ip address 10.200.200.1 255.255.255.252
no shut
Router eigrp 2
eigrp router-id x.x.x.x
Passive-interface default
No passive-interface vlan 201
Network 10.200.200.0 0.0.0.255
No auto-summary
SW5
Vlan201
Int fa0/1
Switchport trunk allow vlan add 201
Interface vlan 201
Ip address 10.200.200.2 255.255.255.252
no shut
Router eigrp 2
eigrp router-id x.x.x.x
Passive-interface default
No passive-interface vlan 201
Network 10.200.200.0 0.0.0.255
No auto-summary
Repeat on all interlinks using different vlans and subnets.
Active today
This is good suggestion as the first step in transition.
Int fa0/1
switchport trunk allow vlan add 201
switchport trunk native vlan 201
And when other VLANs are not needed (core design is moved from L2 to L3 topology):
Int fa0/1
switchport trunk allow vlan 201
This way, end result would be trunks everywhere, but only native VLAN would be allowed on trunks.
So, it would be equivalent of L3 links. Gain here would be - if VRFs are needed (or temporary VLAN between two location for whatever the reason) you can always add VLAN and use it for VRF on existing trunks with no downtime at all.
At the final stage reconfigure all trunks as routed ports reusing earlier created interlinksHowever, I would not do this. I would leave it as a trunk everywhere and the reason would be a little bit different design:
Int fa0/1
switchport trunk allow vlan add 201
switchport trunk native vlan 201
And when other VLANs are not needed (core design is moved from L2 to L3 topology):
Int fa0/1
switchport trunk allow vlan 201
This way, end result would be trunks everywhere, but only native VLAN would be allowed on trunks.
So, it would be equivalent of L3 links. Gain here would be - if VRFs are needed (or temporary VLAN between two location for whatever the reason) you can always add VLAN and use it for VRF on existing trunks with no downtime at all.
Active 2 days ago
S C
ok so instead of having a routed port now, I will create a SVI 201 (for example) with /30 on sw4 and sw5. I will allow that VLAN 201 on my exiting trunk. So that way I have EIGRP routing as well as the existing layer 2 traffic.
Predrag
So as your next step suggestion, leave the trunk along and prune all VLANs, except vlan 201 from the trunk. Correct?
ok so instead of having a routed port now, I will create a SVI 201 (for example) with /30 on sw4 and sw5. I will allow that VLAN 201 on my exiting trunk. So that way I have EIGRP routing as well as the existing layer 2 traffic.
Predrag
So as your next step suggestion, leave the trunk along and prune all VLANs, except vlan 201 from the trunk. Correct?
Active today
Int fa0/1Will do exactly that - allow only VLAN 201 on trunk.
switchport trunk allow vlan 201
You have a lot of work until that point of network redesign is reached.
For example: configure IP addresses per each location and use new default gateway on location (on distribution or core device). Choose IP addresses carefully so you can easily summarize IP address range for each location.
:)
Active 2 days ago
I will try that. You guys got some really good tips.Thx
Also, it is ok to use 10.200.200.x/30 for all the interlinks. Correct?
Also, it is ok to use 10.200.200.x/30 for all the interlinks. Correct?
Active today
Also, current Core device is the only one that can keep original IP address scheme, but also think about changing them to IP address range that can easily be summarized.
Active 2 days ago
So for each interlink, I have to pick a different vlan. In other words, if I have vlan201 betweeen sw4 and sw5, then I will have vlan202 between sw5 and sw1. Correct?
Watch out on below command, it prunes all your other vlans from the trunk! You don't want this done immediately as it would breaks your existing connectivity (add keyword is very important).
Int fa0/1
  switchport trunk allow vlan 201
Int fa0/1
  switchport trunk allow vlan 201
Active 2 days ago
Yes. I did that command after I configured the network 10.0.0.0 0.255.255.255 in eigrp process for all switches. Thx
Active today
It is not over yet, fun starts here - not to break the network down (my favorite). :)
Configure loopback on every device and advertise it to into EIGRP (not mandatory, but highly recommended).
Core should advertise all networks into EIGRP.
Next steps will temporary break internet in any scenario and should be done either from locations, or issued from the flash (script it).
- static default route from core should be removed
- link between SW2 and FW becomes point-to-point
- SW2 advertise default route into EIGRP
(order of operations can be changed and actual scenario can vary, carefully plan this part it can cut you off of the network)
On SW2 and Core issue reload in X (at least 20) before starting with any of this (the only protection that you really have since you can't be in SW and Core location at once (or maybe you can?)), and have fun. :)
When this is done EIGRP basic package is over - locations are ready to be moved to new IP address ranges (and next part starts with DHCP team).
Configure loopback on every device and advertise it to into EIGRP (not mandatory, but highly recommended).
Core should advertise all networks into EIGRP.
Next steps will temporary break internet in any scenario and should be done either from locations, or issued from the flash (script it).
- static default route from core should be removed
- link between SW2 and FW becomes point-to-point
- SW2 advertise default route into EIGRP
(order of operations can be changed and actual scenario can vary, carefully plan this part it can cut you off of the network)
On SW2 and Core issue reload in X (at least 20) before starting with any of this (the only protection that you really have since you can't be in SW and Core location at once (or maybe you can?)), and have fun. :)
When this is done EIGRP basic package is over - locations are ready to be moved to new IP address ranges (and next part starts with DHCP team).
Active 2 days ago
I am physically at the core. I can telnet to sw4 and perform the change. I did this in Packet Tracer and there was no disconnect.
I prefer not to make all the changes in one day. So can I just start enable eigrp routing between sw4 and sw5 and let it run for a few days then move to sw5 and sw1 and so on. I will make the core and sw2 last. If I do it that way, I will initiate the network 10.0.0.0 command in eigrp. Will that work?
I prefer not to make all the changes in one day. So can I just start enable eigrp routing between sw4 and sw5 and let it run for a few days then move to sw5 and sw1 and so on. I will make the core and sw2 last. If I do it that way, I will initiate the network 10.0.0.0 command in eigrp. Will that work?
Active today
Yes, it will work (you will not really use EIGRP at all in the first days). :)
If you advertise default route into EIGRP prior to remove static route from Core it will replace default route fast, however you still need to change link between SW2 and FW.
I don't know full topology and all details. With knowing all details maybe downtime can be avoided completely , however it is very unlikely, but it may be possible. If you have two different exit points to internet (on different location) for sure it can be done without downtime.
If you advertise default route into EIGRP prior to remove static route from Core it will replace default route fast, however you still need to change link between SW2 and FW.
I don't know full topology and all details. With knowing all details maybe downtime can be avoided completely , however it is very unlikely, but it may be possible. If you have two different exit points to internet (on different location) for sure it can be done without downtime.
Active 2 days ago
Currently everything is at layer 2 with the DG to the core.
Yes. sw2 and the fw will need to be a pt-to-pt. I can afford downtime to the Internet during the change. Thx
Yes. sw2 and the fw will need to be a pt-to-pt. I can afford downtime to the Internet during the change. Thx
Active 2 days ago
I think the pt to pt interlink cannot be a trunk as I cannot use ip helper-address for DHCP on the trunk. Any work around? Thx
Active today
Currently you have interVLAN routing on Core switch. After redesign you should have interface VLAN for every VLAN on every location (you can keep the same VLAN numbers and names with new IP addresses). L2 ends on distribution or core device. All VLANs are terminated locally. On each interface VLAN that needs DHCP you will configure ip helper address.
On interlink between SW2 and FW you can use L3 link or trunk, whatever you prefer.
On interlink between SW2 and FW you can use L3 link or trunk, whatever you prefer.
Active 2 days ago
That's right. Why didn't I think of that?
I will remove the SVI 40 from the core and add ip helper-address in svi 40 on sw4. Thx
I will remove the SVI 40 from the core and add ip helper-address in svi 40 on sw4. Thx
Active 2 days ago
I have the following situation:
- When I configured the pt-to-pt vlan with 10.200.200.0/30 between core and sw4, I was able to ping 10.10.100.254 from sw4.
- When I configured the pt-to-pt vlan with 172.16.250.0/30 between core and sw4, I was not able to ping 10.10.100.254 from sw4. I see that there is a route to the core as the last resort but I am not sure why I could not ping 10.10.100.254? Any thoughts?
- When I configured the pt-to-pt vlan with 10.200.200.0/30 between core and sw4, I was able to ping 10.10.100.254 from sw4.
- When I configured the pt-to-pt vlan with 172.16.250.0/30 between core and sw4, I was not able to ping 10.10.100.254 from sw4. I see that there is a route to the core as the last resort but I am not sure why I could not ping 10.10.100.254? Any thoughts?
Is the 172.16.x.x network in the routing table from 10.10.100.254 perspective. Check th source ip of the ping packet from SW4?
Based on your earlier message you've added to eigrp 10.x.x.x only. Why 172.x.x.x now? Have you tried adding network statement for that new range?
Based on your earlier message you've added to eigrp 10.x.x.x only. Why 172.x.x.x now? Have you tried adding network statement for that new range?
Active 2 days ago
Arrgg... I forgot a static route 172.16.0.0/16 from my fw pointed back to the internal network. Good catch S C. Thx
Active 2 days ago
I created the interlinks /30 pt-to-pt for all sites without downtime.
I consoled in sw2 and redistribute my default route 10.10.100.254 into eigrp.
I removed all the default routes from all other switches. They now see sw2 as the way to get to the fw.
I had a continuous ping from core to 10.10.100.254 and on sw2, I configured the trunk to allow only vlan254 between sw2 and sw3. My pings from the core then failed. I am still troubleshooting the issue but any thoughts will be appreciated. Thx
I consoled in sw2 and redistribute my default route 10.10.100.254 into eigrp.
I removed all the default routes from all other switches. They now see sw2 as the way to get to the fw.
I had a continuous ping from core to 10.10.100.254 and on sw2, I configured the trunk to allow only vlan254 between sw2 and sw3. My pings from the core then failed. I am still troubleshooting the issue but any thoughts will be appreciated. Thx
Active today
And now we are having fun (and reason for downtime). :)
- Remove vlan 100 from core (core it trying to resolve 10.10.100.254 by broadcast and can't resolve it since VLAN 100 is broken. For core it is directly connected network - 10.10.100.0/24).
- On SW2 add vlan 100 (if removed) and interface VLAN 100 with IP address 10.10.100.253 (maybe change subnet mask on both devices to /30?)
- Then you need to advertise default route from SW2 (and, of course, have default route (or network) on SW2)
Don't know how you advertise default route currently, but if you configured core to advertise default route - that need to be removed.
That's part of link become p-t-p between SW2 and FW. Network with the same/overlapping IP address range must be removed from CORE, or link between FW and SW2 must be placed in a new subnet to be reachable from core. Rule - you can't have discontiguous networks. You can have the same VLAN names and numbers everywhere (it is locally significant information) as long as IP address ranges are unique.
I configured the trunk to allow only vlan254 between sw2 and sw3You removed VLAN 100 from link, and fw is in located in vlan 100. There are several ways to resolve this, for example:
- Remove vlan 100 from core (core it trying to resolve 10.10.100.254 by broadcast and can't resolve it since VLAN 100 is broken. For core it is directly connected network - 10.10.100.0/24).
- On SW2 add vlan 100 (if removed) and interface VLAN 100 with IP address 10.10.100.253 (maybe change subnet mask on both devices to /30?)
- Then you need to advertise default route from SW2 (and, of course, have default route (or network) on SW2)
Don't know how you advertise default route currently, but if you configured core to advertise default route - that need to be removed.
That's part of link become p-t-p between SW2 and FW. Network with the same/overlapping IP address range must be removed from CORE, or link between FW and SW2 must be placed in a new subnet to be reachable from core. Rule - you can't have discontiguous networks. You can have the same VLAN names and numbers everywhere (it is locally significant information) as long as IP address ranges are unique.
Active 2 days ago
It seems to be working. I redistributed the default static route to EIGRP from sw2 and removed all the static route from other switches. I also pruned other VLANs and only the pt-to-pt VLANs are allowed on the trunk. I did all of that from the telnet from the core.
Now, I checked my EIGRP (sh ip eigrp topology) and I was expecting 2 routes for each interface. But only a couple of them has it. Each of the other routes have 1 successor. Does it sound right? Thx
Now, I checked my EIGRP (sh ip eigrp topology) and I was expecting 2 routes for each interface. But only a couple of them has it. Each of the other routes have 1 successor. Does it sound right? Thx
Active today
That is expected behavior. Only the best route is placed into routing table and by default only equal cost routes are placed in routing table. If you want you want you can change variance to have more routes placed in routing table. By default variance is 1 and that means that only best routes with equal cost paths will be placed in routing table. If you change variance to be higher there should be few more routes placed in routing table. Think about shape of network - it is a circle, by default only networks from the opposite side of circle (depending on number of nodes) have a chance to have two routes with equal cost and those will be in that case placed in routing table. You can change variance and more routes will be placed in routing and topology table. EIGRP is the only protocol that can do unequal cost path load balancing.
router eigrp x
variance 4
router eigrp x
variance 4
Featured Post
Hear ATEN Product Manager YT Liang review HDBaseT technology, highlighting ATEN’s latest solutions as they relate to real-world applications during her presentation at the HDBaseT booth at InfoComm 2017.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I had an issue with InstallShield not being able to use Computer Browser service on Windows Server 2012. Here is the solution I found.
This article is a collection of issues that people face from time to time and possible solutions to those issues. I hope you enjoy reading it.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Suggested Courses
Course of the Month10 days, 4 hours left to enroll
722 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.