[c-nsp] OSPF issue (Solved)

John Elliot johnelliot67 at hotmail.com
Mon Dec 5 04:46:04 EST 2011

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 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 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 when pinging from R3:

>From "R3"
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to, 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 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

Thanks again for your assistance.

> I suspect the carrier.


More information about the cisco-nsp mailing list