5 recommendations |
to phibs
Re: [Networking] IPv6 working!umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things.
For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue. |
|
7 recommendations |
Lexatt
Member
2020-Jun-18 1:23 am
If it's Juniper, it's not PON side. It may be access network side, still, but not PON. They use Alcatel and a few other vendors for PON equipment, not Juniper (I'm not even sure Juniper MAKES PON equipment off the top of my head).
Their backbone is a mixture of Cisco and Juniper, so it may well be access network. We won't ever know, unless Branch happens to get us the right insider info. |
|
phibs join:2012-09-25 Newark, DE
4 recommendations |
phibs
Member
2020-Jun-18 2:27 am
I mean we've been waiting since... 2012 |
|
sporkmedrop the crantini and move it, sister MVM join:2000-07-01 Morristown, NJ
4 recommendations |
said by phibs:I mean we've been waiting since... 2012 Exactly. Just not believing that this bug has been around for 8+ years and every other Juniper customer was just like ¯\_(ツ)_/¯ |
|
1 recommendation |
Anon1138d to ps0ps
Anon
2020-Jun-18 3:27 pm
to ps0ps
said by ps0ps:umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things. Definitely not limited to the PON portion of the network. This affects tons of other ISPs. said by ps0ps:For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue. Different issue all together. |
|
Anon1138d
4 recommendations |
Anon1138d to sporkme
Anon
2020-Jun-18 3:40 pm
to sporkme
said by sporkme:Exactly. Just not believing that this bug has been around for 8+ years and every other Juniper customer was just like ¯\_(ツ)_/¯ They can't ¯\_(ツ)_/¯ if they're not aware of the issue. Windows is the master at having bugs that are 10+ years old that are being found now. This is just a convenient excuse. It doesn't excuse the previous numerous years of being incompetent. |
|
GLX join:2000-01-18 Hoboken, NJ
4 recommendations |
to Anon1138d
Completely wrong.
It's a PON issue related to Alcatel, who basically refused to fix it for years. |
|
sporkmedrop the crantini and move it, sister MVM join:2000-07-01 Morristown, NJ
2 recommendations |
said by GLX:Completely wrong.
It's a PON issue related to Alcatel, who basically refused to fix it for years. How the mighty have fallen. There was a time if Bell Atlantic said "jump" to a vendor, the answer would be "how high?". |
|
6 recommendations |
to Anon1138d
said by Anon1138d :said by ps0ps:umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things. Definitely not limited to the PON portion of the network. This affects tons of other ISPs. said by ps0ps:For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue. Different issue all together. You're completely missing the point. The quoted Juniper bugs have nothing to do with why Verizon has paused their IPv6 rollout. Spreading false information about a bug that has nothing to do with the FiOS rollout just confuses people. Personally I have run into my fair share of IPv6 bugs with vendors, but we got them all fixed and have been running IPv6 only inside our datacenters since 2014. My guess is Verizon really wants to finally do this and ran into a show stopper that would have ended up with massive support calls. They can't just roll something out because some customers want it. The amount of bugs I had with the early testing of Comcast's IPv6 on DOCSIS was horrible and working with them to resolve the issues took a while and then viola, it slowly rolled out nation wide to where 80+% of their homes use IPv6 everyday. |
|
4 recommendations |
to GLX
said by GLX:It's a PON issue related to Alcatel, who basically refused to fix it for years. The PON is layer 2 from GWR to customer location router. The demux interface on the Juniper router in the CO runs through an Aggregate Ethernet fiber bundle to the OLT, then it's GPON from the PON card on the OLT down to the customer site ONT, through the twisted pair Ethernet cable to the customer router. No IP. It would be weird for the layer 2 PON to have effects at layer 3 IPv6. Is there a frame size problem with the larger IPv6 header? Maybe? Is that likely? It wouldn't be my first guess. The linked bug with JunOS may not be the problem, but I would bet it's there before I'd bet it's in the PON. |
|
GLX join:2000-01-18 Hoboken, NJ
6 recommendations |
GLX
Member
2020-Jun-19 6:47 am
That is a relatively new bug and certainly hasn't caused them to not deploy v6 for a decade+ before this.
Unfortunately I can't comment more but you're on the right track with thinking about the OLT. |
|
5 recommendations |
to custer
Verizon isn't the only one having trouble with network equipment bugs on ipv6. Aussie Broadband pauses IPv6 trial due to Cisco bug - Latest patch solved one problem but caused another. » www.itnews.com.au/news/a ··· g-534851...the ASRs are currently impacted by a firmware bug that “causes the DHCP [Dynamic Host Configuration Protocol] process on the routers to crash, so customers are not able to reauthenticate,” Aussie Broadband said in a customer advisory. ...The bug has official recognition from Cisco - and is one of five that Aussie Broadband has uncovered in Cisco code over the past 18 months “that have not been discovered previously”. Cisco Bug: CSCvr71624 - dhcpv6d memory leak when handling relay-reply with interface-id Last Modified May 04, 2020 |
|
Smith6612 MVM join:2008-02-01 North Tonawanda, NY ·Charter Ubee EU2251 Ubiquiti UAP-IW-HD Ubiquiti UniFi AP-AC-HD
7 recommendations |
to Lexatt
I know DOCSIS is a bit of a different Animal, but I remember working with some Time Warner Cable engineers in my area on an IPv6 bug that was present in the firmware they had loaded onto the Motorola SB6141 cable modems around here. The firmware bug caused the modem to rewrite the TCP headers in all IPv6 traffic with a TCP Scaling factor of 128, on top of the base Receive/Send window set by the sender/receiver. As a result, this meant that while IPv6 traffic flowed, there was a very high number of unnecessary TCP retransmits and TCP discards, which caused plenty of issues with connection reliability and the big one... Speed. This was because of mismatches in ACK/BDP timing unknown to either end being created by the modem mangling packets. I remember spending about an hour on the phone with the engineers at Time Warner Cable running packet captures with them (they ran one on the CMTS, I ran one from my end) and diving into where the problem was.
A fix ended up being available already from Motorola / Arris, and they deployed it a few weeks later during one of their maintenance periods. |
|
Obihai OBi202 Ubiquiti EdgeRouter X Aerohive AP230
3 recommendations |
jhclce
Member
2020-Jun-19 12:17 pm
Lexatt, the above reply by Smith is an excellent example of the problems that supposedly "layer 2" equipment can still manage to have related to IPv6 compatibility. There are often hidden assumptions present about the form and structure of IP packets which break when IPv6 is introduced. |
|
sporkmedrop the crantini and move it, sister MVM join:2000-07-01 Morristown, NJ
1 recommendation |
to Smith6612
said by Smith6612:The firmware bug caused the modem to rewrite the TCP headers in all IPv6 traffic with a TCP Scaling factor of 128, on top of the base Receive/Send window set by the sender/receiver. Good lord, I assume this wasn't random, but some kind of misfire of a feature on the modem. KISS. |
|
3 recommendations |
to Smith6612
Yeah, there is no limit to how badly the developers can screw up but...that is a weird one. Were the re-writes valid values?
Still, outright corruption of encapsulated data at the level of a software bug isn't something that incredibly commonly escapes acceptance testing, the PON itself is not where I would look for a bug preventing IPv6 deployment first. |
|
Smith6612 MVM join:2008-02-01 North Tonawanda, NY
5 recommendations |
The re-writes were generating "Valid" values... if you assume negotiating a TCP Receive Window of 1,536,000 bytes when 12,000 bytes is the true negotiated value. |
|
GLX join:2000-01-18 Hoboken, NJ
2 recommendations |
to Lexatt
The PON is responsible for admission control (and identification). |
|
1 recommendation |
Anon1138d to GLX
Anon
2020-Jun-21 5:22 pm
to GLX
said by GLX:Completely wrong.
It's a PON issue related to Alcatel, who basically refused to fix it for years. I wasn't the one spreading the bogus information. I didn't believe it in the first place. Lots of other ISPs are running v6 on the same hw and code. |
|
|
Anon1138d
2 recommendations |
Anon1138d to jhclce
Anon
2020-Jun-21 5:29 pm
to jhclce
said by jhclce:Lexatt, the above reply by Smith is an excellent example of the problems that supposedly "layer 2" equipment can still manage to have related to IPv6 compatibility. There are often hidden assumptions present about the form and structure of IP packets which break when IPv6 is introduced. There is very little out there that is purely Layer 2 only nowadays. This isn't specific to IPv6 only. This is just where a bug has been exposed. v4 bugs of this nature have definitely existed. |
|
2 recommendations |
to custer
Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...? |
|
Branch:D Premium Member join:2014-07-22 VHO 4 Greenwave FiOS-G1100 Actiontec WCB6200Q
4 recommendations |
Branch
Premium Member
2020-Jun-26 1:46 pm
said by Da Geek Kid:Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...? No request. You can look at yourIP in your router settings |
|
1 recommendation |
thanks. |
|
3 recommendations |
to Branch
said by Branch:said by Da Geek Kid:Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...? No request. You can look at yourIP in your router settings Technically you can request it. There was script for pfsense earlier in this thread that uses rstool and looks for a response. |
|
2 recommendations |
Funny thing is, I tried 5 times and as usual with Vz keeps bouncing between different groups of CS teams and mostly had no clue what I was requesting, each time hold time of 3hrs.
I don't know how much Vz pays some company to get good rating for CS... |
|
Branch:D Premium Member join:2014-07-22 VHO 4 Greenwave FiOS-G1100 Actiontec WCB6200Q
6 recommendations |
Branch
Premium Member
2020-Jun-30 5:18 pm
said by Da Geek Kid:Funny thing is, I tried 5 times and as usual with Vz keeps bouncing between different groups of CS teams and mostly had no clue what I was requesting, each time hold time of 3hrs.
I don't know how much Vz pays some company to get good rating for CS... Don't call. You cannot ask for an IPV6 address. it's a waste of time. you will get one when you get one, and probably not for a while, covid pushed back a bunch of things. I know that's not helpful but that's the way it is. |
|
2 edits
2 recommendations |
So,
I use a 3rd party router (pfSense)
I'm curious to check if IPv6 is available in my area. Anyone know how I should try to acquire an address range? Should I set the WAN to DHCPv6? or SLAAC?
I tried enabling DHCP6, but it doesn't appear to have pulled an address. Not sure if this is just because it isn't enabled here yet, or if it is because I have configured something incorrectly.
And on the LAN side, do they give you a block so you can use DHCPv6, or is SLAAC the only option?
Much Obliged, Matt |
|
jnv11 join:2015-05-18 Morrisville, NC
4 recommendations |
jnv11
Member
2020-Jul-23 5:43 pm
If IPv6 is enabled in your area, your router will need DHCPv6-PD to acquire an address range on the WAN side. You can choose whatever method that you want to distribute IPv6 addresses on the LAN side once you have an address range from DHCPv6-PD on the WAN side. |
|
3 recommendations |
said by jnv11:You can choose whatever method that you want to distribute IPv6 addresses on the LAN side once you have an address range from DHCPv6-PD on the WAN side. Are you sure about that? My understanding is that DHCPv6 currently cannot deal with having a dynamic upstream address range, and that in order to use it, you absolutely positively need to have a static block assigned, or you'll be manually reconfiguring it every time the AR changes. So, if AR is dynamic, SLAAC is the only option. At least this is what my reading suggests. |
|
5 recommendations |
Anon1138d
Anon
2020-Jul-23 9:31 pm
said by mattlach:Are you sure about that?
My understanding is that DHCPv6 currently cannot deal with having a dynamic upstream address range, and that in order to use it, you absolutely positively need to have a static block assigned, or you'll be manually reconfiguring it every time the AR changes.
So, if AR is dynamic, SLAAC is the only option.
At least this is what my reading suggests. That's an implementation issue not a protocol issue. It's how all the pieces fit together. Meaning if you have for example a DHCPv6-PD client there needs a means of (re)configuring the relevant network interfaces and then feeding the DHCPv6 server and/or the SLAAC server the first prefix when starting up and any new prefix once the existing one has expired; whether that can be done via command line parameters or generating a new config file and restarting the daemon. |
|