Redistribute BGP into EIGRP help needed.

[the-lebowski]

Having a hell of a time getting BGP into EIGRP on one end of my WAN.  

Its working on one end but not the other.  I want this router to redistribute any BGP learned route into EIGRP and specific EIGRP learned routes into BGP.  

l3-CE#show run .....
router eigrp 3000
 redistribute bgp 65000 route-map BGP2EIGRP
 network 10.0.0.0
 no auto-summary
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 bgp redistribute-internal
 network 10.0.0.0
 redistribute connected
 redistribute static
 redistribute eigrp 3000 route-map EIGRP2BGP
 neighbor 100.65.0.5 remote-as 3549
 neighbor 100.65.0.5 send-community
 neighbor 100.65.0.5 soft-reconfiguration inbound
 no auto-summary
!
ip forward-protocol nd
ip route 10.99.0.0 255.255.0.0 10.120.2.1
ip route 10.100.0.0 255.255.0.0 10.120.2.1
!
!
no ip http server
no ip http secure-server
!
access-list 90 permit 10.100.0.0 0.0.255.255
access-list 100 permit ip any any
no cdp log mismatch duplex
!
!
!
route-map BPG2EIGRP permit 10
 match ip address 100
 set metric 100 1 255 1 1500
 set tag 10
!
route-map EIGRP2BGP deny 10
 match tag 10
!
route-map EIGRP2BGP permit 20
 match ip address 90
!
l3-CE#show ip route eigrp

l3-CE#show ip route bgp
 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.196.2.0/24 [20/0] via 100.65.0.5, 00:09:13
B 10.196.0.0/16 [20/0] via 100.65.0.5, 00:09:13

l3-CE#show ip eigrp neighbors
IP-EIGRP neighbors for process 3000
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
1 10.100.2.1 Fa0/0 13 00:09:22 48 288 0 43
0 10.100.2.10 Fa0/0 10 00:09:22 34 204 0 61

Downstream router (no eigrp routes):

6509-ds#show ip eigrp neighbors
IP-EIGRP neighbors for process 3000
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 10.100.2.5 Vl2 11 00:09:46 41 246 0 24
2 10.100.2.10 Vl2 14 02:27:33 27 200 0 59

6509-ds#show ip route eigrp

[the-lebowski]

I am open to all suggestions and enjoy working through all of this.  

I assumed incorrectly that if the MPLS went down then the traffic would route over the DMVPN tunnels but you're right and it won't because of the static routes on the PE.  I shut down the MPLS interface on remote side and the core still thinks the route is available via MPLS which it obviously isn't because the interface is down.  

However I think I figured out how to make this work without static routes and using the 2 aggregate-address statements to the remote BGP/EIGRP router.  I also remove the static routes from the PE router.  

 aggregate-address 10.196.0.0 255.255.128.0 summary-only
 aggregate-address 10.196.128.0 255.255.128.0 summary-only

P 10.196.0.0/17, 1 successors, FD is 2562816, tag is 3549
 via 10.100.2.5 (2562816/2560256), Vlan2
P 10.196.0.0/16, 1 successors, FD is 13150720
 via 10.100.255.2 (13150720/13125120), FastEthernet0/1

D EX 10.196.0.0/17 [170/2562816] via 10.100.2.5, 00:05:08, Vlan2
D 10.196.0.0/16
 [90/13150720] via 10.100.255.2, 00:14:49, FastEthernet0/1

Granted I only have routes that fall under the 10.196.0.0/17 network so I assume that is why I am only seeing that network now.  However it is preferring that BGP learned route from my core which is good.  When I shut down MPLS on the far end it fails over to the EIGRP route via DMVPN, albeit it takes its time.  

[Jon Marshall]

Not sure which interface you shut down in your test with static routes ?

Did you add the static routes to the CE ?

If you shut the interface on the CE connecting to the PE then even with static routes the CE can no longer advertise the routes via BGP is the main site should no longer receive those routes.

Perhaps I am misunderstanding what you did or just as likely I don't have the full picture of your topology ?

