Since it seems to be ipv6 month here at NZNog I thought I would bring this up.
Some of you have commented that Orcon is in trial mode for IPv6 and are probably wondering why we haven’t progressed.
We have had IPV6 enabled for a while and have a good number of ipv6 customers online now. However we found an issue on the Chorus network which stopped us rolling it out further. (UFB ipv6 was another battle which requires beer!)
What we found was some Chrous DSLAMS with certain card types would drop IPV6CP packets in one direction when doing the PPPoE->PPPoA conversation. It would seem that these cards don’t support Ipv6. Weirdly enough it would seem it is the newer card types used for Broadband IP. (citation needed). This in itself isn’t a major but we also found our NFV4 modem would reset its entire PPPoE stack if the IPV6CP conversation started but didn’t complete as expected, so customers would constantly be disconnected and cycle around. (The Genius modem works well with ipv6)
The NFV4 issue aside (we are resolving with the Vendor). We approached the Chorus tech team and they helped identify the issue but that’s is where its hit a brick wall. The Chorus op team are not keen on fixing the issue nationwide as it involves new code versions, a massive amount of testing and a long rollout program. (I can understand where they are coming from).
To summarise:
IPV6 doesn’t work on Chorus EUBA on some line card types
Only affect PPPoE->PPPoA translation
PPPoE end to end is fine.
Chorus say IPV6 not supported on EUBA
Customer numbers effected are smallish.
We will fix the NFV4 issue, but keen to rollout more IPV6 to all customers, not just the lucky ones on card types which work.
Has any other ISP’s (the bigger ones especially) noticed this? As it will require some pressure to get some progress.
Cheers,
Simon Allard
Orcon/Callplus
[cid:image92256e.PNG(a)016ea4ce.48a80470]
Simon Allard // Senior Network Architect
D: 09 550 2790 M: 020 100 0790 F:
www.callplus.co.nz<http://www.callplus.co.nz> | www.slingshot.co.nz<http://www.slingshot.co.nz> | www.flip.co.nz<http://www.flip.co.nz> | www.orcon.net.nz<http://www.orcon.net.nz>
This message and any attachments contain privileged and confidential information. If you
are not the intended recipient of this message, you are hereby notified that any use,
dissemination, distribution or reproduction of this message is prohibited.
If you have received this message in error please notify the sender immediately via email
and then destroy this message and any attachments.
On the off chance that someone else has seen this before and knows what
causes it, does anyone know of any software that generates ARP
_Requests_ with the Target Protocol Address (TPA) of 255.255.255.255
(all ones). Such that results in this sort of log message from picky
switches:
<188> Jul 29 10:47:13 [SWITCH] ARP[ipMapForwarding]:
ipmap_arp_api.c(1147) 1021154 %% Received ARP Request on interface Vl1
with bad target IP address 255.255.255.255. Sender IP is [REALIP],
sender MAC is [REALMAC].
As far as I can tell they happen _approximately_ every 5 minutes, but
definitely not to the second. I'm told the Sender IP is a relatively
old Windows host, but the Windows admins don't know of anything
installed which would do that.
Searching the Internet doesn't turn up much. I did find UNARP
(https://tools.ietf.org/html/rfc1868), but that's supposed to be an
unsolicited ARP _Reply_, and this is a Request; and besides this isn't
the scenario UNARP was invented for anyway. The only other speculation
I can find is maybe it's a gratuitous ARP that doesn't follow RFC5227
(https://tools.ietf.org/html/rfc5227; which says that Target Protocol
Address should be set to the address you want to claim), but that also
seems implausible (especially since the DHCP leases at this site are
longer than 5/10 minutes).
Any thoughts as to what might be generating it welcomed.
Ewen
PS: This is not the ARP being _broadcast_ to the all address
255.255.255.255; that happens all the time on requests. This is asking
"who-has 255.255.255.255"!
