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

2010-10-20 Thread Ger, Javier 
Thanks a lot Harry.

Regards.

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


-Mensaje original-
De: Harry Reynolds [mailto:ha...@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@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:j...@cablevision.com.ar] 
Sent: Wednesday, October 20, 2010 7:15 AM
To: Harry Reynolds; David Lockuan; Cristian Frizziero
Cc: juniper-nsp@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
j...@cablevision.com.ar
www.cablevision.com.ar


-Mensaje original-
De: Harry Reynolds [mailto:ha...@juniper.net] Enviado el: Martes, 19 de Octubre 
de 2010 12:39 p.m.
Para: Ger, Javier; David Lockuan; Cristian Frizziero
CC: juniper-nsp@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-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 
bot

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

2010-10-20 Thread Harry Reynolds 
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:j...@cablevision.com.ar] 
Sent: Wednesday, October 20, 2010 7:15 AM
To: Harry Reynolds; David Lockuan; Cristian Frizziero
Cc: juniper-nsp@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
j...@cablevision.com.ar
www.cablevision.com.ar


-Mensaje original-
De: Harry Reynolds [mailto:ha...@juniper.net] Enviado el: Martes, 19 de Octubre 
de 2010 12:39 p.m.
Para: Ger, Javier; David Lockuan; Cristian Frizziero
CC: juniper-nsp@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-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 nex

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

2010-10-20 Thread Ger, Javier 
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
j...@cablevision.com.ar
www.cablevision.com.ar


-Mensaje original-
De: Harry Reynolds [mailto:ha...@juniper.net] 
Enviado el: Martes, 19 de Octubre de 2010 12:39 p.m.
Para: Ger, Javier; David Lockuan; Cristian Frizziero
CC: juniper-nsp@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-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 ea

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

2010-10-19 Thread Harry Reynolds 
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.ne

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

2010-10-19 Thread Ger, Javier 
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

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

2010-10-16 Thread David Lockuan 
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.

***
{master}
n...@mx960-lab-re0> ...cal-systems PE1 routing-instances | display set
set logical-systems PE1 routing-instances VPN-A instance-type vrf
set logical-systems PE1 routing-instances VPN-A interface ge-3/0/0.2400
set logical-systems PE1 routing-instances VPN-A route-distinguisher 100:10
set logical-systems PE1 routing-instances VPN-A vrf-import VPN-A-import
set logical-systems PE1 routing-instances VPN-A vrf-export VPN-A-export
set logical-systems PE1 routing-instances VPN-A vrf-target target:100:10
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-A routing-options static
route 172.20.0.0/24 next-hop 10.10.5.2
set logical-systems PE1 routing-instances VPN-B instance-type vrf
set logical-systems PE1 routing-instances VPN-B interface ge-3/0/0.2402
set logical-systems PE1 routing-instances VPN-B route-distinguisher 100:20
set logical-systems PE1 routing-instances VPN-B vrf-import VPN-B-import
set logical-systems PE1 routing-instances VPN-B vrf-export VPN-B-export
set logical-systems PE1 routing-instances VPN-B vrf-target target:100:20
set logical-systems PE1 routing-instances VPN-B routing-options static
route 192.168.0.0/24 next-hop 10.10.5.6

{master}
n...@mx960-lab-re0> ...ogical-systems PE2 routing-instances | display set
set logical-systems PE2 routing-instances VPN-A instance-type vrf
set logical-systems PE2 routing-instances VPN-A interface ge-3/0/0.2602
set logical-systems PE2 routing-instances VPN-A route-distinguisher 100:10
set logical-systems PE2 routing-instances VPN-A vrf-import VPN-A-import
set logical-systems PE2 routing-instances VPN-A vrf-export VPN-A-export
set logical-systems PE2 routing-instances VPN-A vrf-target target:100:10
set logical-systems PE2 routing-instances VPN-A vrf-table-label
set logical-systems PE2 routing-instances VPN-A routing-options static
route 172.20.1.0/24 next-hop 10.10.6.6
set logical-systems PE2 routing-instances VPN-B instance-type vrf
set logical-systems PE2 routing-instances VPN-B interface ge-3/0/0.2600
set logical-systems PE2 routing-instances VPN-B route-distinguisher 100:20
set logical-systems PE2 routing-instances VPN-B vrf-import VPN-B-import
set logical-systems PE2 routing-instances VPN-B vrf-export VPN-B-export
set logical-systems PE2 routing-instances VPN-B vrf-target target:100:20
set logical-systems PE2 routing-instances VPN-B routing-options static
route 192.168.1.0/24 next-hop 10.10.6.2

{master}
n...@mx960-lab-re0> ...te table VPN-A.inet.0 logical-system PE1 detail

