[c-nsp] Leaking global into VRF

[Harold Ritter]

Jason,

Remember that the traffic will be forwarded according to the global routing table, so you do not need a label unless you have a BGP free core. Does the destination have a route back to the VRF route though?

Regards

Le 2010-11-09 à 08:45, Jason Lixfeld a écrit :

> 
> On 2010-11-09, at 1:18 AM, Oliver Boehmer (oboehmer) wrote:
> 
>> Jason,
>> 
>>> I'm trying to lab up a scenario where I can leak routes from the
>> global
>>> table into a VRF, but I'm running up against an issue and I'm hoping
>> someone
>>> here can point out where I might be misstepping.
>>> 
>>> My P router is also my peering router.  That is, in addition to it's P
>>> duties, it also speaks eBGP to another autonomous system.  I want to
>> take
>>> the eBGP learned prefixes and import them into a VRF.  This part seems
>> to
>>> work, but the issue is that the adjacent PE doesn't seem to see the
>> prefix
>>> that has been imported.  The PE sees the global entry, but it doesn't
>> see
>>> the prefix in the vpnv4 AF for the VRF in question.
>> 
>> This looks expected as a PE router (your peering router) importing a
>> prefix from another VRF (or from global in your case) into a VRF never
>> exports this prefix from the importing VRF into vpnv4. So in your case,
>> you need the "import ipv4 unicast map VRF-IMPORT" on all PE routers
>> needing the prefix.  
> 
> Interesting.  I was of the belief that MPBGP would take care of announcing these prefixes once leaked into a VRF AF.  Have I misunderstood the extent of MPBGP here, or is there another way to do it that uses (MP)BGP in some way?
> 
> Until then, I've set import ipv4 ... on all the PEs down the line, and while the prefix is now seen inside the VRF on all the devices I expect it to, my packets still don't seem to be getting to where I want them to go.  That is, they seem to be going nowhere.  I think one reason why is because no routers inside my network have a label associated with the eBGP prefix I'm trying to reach:
> 
> P1#show ip route vrf INTERNET 7.7.7.7
> 
> Routing Table: INTERNET
> Routing entry for 7.7.7.7/32
>  Known via "bgp 6666", distance 20, metric 0
>  Tag 1, type external
>  Last update from 7.0.0.1 00:02:38 ago
>  Routing Descriptor Blocks:
>  * 7.0.0.1 (default), from 7.0.0.1, 00:02:38 ago
>      Route metric is 0, traffic share count is 1
>      AS Hops 1
>      Route tag 1
>      MPLS label: none
> P1#
> 
> And if this is potentially the root cause, how to get a label on this prefix isn't clear to me.  This is an eBGP prefix from an outside AS.  They have no knowledge that their announcements are ultimately going to end up in a VRF once they get over to us.  I only mention that incase it turns out to be part of the problem.
> _______________________________________________
> 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/


Harold Ritter
Directeur Technique/Technical Leader
Advanced Services Central Engineering
CCIE 4168 (R&S, SP)

harold at cisco.com
Téléphone: 514 847 6856

Les Systèmes Cisco 
1800 McGill College
Suite 700
Montréal, Québec H3A 3J6
Canada