Hi Guys - Just following up on this issue...Carrier is stating that they are not filtering multicast(support case is still open, but we appear to be getting nowhere) 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. 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? Any suggestions are greatly appreciated!
Date: Sun, 13 Nov 2011 09:55:24 +0100 Subject: Re: [c-nsp] OSPF issue From: [email protected] To: [email protected] CC: [email protected]; [email protected] It looks like it's actually multicast packets that are getting filtered somehow. MPLS (LDP) is also making use of it for discovering the neighbors (224.0.0.2). Untill you get the multicast issue sorted with your carrier, you could do a targeted (unicast) discovery for LDP. that should work. On Sun, Nov 13, 2011 at 2:51 AM, John Elliot <[email protected]> wrote: Cheers guys - It would appear that there is some filtering of ospf on this new link...I've changed both ends ints to non-broadcast, and added nei statements to ospf, and we now have adj that's been up for ~30min. Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:01:37 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:31 xxx.xxx.66.2 FastEthernet3/0 Ill get onto carrier tomorrow regarding the multicast filtering.Side note - Is there any potential issues with running mpls over this link(As I dont see ldp neig on R1 for R2):#sh mpls ldp neighbor port-channel 1.87(I do see ldp nei on R2 though(via both portchan1.86 + portchan1.87))Thanks again for your assistance.....much appreciated! > Date: Sat, 12 Nov 2011 15:49:57 -0800 > From: [email protected] > To: [email protected] > Subject: Re: [c-nsp] OSPF issue > > On 11/12/11 3:26 PM, John Elliot wrote: > > > Ok - enabling point-to-point on each of the "new" ints on R1+R2, and it now > > doesnt form adj. > > > > R1 no longer sees R2 in neighbors via "new" Int: > > > > > > Neighbor ID Pri State Dead Time Address > > Interfacexxx.xxx.76.248 1 FULL/DR 00:00:35 xxx.xxx.66.2 > > FastEthernet3/0 > > > > R2 is stuck in init: > > > > > > Neighbor ID Pri State Dead Time Address > > Interfacexxx.xxx.76.238 0 INIT/ - 00:00:36 xxx.xxx.66.61 > > Port-channel1.87 > > xxx.xxx.76.238 1 FULL/BDR 00:00:30 xxx.xxx.66.1 > > Port-channel1.86 > > Based on your previous post re multicast pings, it may be that your > provider isn't passing multicast. If this is the case you can either > get them to fix this (best) or statically assign neighbors in router > config mode (sort of an ugly hack). > > The results of "show ip ospf interface [interface name]" on both sides > after configuring point-to-point on the interfaces would be useful > information. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - [email protected] > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
