[c-nsp] PMTUD broken on 12.4(15)Tx (and later)?

Tue Dec 2 05:09:38 EST 2008

Hi.

We do have a customer case using "Client-Initiated L2TP tunneling"
between the LNS and the CPE. Trying to be polite we have used PMTUD on
the pseudowire, and it have caused no pain using 12.4(9)Tx. Recently
one CPE were shipped with 12.4(15)Tx, and suddenly no customer traffic
(Windows hosts) went through the circuit. Does this sound familiar to
someone?

The router used as CPE is a 878, the LNS is a 7200/NPE-G2 running SRC2.

>From the CPE running 12.4(15)T7:

Configuration:
l2tp-class L2TP
 hostname <name>
 password <password>
!
pseudowire-class PW
 encapsulation l2tpv2
 protocol l2tpv2 L2TP
 ip pmtu
 ip dfbit set
!
interface Virtual-PPP62
 ip address negotiated
 ppp authentication pap callin
 ppp pap sent-username <username> password <password>
 ppp ipcp route default
 pseudowire 62.99.1.1 62 pw-class PW

The routing look like:
cpe#sh ip ro
Gateway of last resort is 62.99.4.1 to network 0.0.0.0

     62.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       62.99.4.1/32 is directly connected, Virtual-PPP62
S       62.99.1.1/32 is directly connected, ATM0.1
C       62.99.2.0/30 is directly connected, ATM0.1
C       62.99.4.43/32 is directly connected, Virtual-PPP62
S*   0.0.0.0/0 [1/0] via 62.99.4.1

When pinging a remote host routed via the Virtual-PPP interface,
everything is shiny until I try the same with the DF-bit set. A "debug
ip icmp" trace is also shown.

cpe#ping 62.2.0.1 repeat 1
Sending 1, 100-byte ICMP Echos to 62.2.0.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
syslog: Dec  2 10:26:27 CET: ICMP: echo reply rcvd, src 62.2.0.1, dst
62.99.4.43ping 62.2.0.1 repeat 1 df

cpe#ping 62.2.0.1 repeat 1 df-bit
Sending 1, 100-byte ICMP Echos to 62.2.0.1, timeout is 2 seconds:
Packet sent with the DF bit set
M
Success rate is 0 percent (0/1)
syslog: Dec  2 10:26:33 CET: ICMP: dst (62.99.4.43) frag. needed and
DF set unreachable rcv from 62.2.0.1

The source IP-address in the last ICMP reply is bogus (or buggy).
Sniffing the Vlan carrying the traffic between the CPE and the LNS
clearly reveals NO traffic is leaving the CPE. When pinging without
the DF-bit set, I do see the traffic on the Vlan:

10:26:24.501539 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[OP](20868/52254) {LCP, Echo-Request (0x09), id 104, length 14}
10:26:24.501743 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[OP](33620/1373) {LCP, Echo-Reply (0x0a), id 104, length 14}

<without DF-bit>
10:26:27.530673 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[O](20868/17425) {IP 62.99.4.43 > 62.2.0.1: ICMP echo request, id
47, seq 0, length 80}
10:26:27.531384 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[O](33620/1372) {IP 62.2.0.1 > 62.99.4.43: ICMP echo reply, id
47, seq 0, length 80}
</without DF-bit>

10:26:30.643664 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[OP](20868/17425) {LCP, Echo-Request (0x09), id 105, length 14}
10:26:30.643884 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[OP](33620/1372) {LCP, Echo-Reply (0x0a), id 105, length 14}
10:26:32.600105 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[OP](33620/1372) {LCP, Echo-Request (0x09), id 108, length 14}
10:26:32.603199 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[OP](20868/17425) {LCP, Echo-Reply (0x0a), id 108, length 14}
10:26:32.632030 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[OP](33620/1373) {LCP, Echo-Request (0x09), id 108, length 14}
10:26:32.635035 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[OP](20868/52254) {LCP, Echo-Reply (0x0a), id 108, length 14}

<here the pings with DF-bit set should have been/>

10:26:34.738665 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[OP](20868/52254) {LCP, Echo-Request (0x09), id 105, length 14}
10:26:34.738875 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[OP](33620/1373) {LCP, Echo-Reply (0x0a), id 105, length 14}

Pinging the LNS terminating the L2TP session (which of course is NOT
routed via the Virtual-PPP interface) do work fine:

cpe#ping 62.99.1.1 repeat 1 df-bit
Sending 1, 100-byte ICMP Echos to 62.99.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
syslog: Dec  2 10:50:39 CET: ICMP: echo reply rcvd, src 62.99.1.1, dst 62.99.2.2

<sniffer>
10:50:39.508530 vlan 162, p 0, IP 62.99.2.2 > 62.99.1.1: ICMP echo
request, id 50, seq 0, length 80
10:50:39.508870 vlan 162, p 0, IP 62.99.1.1 > 62.99.2.2: ICMP echo
reply, id 50, seq 0, length 80
</sniffer>

If I remove "ip pmtu" from the pseudowire-class, pinging over the
Virtual-PPP session works fine with a set DF-bit.

cpe(config)#pseudowire-class PW
cpe(config-pw-class)#no ip pmtu
cpe(config-pw-class)#end

Dec  2 10:55:34 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-PPP62, changed state to down
Dec  2 10:55:38 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-PPP62, changed state to up

cpe#sh int virtual-ppp 62
Virtual-PPP62 is up, line protocol is up
  Hardware is Virtual PPP interface
  Internet address is 62.99.4.44/32

cpe#ping 62.2.0.1 repeat 1 df-bit
Sending 1, 100-byte ICMP Echos to 62.2.0.1, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
syslog: Dec  2 10:56:50 CET: ICMP: echo reply rcvd, src 62.2.0.1, dst 62.99.4.44

<sniffer>
10:56:50.833757 vlan 162, p 0, IP 62.99.2.2.1701 > 62.99.1.1.1701:
l2tp:[O](20868/47771) {IP 62.99.4.44 > 62.2.0.1: ICMP echo request, id
51, seq 0, length 80}
10:56:50.834445 vlan 162, p 0, IP 62.99.1.1.1701 > 62.99.2.2.1701:
l2tp:[O](33620/1374) {IP 62.2.0.1 > 62.99.4.44: ICMP echo reply, id
51, seq 0, length 80}
</sniffer>

The same behavior is seen on 12.4(20)Tx as well.

Note: The captures are not from a production network, so all
IP-addresses are used in a private context (read: lab environment).
There is no affiliation with neither "Cablecom GmbH" (62.2.0.0/16) nor
"Euskaltel" (62.99.0.0/17).

-- 
Pelle