[j-nsp] EX4550 apparently dropping IPv6 RA

[Scott Granados]

I thought that was standard operating procedure for the systems guys to blame the network?

:)

On Jun 17, 2014, at 1:59 PM, Morgan McLean <wrx230 at gmail.com> wrote:

> If I had a dollar for every time the systems guys changed something and
> then cried to neteng... :)
> 
> Thanks,
> Morgan
> 
> 
> On Mon, Jun 16, 2014 at 7:11 AM, John Neiberger <jneiberger at gmail.com>
> wrote:
> 
>> This all turned out to be a false alarm. Someone on the server team had
>> changed the configuration on all the servers such that they were ignoring
>> RAs from the MX960. Everyone thought the EX4550 wasn't passing the RAs
>> because the filter they used to catch them wasn't apparently catching them.
>> The counters for ND/NS were incrementing but the counters for RA/RS were
>> not. The RAs clearly are passing through the EX4550, but for whatever
>> reason, the filter isn't counting them. The server issue has been corrected
>> and everything is working now.
>> 
>> Thanks,
>> John
>> 
>> 
>> On Mon, Jun 16, 2014 at 6:31 AM, Benoit Plessis <b.plessis at doyousoft.com>
>> wrote:
>> 
>>> Hi,
>>> 
>>> It won't help you i fear but i did see exactly the same defect on some
>>> other concurrent platform (cisco 3560G).
>>> 
>>> With the latest IOS software (15.x) a 3560G unit in L3 mode does
>>> correctly send RA and reply to RS, but the same
>>> unit in L2 mode between a router and a server fail to deliver RA/RS
>>> messages ...
>>> "Normal" IPv6 trafic correctly flow thru the 3560G in L2 however.
>>> 
>>> Downgrading the L2 unit to a 12.xx release did solve the problem, and
>>> also did replacing the 3560G
>>> by a 2960G even in IOS 15.
>>> 
>>> Looks like some packet handling code isn't correctly de-activated.
>>> 
>>> 
>>> Le 16/06/2014 07:23, John Neiberger a écrit :
>>>> This does seem to be specific to RA/RS. I haven't been involved in
>>>> troubleshooting over the weekend but the updates I read said that they
>>> took
>>>> some packet captures of RA messages from the Cisco 7600 that the switch
>>>> used to be connected to and compared them with captures taken from the
>>>> MX960. They found some differences and adjusted to the configuration to
>>>> make them the same, but that still did not resolve the problem. The
>> issue
>>>> has been escalated with Juniper. Last I read, no one really has any
>> idea
>>>> yet what is going on. They've got an action plan for tomorrow, so I'll
>>> know
>>>> more after a meeting in the morning. Sure seems awfully funky, though.
>>> JTAC
>>>> seems to be at a loss to explain what is happening.
>>>> 
>>>> Thanks,
>>>> John
>>>> 
>>>> 
>>>> On Sun, Jun 15, 2014 at 5:22 AM, Phil Mayers <p.mayers at imperial.ac.uk>
>>>> wrote:
>>>> 
>>>>> On 14/06/14 22:24, John Neiberger wrote:
>>>>> 
>>>>> The EX4550 is just layer two. There is no routing configured on it,
>> so
>>> it
>>>>>> should just be passing the RAs from the router to the hosts on the
>>> second
>>>>>> switch, but that doesn't seem to be happening.
>>>>>> 
>>>>> Is it RA/RS specific, or is forwarding to fe80::1 and related groups
>>>>> broken?
>>>>> 
>>>>> 
>>>>> Have any of you ever seen anything quite like this?
>>>>> On other platforms, I've seen IPv6 link-local multicast fail to flow
>> as
>>>>> some tiny table, sized with IPv4 assumptions, overflowed.
>>>>> 
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>> 
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp