I have an issue I would like to resolve, so I thought I would throw it out to the forum... I used to have a Point-to-Point dedicated T-1 between my facilities. The subnet was the same and as EIGRP learned it was a neighbor and all routes were advertised as local routes in the routing table. I recently removed this T-1 and upgraded to a MPLS service (T-1 hand off) and both ends are now separate subnets. However now my routes are being seen as External on the routing table and now I see that the remote end does not show up as a neighbor in EIGRP. I do not want this to happen. It is causing havoc to my backup links when they come active and restore back to normal. Routes prefere my backup to the primary link because when the backup comes up it is a point-to-point link and is learned as a local neighbor. When the primary is restored the routes do not want to bounce back to the MPLS because again it is external and the remote end is not a neighbor. Is there a way to make the MPLS path show up as local route and have the remote end show up as its neighbor via the MPLS??? Thanks in advance for any assistance..
So there are two basic types of mpls services, Layer 3 services, where your router, CE, peers with the providers routers, PE, at boths ends and the provider creates a mpls L3 vpn across their network. The other solution is where the provider creates a layer 2 vpn and you do not see the PE at all, you just have a p2p link with your CE routers on both ends.
So it sounds like you might have L3 solution. Are you neighboring with a router on the new T1? Is the eigrp AS number the same on both your routers?
Yes. To explain further, The MPLS is a layer 3 and the EIGRP AS are the same on both remote ends. However the remote ends are not neighbors to each other over the MPLS. Only when my backup T-1 comes up do the routes move onto it for it is a point to point T-1 so the endpoint IPs are in the same subnet so the EIGRP neighbors up to each other on the backup T-1. When the primary MPLS comes back up the routes prefer to stay on the P-To-P T-1 backup. I have to force them off it onto the MPLS. I see that routes learned via the MPLS are External EIGRP and routes learned via the P-to-P are local. Again I'm looking for a solution to apply that will make the MPLS route more attractive over the P-to-P T-1....
We faced a similiar issue with AD 90 vs AD 170 routes.
One possible solution is to make the interfaces on each router between your p-to-p T-1 link passive under EIGRP so they do not exchange EIGRP routes. But only the interfaces that actually connect to the T-1.
On each router on either end of the p-to-p link use static routes for the remote site with an AD higher than 170 eg 200. You will also need to redistribute these statics into EIGRP within the local site.
So under normal MPLS operation the AD 170 EIGRP routes will be used. If the MPLS link fails the EIGRP routes with the AD of 200 will be used. Once the MPLS is restored the routes with AD 170 should then be used.
Hi - appreciate if you can elaborate on (or example) the passive interface option to tackle this issue. Basically,is the suggestion to only include the /30 subnet which is part of the P2P link in EIGRP and set passive to the other interfaces for both the routers.
In our case, the one end is a remote site and other end is a HUB. So, just being extra cautious on the HUB
The question is "why are the routes through the provider mpls network showing up as external?". If the provider is using BGP L3 VPN's and the AS number for EIGRP is the same on both sides, then the routes should show up as internal eigrp routes. If the provider is not using BGP between his PE routers, for instance if he was using VRF lite to connect your two sites and if they were doing extra redistribution, then they could show up as external routes. The problem lies in how the provider is exchanging your routes across its backbone and the best solution would be to get them to correct their configuration. A less desirable solution could be to force your end routers to become eigrp neighbors by connecting them via a tunnel through the mpls interface. Then all you have to do is keep the cost lower then your backup link and you'll keep using the mpls link. Downfalls are a static route to prevent the recurse routing from dropping the tunnel and also inefficient use of bandwidth, mtu issues and the like.
I would find out from the provider why your routes are not showing up as internal because by default, with a bgp based l3 vpn, if the as number are the same on both ends, then the as number is sent via a bgp extended community with the routing info, and the routes should show up as internal. If that info is missing, then they will be external.
i think the routes are being seen as EIGRP external because the CE and PE are using BGP to exchange routes. Once these BGP routes are received from the PE to a CE the CE then has to redistribute these into EIGRP which will then make them AD 170.
Thanks to Jon and Bob for their input on this matter. I agree with both of you. The carrier is a layer 3 and they are using BGP and my routes are redistributed into their MPLS network. The quick way arounf this would be to make my backup passive and float static route the links. But I would like to resolve this correctly. I will investigate with the carrier to see what they can do for me. I was wondering if their is an command under my ROUTER EIGRP that can advertise the MPLS as a local route or define my neighbor across the link and force the EIGRP to neighborup with the remote end??? I was looking at the DEFAULT INFORMATION IN (or OUT) command, but not sure this will solve my issue. Can a Distribute list possibly solve this?
The MPLS provider could have mis configured their MP-BGP. There should be no problem if they implemented the AS override, an extended BGP attribute that connects two remote sites as if they are in the same AS even though there has been " another AS" in the MPLS cloud. Virtually, your 2 sites are in the same AS and should not see routes as external routes.
You may contact your MPLS provider and you should not do any changes on your side.
Hi, another option is, instead of using IP VPN, you may rather use VPLS, if this is supported by your MPLS provider. This is a Layer 2 VPN solution in MPLS.
I don't think the problem is with the allowas-in BGP configuration. The problem is that the 2 sites are exchanging routes over the MPLS cloud using BGP. These BGPP routes then need to be redistributed into the EIGRP routing protocol within each site which automatically makes them AD 170.
You could change the AD distance of redistributed EIGRP routes if you want which may also provide a solution.
I believe some MPLS providers allow EIGRP to be used to peer across the MPLS cloud but not all. Here in UK we use BT and EIGRP peering is not an option at present.
I just posted a similar question to NetForums as we are running into a similar sitatuion where in we want to prefer AD 170 over AD 90.
One workaround we are contemplating is at the REMOTE LAN gateway (the subnets on the 4500 are defined as VLANs and it does EIGRP). So, if we just did redistribute connected at the REMOTE 4500, the routes from the REMOTE gateway will travel towards the HUB as EIGRP-external (whether it takes the MPLS or FR path). And by adding delay along the interfaces for the backup path - the HUB will prefer AD 170 with the lesser delay.
i guess its still a workaround, we'll find out if it works in a couple of weeks. Has anyone dealt this situation like this before
why dont you just make external routes use AD90 on your routers:
router eigrp 100
distance eigrp 90 90
and then let the metrics determine the best route?
Found this info and could be a solution but has to support by your MPLS provider.
EIGRP Connectivity Between VPN Client Sites over a Service Provider Backbone
In Figure 1, the EIGRP routes in Site 1 are carried through the BGP core network as iBGP routes. The EIGRP routes in "Site 1" and "Site 2" are converted to iBGP routes and EIGRP extended community attributes are appended to the iBGP routes. (See Table 1 for a description of these attributes.) The EIGRP extended community attributes are appended to the EIGRP routes when they are redistributed into BGP as iBGP routes, and VPN routing information is redistributed between the PE routers by multiprotocol BGP.
The routes that originate in "Site 1" travel to the PE router that is connected to the CE router in "Site 2" of the VPN and are then converted back to EIGRP routes using the EIGRP extended community attributes. EIGRP routes are treated the same in "Site 1" and "Site 2." If the route is internal in "Site 1", it will be internal in "Site 2", and if the route is external in "Site 1", it will be external in "Site 2." All EIGRP metrics are preserved, and EIGRP metric information, along with the autonomous system, tag, and external data, is carried across the VPN over the BGP core network.
The route would be seen as external or internal depending upon how they are exchanging the same with the provider PE.
If EIGRP is used between the 2, then the routes would be tagged as internal but if we use any other routing protocol, it would be seen as external.
For those of you who would like to know,
I was able to get this working well in my environment through the MPLS. I used the DISTANCE EIGRP 170 170(IntAS)(extAS) command on the router that has my backup T-1 on it only on one side of the circuit. This way it advertises an AS of 170 for Internal and External routes. I still see EX on the routes over the MPLS but now I have made it where the MPLS routes are AS 90 and backup T-1 AS 170. I removed this command and noticed EIGRP neighboring changes for the wrong route and when implemented routes diverge correctly....Thanks everyone for their assistance and comments...
Hi - would you be able to copy/send your config (without the sensitive info). Was the admin distance modification done at the point to point router on the remote end ? We are in a similar fix, but my understanding is that changing the admin distance is not 'supported' by cisco/tac - though the command is there. In our case, we have a similar issue with the mpls (D-EX) needing to be primary and the framerelay (EIGRP int) has to be backup.