VPN-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
10.10.5.0/30 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-3/0/0.2400, selected
State: 
Age: 2d 16:06:32
Task: IF
Announcement bits (1): 2-BGP RT Background
AS path: I

10.10.5.1/32 (1 entry, 0 announced)
*Local  Preference: 0
Next hop type: Local
Next-hop reference count: 8
Interface: ge-3/0/0.2400
State: 
Age: 2d 16:06:32
Task: IF
AS path: I

10.10.6.4/30 (1 entry, 1 announced)
*BGPPreference: 170/-101
Route Distinguisher: 100:10
Next hop type: Indirect
Next-hop reference count: 6
Source: 1.1.1.12
Next hop type: Router, Next hop index: 1048587
Next hop: 10.10.2.1 via ge-3/0/1.2000, selected
Label operation: Push 16, Push 299952(top)
Next hop: 10.10.2.5 via ge-3/0/1.2002
Label operation: Push 16, Push 299968(top)
Protocol next hop: 1.1.1.12
Push 16
Indirect next hop: 8ea0240 1048589
State: 
Local AS:   100 Peer AS:   100
Age: 3:07   Metric2: 1
Task: BGP_100.1.1.1.12+61440
Announcement bits (1): 1-KRT
AS path: I
Communities: target:100:10
Import Accepted
VPN Label: 16

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

2010-10-15 Thread Cristian Frizziero 

 Ok Nilesh,

Thank you very much, I had a wrong concept in my head.

I think that David is working with a lab where he has 2 VPNs in PE1, and 
there will be a second PE with VPN-A and VPN-B too.


The issue he is seeing is between the CEs of VPN-A connected to PE1 and PE2.

David, can you confirm this to me?

Thanks

logo impre
Ing. Cristian Frizziero
Padilla 448 -- Buenos Aires
Tel +54.11.5291.9150 (Ext.517)
Cel +54.9.11.6249.1303
cristian.frizzi...@iquall.net 
www.iquall.net 


El 15/10/2010 13:55, Nilesh Khambal escribió:

Hi Cristian,

JUNOS does not send label per prefix. It is always one label per vrf.
vrf-table-label enables special handling for the packets destined to the vrf
w/ vrf-table-label enabled in the egress PE on its core facing PFEs (PE->P
link). It avoids the double lookups needed for multi-access segments such as
Ethernet between PE and CE (one for the VPN label and the second one for ARP
as you mentioned). It also sends a unique label range to enable this special
handling.

David: I don't understand. Why both VPN-A and VPN-B are part of same
logical-system?


set logical-systems PE1 routing-instances VPN-A instance-type vrf
set logical-systems PE1 routing-instances VPN-B instance-type vrf

If you are planning to simulate the two different PE routers, don't you
think these 2 vrfs should be part of 2 different logical systems?

Thanks,
Nilesh.

On 10/15/10 5:36 AM, "Cristian Frizziero"
wrote:


   Hy David!!!

I understand that the statement vpn-table-label allow PE to announce a
different label for every VPN route of a VRF. In this way, in the
forwarding plane we can avoid a lookup, which is very useful in the case
of multipoint interfaces, such as ETH. The point is that multipoint
interfaces normally need a specific lookup for ARP resolution, and only
we can perform 3 lookups on the PE.

With vpn-table-label, 3 lookups will be enough to reach the final
destination.

I hope this will help.

logo impre
Ing. Cristian Frizziero
Padilla 448 -- Buenos Aires
Tel +54.11.5291.9150 (Ext.517)
Cel +54.9.11.6249.1303
cristian.frizzi...@iquall.net
www.iquall.net


El 14/10/2010 21:43, David Lockuan escribió:

Hi guys,

I have been doing a lab with a MX960 with release 10.0R3.10, I set a
topology with logical-systems, in theory all it is working because I can see
the routes of VRF into table bgp.l3vpn.0 but the forwarding between the CE
is not working. This is the configuration of the routing-instance of PE:



*>>
*

set logical-systems PE1 routing-instances VPN-A instance-type vrf
set logical-systems PE1 routing-instances VPN-A interface ge-3/0/0.2400
set logical-systems PE1 routing-instances VPN-A route-distinguisher 100:10
set logical-systems PE1 routing-instances VPN-A vrf-import VPN-A-import
set logical-systems PE1 routing-instances VPN-A vrf-export VPN-A-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-A vrf-target target:100:10
set logical-systems PE1 routing-instances VPN-A routing-options static route
172.20.0.0/24 next-hop 10.10.5.2
set logical-systems PE1 routing-instances VPN-B instance-type vrf
set logical-systems PE1 routing-instances VPN-B interface ge-3/0/0.2402
set logical-systems PE1 routing-instances VPN-B route-distinguisher 100:20
set logical-systems PE1 routing-instances VPN-B vrf-import VPN-B-import
set logical-systems PE1 routing-instances VPN-B vrf-export VPN-B-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-B vrf-target target:100:20
set logical-systems PE1 routing-instances VPN-B routing-options static route
192.168.0.0/24 next-hop 10.10.5.6


