[c-nsp] Expose PE subnet to a vrf?

[Shakeel Ahmad]

Use Blank BGP & Communities to leak your routes in anyway you like.


http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml




On 2/23/07, Jeff Kell <jeff-kell at utc.edu> wrote:
>
> VRF-lite has baffled me once again.  I have what I thought would be a
> simple case of a vrf route leak, but I am either overlooking something
> obvious, or this is going to be harder than I thought.
>
> Scenario:  Moving a "legacy" network to a new multi-VRF core.  The "new"
> network has the global routes, and VRFs defined for "legacy" and
> "management" (plus some others that aren't relevant at the moment).
>
> The CEs are linked to the PE with trunks, each VRF having a dedicated vlan
> like so:
>
> ==========
> interface Vlan800
> description Global VRF mesh
> ip address 10.100.1.1 255.255.252.0
> !
> interface Vlan810
> description Legacy network mesh
> ip vrf forwarding legacy
> ip address 10.110.1.1 255.255.252.0
> !
> interface Vlan820
> description Management network mesh
> ip vrf forwarding management
> ip address 10.120.1.1 255.255.252.0
> ==========
>
> In order for the "management" vlan to function correctly, it needs
> visibility to the global vlan800.  I've checked the documentation on "route
> leaking" between a vrf and the global table, and the suggested method works
> if the advertised route is in the global table.  But it doesn't want to work
> if the advertised route is a *connected* subnet:
>
> > New-Core(config)#ip route vrf management 10.100.0.0 255.255.252.0
> 10.100.1.1 global
> > %Invalid next hop address (it's this router)
>
> How do I advertise 10.100 into vrf management, and the return route for
> 10.120 in the global table?
>
> Jeff
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>