Hi guys, Just an update to this, after couple of weeks (of exhaustive!) troubleshooting with carrier, I checked load-balancing on the portchan(3750), it was set to default (src mac), and after testing the loadbalancing via mac(of the working+non working links), a pattern emerged - All non-working multicast(in one direction) was going via gi2/0/24, all working multicast was going via gi1/0/24 - So shut gi2/0/24 down and voila, ospf+mpls came up immediately on the new link. So pretty painful one to work out, and will need to upgrade the ios and re-test via the dual links. Thanks to all that assisted.
From: [email protected] To: [email protected]; [email protected] Subject: RE: [c-nsp] OSPF issue Date: Thu, 17 Nov 2011 11:17:08 +1100 > > On 11/16/11 3:28 PM, John Elliot wrote: > > If I ping 224.0.0.5 from R2, I do not get a response from R1 via the > > "new" link - Also, debugging icmp on r1, I only see requests from R2 via > > the existing(working) link, so the multicast pings are not reaching R1 > > via the "new" link. > > If you ping 224.0.0.5 from a router connected to R1 on a different link, > do you get a response? (I suspect your carrier is indeed filtering > multicast.) (Hopefully the formatting doesnt get killed by hotmail.) Yes - R1 has 3 "active" ospf+mpls connections (one to R2, and two to R3) R3 has 2 links to R1, both of which work without issue, and respond to 224.0.0.5 when pinging from R3: >From "R3" #ping 224.0.0.5 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds: Reply to request 0 from xxx.xxx.66.237, 8 ms Reply to request 0 from xxx.xxx.66.173, 8 ms (Note, Ive removed "other" replies..R3 has other ospf neighbours also) (i.e. no need for non-broadcast or neighbor statements to form adjacencies) > > > R1(7206 w/ G1) connects via trunk to 3750(As portchan), and the carrier > > hand-off is via trunk port on the same 3750 - The switch is not doing > > any L3, has no filtering of multicast enabled...Am I seeing a potential > > ios bug? > > Verify that R1 is indeed communicating on 224.0.0.5 on the interface > facing the carrier, then beat on them until they fix it. If it isn't > and should be (no passive-interface or something misconfigured), then > maybe an IOS bug. > sh ip ospf 100 int is stating that portchan1.87 is active #sh ip ospf 100 interface Port-channel1.87 is up, line protocol is up (It has an active adj via this link atm as I have it configured with non-broadcast and neighbour statement in ospf 100) Unless there is some other test I can use to confirm portchan1.87 is indeed communicating on 224.0.0.5? Thanks again for your assistance. > I suspect the carrier. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
