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-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ger, Javier Sent: Tuesday, October 19, 2010 7:31 AM To: David Lockuan; Cristian Frizziero Cc: juniper-nsp@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-boun...@puck.nether.net [mailto:juniper-nsp-boun...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
