IPv6 - Small Packets Not Received

Hi All

Posting here wondering if anyone has experienced a similar issue.

I first had a problem with DHCPv6 prefix delegation. Got a WAN IP fine with IPv6CP but no DHCP prefixes.

I'd send out a DHCP solicit message toward Zen but get no response. Speaking with the Zen help desk they advised I could scrap DHCPv6 as they have a default route that points to the <WAN IP RANGE>::1 address anyway. I configured this IPv6 address on my WAN interface and can now send LARGE sized packets, but small ones get lost at / before the first hop.

I've run a few tests as follows...

<MY/48>:0:1::2 is configured as a LAN side IP on my router.

First I ping this IP from a server on the Internet.

If i use a payload size of 800 bytes, I can ping this IP fine.

root@www:~# ping6 <MY/48>:0:1::2 -s 800
PING <MY/48>:0:1::2(<MY/48>:0:1::2) 800 data bytes
808 bytes from <MY/48>:0:1::2: icmp_seq=1 ttl=57 time=23.9 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=2 ttl=57 time=23.4 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=3 ttl=57 time=91.0 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=4 ttl=57 time=22.4 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=5 ttl=57 time=22.6 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=6 ttl=57 time=23.4 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=7 ttl=57 time=32.4 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=8 ttl=57 time=22.3 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=9 ttl=57 time=22.9 ms
808 bytes from <MY/48>:0:1::2: icmp_seq=10 ttl=57 time=22.7 ms
^C
--- <MY/48>:0:1::2 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 22.381/30.757/91.070/20.303 ms

If i use a payload size of 500, I get no response!

root@www:~# ping6 <MY/48>:0:1::2 -s 500
PING <MY/48>:0:1::2(<MY/48>:0:1::2) 500 data bytes
^C
--- <MY/48>:0:1::2 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 9999ms


If I ping the first hop in the Zen network from my router I see the same problem. It also depends on the data in the ping packet as to whether or not I receive a response.

Heres a ping to the Zen first hop with 0's in the packet

Home-R1#ping 2A02:8010::4:0:0:1B size 500 source lo20 data 0000
Type escape sequence to abort.
Sending 5, 500-byte ICMP Echos to 2A02:8010::4:0:0:1B, timeout is 2 seconds:
Packet sent with a source address of <MY/48>:0:1::2
Packet has data pattern 0x0
�..

Heres a ping with alternating 1 and 0 HEX values.

Success rate is 0 percent (0/5)

Home-R1#ping 2A02:8010::4:0:0:1B size 500 source lo20 data 1010
Type escape sequence to abort.
Sending 5, 500-byte ICMP Echos to 2A02:8010::4:0:0:1B, timeout is 2 seconds:
Packet sent with a source address of <MY/48>:0:1::2
Packet has data pattern 0x1010
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/28 ms

To ensure this isn't a bug with my router, I captured on the wire between the Zen TG589VN and my router. Packets that aren't received from the Internet by my router aren't seen as encapsulated PPPoE frames on the wire. For the failed ping tests from my router, I see the PPP frames go out, but nothing comes back!

I think this is also likely whats breaking DHCPv6.

The fact that the ping test with the "1010" data pattern works fine means this can't be any sort of routing issue.

I've tried to reproduce this issue on my system and I can't. I have no problems sending and receiving ICMPv6 echo request and reply packets of any size over Zen FTTC. With the "don't fragment" bit set, everything works with a payload of up to 1452 bytes, which equates to the full MTU 1500 of my connection.

What router are you using?

Hi David

Thanks for taking the time to reply.

Yes, it seems that Zen's IPv6 service works for most people.

I can ping fine right up to my 1500 byte MTU. The problem just seems to be smaller packets and depends on the data in the packet payload.

Im using the TG589VN router supplied by Zen in bridge mode. PPPoE terminates on a Cisco 1861. The problem can't be my router, because if I capture on the wire between the 1861 and the 589VN I see the ICMP echo request go out to Zens gateway, but nothing in return until I increase the packet size (or sometimes if i range the payload data). Could possibly be a problem with the 589VN, but this router works fine for other customers.

Out of interest, is your FTTC LLU or a BTW link back to Zen?

