[j-nsp] Weird traceroute across MPLS core using labeled-unicastIBGP

Mon Mar 8 13:37:34 EST 2004

I will investigate a PR on the monitor traffic. Does seem broke. I will let
you know.

I think I might have an idea about what is happening with the monitor
traffic.

Note that below is based on an M5/M20 with Non-EFPC and JUNOS 6.2R1.5

1. If the traffic is sourced from the CE, then monitor traffic does not
function on PE/P routers (as you know.) On traffic from/to the CE there is
no MPLS/VPN encapsulation, again as I am sure that you know.

2. If you ping/traceroute from the local PE, say PE-1, to the remote VRF
interface or CE, then the path of the ICMP traffic is from the local PE to
remote PE via mpls forwarding. When the remote PE/CE responds to the ping or
traceroute the returning traffic, even though addressed to the VRF interface
on the local PE, is *not* initially processed by the local PE. Instead, the
local PE pops the label and forwards the traffic to the local CE, which then
routes the traffic back to the local PE where the response traffic is
detected. Note that the traffic coming back from the remote PE/CE is handled
as transit traffic so tcpdump at the local PE core-facing interface will not
display the response traffic.

3. My testing shows that ping/traceroute traffic originated by the local PE
can be monitored on the core-facing interface. Note the absence of response
traffic in the captures, despite the test succeeding.

My Set up is:

CE	PE	  p	    PE	CE
hk-----sj-----de-------mo-----am
	     ^
	so-0/1/1			192.168.24.1

<<<< this is a ping; note TTL is max in both labels:

lab at San_Jose> monitor traffic interface so-0/1/1 
verbose output suppressed, use <detail> or <extensive> for full protocol
decode
Listening on so-0/1/1, capture size 96 bytes

11:26:41.670041 Out IP 10.0.0.1 > 10.0.0.2: RSVP Hello Message, length: 32
11:26:41.689727  In IP 10.0.0.2 > 10.0.0.1: RSVP Hello Message, length: 32
11:26:43.640057 Out IP 10.0.0.1 > 224.0.0.5: OSPFv2 Hello length: 48
11:26:43.959927 Out LCP echo request            (type 0x09  id 0x5f  len
0x0008)
11:26:43.960592  In LCP echo reply              (type 0x0a  id 0x5f  len
0x0008)
11:26:45.321345 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 255), IP, length: 92
11:26:45.322972 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 255), IP, length: 92
11:26:45.324342 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 255), IP, length: 92
11:26:45.325340 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 255), IP, length: 92
11:26:45.326340 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 255), IP, length: 92
11:26:45.509691  In IP 10.0.0.2 > 224.0.0.5: OSPFv2 Hello length: 48
^C
13 packets received by filter
0 packets dropped by kernel

<<< This is a traceroute. Note TTL of 1 in VRF lable:

lab at San_Jose> monitor traffic interface so-0/1/1    
verbose output suppressed, use <detail> or <extensive> for full protocol
decode
Listening on so-0/1/1, capture size 96 bytes

11:27:45.440623 Out IP 10.0.0.1 > 10.0.0.2: RSVP Hello Message, length: 32
11:27:45.458275  In IP 10.0.0.2 > 10.0.0.1: RSVP Hello Message, length: 32
11:27:46.068161 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 1), IP, length: 48
11:27:46.071253 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 1), IP, length: 48
11:27:46.072192 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 1), IP, length: 48
11:27:46.073151 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 2), IP, length: 48
11:27:46.075589 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 2), IP, length: 48
11:27:46.077168 Out MPLS (label 100048, exp 7, ttl 255) (label 100064, exp
0, [S], ttl 2), IP, length: 48
11:27:46.530655 Out IP 10.0.0.1 > 224.0.0.5: OSPFv2 Hello length: 48
11:27:50.318223  In IP 10.0.0.2 > 224.0.0.5: OSPFv2 Hello length: 48

[edit]
lab at San_Jose# run show version 
Hostname: San_Jose
Model: m20
JUNOS Base OS boot [6.2R1.5]
JUNOS Base OS Software Suite [6.2R1.5]

HTHs.

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of 
> Daniel Roesen
> Sent: Monday, March 08, 2004 9:07 AM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Weird traceroute across MPLS core using 
> labeled-unicastIBGP
> 
> 
> On Mon, Mar 08, 2004 at 08:52:48AM -0800, harry wrote:
> > You should be able to monitor locally generated/terminated VPN 
> > traffic.
> 
> Well, but I can see only the ICMP TTL exceeded coming back 
> via native (non-MPLS) forwarding, but I don't see the 
> traceroute probes. This is by "monitor traffic interface 
> ge-0/0/0.100" which is the interface both the LSP and native 
> forwarding goes via.
> 
> > Not sure about the default to fxp0.0; I get the same behavior...
> 
> Can you open a PR about that?
> 
> > Curious as to why you would monitor fxp0 for VPN traffic.
> 
> My comment regarding fxp0 was not regarding the traceroute 
> stuff, I just happened to noticed it when playing around with 
> tcpdump and forgetting to specify -i. I wondered why I don't 
> see lots of SSH traffic scrolling by. :-)
> 
> > Is this an olive?
> 
> Nope.
> 
> A1> show version | match Model
> Model: m10
> 
> fxp0 is just the management LAN in the lab here.
> 
> And as we all know, Olives don't exist. :-)
> 
> 
> Best regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
> 