*>>
*

But when I unset the command of vrf-table-label, the forwarding between
CE's, it works correctly.

Someone know when it is necessary to used the command "vrf-table-label"? The
only diferent that I found it was in the VPN label. When the command
"vrf-table-label" is set, the vpn label is 16 or in the range of 16 - 1023.
And when the command is not set, the vpn label is 30 or in the range of
10 - 1048075.

Thanks in advance,

Best regards,


___
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

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

2010-10-15 Thread Nilesh Khambal 
Hi Cristian,

JUNOS does not send label per prefix. It is always one label per vrf.
vrf-table-label enables special handling for the packets destined to the vrf
w/ vrf-table-label enabled in the egress PE on its core facing PFEs (PE->P
link). It avoids the double lookups needed for multi-access segments such as
Ethernet between PE and CE (one for the VPN label and the second one for ARP
as you mentioned). It also sends a unique label range to enable this special
handling.

David: I don't understand. Why both VPN-A and VPN-B are part of same
logical-system? 

>> set logical-systems PE1 routing-instances VPN-A instance-type vrf

>> set logical-systems PE1 routing-instances VPN-B instance-type vrf

If you are planning to simulate the two different PE routers, don't you
think these 2 vrfs should be part of 2 different logical systems?

Thanks,
Nilesh. 

On 10/15/10 5:36 AM, "Cristian Frizziero" 
wrote:

>   Hy David!!!
> 
> I understand that the statement vpn-table-label allow PE to announce a
> different label for every VPN route of a VRF. In this way, in the
> forwarding plane we can avoid a lookup, which is very useful in the case
> of multipoint interfaces, such as ETH. The point is that multipoint
> interfaces normally need a specific lookup for ARP resolution, and only
> we can perform 3 lookups on the PE.
> 
> With vpn-table-label, 3 lookups will be enough to reach the final
> destination.
> 
> I hope this will help.
> 
> logo impre
> Ing. Cristian Frizziero
> Padilla 448 -- Buenos Aires
> Tel +54.11.5291.9150 (Ext.517)
> Cel +54.9.11.6249.1303
> cristian.frizzi...@iquall.net 
> www.iquall.net 
> 
> 
> El 14/10/2010 21:43, David Lockuan escribió:
>> Hi guys,
>> 
>> I have been doing a lab with a MX960 with release 10.0R3.10, I set a
>> topology with logical-systems, in theory all it is working because I can see
>> the routes of VRF into table bgp.l3vpn.0 but the forwarding between the CE
>> is not working. This is the configuration of the routing-instance of PE:
>> 
>> 
*>>
*
>> set logical-systems PE1 routing-instances VPN-A instance-type vrf
>> set logical-systems PE1 routing-instances VPN-A interface ge-3/0/0.2400
>> set logical-systems PE1 routing-instances VPN-A route-distinguisher 100:10
>> set logical-systems PE1 routing-instances VPN-A vrf-import VPN-A-import
>> set logical-systems PE1 routing-instances VPN-A vrf-export VPN-A-export
>> set logical-systems PE1 routing-instances VPN-A vrf-table-label
>> set logical-systems PE1 routing-instances VPN-A vrf-target target:100:10
>> set logical-systems PE1 routing-instances VPN-A routing-options static route
>> 172.20.0.0/24 next-hop 10.10.5.2
>> set logical-systems PE1 routing-instances VPN-B instance-type vrf
>> set logical-systems PE1 routing-instances VPN-B interface ge-3/0/0.2402
>> set logical-systems PE1 routing-instances VPN-B route-distinguisher 100:20
>> set logical-systems PE1 routing-instances VPN-B vrf-import VPN-B-import
>> set logical-systems PE1 routing-instances VPN-B vrf-export VPN-B-export
>> set logical-systems PE1 routing-instances VPN-A vrf-table-label
>> set logical-systems PE1 routing-instances VPN-B vrf-target target:100:20
>> set logical-systems PE1 routing-instances VPN-B routing-options static route
>> 192.168.0.0/24 next-hop 10.10.5.6
>> 
*>>
*
>> But when I unset the command of vrf-table-label, the forwarding between
>> CE's, it works correctly.
>> 
>> Someone know when it is necessary to used the command "vrf-table-label"? The
>> only diferent that I found it was in the VPN label. When the command
>> "vrf-table-label" is set, the vpn label is 16 or in the range of 16 - 1023.
>> And when the command is not set, the vpn label is 30 or in the range of
>> 10 - 1048075.
>> 
>> Thanks in advance,
>> 
>> Best regards,
>> 
> ___
> 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

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

