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

[Arie Vayner (avayner)]

Jeff,

Try using the destination interface name as well.

Arie 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Kell
Sent: Friday, February 23, 2007 17:00 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Expose PE subnet to a vrf?

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/