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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>>> 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 [email protected] >>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>> >>>> _______________________________________________ >>>> juniper-nsp mailing list [email protected] >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >>> >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