2010-10-15 Thread Cristian Frizziero 

 Hy David!!!

I understand that the statement vpn-table-label allow PE to announce a 
different label for every VPN route of a VRF. In this way, in the 
forwarding plane we can avoid a lookup, which is very useful in the case 
of multipoint interfaces, such as ETH. The point is that multipoint 
interfaces normally need a specific lookup for ARP resolution, and only 
we can perform 3 lookups on the PE.


With vpn-table-label, 3 lookups will be enough to reach the final 
destination.


I hope this will help.

logo impre
Ing. Cristian Frizziero
Padilla 448 -- Buenos Aires
Tel +54.11.5291.9150 (Ext.517)
Cel +54.9.11.6249.1303
cristian.frizzi...@iquall.net 
www.iquall.net 


El 14/10/2010 21:43, David Lockuan escribió:

Hi guys,

I have been doing a lab with a MX960 with release 10.0R3.10, I set a
topology with logical-systems, in theory all it is working because I can see
the routes of VRF into table bgp.l3vpn.0 but the forwarding between the CE
is not working. This is the configuration of the routing-instance of PE:

**
set logical-systems PE1 routing-instances VPN-A instance-type vrf
set logical-systems PE1 routing-instances VPN-A interface ge-3/0/0.2400
set logical-systems PE1 routing-instances VPN-A route-distinguisher 100:10
set logical-systems PE1 routing-instances VPN-A vrf-import VPN-A-import
set logical-systems PE1 routing-instances VPN-A vrf-export VPN-A-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-A vrf-target target:100:10
set logical-systems PE1 routing-instances VPN-A routing-options static route
172.20.0.0/24 next-hop 10.10.5.2
set logical-systems PE1 routing-instances VPN-B instance-type vrf
set logical-systems PE1 routing-instances VPN-B interface ge-3/0/0.2402
set logical-systems PE1 routing-instances VPN-B route-distinguisher 100:20
set logical-systems PE1 routing-instances VPN-B vrf-import VPN-B-import
set logical-systems PE1 routing-instances VPN-B vrf-export VPN-B-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-B vrf-target target:100:20
set logical-systems PE1 routing-instances VPN-B routing-options static route
192.168.0.0/24 next-hop 10.10.5.6
**
But when I unset the command of vrf-table-label, the forwarding between
CE's, it works correctly.

Someone know when it is necessary to used the command "vrf-table-label"? The
only diferent that I found it was in the VPN label. When the command
"vrf-table-label" is set, the vpn label is 16 or in the range of 16 - 1023.
And when the command is not set, the vpn label is 30 or in the range of
10 - 1048075.

Thanks in advance,

Best regards,


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2010-10-14 Thread David Lockuan 
Hi guys,

I have been doing a lab with a MX960 with release 10.0R3.10, I set a
topology with logical-systems, in theory all it is working because I can see
the routes of VRF into table bgp.l3vpn.0 but the forwarding between the CE
is not working. This is the configuration of the routing-instance of PE:

**
set logical-systems PE1 routing-instances VPN-A instance-type vrf
set logical-systems PE1 routing-instances VPN-A interface ge-3/0/0.2400
set logical-systems PE1 routing-instances VPN-A route-distinguisher 100:10
set logical-systems PE1 routing-instances VPN-A vrf-import VPN-A-import
set logical-systems PE1 routing-instances VPN-A vrf-export VPN-A-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-A vrf-target target:100:10
set logical-systems PE1 routing-instances VPN-A routing-options static route
172.20.0.0/24 next-hop 10.10.5.2
set logical-systems PE1 routing-instances VPN-B instance-type vrf
set logical-systems PE1 routing-instances VPN-B interface ge-3/0/0.2402
set logical-systems PE1 routing-instances VPN-B route-distinguisher 100:20
set logical-systems PE1 routing-instances VPN-B vrf-import VPN-B-import
set logical-systems PE1 routing-instances VPN-B vrf-export VPN-B-export
set logical-systems PE1 routing-instances VPN-A vrf-table-label
set logical-systems PE1 routing-instances VPN-B vrf-target target:100:20
set logical-systems PE1 routing-instances VPN-B routing-options static route
192.168.0.0/24 next-hop 10.10.5.6
**
But when I unset the command of vrf-table-label, the forwarding between
CE's, it works correctly.

Someone know when it is necessary to used the command "vrf-table-label"? The
only diferent that I found it was in the VPN label. When the command
"vrf-table-label" is set, the vpn label is 16 or in the range of 16 - 1023.
And when the command is not set, the vpn label is 30 or in the range of
10 - 1048075.

Thanks in advance,

Best regards,

-- 
David.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp