[j-nsp] Problem of Forwarding on VPN using vrf-table-label.

Wed Oct 20 17:19:29 EDT 2010

Thanks a lot Harry.

Regards.

Javier Ger
Hornos 690 - Buenos Aires - Argentina
Tel +54.11.5530.4531
Cel +54.9.11.3926.5017
jger at cablevision.com.ar
www.cablevision.com.ar

-----Mensaje original-----
De: Harry Reynolds [mailto:harry at juniper.net] 
Enviado el: Miércoles, 20 de Octubre de 2010 12:56 p.m.
Para: Ger, Javier; David Lockuan; Cristian Frizziero
CC: juniper-nsp at puck.nether.net
Asunto: RE: [j-nsp] Problem of Forwarding on VPN using vrf-table-label.

If I follow, by learning a route from the ce whether by static, ospf, bgp, etc, the PE is able to bind that route to the CE next-hop. IIRC, by learning at least one such a route the direct can be advertised when using vrf-target.  Note that in the event of a ping (coming in as mpls from the core) targeted to the PE's end of the direct vrf link, I believe that the packet is actually directed out the vrf-interface where the CE then routes it back. As the packet now arrives as native IP on the vrf interface, we can do the lookup and reply to the ping.  

With vrf-table we can advertise the direct w/o first learning a remote ce next hop. And the extra hop through the ce for a local pe vrf ping is avoided.

To clarify my previous wording, the vrf label identifies both the VRF and a particular pe-ce interface in that VRF. All routes learned over that pe-ce interface share the same label unless per-prefix-label is used.

HTHs

Regards

-----Original Message-----
From: Ger, Javier [mailto:jger at cablevision.com.ar] 
Sent: Wednesday, October 20, 2010 7:15 AM
To: Harry Reynolds; David Lockuan; Cristian Frizziero
Cc: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Problem of Forwarding on VPN using vrf-table-label.

Hello Harry,

Thank you for your valuable help. Your reply covers most of the questions I had related to this topic.

Could you possibly give me a feedback about why when the vrf-table-label is not configured the only direct routes (on multi-access) that are advertised are those having an active eBGP route through them? Since we have 2 BGP sessions to the CE (one per interface), I thought that regardless of whether the VRF has or not active routes through each interface, the behavior should be similar for both direct routes.

Thanks again.

Javier Ger.
Hornos 690 - Buenos Aires - Argentina
Tel +54.11.5530.4531
Cel +54.9.11.3926.5017
jger at cablevision.com.ar
www.cablevision.com.ar

-----Mensaje original-----
De: Harry Reynolds [mailto:harry at juniper.net] Enviado el: Martes, 19 de Octubre de 2010 12:39 p.m.
Para: Ger, Javier; David Lockuan; Cristian Frizziero
CC: juniper-nsp at puck.nether.net
Asunto: RE: [j-nsp] Problem of Forwarding on VPN using vrf-table-label.

This is as all as per design.

http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-10978770.html

By default the "route lookup" action for l3vpn is performed on the vrf label. This prevents IP L3 lookup and related functions like egress firewall and arp from occurring on multi-access (ethernet) vrf links. As a result the router will only advertise a label for a route that has a CE nexthop rewrite pre-populated.  Any route learned from the ce has such a next hop and is advertised (This assumed that vrf-target is set). 

Direct routes (on multi-access) do not have such a next hop and are therefore not advertised with a vrf label. Note again that this issue is not seen on p-t-p links, only ethernet due to ARP.

When you enable vrf-table-label a special block of labels are used (hence you see the label change); the key is these special labels allow the vrf_table->vrf mapping to occur at FPC ingress (where the label is popped), which in turns allows the route lookup to occur at layer 3. There is only one pass through the route lookup unless a tunnel pic is used (vt interface), and that lookup is either on the vrf label, or on the IP packet, depending upon the setting of vrf-table.

The L3 lookup allows arp (and egress FW filter) to be performed. The ability to arp for the next hop allows us to advertise a labeled route for the direct pe-ce vrf interface.

So, why not just make vrf-table a default? Because there are limits on core facing HW that can cause silent discard when the feature is not supported. See the link provided.

HTHs

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Ger, Javier
Sent: Tuesday, October 19, 2010 7:31 AM
To: David Lockuan; Cristian Frizziero
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Problem of Forwarding on VPN using vrf-table-label.

Dear community,

just to add some additional comments/questions about this topic.

We have 2 PE (logical systems) with 2 VRF belonging to same VPN (working with AFI IPv4 and SAFI VPNv4).
- VRF-A in PE1 has only 1 CE1 facing interface and a PE-CE eBGP session is established throught it.
- VRF-A within PE2 has 2 interfaces to CE2. There are 2 eBGP sessiones between both devices, one per interface.
- VRFs in both ends are using the vrf-target option, which should result in a default VRF policy that advertise all active routes in the VRF, including the directly connected routes from the PE-CE VRF interfaces. 

Based on the mentioned scenario we see the following behavior.
1- When vrf-table-label is not configured, the only direct routes we receive on the remote end are those having an active eBGP route (in other words, the next hop of the eBGP active route, pointing to the attached CE, belongs to /30 of the direct route being received).
2- When vrf-table-label is configured, every direct route is received on the remote, even those not having an active eBGP route.

I would like to have a better understanding about the reasons for the described behavior.

Any help would be much appreciated.

-----Mensaje original-----
De: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] En nombre de David Lockuan Enviado el: Sábado, 16 de Octubre de 2010 07:16 p.m.
Para: Cristian Frizziero
CC: juniper-nsp at puck.nether.net
Asunto: Re: [j-nsp] Problem of Forwarding on VPN using vrf-table-label.

Hi Cristian,

It is correct, I had 2 PE with 2 VPN. Sorry I don't send the configuration of both PE's. Just now I send you the both configurations.

I noted that when I used the command "vrf-table-label" the next-hop after the label lookup is to next-table of the VPN and when I don't used it the next-hop is the IP address or interface to face the CE router. Other things that I noted is the vpn-label on both PE is the same for each VPN and when I don't use the command the vpn-label is different for each VPN.

I send the output of my review. In this case I put only into VPN-A the command and the VPN-B is without the command.

Visite http://www.cablevision.com.ar

Visite http://www.fibertel.com.ar

___________________________________________________________________________

Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.

This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone. Many thanks.
___________________________________________________________________________

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Visite http://www.cablevision.com.ar

Visite http://www.fibertel.com.ar

___________________________________________________________________________

Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.

This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone. Many thanks.
___________________________________________________________________________

Visite http://www.cablevision.com.ar

Visite http://www.fibertel.com.ar

___________________________________________________________________________

Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.

This message is confidential. It may also contain information that is privileged or not
authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone. Many thanks.
___________________________________________________________________________