[j-nsp] next-hop address on LAN

Rafal Szarecki (WA/EPO) rafal.szarecki at ericsson.com
Thu Mar 9 02:37:08 EST 2006


Ofcourse vrf-table-label works also, but this is not just replacement.

The difference is how egress PE takes forwarding decision. With vrf-table-lable label is stripped and then vrf makes regular IP lookup. With static routes, PE nake decission base on inner label and then behave as penultimate hop (make PHP). So logically LSP egress is not PE but CE.

VRF-table-lable has following limitation:
- not all types of uplink configuration (core interfaces) are supported
- even more limitation on core interface if LR are used
- if you configure Hub-end-Spoke or central services VPN, then skokes can communicate each oder via hub vrf, but without touching hub CE.  (spokes have different route-targets). 

Rafal

> -----Original Message-----
> From: Ariff Premji [mailto:premji at speakeasy.net] 
> Sent: Thursday, March 09, 2006 8:23 AM
> To: Rafal Szarecki (WA/EPO)
> Cc: Thomas Salmen; juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] next-hop address on LAN
> 
> Thomas,
> Add the vrf-table-label command to you VPN config and you 
> should be all set (on the VPN that has the GE):
> 
> >> routing-instances {
> >>     test_vpn {
> >>         instance-type vrf;
> >>         interface ge-1/3/0.205;
>             vrf-table-label                 <---*****
> >>         route-distinguisher 65001:1001;
> >>         vrf-target target: 65001:1001;
> >>     }
> >> }
> 
> 
> The method Rafal indicated below has been replaced with this knob:
> 
> http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-
> vpns/html/vpnl3-config25.html#1141682
> 
> Hths,
> 
> -Ariff
> 
> On Mar 8, 2006, at 11:14 PM, Rafal Szarecki ((WA/EPO)) wrote:
> 
> > Hi,
> >
> > You need hack. You have to have some routing in  VRF. Can be static 
> > one. So try to add:
> >
> >  routing-instances {
> >      test_vpn {
> >         routing-option {
> > 	static {
> > 		route <CE-address/32> next-hop <CE-address/32>;
> >      }
> >  }
> >
> > Stiupid but should work.
> > The reason is that in RFC2546bis CE is mandatory ad is a *router*, 
> > thus on vrf you have to have routing to networks behind.
> > Fore some reason JUNOS do not assign lable to connected 
> networks but 
> > only to this routed via static or dynamic routing.
> >
> > This is behaviour specififc for multiaccess links (ethernet), and 
> > never happen on p-t-p like ATM VC.
> >
> > Rafał Jan Szarecki JNCIE #136
> > Senior Consultant - Datacom Networks
> > Ericsson Poland EPO/S/D
> > Office: +48 22 6916635
> > ECN:    837 6635
> > Mobile: +48 602418971
> > Skype: callto://Rafal_Szarecki <callto://Rafal_Szarecki/>
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: juniper-nsp-bounces at puck.nether.net
> >> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Thomas 
> >> Salmen
> >> Sent: Thursday, March 09, 2006 5:07 AM
> >> To: juniper-nsp at puck.nether.net
> >> Subject: [j-nsp] next-hop address on LAN
> >>
> >>
> >> Hello,
> >>
> >> Can anybody suggest what the following might mean?
> >>
> >>
> >> thomas at nct_ar3# run show route advertising-protocol bgp
> >> 172.16.8.2 extensive
> >>
> >>
> >> orcon_vpn.inet.0: 3 destinations, 3 routes (3 active, 0 
> holddown, 0 
> >> hidden)
> >>
> >> * 10.78.1.0/30 (1 entry, 1 announced)  BGP group internal type 
> >> Internal
> >>      Route Distinguisher: 65001:1001
> >>      BGP label allocation failure: Need a nexthop address on LAN  
> >> <---- this
> >>      Nexthop: Self
> >>      Flags: Nexthop Change
> >>      Localpref: 100
> >>      AS path: I
> >>      Communities: target: 65001:1001
> >>
> >>
> >> I'm configuring a VPN between two M-series, cr2 and ar3. The VPN 
> >> consists of and ATM PVC connected to cr2 and a GE 
> interface connected 
> >> to ar3, static routing only.
> >>
> >>
> >>
> >> ar3 is learning connected routes for the ATM interface from cr2:
> >>
> >> thomas at nct_ar3# run show route table test_vpn
> >>
> >> orcon_vpn.inet.0: 3 destinations, 3 routes (3 active, 0 
> holddown, 0 
> >> hidden)
> >> + = Active Route, - = Last Active, * = Both
> >>
> >> 10.78.1.0/30       *[Direct/0] 03:06:58
> >>> via ge-1/3/0.205
> >> 10.78.1.1/32       *[Local/0] 03:07:00
> >>                       Local via ge-1/3/0.205
> >> 10.240.1.0/30      *[BGP/170] 00:02:54, localpref 100, from  
> >> 172.16.8.2
> >>                       AS path: I
> >>> to 172.16.9.4 via ge-1/3/0.200,
> >> label-switched-path
> >> pe_nct_cr2
> >>
> >>
> >>
> >>
> >> However cr2 isn't learning VPN routes from ar3:
> >>
> >> thomas at nct_m02# run show route table test_vpn
> >>
> >> orcon_vpn.inet.0: 2 destinations, 2 routes (2 active, 0 
> holddown, 0 
> >> hidden)
> >> + = Active Route, - = Last Active, * = Both
> >>
> >> 10.240.1.0/30      *[Direct/0] 2w4d 11:39:19
> >>> via at-0/1/1.100
> >> 10.240.1.1/32      *[Local/0] 2w4d 11:39:26
> >>                       Local via at-0/1/1.100
> >>
> >>
> >>
> >>
> >> And I can't figure out why. ar3 Config:
> >>
> >> rsvp {
> >>     traceoptions {
> >>         file log.rsvp;
> >>         flag packets;
> >>     }
> >>     interface ge-1/3/0.200;
> >> }
> >> mpls {
> >>     label-switched-path pe_nct_cr2 {
> >>         to 172.16.8.2;
> >>     }
> >>     label-switched-path pe_nct_erx02 {
> >>         to 172.16.8.15;
> >>     }
> >>     interface ge-1/3/0.200;
> >> }
> >> bgp {
> >>     group internal {
> >>         local-address 172.16.8.8;
> >>         family inet {
> >>             unicast;
> >>         }
> >>         family inet-vpn {
> >>             unicast;
> >>         }
> >>         peer-as 65001;
> >>         local-as 65001;
> >>         neighbor 172.16.8.2 {
> >>             import ibgp_reflector_import;
> >>             export ibgp_reflector_export;
> >>         }
> >>     }
> >> }
> >>
> >> routing-instances {
> >>     test_vpn {
> >>         instance-type vrf;
> >>         interface ge-1/3/0.205;
> >>         route-distinguisher 65001:1001;
> >>         vrf-target target: 65001:1001;
> >>     }
> >> }
> >>
> >>
> >> interfaces {
> >>     ge-1/3/0 {
> >>         vlan-tagging;
> >>         mtu 9000;
> >>         unit 200 {
> >>             description "Core Interface";
> >>             vlan-id 200;
> >>             family inet {
> >>                 address 172.16.9.8/26;
> >>             }
> >>             family mpls;
> >>         }
> >>         unit 205 {
> >>             description "Test Interface";
> >>             vlan-id 205;
> >>             family inet {
> >>                 address 10.78.1.1/30;
> >>             }
> >>         }
> >>     }
> >>     lo0 {
> >>         unit 0 {
> >>             family inet {
> >>                 filter {
> >>                     input filter_re;
> >>                 }
> >>                 address 172.16.8.8/32;
> >>                 address 127.0.0.1/32;
> >>             }
> >>         }
> >>     }
> >> }
> >>
> >>
> >>
> >> Appreciate any advice.
> >>
> >> Cheers,
> >> Thomas
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> >> http://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net 
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 



More information about the juniper-nsp mailing list