I've done a bit more testing on this as I had a nagging feeling that maybe my outgoing traffic was dropped by the TG589VN before even going out onto the VDSL link.

Turns out the packets go out just fine in both working and none working scenarios. So problem is certainly upstream.

My testing as follows:



I clear the interface counters down on the Zen TG589VN router.

{Administrator}[eth bridge]=>:eth bridge clear

I send 300 "working" pings with a timeout of 0. This is so that they can be sent out as fast as possible, so I can check the counters on the Zen router without them incrementing much with other traffic.

Home-R1#ping 2A02:8010::4:0:0:1B source lo20 rep 300 data 101 timeout 0


On the TG589VN we see around 300 frames out (icmp echo requests) from my router and 300 frames in (icmp echo replies) from the Zen 1st hop router.


VDSL2 : dest : efmif1
Connection State: connected Retry: 10
Priority Tagging: Disabled
PortState : forwarding Interface: up
PortNr : 7
multiWANuntagged : disabled
Multicast filter: disabled
WAN : enabled
IGMP snooping : enabled
MLD snooping : enabled
Transparent Prio: disabled
BPDU Filtering : disabled
Extra Tagging : none
Dynamic VLAN : disabled
VLAN: Default VLAN: dummy Ingressfiltering: disabled
Acceptvlanonly: disabled
Priority Config: disabled IP Prec: disabled Priority: 0
Regeneration table : 0 1 2 3 4 5 6 7
RX bytes: 37986 frames: 301
TX bytes: 37932 frames: 302 dropframes: 0




I clear the interface stats down again

{Administrator}[eth bridge]=>:eth bridge clear


I now send packets with a different data pattern that would usually result I lost pings (same source and destination address).

Home-R1#ping 2A02:8010::4:0:0:1B source lo20 rep 300 data 0001 timeout 0

On the TG589VN we see 301 frames go out to Zen (300 packets + 1 from other traffic) and 1 (other none-test traffic) back in.


VDSL2 : dest : efmif1
Connection State: connected Retry: 10
Priority Tagging: Disabled
PortState : forwarding Interface: up
PortNr : 7
multiWANuntagged : disabled
Multicast filter: disabled
WAN : enabled
IGMP snooping : enabled
MLD snooping : enabled
Transparent Prio: disabled
BPDU Filtering : disabled
Extra Tagging : none
Dynamic VLAN : disabled
VLAN: Default VLAN: dummy Ingressfiltering: disabled
Acceptvlanonly: disabled
Priority Config: disabled IP Prec: disabled Priority: 0
Regeneration table : 0 1 2 3 4 5 6 7
RX bytes: 220 frames: 1
TX bytes: 37866 frames: 301 dropframes: 0

Hi,

Thank you for raising this. I've also not been able to replicate this issue. I've passed it onto our CPE development team to see if they get the same result using a TG589VN, and to find out if it is unique to that device.

Which version of the firmware are you running?

Cheers,
Bran.

Hi Bran,

Thank you very much for replying.

I don't believe the outputs are indicative of any problem with your CPE. I think its telling the truth when it shows no packets in from Zen in the below test. I certainly don't see them on the wire on the link between the CPE and my router. I think we would be wasting the time of your CPE development team by asking them to take a look at it before your networks team can prove it to be a CPE issue.

The packets are dropped somewhere between the outside of the TG589VN up to and including the first hop in Zen.

I ran some more testing last night where I set up a capture on a web server and repeated the same tests. Packets get from my router to the web server fine. The web server responds with an ICMPv6 echo reply, but this reply never makes it back to the outside interface on my TG589VN.

If I alter the packets to be much larger (say 1400 bytes) they go through fine. If I change the data in the payload of the ping packet, some data patterns go through fine.

So in summary:
The fault is between outside of TG589 CPE up to and including Zen first hop. Only in Zen to CPE direction. It affects only IPv6 packets. If the packet size, destination address or data pattern is varied then this affects if the packets pass. Larger packets are more likely to pass without issue.

I can provide more detail on any of these points if required and can also share the reference for my email trail with Zen which has an abundance of outputs and packet captures.

Edited by deleted (Mon 15-Feb-16 21:30:47)