02-23-2009 06:54 AM - last edited on 03-25-2019 03:22 PM by ciscomoderator
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.
02-24-2009 01:44 PM
Yes, that simple.
Make sure to have remote-as 65000 on the new neighbor entry, remove EIGRP at the Branch office and the summary EIGRP piece at the Home Office.
HTH,
__
Edison.
02-23-2009 07:11 AM
If the 2 CEs belong to the same EIGRP AS, routes won't be external.
Please refer to this article for more information:
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a00801eb09a.shtml
HTH,
__
Edison.
02-23-2009 07:23 AM
Edison,
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.
Regards
02-23-2009 07:27 AM
Harold,
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.
__
Edison.
02-23-2009 07:21 AM
George,
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
Regards
02-23-2009 08:23 AM
Harold,
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.
02-23-2009 08:30 AM
George,
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.
Regards
02-23-2009 08:51 AM
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
192.168.2.0/24
192.168.3.0/24
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.
HTH,
__
Edison.
02-23-2009 10:35 AM
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?
02-23-2009 10:49 AM
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.
HTH,
__
Edison.
02-23-2009 12:03 PM
Edison,
I'm not sure I'm understanding all of the questions in your last post. The MPLS connection in all the branches is serial. I don't really want the backup interface option because at least one recent outage was a provider BGP issue where we were up/up but the routes were blackholed in the cloud. That's why I prefer having the routing protocols take care of it. The branches connect only to the home office (or possibly to another branch), they have no other path.
I want the FR to be disaster-recovery only because of how we are billed for it -- it's cheap but we have 0 CIR and a pretty strict limit on monthly usage (95th percentile). I'd rather not get into running BGP on the FR.
So I want everything going over MPLS unless that's down or the provider is having a routing problem. If I understand you and Harold correctly, I'm looking at something like this:
BRANCH
router eigrp 1
network 172.14.0.0 0.0.0.255
192.168.0.0 0.0.0.255
eigrp stub receive-only
no eigrp log-neighbor-changes
!
router bgp 65000
bgp log-neighbor-changes
neighbor nnn.nnn.nnn.nnn remote-as xxx
!
address-family ipv4
neighbor nnn.nnn.nnn.nnn activate
no auto-summary
no synchronization
network 172.18.14.0 mask 255.255.255.0
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 zzz.zzz.zzz.zzz
HOME OFFICE
router eigrp 1
network 192.168.0.0 0.0.0.255
redistribute bgp 65000 metric 1544 150 255 100 1500
no auto-summary
!
router bgp 65000
bgp log-neighbor-changes
neighbor zzz.zzz.zzz.zzz remote-as 209
!
address-family ipv4
redistribute eigrp 1
neighbor zzz.zzz.zzz.zzz activate
no auto-summary
no synchronization
exit-address-family
!
ip summary-address eigrp 1 0.0.0.0 0.0.0.0
02-23-2009 12:53 PM
ip route 0.0.0.0 0.0.0.0 zzz.zzz.zzz.zzz
Branch has a static default route pointing to?
Would this default route be removed if the gateway is down? If not, the solution provided by Harold won't work as the EIGRP summary route will never be in the routing table.
If the default route is removed from the routing table when the gateway is down, then Harold's solution will instruct the Branch router to use the FR link for Home Office connection.
However, under non-failure scenario, you are still advertising the subnet 172.18.14.0/24 via BGP and EIGRP from the Branch. This part of the design hasn't been addressed. I gave you a couple of choices but it seems you didn't like either one.
I understand the backup interface not being the most ideal but the use of BGP in the FR link should be something you should consider.
__
Edison.
02-24-2009 12:26 PM
OK, I wrote an eloquent response, but had to run to a meeting, and it vanished.
The static 0.0.0.0 at the branch points to the MPLS PE address closest to the home office. That way if we have either physical or routing problems, it goes away, and is replaced by the eigrp summary 0.0.0.0 recommended by Harold (which I see I failed to put in the model config in my last post.)
I see what you mean about the non-fail scenario. I guess I don't need to advertise 172.18.14.0/24 via EIGRP, I can just send it over BGP back to the home office. As noted earlier, I am hesitant about "backup interface" because I've already lived through a failure scenario where it wouldn't have worked. I'm hesitant about running BGP on the FR link mainly because we have no experience with BGP as an IGP -- we use it as an EGP only. Would that just be another neighbor relationship in the same BGP AS? How would I keep it from being used in a non-fail scenario?
Thanks again for taking the time to engage in this discussion.
02-24-2009 12:55 PM
If you don't send 172.18.14.0/24 over EIGRP then how you plan to advertise that subnet in a failure via the FR link?
I understand your hesitation regarding the backup interface command.
As for the BGP query, yes - it's that simple. All you need to do a neighbor with via the FR links. Best to get familiar with BGP Path Selection from this article:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml
HTH,
__
Edison.
02-24-2009 01:38 PM
Yeah, I remember studying that BGP path selection a while back. So it can be as simple as this?
BRANCH OFFICE
router eigrp 1
network 172.14.0.0 0.0.0.255
eigrp stub receive-only
no eigrp log-neighbor-changes
!
router bgp 65000
bgp log-neighbor-changes
neighbor nnn.nnn.nnn.nnn remote-as xxx weight 100
neighbor 192.168.0.2
!
address-family ipv4
neighbor nnn.nnn.nnn.nnn activate
neighbor 192.168.0.2 activate
no auto-summary
no synchronization
network 172.18.14.0 mask 255.255.255.0
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 zzz.zzz.zzz.zzz
HOME OFFICE
router eigrp 1
redistribute bgp 65000 metric 1544 150 255 100 1500
no auto-summary
!
router bgp 65000
bgp log-neighbor-changes
neighbor zzz.zzz.zzz.zzz remote-as xxx weight 100
neighbor 192.168.0.1
!
address-family ipv4
redistribute eigrp 1
neighbor zzz.zzz.zzz.zzz activate
neighbor 192.168.0.1 activate
no auto-summary
no synchronization
exit-address-family
!
ip summary-address eigrp 1 0.0.0.0 0.0.0.0
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: