4 ms·

And somehow juniper (and juniper support engineers for large routers) is unaware of these things? I'm skeptical. Particularly for ongoing problems where secon

by x0x0 12y ago

And somehow juniper (and juniper support engineers for large routers) is unaware of these things? I'm skeptical. Particularly for ongoing problems where second and third level support get involved.

ploxiln 12y ago
Don't be so surprised. There can be corporate-political problems to engineers solving the problem. For example, the official marketing line is "we support feature X!", and while the engineer wants to say "that doesn't work right, turn that shit off" he can't really do that. Or maybe the solution is to not use Juniper for ipv6. I really don't know. It's possible that Juniper's development process and goals prevented solid ipv6 support - another case where even if their engineers were aware, they couldn't do anything to help this guy.
jauer 12y ago
I wouldn't be surprised if this turns out to be a MIT-environment-specific issue. E.g. Juniper support wasn't aware of it because they assumed no one would try to use stateless configuration in what would generally be a managed environment using dhcpv6.
- ay 12y ago
  Yes and no. Quite a few large environments use SLAAC and they work just fine (though I work for cisco so a bias is quite possible ;-). But there's certainly something specific to MIT's setup that makes it melt down in such a spectacular fashion with v6. "Forwarding loops" (preexisting?) from the blog raise some suspicion. The local environment frequently has a huge impact - and for the most extreme/"obvious" cases it took me to recreate the setup in the lab and show folks how it works fine with their config and traffic to make them believe that it was not just stupidly broken - because in their environment they could reproduce the bug every time!
res0nat0r 12y ago
Normally when the big dogs for a product get called in it is to find out why their product has an issue, they are the code experts for that. This doesn't mean they are inherently experts in every protocol their product happens to be using.

by x0x0 12y ago

And somehow juniper (and juniper support engineers for large routers) is unaware of these things? I'm skeptical. Particularly for ongoing problems where second and third level support get involved.

ploxiln 12y ago

Don't be so surprised. There can be corporate-political problems to engineers solving the problem. For example, the official marketing line is "we support feature X!", and while the engineer wants to say "that doesn't work right, turn that shit off" he can't really do that. Or maybe the solution is to not use Juniper for ipv6. I really don't know. It's possible that Juniper's development process and goals prevented solid ipv6 support - another case where even if their engineers were aware, they couldn't do anything to help this guy.

jauer 12y ago

I wouldn't be surprised if this turns out to be a MIT-environment-specific issue. E.g. Juniper support wasn't aware of it because they assumed no one would try to use stateless configuration in what would generally be a managed environment using dhcpv6.

ay 12y ago
Yes and no. Quite a few large environments use SLAAC and they work just fine (though I work for cisco so a bias is quite possible ;-). But there's certainly something specific to MIT's setup that makes it melt down in such a spectacular fashion with v6. "Forwarding loops" (preexisting?) from the blog raise some suspicion. The local environment frequently has a huge impact - and for the most extreme/"obvious" cases it took me to recreate the setup in the lab and show folks how it works fine with their config and traffic to make them believe that it was not just stupidly broken - because in their environment they could reproduce the bug every time!

res0nat0r 12y ago

Normally when the big dogs for a product get called in it is to find out why their product has an issue, they are the code experts for that. This doesn't mean they are inherently experts in every protocol their product happens to be using.