An clarification would help because I am not sure why that didn't work.

As for the summary address advertisement, yes at least one more specific prefix for each of the summary addresses must be in the BGP table.

Jon

[the-lebowski]

Added them to the PE.  Will do a diagram tomorrow but it looks like so:

Remote site <-----> PE <------> CE <-----> 6500 core.  

Static routes were on the PE with the remote site as the next hop.  So when I shut down the MPLS interface on the remote site the next hop of those static routes (remote site) was down so it broke.  CE was still advertising the routes to back to the 6500.  

Are you saying to put the static routes on the CE instead pointing towards the PE?  

[Jon Marshall]

Yes, they should have been added to the CE device.

Sorry, I thought this was a scenario where you controlled the CE device and the PE was controlled by the SP.

If you add them to the PE then yes it will never switch to the DMPVN because those routes are still being advertised with BGP.

My understanding was that the CE at the remote site was receiving EIGRP routes from another internal L3 device eg. a L3 switch and then the CE was advertising the routes with BGP to the MPLS network.

Is this not the case ?

Jon

[the-lebowski]

Your understanding is correct and that is the case in production.  However in this scenario I manage the PE because its in the lab :). 

I went ahead and created the static routes on the CE, re-added the network statements to BGP and added 'redistribute static' on the EIGRP process on the CE which allowed the /17s to be advertised to the core.  But again once I shutdown the MPLS interface on the remote site those routes are still being advertised via the MPLS path and not failing over.  If I shutdown the interface connecting PE and CE it works correctly.  

[Jon Marshall]

What interface is the MPLS interface in the remote site, do you mean the one on the PE connecting to the MPLS network ?

If you shut either the CE to PE interface or the MPLS facing PE interface then those routes cannot possibly be advertised because there is no path.

Jon

[the-lebowski]

Maybe this thread has run its course with all the back and forth.  Lets continue offline (is there a way to share contact info)?

Make a long story short if I have static routes on the CE how is the core going to know to stop sending traffic via that route?  The core will always take the route unless its connection to the CE is down.  Anything down beyond the CE it will still get those static routes redistributed to it from the CE regardless correct? 

[Jon Marshall]

You can e-mail if you like.

You diagram should show two CEs and two PEs but it isn't so I am a bit confused.

The static routes on the CE should point to the L3 internal device as the next hop IP.

If the CE to PE connection goes down then you can't advertise those routes via BGP so it should fail over to DMVPN.

If the CE to internal device link fails then the static routes should be removed from the routing table and then BGP can't advertise them.

That is how it should work but it sounds like you have a different setup.

jms.123@hotmail.co.uk

Jon

[Jon Marshall]

Forgot to ask is the backup link purely for use between these two sites or is the backup part of a DMVPN solution, for example, where each backup link has to advertise EIGRP routes to all other sites ?

Jon

[the-lebowski]

Thanks Johnand yes to your question. 

It is part of a DMVPN environment, which they do advertise to each other their routes via EIGRP.  I was able to get it working by doing two things (with TAC's help).  Whether this will break everything in production I am still not sure.  

1. Adjusting the metric on the BGP2EIGRP route map:

route-map BGP2EIGRP permit 10
 match ip address 100
 set metric 1000 1 255 1 1500

2. Changing the EIGRP distance on the 6500

router eigrp 3000
 redistribute connected
 redistribute static
 network 10.0.0.0
 distance eigrp 90 89

D EX 10.196.2.0/24 [89/2562816] via 10.100.2.5, 00:32:12, Vlan2
D EX 10.196.0.0/24 [89/2562816] via 10.100.2.5, 00:32:12, Vlan2
D EX 10.196.0.0/16 [89/2562816] via 10.100.2.5, 00:32:13, Vlan2

[Jon Marshall]

Okay so basically what I assumed you didn't want to do :)

The reason I didn't suggest it is because it affects all external routes and I didn't have the full picture of the toology.

As long as that does not break anything else it is fine and will work.

Jon

[the-lebowski]

Duplicate.