Re: [c-nsp] OSPF issue (Solved)
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: johnellio...@hotmail.com To: j...@west.net; cisco-nsp@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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
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: kim...@gmail.com To: johnellio...@hotmail.com CC: j...@west.net; cisco-nsp@puck.nether.net 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 johnellio...@hotmail.com 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.2481 FULL/DR 00:01:37xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:31xxx.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: j...@west.net To: cisco-nsp@puck.nether.net 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.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30xxx.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 - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
On 11/16/11 3:28 PM, John Elliot wrote: 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. 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.) 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. I suspect the carrier. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
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 cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
...(bug) while possible; I still think it is your *new* provider doing something funky to multicast-macs; not multicast-ip. ./Randy --- On Wed, 11/16/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: kim...@gmail.com Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Wednesday, November 16, 2011, 3:28 PM 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: kim...@gmail.com To: johnellio...@hotmail.com CC: j...@west.net; cisco-nsp@puck.nether.net 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 johnellio...@hotmail.com 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: j...@west.net To: cisco-nsp@puck.nether.net 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 - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
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 johnellio...@hotmail.comwrote: 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.2481 FULL/DR 00:01:37xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:31 xxx.xxx.66.2FastEthernet3/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: j...@west.net To: cisco-nsp@puck.nether.net 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.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30xxx.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 - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
On 11/11/11 6:30 PM, John Elliot wrote: OSPF Issue Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1): Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:00xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:39xxx.xxx.66.2FastEthernet3/0 Then new link loses adj. after ~60seconds Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38xxx.xxx.66.2FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. Right, both ends are set to mtu of 1500. Does it pass 1500? ping far-side df size 1500 I'm suspecting an intermediate (carrier) MTU problem. Neighboring up uses small-enough packets, but delivering the initial load of routing data hits the MTU problem and the session melts down. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.comwrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working) is handed of via vlan at R2(Which is portchan dot1q subint), the other is physical int FA3/0, the one that is up/down, is handed off via different provider, same vlan at each end, and as portchan dot1q subints. Hope that makes sense? HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:39xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: 2 Way Communication to xxx.xxx.76.248 on Port-channel1.87, state 2WAYNov 12 10:12:58.448 aest: OSPF: Neighbor
Re: [c-nsp] OSPF issue
NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. Right, both ends are set to mtu of 1500. Does it pass 1500? ping far-side df size 1500 I'm suspecting an intermediate (carrier) MTU problem. Neighboring up uses small-enough packets, but delivering the initial load of routing data hits the MTU problem and the session melts down. Thanks for the reply - can pass 1500: #ping xxx.xxx.66.62 size 1500 df-bit repeat 100 Type escape sequence to abort.Sending 100, 1500-byte ICMP Echos to xxx.xxx.66.62, timeout is 2 seconds:Packet sent with the DF bit setSuccess rate is 100 percent (100/100), round-trip min/avg/max = 16/16/20 ms ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
Hi K, I've attached details in txt doc...hopefully it's permitted by the list. Date: Sat, 12 Nov 2011 17:53:52 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: randy_94...@yahoo.com; cisco-nsp@puck.nether.net Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.com wrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working) is handed of via vlan at R2(Which is portchan dot1q subint), the other is physical int FA3/0, the one that is up/down, is handed off via different provider, same vlan at each end, and as portchan dot1q subints. Hope that makes sense? HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:39xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key
Re: [c-nsp] OSPF issue
It seems as though R1 is not receiving hello's from R2 at some point and does so for the length of the dead timer, thus causing the adj to drop. This could be caused by any number of things. One suspect might be the use of spanning tree in carrier domain on the VLAN with an unstable topology. If somehow a topology change occurs on your circuit in the carrier domain and they are using plain 802.1d spanning tree with default settings, it could take at least 52 sec before traffic starts flowing on any alternate path in their L2 domain. During those 52 sec, any (redundant) ports that are making up the circuit connecting your R1 and R2 are likely discarding frames. The default dead time for OSPF is 40 sec. After the adjacency is formed, does the dead time decrease all the way to 0 right from the start ? Have you tried doing a ping between R1 and R2 on the dot1q subinterfaces for a period longer than 60 sec ? If that succeeds then this theory can be considered irrelevant. Also, seeing that this is a point-to-point topology, you might want to consider, as per Randy's suggestion, configuring the OSPF network type to point-to-point as there are no other routers on the segment so there's no point in doing DR/BDR election. From the output you've given so far, I don't see any weird stuff. Maybe you could provide your router config from R1 and R2 ? Just the router ospf section should suffice. If non of this helps or is ruled out, then we could be looking at a software bug. On Sat, Nov 12, 2011 at 9:21 PM, John Elliot johnellio...@hotmail.comwrote: Hi K, I've attached details in txt doc...hopefully it's permitted by the list. -- Date: Sat, 12 Nov 2011 17:53:52 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: randy_94...@yahoo.com; cisco-nsp@puck.nether.net Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.comwrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working) is handed of via vlan at R2(Which is portchan dot1q subint), the other is physical int FA3/0, the one that is up/down, is handed off via different provider, same vlan at each end, and as portchan dot1q subints. Hope that makes sense? HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:39xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12
Re: [c-nsp] OSPF issue
Thanks for the reply. Sent 1 pings from R1-R2, 1 loss: Success rate is 99 percent (/1), round-trip min/avg/max = 16/17/264 ms I will try p-t-p suggestion now. I also have just noticed that ping multicast address, I am not getting a response from R1's new Int (When pinging from R2), but I am getting response in the reverse direction? From R1-R2#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.2, 16 msReply to request 0 from xxx.xxx.66.62, 16 ms From R2-R1 #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.1, 16 ms (Ran it a few times and same result) Date: Sat, 12 Nov 2011 23:28:26 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: cisco-nsp@puck.nether.net It seems as though R1 is not receiving hello's from R2 at some point and does so for the length of the dead timer, thus causing the adj to drop. This could be caused by any number of things. One suspect might be the use of spanning tree in carrier domain on the VLAN with an unstable topology. If somehow a topology change occurs on your circuit in the carrier domain and they are using plain 802.1d spanning tree with default settings, it could take at least 52 sec before traffic starts flowing on any alternate path in their L2 domain. During those 52 sec, any (redundant) ports that are making up the circuit connecting your R1 and R2 are likely discarding frames. The default dead time for OSPF is 40 sec. After the adjacency is formed, does the dead time decrease all the way to 0 right from the start ? Have you tried doing a ping between R1 and R2 on the dot1q subinterfaces for a period longer than 60 sec ? If that succeeds then this theory can be considered irrelevant. Also, seeing that this is a point-to-point topology, you might want to consider, as per Randy's suggestion, configuring the OSPF network type to point-to-point as there are no other routers on the segment so there's no point in doing DR/BDR election. From the output you've given so far, I don't see any weird stuff. Maybe you could provide your router config from R1 and R2 ? Just the router ospf section should suffice. If non of this helps or is ruled out, then we could be looking at a software bug. On Sat, Nov 12, 2011 at 9:21 PM, John Elliot johnellio...@hotmail.com wrote: Hi K, I've attached details in txt doc...hopefully it's permitted by the list. Date: Sat, 12 Nov 2011 17:53:52 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: randy_94...@yahoo.com; cisco-nsp@puck.nether.net Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.com wrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working) is handed of via vlan at R2(Which is portchan dot1q subint), the other is physical int FA3/0, the one that is up/down, is handed off via different provider, same vlan at each end, and as portchan dot1q subints. Hope that makes sense? HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We
Re: [c-nsp] OSPF issue
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 From: johnellio...@hotmail.com To: kim...@gmail.com Date: Sun, 13 Nov 2011 09:47:04 +1100 CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF issue Thanks for the reply. Sent 1 pings from R1-R2, 1 loss: Success rate is 99 percent (/1), round-trip min/avg/max = 16/17/264 ms I will try p-t-p suggestion now. I also have just noticed that ping multicast address, I am not getting a response from R1's new Int (When pinging from R2), but I am getting response in the reverse direction? From R1-R2#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.2, 16 msReply to request 0 from xxx.xxx.66.62, 16 ms From R2-R1 #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.1, 16 ms (Ran it a few times and same result) Date: Sat, 12 Nov 2011 23:28:26 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: cisco-nsp@puck.nether.net It seems as though R1 is not receiving hello's from R2 at some point and does so for the length of the dead timer, thus causing the adj to drop. This could be caused by any number of things. One suspect might be the use of spanning tree in carrier domain on the VLAN with an unstable topology. If somehow a topology change occurs on your circuit in the carrier domain and they are using plain 802.1d spanning tree with default settings, it could take at least 52 sec before traffic starts flowing on any alternate path in their L2 domain. During those 52 sec, any (redundant) ports that are making up the circuit connecting your R1 and R2 are likely discarding frames. The default dead time for OSPF is 40 sec. After the adjacency is formed, does the dead time decrease all the way to 0 right from the start ? Have you tried doing a ping between R1 and R2 on the dot1q subinterfaces for a period longer than 60 sec ? If that succeeds then this theory can be considered irrelevant. Also, seeing that this is a point-to-point topology, you might want to consider, as per Randy's suggestion, configuring the OSPF network type to point-to-point as there are no other routers on the segment so there's no point in doing DR/BDR election. From the output you've given so far, I don't see any weird stuff. Maybe you could provide your router config from R1 and R2 ? Just the router ospf section should suffice. If non of this helps or is ruled out, then we could be looking at a software bug. On Sat, Nov 12, 2011 at 9:21 PM, John Elliot johnellio...@hotmail.com wrote: Hi K, I've attached details in txt doc...hopefully it's permitted by the list. Date: Sat, 12 Nov 2011 17:53:52 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: randy_94...@yahoo.com; cisco-nsp@puck.nether.net Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.com wrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working
Re: [c-nsp] OSPF issue
Hi John, ...that will not work - you will have to change the network type to pt-to-pt on all four interfaces. I have just started catching up on this thread ...I am curious: The new port-channels on r1 and r2 are the interface-stats for channel-group members clean? are they all full-dup on both ends? same method for bundling links on r1 and r2 correct? ./Randy --- On Sat, 11/12/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: kim...@gmail.com Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Saturday, November 12, 2011, 3:26 PM 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 From: johnellio...@hotmail.com To: kim...@gmail.com Date: Sun, 13 Nov 2011 09:47:04 +1100 CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF issue Thanks for the reply. Sent 1 pings from R1-R2, 1 loss: Success rate is 99 percent (/1), round-trip min/avg/max = 16/17/264 ms I will try p-t-p suggestion now. I also have just noticed that ping multicast address, I am not getting a response from R1's new Int (When pinging from R2), but I am getting response in the reverse direction? From R1-R2#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.2, 16 msReply to request 0 from xxx.xxx.66.62, 16 ms From R2-R1 #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.1, 16 ms (Ran it a few times and same result) Date: Sat, 12 Nov 2011 23:28:26 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: cisco-nsp@puck.nether.net It seems as though R1 is not receiving hello's from R2 at some point and does so for the length of the dead timer, thus causing the adj to drop. This could be caused by any number of things. One suspect might be the use of spanning tree in carrier domain on the VLAN with an unstable topology. If somehow a topology change occurs on your circuit in the carrier domain and they are using plain 802.1d spanning tree with default settings, it could take at least 52 sec before traffic starts flowing on any alternate path in their L2 domain. During those 52 sec, any (redundant) ports that are making up the circuit connecting your R1 and R2 are likely discarding frames. The default dead time for OSPF is 40 sec. After the adjacency is formed, does the dead time decrease all the way to 0 right from the start ? Have you tried doing a ping between R1 and R2 on the dot1q subinterfaces for a period longer than 60 sec ? If that succeeds then this theory can be considered irrelevant. Also, seeing that this is a point-to-point topology, you might want to consider, as per Randy's suggestion, configuring the OSPF network type to point-to-point as there are no other routers on the segment so there's no point in doing DR/BDR election. From the output you've given so far, I don't see any weird stuff. Maybe you could provide your router config from R1 and R2 ? Just the router ospf section should suffice. If non of this helps or is ruled out, then we could be looking at a software bug. On Sat, Nov 12, 2011 at 9:21 PM, John Elliot johnellio...@hotmail.com wrote: Hi K, I've attached details in txt doc...hopefully it's permitted by the list. Date: Sat, 12 Nov 2011 17:53:52 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: randy_94...@yahoo.com; cisco-nsp@puck.nether.net Hi John, I'm failing to get the full picture of the situation. Short from the fact that I'm contracting a headache from trying to read the logs :-) Maybe I could help if you could provide the configs of the ports and maybe supply the output of the commands and log with proper formatting. Also, throw in a show ip ospf in there. Rgds, K On Sat, Nov 12, 2011 at 7:43 AM, John Elliot johnellio...@hotmail.com wrote: Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider
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.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30xxx.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 - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
Hi Randy, Hi John, ...that will not work - you will have to change the network type to pt-to-pt on all four interfaces. Thanks - Ill keep them as broadcast for the time beingboth routers have a number of other adjacencies, so Id prefer to not break them as it is in production. I have just started catching up on this thread ...I am curious: The new port-channels on r1 and r2 are the interface-stats for channel-group members clean? are they all full-dup on both ends? same method for bundling links on r1 and r2 correct? ./Randy portchan on R1+R2 are clean+full dup both endsthey also have other existing (working) links with ospf running without issue(Plus numerous client ethernet tails all also working fine) R1 hasportchan subint to R3 (OSPF Working fine for years) GigEth subint to R3 (OSPF Working fine for years)Fasteth int to R2 (OSPF working fine for years)portchan subint to R2 (OSPF not working as discussed) (R1 portchan is dual trunk to 3750 stack, which then has carrier hand-offs as trunk ports(Tails handed off to us as vlans)) R2 hasportchan subint to R1 (OSPF Working fine for years)portchan subint to R1 (OSPF not working as discussed)portchan subint to R3 (OSPF working fine for years) (R2 portchan is dual trunk to 3560, which then has carrier hand-offs as trunk ports(Tails handed off to us as vlans)) --- On Sat, 11/12/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: kim...@gmail.com Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Saturday, November 12, 2011, 3:26 PM 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.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30 xxx.xxx.66.1Port-channel1.86 From: johnellio...@hotmail.com To: kim...@gmail.com Date: Sun, 13 Nov 2011 09:47:04 +1100 CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF issue Thanks for the reply. Sent 1 pings from R1-R2, 1 loss: Success rate is 99 percent (/1), round-trip min/avg/max = 16/17/264 ms I will try p-t-p suggestion now. I also have just noticed that ping multicast address, I am not getting a response from R1's new Int (When pinging from R2), but I am getting response in the reverse direction? From R1-R2#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.2, 16 msReply to request 0 from xxx.xxx.66.62, 16 ms From R2-R1 #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.1, 16 ms (Ran it a few times and same result) Date: Sat, 12 Nov 2011 23:28:26 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: cisco-nsp@puck.nether.net It seems as though R1 is not receiving hello's from R2 at some point and does so for the length of the dead timer, thus causing the adj to drop. This could be caused by any number of things. One suspect might be the use of spanning tree in carrier domain on the VLAN with an unstable topology. If somehow a topology change occurs on your circuit in the carrier domain and they are using plain 802.1d spanning tree with default settings, it could take at least 52 sec before traffic starts flowing on any alternate path in their L2 domain. During those 52 sec, any (redundant) ports that are making up the circuit connecting your R1 and R2 are likely discarding frames. The default dead time for OSPF is 40 sec. After the adjacency is formed, does the dead time decrease all the way to 0 right from the start ? Have you tried doing a ping between R1 and R2 on the dot1q subinterfaces for a period longer than 60 sec ? If that succeeds then this theory can be considered irrelevant. Also, seeing that this is a point-to-point topology, you might want to consider, as per Randy's suggestion, configuring the OSPF network type to point-to-point as there are no other routers on the segment so there's no point in doing DR/BDR election. From the output you've given so far, I don't see any weird stuff. Maybe you could provide your router config from R1 and R2 ? Just the router ospf section should suffice. If non of this helps or is ruled out, then we could be looking at a software bug. On Sat, Nov 12, 2011 at 9:21 PM, John Elliot
Re: [c-nsp] OSPF issue
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). Thanks - If provider is blocking multicast, would we still be able to get an adjacency(albeit for a short time)? The results of show ip ospf interface [interface name] on both sides after configuring point-to-point on the interfaces would be useful information. I've removed p-t-p conf, but recorded this when it was enabled on both ints:(Hopefully formatting doesnt make it unreadable) R1 Port-channel1.87 is up, line protocol is up Internet Address xxx.xxx.66.61/30, Area 0.0.0.0 Process ID 100, Router ID xxx.xxx.76.238, Network Type POINT_TO_POINT, Cost: 190 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5oob-resync timeout 40Hello due in 00:00:04 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 6/16, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 50 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabledYoungest key id is 10 R2 Port-channel1.87 is up, line protocol is up Internet Address xxx.xxx.66.62/30, Area 0.0.0.0 Process ID 100, Router ID xxx.xxx.76.248, Network Type POINT_TO_POINT, Cost: 190 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5oob-resync timeout 40Hello due in 00:00:00 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 6/6, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 45 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabledYoungest key id is 10 -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF issue
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.2481 FULL/DR 00:01:37xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:31xxx.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: j...@west.net To: cisco-nsp@puck.nether.net 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.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30xxx.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 - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] OSPF issue
OSPF Issue Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1): Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:00xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:39xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60seconds Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: 2 Way Communication to xxx.xxx.76.248 on Port-channel1.87, state 2WAYNov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:58.448 aest: OSPF: E! lect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest:DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.448 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0x1717 opt 0x52 flag 0x7 len 32Nov 12 10:12:58.448 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: Set Port-channel1.87 flush timerNov 12 10:12:58.448 aest: OSPF: Remember old DR xxx.xxx.76.238 (id)Nov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest:DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.464 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTARTNov 12 10:12:58.464 aest: OSPF: NBR Negotiation Done. We a! re the SLAVENov 12 10:12:58.464 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x2 len 1412Nov 12 10:12:58.464 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.484 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB51 opt 0x52 flag 0x3 len 1412 mtu 1500 state EXCHANGENov 12 10:12:58.484 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB51 opt 0x52 flag 0x2 len 1412Nov 12 10:12:58.484 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.500 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB52 opt 0x52 flag 0x3 len 1412 mtu 1500 state EXCHANGENov 12 10:12:58.500 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB52 opt 0x52 flag 0x2 len 1412Nov 12 10:12:58.500 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.520 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB53 opt 0x52 flag 0x3 len 1412 mtu 1500 state EXCHANGENov 12 10:12:58.520
Re: [c-nsp] OSPF issue
-channel1.87, state FULLNov 12 10:12:58.776 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from LOADING to FULL, Loading DoneNov 12 10:12:58.776 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB62 opt 0x52 flag 0x0 len 32Nov 12 10:12:58.780 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.948 ! aest: OSPF: Reset old DR on Port-channel1.87 R2 logs: Nov 12 10:12:58.436 AEST: OSPF: Cannot see ourself in hello from xxx.xxx.76.238 on Port-channel1.87, state INITNov 12 10:12:58.436 AEST: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.436 AEST: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.436 AEST: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:58.436 AEST: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.436 AEST:DR: xxx.xxx.76.248 (Id) BDR: none Nov 12 10:12:58.436 AEST: OSPF: Send with youngest Key 10Nov 12 10:12:58.452 AEST: OSPF: Rcv DBD from xxx.xxx.76.238 on Port-channel1.87 seq 0x1717 opt 0x52 flag 0x7 len 32 mtu 1500 state INITNov 12 10:12:58.452 AEST: OSPF: 2 Way Communication to xxx.xxx.76.238 on Port-channel1.87, state 2WAYNov 12 10:12:58.452 AEST: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.452 AEST: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.452 AEST: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.452 AEST: OSPF: Elect DR xxx.xxx.76.2! 48Nov 12 10:12:58.452 AEST:DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.452 AEST: OSPF: Port-channel1.87 Nbr xxx.xxx.76.238: Prepare dbase exchangeNov 12 10:12:58.452 AEST: OSPF: Send DBD to xxx.xxx.76.238 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x7 len 32Nov 12 10:12:58.452 AEST: OSPF: Send with youngest Key 10Nov 12 10:12:58.452 AEST: OSPF: First DBD and we are not SLAVENov 12 10:12:58.472 AEST: OSPF: Rcv DBD from xxx.xxx.76.238 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x2 len 1412 mtu 1500 state EXSTARTNov 12 10:12:58.472 AEST: OSPF: NBR Negotiation Done. We are the MASTERNov 12 10:12:58.472 AEST: OSPF: Port-channel1.87 Nbr xxx.xxx.76.238: Summary list built, size 1176Nov 12 10:12:58.472 AEST: OSPF: Send DBD to xxx.xxx.76.238 on Port-channel1.87 seq 0xB51 opt 0x52 flag 0x3 len 1412Nov 12 10:12:58.472 AEST: OSPF: Send with youngest Key 10Nov 12 10:12:58.488 AEST: OSPF: Rcv DBD from xxx.xxx.76.238 on Port-channel1.87 seq 0xB51 opt 0x52 ! flag 0x2 len 1412 mtu 1500 state EXCHANGENov 12 10:12:58.488 AEST: OSPF: Send DBD to xxx.xxx.76.238 on Port-channel1.87 seq 0xB52 opt 0x52 flag 0x3 len 1412 Any assistance is greatly appreciated. Cheers From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:30:45 +1100 Subject: [c-nsp] OSPF issue OSPF Issue Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1): Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:00xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:39 xxx.xxx.66.2FastEthernet3/0 Then new link loses adj. after ~60seconds Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build
Re: [c-nsp] OSPF issue
Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:39xxx.xxx.66.2FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:38xxx.xxx.66.2FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: 2 Way Communication to xxx.xxx.76.248 on Port-channel1.87, state 2WAYNov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:58.448 aest: OSPF:! E! lect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest:DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.448 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0x1717 opt 0x52 flag 0x7 len 32Nov 12 10:12:58.448 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: Set Port-channel1.87 flush timerNov 12 10:12:58.448 aest: OSPF: Remember old DR xxx.xxx.76.238 (id)Nov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.464 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x7 len 32 mtu 150! 0 state EXSTARTNov 12 10:12:58.464 aest: OSPF: NBR Negotiation Done. We a! re the SLAVENov 12 10:12:58.464 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB50 opt 0x52 flag 0x2 len 1412Nov 12 10:12:58.464 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.484 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB51 opt 0x52 flag 0x3 len 1412 mtu 1500 state EXCHANGENov 12 10:12:58.484 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0xB51 opt 0x52 flag 0x2 len 1412Nov 12 10:12:58.484 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.500 aest: OSPF: Rcv DBD from xxx.xxx.76.248 on Port-channel1.87 seq 0xB52 opt 0x52 flag 0x3 len 1412 mtu 1500 state
Re: [c-nsp] OSPF issue
Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:39 xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38 xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: 2 Way Communication to xxx.xxx.76.248 on Port-channel1.87, state 2WAYNov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:58.448 aest: OSPF:! E! lect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.448 aest: OSPF: Send DBD to xxx.xxx.76.248 on Port-channel1.87 seq 0x1717 opt 0x52 flag 0x7 len 32Nov 12 10:12:58.448 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: Set Port-channel1.87 flush timerNov 12 10:12:58.448 aest: OSPF: Remember old DR xxx.xxx.76.238 (id)Nov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238
Re: [c-nsp] OSPF issue
Lets try this once again: You have a port-channel between R1 and R2(over which; you have had ospf running without a problem...Correct? No - We have a working ospf adj between FA3/0(R1), and a vlan/dot1q subint /30(R2) via provider A Also you have ospf-running on a broadcast-segment ie, netmask on port-channel ip-addr is NOT /30 is, not ospf-network point-to-point. No - We have a new link (/30) new vlan from new provider, same vlan at both ends(As dot1q subints) that is going up/down every ~60sec So you now have a situation where you are asking two routers R1 and R2( with their-own ospf-router-ids to form another OSPF Neighbor relation via the same port-channel! The question you need to ask yourself is this: How can that be possible? It is NOT. Change your config to be point-to-point(ospf) and you will see the what-you-expect! We have 2 links, both /30's, one (working) is handed of via vlan at R2(Which is portchan dot1q subint), the other is physical int FA3/0, the one that is up/down, is handed off via different provider, same vlan at each end, and as portchan dot1q subints. Hope that makes sense? HTH ./Randy --- On Fri, 11/11/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: cisco-nsp cisco-nsp@puck.nether.net Date: Friday, November 11, 2011, 4:51 PM Well, that turned out better :/ From: johnellio...@hotmail.com To: cisco-nsp@puck.nether.net Date: Sat, 12 Nov 2011 11:47:58 +1100 Subject: Re: [c-nsp] OSPF issue Err - dont know where the line breaks went in that msg? I'll try re-send(Hopefully a tad more readable) Hope someone can assist with an ospf problem - We have an existing ospf adj running fine between R1+R2, we have just provisioned a second link, enabled ospf and we see it form adjacency which lasts ~60seconds, then R1 sees R2 as dead, and R2 Cannot see ourself in hello from R1, and then the whole thing starts again. With both adj. up(From R1):Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:00 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:39xxx.xxx.66.2 FastEthernet3/0 Then new link loses adj. after ~60secondsNeighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:38xxx.xxx.66.2 FastEthernet3/0 NB - pings to/from both R1+R2 are clean(No loss/excessive latency), and both ends(Ints) set to mtu of 1500. R1 logs Nov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is deadNov 12 10:12:48.716 aest: OSPF: xxx.xxx.76.248 address xxx.xxx.66.62 on Port-channel1.87 is dead, state DOWNNov 12 10:12:48.716 aest: %OSPF-5-ADJCHG: Process 100, Nbr xxx.xxx.76.248 on Port-channel1.87 from FULL to DOWN, Neighbor Down: Dead timer expiredNov 12 10:12:48.716 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:48.716 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:48.716 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:48.716 aest: OSPF: Elect DR xxx.xxx.76.238Nov 12 10:12:48.716 aest:DR: xxx.xxx.76.238 (Id) BDR: none Nov 12 10:12:48.716 aest: OSPF: Reset Port-channel1.87 flush timerNov 12 10:12:48.716 aest: OSPF: Remember old DR xxx.xxx.76.248 (id)Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12! :4! 9.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Send with youngest Key 10Nov 12 10:12:49.216 aest: OSPF: Build router LSA for area 0.0.0.0, router ID xxx.xxx.76.238, seq 0x80014360, process 100Nov 12 10:12:49.216 aest: OSPF: No full nbrs to build Net Lsa for interface Port-channel1.87Nov 12 10:12:51.716 aest: OSPF: Send with youngest Key 10Nov 12 10:12:51.732 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.432 aest: OSPF: Send with youngest Key 10Nov 12 10:12:58.448 aest: OSPF: 2 Way Communication to xxx.xxx.76.248 on Port-channel1.87, state 2WAYNov 12 10:12:58.448 aest: OSPF: Neighbor change Event on interface Port-channel1.87Nov 12 10:12:58.448 aest: OSPF: DR/BDR election on Port-channel1.87 Nov 12 10:12:58.448 aest: OSPF: Elect BDR 0.0.0.0Nov 12 10:12:58.448 aest: OSPF:! E! lect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: OSPF: Elect BDR xxx.xxx.76.238Nov 12 10:12:58.448 aest: OSPF: Elect DR xxx.xxx.76.248Nov 12 10:12:58.448 aest: DR: xxx.xxx.76.248 (Id) BDR: xxx.xxx.76.238 (Id)Nov 12 10:12:58.448
