Preferring EIGRP external

Answered Question
Feb 23rd, 2009

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?

I have this problem too.
0 votes
Correct Answer by Edison Ortiz about 7 years 9 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Harold Ritter Mon, 02/23/2009 - 07:23

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

Edison Ortiz Mon, 02/23/2009 - 07:27

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.

Harold Ritter Mon, 02/23/2009 - 07:21

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 0.0.0.0 0.0.0.0

Regards

gkuzmowycz Mon, 02/23/2009 - 08:23

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.

Harold Ritter Mon, 02/23/2009 - 08:30

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

Edison Ortiz Mon, 02/23/2009 - 08:51

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.

gkuzmowycz Mon, 02/23/2009 - 10:35

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?

Edison Ortiz Mon, 02/23/2009 - 10:49

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.

gkuzmowycz Mon, 02/23/2009 - 12:03

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

Edison Ortiz Mon, 02/23/2009 - 12:53

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.

gkuzmowycz Tue, 02/24/2009 - 12:26

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.

Edison Ortiz Tue, 02/24/2009 - 12:55

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.

gkuzmowycz Tue, 02/24/2009 - 13:38

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

Correct Answer
Edison Ortiz Tue, 02/24/2009 - 13:44

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.

Actions

This Discussion