[c-nsp] OSPF issue (Solved)

[John Elliot]

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: johnelliot67 at hotmail.com
To: jay at west.net; cisco-nsp at puck.nether.net
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.