multicast packetloss

[Chris1]

I believe my issue is related to xos0053644, but info on that specific issue seems to be limited to https://extremeportal.force.com/ExtrArticleDetail?an=000075074 no mention in release notes etc. Unless i'm missing a way to search bulk release notes/version history for bug numbers.

Also not 100% sure this is the issue, we do seem to have issues periodically with OSPF at some sites, but i'm unsure which of my switches is the root cause.

Our layout is
Remote Site Switch (ospf x450/x460-g2 etc) -> FIBER -> MLAG-Aggregation (l2-transit x670) -> FIBER -> MLAG-Core switches (ospf x670-g2)

The one page I found says "temporary/short outages" on ospf but honestly we've seen outages of many hours or days on ospf for some sites, and it doesn't happen to all the sites.

Should i just disable the to-cpu on all ports of our aggregation switches? Is their a draw back to doing that if those switches are only qinq and vlans no l3 beyond inband management ip? Can i do the commands on a live network or will it affect traffic flow on the transit switch?

I'm having issues understanding the problem, theirs 4 solutions listed but no explanation really of figuring out which switches are the issue actually, or what the draw back is to each of the solutions

None of the options seem to be for running on the actual OSPF switch (the ones with the ip interfaces) so is the issue only on switches that are layer 2 transit switches?

[EtherMAN]

Makes sense... I am very interested in how this proceeds and what the final fix is... we will be moving away from the 8900 in the nest year or so and going to 670 G2's and 870's. I am in same boat as you. Would love to reboot and upgrade our 8900 but there are just to many single links and critical services... Some have been running over 1200 days so they are way over due...

If we have any additional insight in this I will drop you all an update too.

[Chris1]

Ya still having issues, as a note we don't have 8900's we have all x460-g2 and x670-g2's

I plan to upgrade to recommended latest patches soon, but due to some traffic engineering issues our redundancy isn't fully redundant at the moment so trying to get that fixed before i do any reboots/upgrades, and we created temporary static routes to back up the ospf routes until we get the problem solved so it isn't affecting customer traffic.

I've seen both site that drop out and stay out for seemingly forever and others drop randomly, but i don't want to open a gtac case until i upgrade the affected routers and my core to the recommended versions to avoid reporting something thats already been fixed in the recommended versions.

[EtherMAN]

Chris, just wondering if you resolved this or are still fighting Mcast problems between your routers?

[EtherMAN]

Chris, sorry to hear you are still having issues... here is link to recommended code http://www.extremenetworks.com/extreme-hardwaresoftware-compatibility-recommendation-matrices/softwa... It seems you only did the 8900's in your core, are there other layer 2 only switches in the path?... There is a chance that you may have a resource issues in the blocks and tables and I would start working with GTAC if you have not already to open a case and see if you can figure this out. I can tell you already though they will ask you to get to current code before they will do very much of anything. If there are other layer 2 switches in your path you may also need to clear their tables too... Clearing the tables does not affect traffic so it cant hurt.

You said yours are coming and going right? This is a bit different than what we have seen in the past. Once we see the issue on a vlan the routers will not find their neighbors till we intervene and clear the tables. They go down and stay down. You said yours are coming and going so you may indeed have another issue.