[c-nsp] redistribute routes leaked from another VRF?

[Alexander Clouter]

Jeff Bacon <bacon at walleyesoftware.com> wrote:
> 
> The unicast I want to switch out into a VRF. 
> 
> I get the notion of using VRF source-selection but I'm uncomfortable
> with it, and I'm not sure how well it works in hdw at line rate, which
> it needs to. Besides, I'd like to drive the source select map from the
> routing protocol I'm receiving from the far end...) 
> 
Hopefully I understand what you are trying to do, I just had to work 
this out for myself yesterday when some infernal building services 
equipment landed on my desk that needs to connect to our LAN (and passed 
around over OSPF across multiple routers). :(

Turns out the 6500 12.2(33)SXI4a does not support 'vrf source select' 
(well grumbles 'unsupported and not official' so best avoided I guess) 
unless you have forked out for a services provider images....apparently.  
Means you have to turn to PBR to save the day:
----
6509-1#show ip access-list estates 
Extended IP access list estates
    10 permit ip 172.16.11.64 0.0.0.15 10.192.0.0 0.0.255.255 (124047 matches)

6509-1#show route-map estates
route-map estates, permit, sequence 10
  Match clauses:
    ip address (access-lists): estates
  Set clauses:
    vrf estates
  Policy routing matches: 123023 packets, 7586318 bytes

6509-1#show ip vrf estates
  Name                             Default RD          Interfaces
  estates                          65000:0             Vl2900
                                                       Vl2901
                                                       Vl....

6509-1#show run int vlan130
Building configuration...

Current configuration : 791 bytes
!
interface Vlan130
 description infernal equipment
 ip vrf receive estates
 ip address 172.16.11.78 255.255.255.240
 ip access-group 2130 in
 no ip redirects
 ip policy route-map estates
 standby 130 ip 172.16.11.65
end

router ospf 1000 vrf estates
 router-id 10.192.0.253
 log-adjacency-changes
 redistribute connected subnets <---- needed (do not add 'network')
 passive-interface default
 no passive-interface Vlan2900
 no passive-interface Vlan2901
 no passive-interface Vlan....
 network 10.192.0.0 0.0.255.255 area 0
 network 172.18.0.0 0.0.255.255 area 0
 network 172.31.4.0 0.0.0.255 area 0
----

In short, you add to your connected interfaces 'ip vrf receive estates' 
to put those routes into your vrf (in my case 'estates'), this pairs up 
with the 'redistribute connected subnets' in the ospf process; but you 
must *not* add 'network 172.16.11.64 0.0.0.15'.  This sorts out traffic 
going from the VRF to Vlan130.  To get the return traffic back into the 
VRF, that is where the PBR comes into play.

Lit this up yesterday and works a treat.

Cheers

-- 
Alexander Clouter
.sigmonster says: design, v.:
                  	What you regret not doing later on.