Im trying to understand and get a working lab config to import routes from global into a vrf.
My understanding is that the import statement in the vrf config uses a route-map to match routes in the global which would be imported into the vrf.
So in my case below, any routes in Global matching ACL 20, would be imported into vrf GREEN via the route-map IMPORT.
ip vrf GREEN
import ipv4 unicast map IMPORT
route-map IMPORT permit 10
match ip address 20
No joy, however, routes in global matching ACL 20 does not show up in my vrf GREEN routing table
Am I missing something ?
I've always seen it done using prefix-list rather than ACLs.
As shown here:
(although there is a typo there)
What software are you doing this on?
platform im using is 2691 running 12.4(25) advanced ip services.
I think what im missing, after reading abit more detail, is that the ACL or prefix list in the route map, needs to match prefixes received in BGP in the global.
What Im trying to do is match routes in OSPF in the global, and import them into a VRF. Im not running IPv4 BGP on this PE, just VPNv4 BGP for exchanging vrf routes. So back to the drawing board I guess - not quite sure how to go around this.
Required connectivity works fine when I manually configured a static route in the vrf, but I would not like to rely on static routes (hence attempting to import that from OSPF in Global).
any ideas ?
let's recall that import actions are triggered when a new routing update is received or when routes are withdrawn - http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_bgivt.html
have you tried to refresh the routes being covered by the ACL 20?
Also, what is in 'sh ip route' and in 'sh access-list 20' ?
Access-lists are supported.
thanks for your reply.
as per my reply above, may ACL 20 is matching routes in OSPF in Global, not BGP, which is why I believe its not working.
Not sure if we require prefixes to be in RIB via BGP or just in local BGP table.
Can we configure fake BGP process, redistribute OSPF into it and import ipv4?
Overkill? Bad idea? Am I a lunatic?
yeah, it looks like a bgp session in global seems to be the only way out, so i think i'd prefer somehow arranging a real bgp to an upstream router rather than redistribution.
its nice to get fancy in the lab, but the idea is that i would end up with something usable in production sometime soon
will check this out including if the import would happen from the BGP table or the RIB, but somehow if prefixes need to be just in the BGP table, it doesnt sound right.
will get back with the results
contrary to what I expected (and not sure if this is actually expected behaviour), the "import ipv4 unicast" command in a vrf actually allows import from the BGP table, even if the prefix was not installed in RIB.
I thought there would have been an easier way to do this, ie not restricted to said prefix having to be in BGP
My lab example with a default route
1. RIB FAILURE
PE3#sh ip bgp ipv4 unicast nei 10.10.100.102 received-routes
BGP table version is 7, local router ID is 10.10.100.104
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r>i0.0.0.0 10.10.100.102 100 0 i
Total number of prefixes 1
2. VRF IMPORT ROUTE MAP
ip prefix-list IMPORT seq 5 permit 0.0.0.0/0
route-map IMPORT permit 10
match ip address prefix-list IMPORT
3. DEFAULT SHOWS UP IN VRF VIA BGP
PE3#sh ip route vrf GREEN
Gateway of last resort is 10.10.100.102 to network 0.0.0.0
192.168.1.0/27 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, FastEthernet0/1.10
B* 0.0.0.0/0 [200/0] via 10.10.100.102, 00:09:02