Ciscos, BGP, L2TPV3 pseudowires and loopback IPs

Seth ssscud at yahoo.com
Fri Nov 12 04:52:12 UTC 2010


With the latest IOS you MUST use loopback addresses or the Tunnel will not form, regardless of the class settings especially if using a L3 router temination device(s).
SRR


--- On Thu, 11/11/10, Jeff Saxe <jsaxe at briworks.com> wrote:

> From: Jeff Saxe <jsaxe at briworks.com>
> Subject: RE: Ciscos, BGP, L2TPV3 pseudowires and loopback IPs
> To: "nanog at nanog.org" <nanog at nanog.org>, "James Smallacombe" <up at 3.am>
> Date: Thursday, November 11, 2010, 4:29 AM
> Agreed: We used to use L2TPv3 tunnels
> fairly often to provide nailed-up private VLAN services to
> clients when we could only procure a Layer 3 circuit from
> another provider. They're pretty simple to set up and work
> reliably, although you may need to maintain both ends of the
> L2TPv3 at approximately matching IOS versions... at one
> point we had a perfectly working customer, then I upgraded a
> router at one end of the tunnel, and they suddenly had
> major, unexplainable packet loss all through the day. After
> I upgraded the other end, it returned to working fine.
> 
> But yeah, you don't really need a loopback. We routinely
> terminated the tunnels on the WAN address closest to the
> Internet. I think the only time I had to introduce a
> loopback was when one router was a tunnel terminator for two
> far-end locations, and when I tried to configure the second
> peer it complained at me. Also one time I wanted to have two
> parallel tunnels between the same source and destination
> routers (which is perfectly fine, because it has a tunnel
> discriminator number that keeps the two customers' traffic
> separate), except I also wanted to do some fancy QoS
> prioritization on one of them. By the time the traffic hits
> the WAN interface, the tunnel discriminator is buried too
> far down in the packet to use any "match" statements in the
> QoS, so I made one of the tunnels have a separate L2TPv3
> endpoint on each router, and then I could just match on
> destination IP address.
> 
> But that was a weird edge case. Most of the time we just
> used the outside Internet address, either T1 or Ethernet.
> Email me back privately if you want me to dig up the configs
> out of our CatTools archive.
> 
> -- Jeff Saxe
> Blue Ridge InternetWorks
> Charlottesville, VA
> 
> 
> ________________________________________
> From: David Freedman [david.freedman at uk.clara.net]
> Sent: Wednesday, November 10, 2010 1:22 PM
> To: nanog at nanog.org
> Subject: Re: Ciscos, BGP, L2TPV3 pseudowires and loopback
> IPs
> 
> e.
> >
> > We will need to set up a L2TPV3 tunnel to their old
> location (single
> > homed, no BGP on that side).  Upon initial
> reading of Cisco docs to do
> > this, we will need a routable IP on a loopback
> interface for starters.
> 
> I'm pretty sure this is just a recommendation based on good
> practise
> (routeability to endpoints), I'm sure since you are not
> multihomed you
> can just use "ip local interface WAN1" and be done with it,
> I seem to
> remember doing something similar in an l2tpv3 pw class and
> it working.
> 
> 
> 
> > Using one from the /24 LAN is out unless we subnet it,
> which we don't
> > want to do.
> >
> > So the question is, can I just "move" the PTP IP
> address x.x.129.174
> > from the WAN interface to the loopback like this?
> >
> >  interface Loopback0
> >   ip address x.x.129.174
> 255.255.255.252  (that's the mask we're using on
> >         
>    the WAN- Cisco's loopback examples show
> .255)
> >
> >  interface WAN1 (actually a gigether)
> >   ip unnumbered loopback0  (or no
> ip addr?)
> >
> >  neighbor x.x.128.173 update-source Loopback0
> 
> No, if you were to do this you should get a new transfer
> network, you
> can't have the same address on two interfaces (and in fact,
> you should
> really be stealing an address from your internal /24 which
> doesn't
> require any re-subnetting (if you are happy for this
> address to be
> unreachable) and it should have a /32 mask...
> 
> --
> 
> 
> David Freedman
> Group Network Engineering
> Claranet Group
> 
> 
> 
> 


      




More information about the NANOG mailing list