cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4549
Views
0
Helpful
23
Replies

Redistributing iBGP into EIGRP between VRF's

ross.wiggins
Level 1
Level 1

Please someone put me out my misery and help solve this issue!

Hardware = N5K-C5672UP running 7.1(4)N1(1)

Objective:

To redistribute a default route from iBGP (in a VRF named INTERNET) into EIGRP (in another VRF named NV)

Problem:

It does not work!

I feel like I have tried everything from using:

route-target import/export commands

export map commands

redistributing bgp using route-maps with an IP access list

redistributing bgp using route-maps with an IP prefix-list

Current config:

router bgp 15401
address-family ipv4 unicast
network 194.111.182.0/26 route-map NV_IP_RANGE
vrf INTERNET
router-id 1.1.1.1
timers bgp 10 30
log-neighbor-changes
address-family ipv4 unicast
network 195.111.182.0/26 route-map NV_IP_RANGE
distance 20 150 1
neighbor 172.16.5.1 remote-as 15401
update-source loopback100
address-family ipv4 unicast
send-community
route-reflector-client
soft-reconfiguration inbound
neighbor 172.16.5.4 remote-as 15401
update-source loopback100
address-family ipv4 unicast
send-community
soft-reconfiguration inbound
vrf context INTERNET
address-family ipv4 unicast
route-target import 1:1
route-target export 1:1
export map ALLOW_ALL
vrf context NVG
address-family ipv4 unicast
route-target import 1:1
route-target export 1:1
import map ALLOW_ALL

router eigrp 1
address-family ipv4 unicast
vrf NV
default-metric 10000 1 255 1 1500
redistribute static route-map ALLOW_ALL
redistribute bgp 15401 route-map DEFAULT_ROUTE
address-family ipv4 unicast
router eigrp 31
address-family ipv4 unicast
vrf NV
default-metric 100000 10 255 10 1500
redistribute bgp 15401 route-map DEFAULT_ROUTE
address-family ipv4 unicast

ip access-list ALLOW_ALL
10 permit 10 any any
ip access-list DEFAULT_ROUTE
10 permit ip any any

ip prefix-list DEFAULT_ROUTE seq 10 permit 0.0.0.0/0
route-map ALLOW_ALL permit 10
match ip address ALLOW_ALL
route-map DEFAULT_ROUTE permit 10
match ip address DEFAULT_ROUTE
route-map NV_IP_RANGE permit 10
set local-preference 120

23 Replies 23

Yes, the route leaking between VRFs appears to be working from the about output. You can verify the behaviour by removing the route-target import 1:1 from the NV VRF context and you should see it being withdrawn from the BGP table.

EIGRP will only redistribute the BGP default route when it has been installed in the VRF 'NV' RIB so you won’t see it in the EIGRP topology table until you remove the static default route or change its AD to higher than 200.

I removed the static routes and removed the export/import maps.  At that point, 'show ip route vrf INTERNET' was showing the correct default route from BGP.

'Show ip route vrf NV' was displaying 2 redistributed (external EIGRP) default routes from another site (DR) AND the BGP route.

The external EIGRP routes were being favoured due to their lower AD (170) over the iBGP AD of 200.

At that point I then added this to the BGP config:

vrf NVG
address-family ipv4 unicast
distance 20 150 1

'Show ip route vrf NV' was then displaying the favoured BGP route.

The final BGP config looked like this:

router bgp 15401
address-family ipv4 unicast
network 195.111.182.0/26 route-map NV_IP_RANGE
vrf INTERNET
router-id 1.1.1.1
timers bgp 10 30
log-neighbor-changes
address-family ipv4 unicast
network 195.111.182.0/26 route-map NV_IP_RANGE
distance 20 150 1
neighbor 172.16.5.1 remote-as 15404
update-source loopback100
address-family ipv4 unicast
send-community
route-reflector-client
soft-reconfiguration inbound
neighbor 172.16.5.4 remote-as 15401
update-source loopback100
address-family ipv4 unicast
send-community
soft-reconfiguration inbound
vrf NV
address-family ipv4 unicast
distance 20 150 1
vrf context INTERNET
address-family ipv4 unicast
route-target import 1:1
route-target export 1:1
vrf context NV
address-family ipv4 unicast
route-target import 1:1
route-target export 1:1

