03-23-2010 06:52 PM - edited 03-06-2019 10:17 AM
At one of my branch offices I have two methods of connectivity, a P2P L2 metroE, and then our MPLS connection.I'm trying to figure out the best way to implement a routing protocol at this branch office, the problem is that I'm unable to implement a routing protocol on the other end of the P2P and therefore have to advertise it via a static route. The P2P is a 100m connection and the MPLS is only 6m, so I'm trying to route traffic out the P2P when possible and if necessary route traffic out the MPLS network.
The attached image is a rough drawing of the proposed layout. The circle is our edge router, and the two squares are L3 switches. I'm attempting to run HSRP and EIGRP at this location. I guess I'm trying to figure out how to redistribute the one L3's static route to the rest of the devices, and then understand what will happen if that P2P link goes down.
Any help would be greatly appreciated.
03-24-2010 04:12 AM
Robert
Apologies but the description doesn't seem to match the diagram ie. you have 2 connections at a remote site but your diagram is only showing a WAN router with one connection.
Could you perhpas add a bit more detail to the diagram and clarify exactly what you are trying to achieve ?
Jon
03-24-2010 04:35 AM
If you look at the right square (L3 switch) there is a line pointing to a static route. The 100mb MetroE is terminated directly into the SFP slot on that switch. I'm trying to figure out the best way to redistribute the static route on that switch to the other devices. I'm also trying to understand what will happen when we lose that MetroE link if it's a static route.
03-24-2010 05:05 AM
robert.juric wrote:
If you look at the right square (L3 switch) there is a line pointing to a static route. The 100mb MetroE is terminated directly into the SFP slot on that switch. I'm trying to figure out the best way to redistribute the static route on that switch to the other devices. I'm also trying to understand what will happen when we lose that MetroE link if it's a static route.
Ahh, apologies, my mistake.
Well there are a few things to cover
1) you are receiving the route via BGP on your edge router. Are you redistributing that into EIGRP ?
2) the edge router will always think the best path is the MPLS network because EBGP has an AD of 20 whereas EIGRP has AD 90 and 170. Is this is a problem though because does any traffic from your internal LAN go to that router first ?
3) If you do 1) and redistribute into EIGRP and you also redistribute into EIGRP the static route on your L3 switch then you will have 2 routes for the same subnet and the route used will be the one with the lowest metric. From the perspective of the other L3 switch ie. the one not connected to the Metro-E link you need to make sure the preferred route is via the other L3 switch and not the edge router.
4) Because the link from the L3 switch is ethernet you need to check the availability of the remote end of the link because if that fails your L3 switch at this end might still think the link is up.
So i would do this -
1) You need to setup IP SLA on the 4500 L3 switch connected to the Metro ethernet switch
2) If the remote end is responding then you should install a route for 10.10.0.0/16 pointing to the remote end of the Metro Ethernet link.
3) On the same L3 switch you should redistribute the static route for 10.10.0.0/16 into EIGRP so your other L3 switch knows about it
4) Don't redistribute the BGP learned route into EIGRP on the edge router.
5) If the IP SLA fails ie. the next-hop is not available on the Metro-E link then install a static route pointing to the edge router on the L3 switch which again will get redistributed into EIGRP.
The above will ensure all traffic from the remote site uses the Metro-E connection except traffic from the edge router. If that is a problem ie. the edge router then let me know because we can modify the AD of the 10.10.0.0/16 route on the edge router so it prefers the Metro-E connection as well.
Jon
Cisco are currently donating money to the Haiti earthquake appeal for every rating so please consider rating all helpful posts.
03-24-2010 06:01 AM
Apologies if this gets formatted strange, I'm trying to reply via email.
I see now, that makes sense. I'm assuming I could do the same on the other end of the metroE if the topologies are the same or close to it? That should give me true WAN redundancy then for this site.
Are there any other options that still give us redundancy? I'm just asking because my team is starting to get nervous the more complex our setup gets, and I need to learn to put them at ease.
Sent from my BlackBerry
The information in this email and in any attachments is confidential
and may be privileged. If you are not the intended recipient, please
destroy this message, delete any copies held on your systems and notify
the sender immediately. You should not retain, copy, or use this email
for any purpose, and any review or other use of this information by persons
or entities other than the intended recipient or any retransmission without
the written consent of the sender is expressly prohibited.
03-24-2010 06:14 AM
Robert
Understood about the complexity but the key issue is the IP SLA and the nature of ethernet. Because the link could go down at the far end but your end doesn't realise it any solution not using IP SLA could lead to blackholing traffic. And if you have to use IP SLA then the rest of it is quite simple actually.
You could remove the IP SLA, redistribute the same route ie. 10.10.0.0/16 from the edge router and the L3 switch and use offset-lists in EIGRP to make sure the Metro-E is used but you don't protect against a far end failure.
If you don't have the spare equipment to set this up you could look at dynamips on a PC with a lot of memory and CPU horsepower and configure IP SLA for your team to get familiar with. IP SLA is one of those things that looks quite complex from the docs but makes a whole lot more sense when you see it in action.
Jon
03-24-2010 06:44 AM
I'll do some research on the IP SLA.
If we were running a dynamic routing protocol on both ends we could use that to monitor far end reachability and wouldn't need to rely on IP SLA.
Robert
Sent from my BlackBerry
The information in this email and in any attachments is confidential
and may be privileged. If you are not the intended recipient, please
destroy this message, delete any copies held on your systems and notify
the sender immediately. You should not retain, copy, or use this email
for any purpose, and any review or other use of this information by persons
or entities other than the intended recipient or any retransmission without
the written consent of the sender is expressly prohibited.
03-24-2010 10:07 AM
Robert
If we were running a dynamic routing protocol on both ends we could use that to monitor far end reachability and wouldn't need to rely on IP SLA.
Correct.
Jon
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: