cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3592
Views
0
Helpful
2
Replies

BGP export map - My logic might be off...

james.brunner
Level 1
Level 1

Hi all,

I have problem with a VRF export map and I can't see where I have gone wrong.

My set-up is quite simple; I have an Internal VRF which my OSPF process uses along with BGP so I can shunt routes between the two (the route-map 'only-RFC1918_IPs' strips out any routes either way that are not private 10 IPs).

There is a Product VRF which connects to a third party and imports all my prefixes from the Internal VRF. It also has an aggregate summary-only for 10.0.0.0/8 so the 3rd party doesn't get all our 10/x subnets. It receives a set of routes back from the 3rd party and exports them back to the Internal VRF. So far, so good. The 3rd party gets my aggregate, I get their routes.

However, the aggregate is also exported from the Product VRF to the Internal VRF as a local route which we don't want. I tried removing the route-target export from the Product VRF and replacing with a route-map based export map but this doesn't seem to work correctly as I get no routes at all exported into the Internal VRF.

The OSPF redistribute prefix-list stops my upstream OSPF routers getting the aggregate but having it exist in the Internal VRF is causing me issues.

The configuration I tried was:

ip vrf Internal
 description Main VRF
 rd 1:1
 route-target export 1:1
 route-target import 1:1

ip vrf Product
 description Product VRF
 rd 1001:3500
 export map rtSet_nonRFC1918_supernets
 route-target import 1:1

router ospf 100 vrf Internal
 capability vrf-lite
 redistribute bgp 64001 subnets route-map only_RFC1918_IPs
 <etc>

router bgp 64001
 address-family ipv4 vrf Internal
  redistribute ospf 100 match internal external 1 external 2 route-map only_RFC1918_IPs
 exit-address-family

 address-family ipv4 vrf Product
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
  neighbor x.x.x.x remote-as 1001
  <etc>
 exit-address-family

ip prefix-list match_RFC1918_supernets seq 100 permit 10.0.0.0/8

route-map rtSet_nonRFC1918_supernets permit 10
 match ip address prefix-list match_RFC1918_supernets

route-map rtSet_nonRFC1918_supernets permit 20
 set extcommunity rt 1:1

ip prefix-list match_RFC1918_IPs seq 100 permit 10.0.0.0/8 ge 9

route-map only_RFC1918_IPs permit 10
 match ip address prefix-list match_RFC1918_IPs

I think the prefix list match_RFC1918_supernet should match 10.0.0.0/8 only and no other 10.x.x.x addresses with longer masks. The route-map rtSet_nonRFC1918_supernets should work by matching the prefix list in permit 10 but not have any 'set' command so the route gets no RT added (as the VRF Product no longer has no route-target export 1:1). The permit 20 should then match all prefixes as there is no match statement and set all to use RT 1:1

I've also tried changing the rtSet_nonRFC1918_supernets route-map permit 10 to "match route-type local" but that didn't work either.

Have I got my logic wrong or is there a better way to achieve this? Hope that makes sense!

JB.

1 Accepted Solution

Accepted Solutions

Jon Marshall
Hall of Fame
Hall of Fame

JB

From memory you need both statements under your VRF ie. the export map only filters the routes exported but it doesn't actually export them, that is what the route-target export command does. 

It certainly works that way with imports so I expect it is the same. 

Jon

View solution in original post

2 Replies 2

Jon Marshall
Hall of Fame
Hall of Fame

JB

From memory you need both statements under your VRF ie. the export map only filters the routes exported but it doesn't actually export them, that is what the route-target export command does. 

It certainly works that way with imports so I expect it is the same. 

Jon

Thanks Jon,

You were right.

I re-added the "route-target export 1:1" back to the Product VRF and tweaked the export map to change the unwanted supernet to a different tag (1:1001) and then waited for about 30 mins before the VRFs updated as expected :)

The rule seems to be either (a) site on your hands and wait for the updates to go through or (b) force a "clear ip bgp *" if you don't mind your VRF routing going down for a bit. Just don't expect the map to take effect immediately.

JB.

ip vrf Product
 description Product VRF
 rd 1001:3500
 export map rtSet_nonRFC1918_supernets
route-target
export 1:1
 route-target import 1:1

route-map rtSet_nonRFC1918_supernets permit 10
 match ip address prefix-list match_RFC1918_supernets
 set extcommunity rt 1:1001