route-map DEFAULT_ROUTE, permit, sequence 10
Match clauses:
ip address prefix-lists: DEFAULT_ROUTE
Set clauses:

NX-5672-01# show ip prefix-list
ip prefix-list DEFAULT_ROUTE: 2 entries
seq 10 permit 0.0.0.0/0
seq 20 deny 0.0.0.0/0 le 32

EIGRP topology table showed (snippet incl 0.0.0.0/0:

NX-5672-01# show ip eigrp topology vrf NV 
IP-EIGRP Topology Table for AS(31)/ID(10.122.31.110) VRF NV

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 0.0.0.0/0, 0 successors, FD is Inaccessible
via 10.122.31.117 (25630976/25630720), Ethernet1/27
via 10.122.31.109 (25630976/25630720), Ethernet1/28
P 10.3.152.0/21, 0 successors, FD is Inaccessible
via 10.122.31.117 (3584/3328), Ethernet1/27
via 10.122.31.109 (3584/3328), Ethernet1/28

I cleaned up the EIGRP config and didn't need to redistribute BGP into EIGRP 31 so the default route in EIGRP 31 topology table was from the redistributed (DR) default route.

I needed BGP to be redistributed into EIGRP 1 but there was nothing for 0.0.0.0/0 in it's topology table.

At this point, downstream devices which should have been learning it's default route from the Nexus 5k (via EIGRP 1) wasn't and it was learning the default route from the DR site.

I'm not sure at this point if EIGRP 1 is not redistributing the Nexus 5k default route or if perhaps the seeding metric just needs to be adjusted so downstream devices connected to the Nexus 5k prefer it's default route not the one from the DR site....

Ah or could it have been this seeding metric that meant the default route from EIGRP 31/DR site was being favoured:

vrf NV
default-metric 100000 10 255 10 1500

Ok we are progressing.

It doesn’t look like EIGRP AS 1 is redistributing the BGP default route as you should be able to see it in the N5k's EIGRP AS 1 topology table.

Can you confirm that you have configured the default seed metric under EIGRP  and also configured 'match route-type internal' under the route-map that you are referencing in the redistribute BGP statement? Your EIGRP config should look like this.

router eigrp 1
 address-family ipv4 unicast
 vrf NV
  default-metric 10000 1 255 1 1500
  redistribute bgp 15401 route-map DEFAULT_ROUTE
  address-family ipv4 unicast
 !
 ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
 !
 route-map DEFAULT_ROUTE permit 10
  match ip address prefix-list DEFAULT_ROUTE
  match route-type internal

Yes, the default metric seen in the command output in the first post is what is used.

Regarding the route-type, I had it in at one point but when when I removed it (to test what was needed and what wasnt) it didn't impact the route being leaked between VRF's so I left it out.

I noticed when it was in, that the show is EIGRP route-map statictistics command didn't show a match against that line (just the prefix line).  

In your last command output is it written as another permit seq or within the same one?  

Its in the same route-map permit sequence.

This command is required to allow the iBGP default route to be redistributed into EIGRP. The reason that you didn’t see any matches in the statistics is because the iBGP default route was not in the NV VRF RIB. Try and add this command.

OK, I'll re-add and test again.

Hoping to be able to test this tomorrow evening Will.

I'll feedback results once it's done.

Thanks

It worked! :)

The BGP route was redistributed into EIGRP after adding in the additional route-map (match route-type internal) command.

I did however have another issue afterwards which needs looking at:

All internet bound traffic was routing via the Nexus and then stopping.

The default route was via next-hop of 172.16.5.1.

The following static routes exist in the NV VRF so recursive lookups can be done to find the route to 172.16.5.1:

vrf context NV

   ip route 172.16.5.1/32 10.122.31.241

The Nexus could successfully ping 10.122.31.241.

Interestingly, adding in a static route (for the exact same route) resolved the issue:

vrf context NV

   ip route 0.0.0.0/0 172.16.5.1/32

I may post this under a separate question if I'm unable to resolve myself (without the static)

Thank you for your help Will.

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco