[c-nsp] mpls te tunnel problem on directly connected link

[Artyom Viklenko]

Hi, All!

I have some point-to-point ethernet link between two
Cisco 7600 routers with /30 subnet. It's provided by third
party between two cities. This link is not the best from
IGP's point of view. MPLS is enabled on this link.
Plain ping ipv4 or ipv6 works fine. OSPF, PIM and LDP
sees neigboring side all ok.

Then using ip explicit-path via this link MPLS TE tunnel
was built. Tun interface showes that it is up.
'sh mpls traffic-eng tunnels tun xxx' also showes that
all is ok with it.

But if I use command 'ping mpls traffic-eng tun xxx'

#ping mpls traffic-eng tunnel 201
Sending 5, 100-byte MPLS Echos to Tunnel201,
      timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
   'L' - labeled output interface, 'B' - unlabeled output interface,
   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
   'P' - no rx intf label prot, 'p' - premature termination of LSP,
   'R' - transit router, 'I' - unknown upstream index,
   'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
.....
Success rate is 0 percent (0/5)

And with explicit-null label:

#ping mpls traffic-eng tunnel 201 force-explicit-null
Sending 5, 100-byte MPLS Echos to Tunnel201,
      timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
   'L' - labeled output interface, 'B' - unlabeled output interface,
   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
   'P' - no rx intf label prot, 'p' - premature termination of LSP,
   'R' - transit router, 'I' - unknown upstream index,
   'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Also, if I use this tunnel in pw-class for EoMPLS - there is no
thraffic in tunnel.

Based on this I have two questions.

1. MPLS PING without 'force-explicit-null' for this tunnel generate
on wire plain IPv4 UDP packet (physical port was mirrored to anoter
one with tcpdump capturing traffic). Ethertype is 0x0800 - ipv4.
The only seen difference regardless payload is ip header length of 24
bytes versus typical 20 bytes.

With 'force-explicit-null' we have on wire MPLS packet with ethertype
0x8847 AND explicit null label in it. And the the same ipv4 udp with
the same 24 bytes ip header.

So, in the first case without explicit null packets got dropped on
the third party network equipment. An in latter - forwarded without
problems.

Is it really some "transparency" problem in third party equipment?
How I can make sure of this?

Another similar tunnels on other routers built via another transport
providers works fine. That's why I think that problem is not local.
All routers have same hardware (RSP720-3CLX-GE based) and same IOS
version 12.2(33)SRD5 advipservices-k9.

2. I try to advertise explicit-null labels for the link /30 prefix
using 'mpls ldp explicit-null for <acl>'. 'sh mpls ldp bindings' and
'sh mpls ip binding' showes that explicit-null label for this link
prefix got advertized. But 'ping mpls traffic-eng tunnel xxx'
without force-explicit-null does not insert explicit-null label
(local label always imp-null).

Is it expected behavior for directly connected link and TE tunnel
above it?

Plase, give me some klue.

Thanks in andavnce!


-- 
            Sincerely yours,
                             Artyom Viklenko.
-------------------------------------------------------
artem at aws-net.org.ua | http://www.aws-net.org.ua/~artem
artem at viklenko.net   | JID: artem at jabber.aws-net.org.ua
FreeBSD: The Power to Serve   -  http://www.freebsd.org