In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!
L2 to EIGRP slow migration?
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
Asked:
-
13
10-
4
7 Solutions
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.
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.
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?
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.
:)
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?
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.
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
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
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).
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?
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.
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
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
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.
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
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?
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
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
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.
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
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
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
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