[j-nsp] next-hop address on LAN

Thomas Salmen tsalmen at orcon.net.nz
Thu Mar 9 04:27:41 EST 2006


Ah good stuff. Appreciate the pointers - this is exactly what I needed to
find. Solved things quite nicely. 

Cheers,
Thomas

> 
> VT interface is another way. Both are documented below:
> 
> https://www.juniper.net/techpubs/software/junos/junos75/swconfig75-
> vpns/html/vpnl3-config26.html#1072815
> 
> -harshit
> 
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> > Rafal Szarecki (WA/EPO)
> > Sent: Wednesday, March 08, 2006 11:37 PM
> > To: Ariff Premji
> > Cc: juniper-nsp at puck.nether.net
> > Subject: Re: [j-nsp] next-hop address on LAN
> >
> > 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
> > >
> > >
> >
> > _______________________________________________
> > 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