Subject: [mpls] LSP traceroute failure with Inter-AS MPLS

From: "Ilya Varlashkin" <[email-masked]>
Date: Wed, 14 Apr 2010 16:43:57 +0200

Hi,

I was doing some LSP traceroutes across AS boundaries (on real-world
network) and missed replies from some intermediate routers in the target
AS. Digging a bit deeper I've found following: if some AS has BGP-free
core and its internal (core) routers don't have routing information for
foreign prefixes, then these internal routers won't be able to send LSP
Echo Replies to originator of the traceroute. Normal end-to-end traffic
is delivered without problems both ways because PE routers in such AS
put two labels on the stack (using labelled-unicast) when sending
packets towards foreign routers, so core routers don't have to know how
to reach foreign PE.

Before going to our routers' vendor I've looked through RFC4379 once
more to check whether it's an implementation or specification issue. It
looks like there is nothing in RFC to address above mentioned scenario,
so looks like specification issue. 

Similar problem with normal traceroute within MPLS L3VPN environment is
addressed by ICMP-tunnelling trick - forwarding ICMP message along the
same path as original packet that caused generation of that ICMP
message. Wouldn't the same approach work with LSP ping? All what's
needed, from protocol PoV, is to say that if an intermediate router (not
final destination!) needs to send a reply (because TTL expired) doesn't
have route back to originator of LSP ECHO then it should send reply
along the same path as original LSP ECHO. I.e. if PE1 sends LSP ECHO
request to PE2 over intermediate router P, and P would use label L1 and
interface INTF1 to send packets towards PE2, then P should also use
label L1 and interface INTF1 when it needs to send replies back to PE1.
Would doing so cause any problems? If not, should we ammend
specification of LSP ping/traceroute?

Cheers,
iLya

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 14 Apr 2010 13:27:25 -0700

Hi Ilya,

   There is an expired draft by George Swallow & Tom Nadeau that tries to
address the problem you are encountering.

  mpls-tunneling will not help. Mainly because lsp-traceroute is used as a
diagnostic tool to detect where a failure is in the network. If there is a failure
in the network, then the echo request/response will unlikely make it to the 
egress PE.

  So for fault isolation, you need the transit nodes to respond back. How they
respond back is theorized in the above mentioned draft.

Thanks
Nitin  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ilya Varlashkin
> Sent: Wednesday, April 14, 2010 7:44 AM
> To: IETF MPLS
> Subject: [mpls] LSP traceroute failure with Inter-AS MPLS
> 
> Hi,
> 
> network) and missed replies from some intermediate routers in 
> the target AS. Digging a bit deeper I've found following: if 
> some AS has BGP-free core and its internal (core) routers 
> don't have routing information for foreign prefixes, then 
> these internal routers won't be able to send LSP Echo Replies 
> to originator of the traceroute. Normal end-to-end traffic is 
> delivered without problems both ways because PE routers in 
> such AS put two labels on the stack (using labelled-unicast) 
> when sending packets towards foreign routers, so core routers 
> don't have to know how to reach foreign PE.
> 
> Before going to our routers' vendor I've looked through 
> RFC4379 once more to check whether it's an implementation or 
> specification issue. It looks like there is nothing in RFC to 
> address above mentioned scenario, so looks like specification issue. 
> 
> Similar problem with normal traceroute within MPLS L3VPN 
> environment is addressed by ICMP-tunnelling trick - 
> forwarding ICMP message along the same path as original 
> packet that caused generation of that ICMP message. Wouldn't 
> the same approach work with LSP ping? All what's needed, from 
> protocol PoV, is to say that if an intermediate router (not 
> final destination!) needs to send a reply (because TTL 
> expired) doesn't have route back to originator of LSP ECHO 
> then it should send reply along the same path as original LSP 
> ECHO. I.e. if PE1 sends LSP ECHO request to PE2 over 
> intermediate router P, and P would use label L1 and interface 
> INTF1 to send packets towards PE2, then P should also use 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 14 Apr 2010 23:13:44 +0200

Hi Nitin,

>  mpls-tunneling will not help. Mainly because lsp-traceroute is used as a
...

I thought about that, but then better something than nothing at all. After all traceroute in VPN environment is used for the same purpose and it's quite useful because problem is not necessarily complete loss of connectivity but e.g. packet loss.

Do you have pointer to the draft?

/iLya

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 14 Apr 2010 17:05:03 -0700

http://tools.ietf.org/html/draft-ietf-mpls-interas-lspping-00

Thanks
Nitin  

> From: Ilya Varlashkin [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 2:14 PM
> To: Nitin Bahadur
> Cc: IETF MPLS
> Subject: Re: LSP traceroute failure with Inter-AS MPLS
> 
> Hi Nitin,
> 
> >   There is an expired draft by George Swallow & Tom Nadeau 
> that tries 
> > to address the problem you are encountering.
> > 
> >  mpls-tunneling will not help. Mainly because 
> lsp-traceroute is used 
> > as a
> ...
> 
> I thought about that, but then better something than nothing 
> at all. After all traceroute in VPN environment is used for 
> the same purpose and it's quite useful because problem is not 
> necessarily complete loss of connectivity but e.g. packet loss.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 15 Apr 2010 07:34:48 -0400

Yes, for reference, the draft is called draft-nadeau-mpls-interas-lspping-03.txt

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 15 Apr 2010 07:35:54 -0400

Yes, this one is correct. Sorry, disregard my last pointer.

	--Tom

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 15 Apr 2010 13:55:46 +0200

> Behalf Of Thomas Nadeau
> Sent: Thursday, April 15, 2010 1:36 PM
> To: Nitin Bahadur
> Cc: IETF MPLS; Ilya Varlashkin
> Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS
> 
> 
Thomas,

why have you abandoned that draft? Would it be possible to revive it?

/iLya

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 15 Apr 2010 08:30:59 -0400

From my end, I think it got lost in the shuffle when I changed employers, 
so there was no loss in interest per se. In any event, it is a WG draft, so its up 
to the WG on the status.  

	--Tom

---

From: Mark Tinka <[email-masked]>
Date: Fri, 16 Apr 2010 00:35:54 +0800

On Wednesday 14 April 2010 10:43:57 pm Ilya Varlashkin 
wrote:

> Digging a bit
>  deeper I've found following: if some AS has BGP-free
>  core and its internal (core) routers don't have routing
>  information for foreign prefixes, then these internal
>  routers won't be able to send LSP Echo Replies to
>  originator of the traceroute.

Operationally, we run a BGP-free core (free of IPv4 BGP, but 
full IPv6 routing table, of course) where IPv4 traffic is 
switched purely on MPLS labels.

We have a mix of Cisco and Juniper routers that support 
traceroute feedback from the core to sources that are 
external to our AS.

This has worked with us in Cisco IOS since Day One, but we 
had a few challenges with the JUNOS code for this, which was 
later fixed + explicit enabling of ICMP-Tunneling required. 
All is well in our land, now.

Obviously, we currently can't ping core routers from an 
external AS and expect a response, but traceroute works.

I haven't had a chance to read Thomas and George's draft 
until now, although our BGP-free core was erected around the 
same time this draft was initially written/published, so I'm 
not sure if my feedback is even useful. But I'll study it 
and see if there's anything I can add, if necessary, based 
on what we've seen in the wild.

Cheers,

Mark.