We have a number of branch offices connected in a hub-and-spoke configuration with frame-relay links. More recently we connected them with MPLS links, but due to cost considerations with our provider we kept the frame-relay links as backups (but with a zero CIR).
The issue now is which routes are preferred. We run EIGRP internally, but the MPLS connections use BGP. Once the BGP redistributes into EIGRP, the MPLS links are "EIGRP External", and the old frame-relay links are preferred. I worked around this for now by setting the admin distance of EIGRP external to be lower than the internal. We redistribute nothing else into EIGRP, so this does what I want. But my question is whether there is any risk in resetting the admin distances in this way. Should I be accomplishing this using route-maps an policies instead?
Solved! Go to Solution.
If the 2 CEs belong to the same EIGRP AS, routes won't be external.
Please refer to this article for more information:
The document you are referring to assumes EIGRP being used as the PE-CE protocol. In this case, the poster is using BGP and redistribute in EIGRP on the CE.
Yes, you are correct. I misread the original post and thought EIGRP was the PE-CE protocol but the PE-CE protocol is indeed BGP.
Thanks for the catch.
It would be preferable to send a summary route via the FR link. You can summarize at the FR hub site with the following command:
ip summary-address eigrp
Thanks. But a summary route is even more preferred than EIGRP internal, and I don't *want* to prefer the FR link. I want to prefer the MPLS.
The longest prefix is always preferred no matter the AD. So by injecting the default on the FR circuit and the specific prefixes via the MPLS cloud, the latter will always be preferred.
As Harold indicated, the longer prefixes will be chosen regardless the AD on the route.
In addition, we need to address the routes being advertised from the spokes to the hub as well, as they are also internal routes.
You will need to summarize those routes from the spoke to the hub, but you can't use the 0.0.0.0 0.0.0.0 on the summary. You need to use a shorter prefix than the one advertised via the MPLS.
For instance, if you are advertising
via the MPLS from the spoke to the hub, then you need to summarize those routes with 192.168.2.0/23 with the command Harold indicated on the FR interface at the spoke router.
Thanks, Edison and Harold. The problem with the branch offices is that they are very small, generally just one network. In fact, I've set them up as EIGRP stubs.
Seems what I'd have to do in this scenario is make them receive-only stubs and give them a static default route pointing at the MPLS PE. That way everything goes over the MPLS, since the static AD is 1, but if that dies, then the EIGRP summary 0.0.0.0 from Harold's answer gets installed. Does that make sense?
Continue receiving the specifics via the MPLS network and the 0.0.0.0 summary via the FR on the spokes from the hub.
We didn't address a 0.0.0.0 via the MPLS. How is the spoke getting out to the internet? If their internet connection is the hub (via MPLS), then the FR may be preferred.
We still need to address the routes from the spokes to the hub as well. You will be sending specifics via the MPLS and the FR, the FR will be preferred. We need to summarize those routes but as you stated, those locations are single subnet.
I'm not sure how is your connection via MPLS (Ethernet or Serial) but you can look into deploying backup interface command under the MPLS interface pointing towards the FR interface.
If the MPLS interface goes down/down, the backup interface command will bring up the FR interface at the spokes. Keep in mind, this method won't work if the MPLS interface is ethernet and remains up/up.
You can also change the routing protocol in the FR links to BGP and use BGP metrics to prefer one path over the other.
Overall, changing the EIGRP metrics to have external preferred over internal can cause adverse effects.