Solved: Inject EIGRP inot BGP/mpls

DialerString_2 · ‎03-03-2009

I'm redistributing eigrp from as64000 into my providers MPLS/BGP as65000. However, my remote locations, which are in AS64000, can't see and don't use the injected eigrp route. They prefer path X through the MPLS, but if I kill path X, the route will then prefer the injected eigrp path. I believe this has something to do with the metric b/c it's advertised to external peers, in this case MPLS.

thx

Giuseppe Larosa · ‎03-03-2009

Hello Eric,

provide

sh ip route prefix

sh ip bgp prefix

in both conditions to understand what is happening

the configuration can help too.

Hope to help

Giuseppe

View solution in original post

c.captari · ‎03-03-2009

Not having the bgp table at hand it's hard to decide, but if indeed the origin code is what sets the routes apart i advise you to change the origin code when you redistribute

Example

router bgp 64512

redistribute eigrp 1 route-map CHG_ORIGIN

route-map CHG_ORIGIN permit 10

set origin igp

For your reference this is how bgp algorithm choses the best path , in this order:

1. Prefer the path with the highest WEIGHT.

2.Prefer the path with the highest LOCAL_PREF.

3.Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.

4.Prefer the path with the shortest AS_PATH.

5.Prefer the path with the lowest origin type.

Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.

6.Prefer the path with the lowest multi-exit discriminator (MED).

7.Prefer eBGP over iBGP paths.

[.... others ....]

You probably have problems on number 5. That's why you need to have consistency in redistribution. Alternatively, just modify weight or local pref on this routes. They take precedence over origin type

View solution in original post

Giuseppe Larosa · ‎03-04-2009

Hello Eric,

the subnet 10.1.72.0/24 is directly connected to Chicago router.

Notice that router HQ is learning the prefix from the provider (known via BGP 64000 and tag 65000) via EBGP (distance 20, metric 0)

the prefix is redistributed inside eigrp 1000 with metric 9 1 255 1 1500.

You should have a static route pointing to the firewall on HQ

HQ:

ip route 10.1.72.0 255.255.255.0 Fw-nwxt-hop

router bgp 64000

no auto-summary

network 10.101.72.0 255.255.255.0 route-map set-med

route-map set-med permit 10

set metric 1

this creates a locally originated BGP route with origin i (internal) from HQ.

on Chicago router

router bgp 64000

no auto-summary

network 10.1.72.0 255.255.255.0 route-map set-med2

route-map set-med2 permit 10

set metric 10

HQ should then send the BGP advertisement to the PE router.

the HQ advertisement with MED 1 is preferred to the advertisement from Chicago with MED 10.

Hope to help

Giuseppe

View solution in original post

Giuseppe Larosa · ‎03-03-2009

Hello Eric,

provide

sh ip route prefix

sh ip bgp prefix

in both conditions to understand what is happening

the configuration can help too.

Hope to help

Giuseppe

DialerString_2 · ‎03-03-2009

Giuslar,

I did better, I've attached a diagram of what I'm trying to do. The current path to "chicago" is red and I would like for "dc" to use the path through blue.

Thanks agn

Giuseppe Larosa · ‎03-03-2009

Hello Eric,

who can take a routing decision ?

if all three links are connected to the same provider.

You need to make path via HQ more attractive for the Chicago's subnets.

I suppose the redistribution points are at HQ and at Chicago.

You probably need to rise the EIGRP metric or the BGP metric of Chicago subnetsat Chicago-CE router .

A good starting point is to see the current routes

HQ-CE: sh ip route chicago-subnet

Chicago-CE: sh ip route chicago-subnet

being eBGP the routing protocol used on PE-CE links

also provide

HQ-CE:sh ip bgp chicago-subnet

Chicago-CE: sh ip bgp chicago-subnet

where chicago-subnet is a placholder for the Chicago site IP subnets.

But also the provider can play a role here.

Hope to help

Giuseppe

DialerString_2 · ‎03-03-2009

Yes, the path through the HQ router needs to be made more attractive. Once the route from HQ is injected into the MPLS cloud BGP will give that route an AD of 20 but it willhave an incomplete origen and therefore will not be chosen because of that. The other route, directly from Chicago into MPLS, origin will be internal and will be chosen.

Chicago#sh ip route 10.1.72.0

Routing entry for 10.1.72.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via eigrp 1000, bgp 64000

Advertised by bgp 64000

Routing Descriptor Blocks:

* directly connected, via FastEthernet0/0

Route metric is 0, traffic share count is 1

HQ>sh ip route 10.1.72.0

Routing entry for 10.1.72.0/24

Known via "bgp 64000", distance 20, metric 0

Tag 65000, type external

Redistributing via eigrp 1000

Advertised by eigrp 1000 metric 9 1 255 1 1500

Last update from 126.x.x.x.123 (PE)07:40:35 ago

Routing Descriptor Blocks:

* 126.x.x.123 (PE), from 126.x.x.123 (PE), 07:40:35 ago

Route metric is 0, traffic share count is 1

AS Hops 2

Giuseppe Larosa · ‎03-04-2009

Hello Eric,

the subnet 10.1.72.0/24 is directly connected to Chicago router.

Notice that router HQ is learning the prefix from the provider (known via BGP 64000 and tag 65000) via EBGP (distance 20, metric 0)

the prefix is redistributed inside eigrp 1000 with metric 9 1 255 1 1500.

You should have a static route pointing to the firewall on HQ

HQ:

ip route 10.1.72.0 255.255.255.0 Fw-nwxt-hop

router bgp 64000

no auto-summary

network 10.101.72.0 255.255.255.0 route-map set-med

route-map set-med permit 10

set metric 1

this creates a locally originated BGP route with origin i (internal) from HQ.

on Chicago router

router bgp 64000

no auto-summary

network 10.1.72.0 255.255.255.0 route-map set-med2

route-map set-med2 permit 10

set metric 10

HQ should then send the BGP advertisement to the PE router.

the HQ advertisement with MED 1 is preferred to the advertisement from Chicago with MED 10.

Hope to help

Giuseppe

c.captari · ‎03-03-2009

Not having the bgp table at hand it's hard to decide, but if indeed the origin code is what sets the routes apart i advise you to change the origin code when you redistribute

Example

router bgp 64512

redistribute eigrp 1 route-map CHG_ORIGIN

route-map CHG_ORIGIN permit 10

set origin igp

For your reference this is how bgp algorithm choses the best path , in this order:

1. Prefer the path with the highest WEIGHT.

2.Prefer the path with the highest LOCAL_PREF.

3.Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.

4.Prefer the path with the shortest AS_PATH.

5.Prefer the path with the lowest origin type.

Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.

6.Prefer the path with the lowest multi-exit discriminator (MED).

7.Prefer eBGP over iBGP paths.

[.... others ....]

You probably have problems on number 5. That's why you need to have consistency in redistribution. Alternatively, just modify weight or local pref on this routes. They take precedence over origin type

DialerString_2 · ‎03-04-2009

I was able to fix this. I had to modify the origin b/c redistributed routes show as incomplete. Once I did that I adjusted the metrics to 50 and 100. Metrics are sent into external BGP AS.

Thanks to everyone that helped me out with this.

Thanks guys.