Re: [c-nsp] understanding interface traffic counters of Cisco router and Cisco switch
Hi, Not sure if this had been mentioned before as I am jumping in late and have not seem the full discussion! I believe the difference you are seeing is due to the FCS. Usually it is not counted by a router but is by a switch! There can also be some inconsistency between interface types and what is measured where which can makes working out QoS values a nightmare. 4 bytes is just under 0.3% so could account for your discrepancy in this case! Regards Nigel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Martin T m4rtn...@gmail.com wrote: Erik, Harold: I already had disabled CDP and BPDU's. At the moment all switch interfaces involved in this setup have following configuration: switchport access vlan 333 switchport mode access switchport nonegotiate no keepalive no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable ..and spanning-tree on VLAN 333 is disabled(no spanning-tree vlan 333). Updated drawing is here: http://img525.imageshack.us/img525/5736/interfacestrafficcounte.png On top of all this I configured SPAN which had Fa0/1 as a source interface and Fa0/3 as a destination one: monitor session 1 source interface Fa0/1 monitor session 1 destination interface Fa0/3 ..and PC with tcpdump -nei eth0 not host 10.10.10.2 running was listening port Fa0/3. Throughout the 900 seconds long test(iperf -c 10.10.11.2 -u -d -b 20m -t 900) all that tcpdump captured were ARP requests and replies. In other words it looks like there are no protocols running on the switch which might cause such overhead.. In this case, as I mentioned, I did a 900s test with 20Mbps in both directions and difference between switch interfaces and router interfaces were 0.3% as usual: Cisco2950#show interfaces Fa0/1 | i packets input|packets output 1530640 packets input, 2320402324 bytes, 0 no buffer 1530646 packets output, 2320409968 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 1530640 packets input, 2320409584 bytes, 0 no buffer 1530636 packets output, 2320402068 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 1530645 packets input, 2320409904 bytes, 0 no buffer 1530641 packets output, 2320402388 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 1530636 packets input, 2320402362 bytes, 0 no buffer 1530641 packets output, 2320409648 bytes, 0 underruns Cisco2950# C3640#show interfaces Fa2/0 | i packets input|packets output 1530641 packets input, 2314279824 bytes 1530645 packets output, 2314287324 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 1530641 packets input, 2314287084 bytes 1530635 packets output, 2314279464 bytes, 0 underruns C3640# Any additional ideas? :) regards, martin 2011/11/11 Erik Soosalu erik.soos...@calyxinc.com: What about all the other control packet stuff that might be running on the switch (CDP, Spanning Tree, VTP, etc)? Thanks, Erik Soosalu -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Martin T Sent: Friday, November 11, 2011 2:12 PM To: Christopher J. Pilkington Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] understanding interface traffic counters of Cisco router and Cisco switch Sergey, Christopher: I doubt that it's the VLAN tag which adds this additional 0.3% traffic to switch interface counters when compared to router interface counters. As far as I understand, VLAN tag is added in case when frame leaves the switch via trunk(802.1Q) port, but this is not a case in my test- all the switch ports are in switchport mode access. Traffic between switch ports in the switch should have no VLAN information applied.. Any other ideas? Or am I wrong that traffic inside the switch-internal-VLAN has no VLAN tag information? regards, martin 2011/11/11 Christopher J. Pilkington c...@0x1.net: Fa0/1 is an access port, not a 802.1q trunk, the traffic on that interface is not tagged, so the monitor destination will see untagged traffic. On Nov 10, 2011, at 19:38, Martin T m4rtn...@gmail.com wrote: Sergey, I modified the setup a little: http://img64.imageshack.us/img64/5736/interfacestrafficcounte.png ..so now port Fa0/3 in the switch is in monitoring state and all the traffic from switch port Fa0/1 is copied to Fa0/3, which is connected to eth1 interface on ubuntu machine. Now if I start tcpdump -nei eth1 -c10 in ubuntu machine in the middle of the iperf test, then results are: root@ubuntu:~# tcpdump -nei eth1 -c10 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 00:10:30.167558 10:40:10:40:10:40 00:06:d7:4d:c0:61, ethertype IPv4 (0x0800), length 1512: 10.10.10.2.54064 10.10.11.2.5001: UDP, length 1470 00:10:30.167563
[c-nsp] AAA accounting issue
Hello, I'm using 7301 as vrf-aware NAS to terminate PPP sessions from l2tp tunnels into vrfs, and there is huge discrepancy between traffic counters on virtual-access interface and accounting records. For example: --- #sh int virtual-access 4 ... 226 packets input, 11393 bytes, 0 no buffer ... 263 packets output, 13465 bytes, 0 underruns --- #sh aaa user 115 Unique id 115 is currently in use. ... 66BC01A0 0 0001 bytes_in(135) 4 11846(2E46) 66BC01B0 0 0001 bytes_out(275) 4 23802(5CFA) 66BC01E0 0 0001 paks_in(136) 4 235(EB) 66BBF5D0 0 0001 paks_out(276) 4 273(111) --- Packet counters do match, but output bytes is almost twice in aaa. ___ 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] Full BGP Feed Convergence Time on ASR 1006 RP2 Setup
On Nov 11, 2011, at 4:20 PM, Joseph Jackson wrote: On Fri, Nov 11, 2011 at 2:45 AM, Mark Tinka mti...@globaltransit.net wrote: I just brought up an ASR1006 + RP2 + ESP20 + SIP10, peering with 3x route reflectors, receiving a full v4/v6/VPNv4 table from them, simultaneously. For v4, the 1st session was done in about 48 seconds, the other two were done about 10 seconds earlier than that. Hope this helps. Cheers, Mark. Silly question time, but how are you judging that time on - router has stopped receiving prefixes on show ip bgp sum (or neighbor). Or are you defining it having a full feed with some other metric? I would always track the times for: a) bgp stability b) cef table population (show ip cef sum) c) hardware population (show mls cef sum) - Jared ___ 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] AAA accounting issue
В Сбт, 12/11/2011 в 13:41 +0400, Nikolay S. пишет: Hello, I'm using 7301 as vrf-aware NAS to terminate PPP sessions from l2tp tunnels into vrfs, and there is huge discrepancy between traffic counters on virtual-access interface and accounting records. For example: --- #sh int virtual-access 4 ... 226 packets input, 11393 bytes, 0 no buffer ... 263 packets output, 13465 bytes, 0 underruns --- #sh aaa user 115 Unique id 115 is currently in use. ... 66BC01A0 0 0001 bytes_in(135) 4 11846(2E46) 66BC01B0 0 0001 bytes_out(275) 4 23802(5CFA) 66BC01E0 0 0001 paks_in(136) 4 235(EB) 66BBF5D0 0 0001 paks_out(276) 4 273(111) --- Packet counters do match, but output bytes is almost twice in aaa. I did a simple test, sending single ping into the PPP interface, and it seems like l2tp/udp/ip overhead is being accounted for outgoing packets. - Cumulative Byte/Packet Counts : Bytes In = 27624 Bytes Out = 53246 Paks In = 496 Paks Out = 581 - #ping vrf test 172.16.8.80 size 36 repeat 1 Type escape sequence to abort. Sending 1, 36-byte ICMP Echos to 172.16.8.80, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 68/68/68 ms - Cumulative Byte/Packet Counts : Bytes In = 27664 Bytes Out = 53322 Paks In = 497 Paks Out = 582 - For output: 53246 - 53322 = 76 = 36 ICMP + 4 PPP + 8 L2TP + 8 UDP + 20 IP Whereas for input packets only PPP header is accounted: 27664 - 27624 = 40 = 36 ICMP + 4 PPP Could someone tell, if this is an expected behavior or not? ___ 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
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
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
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 A
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] understanding interface traffic counters of Cisco router and Cisco switch
Saku, yes, SNMP counters show exactly the same results as interface counters under CLI. Counters under CLI: Cisco2950#show interfaces Fa0/1 | i packets input|packets output 510257 packets input, 773479509 bytes, 0 no buffer 510270 packets output, 773484727 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 510232 packets input, 773479047 bytes, 0 no buffer 510229 packets output, 773478942 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 510224 packets input, 773476532 bytes, 0 no buffer 510241 packets output, 773482027 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 510221 packets input, 773476198 bytes, 0 no buffer 510238 packets output, 773481663 bytes, 0 underruns Cisco2950# C3640#show interfaces Fa2/0 | i packets input|packets output 510236 packets input, 771438752 bytes 510232 packets output, 771436264 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 510227 packets input, 771437906 bytes 510222 packets output, 771435374 bytes, 0 underruns C3640# Counters under SNMP: Cisco2950: iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 773479509 iso.3.6.1.2.1.2.2.1.16.1 = Counter32: 773488104 iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 773479047 iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 773478942 iso.3.6.1.2.1.2.2.1.10.23 = Counter32: 773476532 iso.3.6.1.2.1.2.2.1.16.23 = Counter32: 773482545 iso.3.6.1.2.1.2.2.1.10.24 = Counter32: 773476198 iso.3.6.1.2.1.2.2.1.16.24 = Counter32: 773481663 C3640: iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 771438344 iso.3.6.1.2.1.2.2.1.16.1 = Counter32: 771436264 iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 771437906 iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 771435374 Nigel, what makes you think that router counters doesn't include FCS? At least both router interfaces and switch interfaces have CRC field present.. regards, martin 2011/11/12 Harold 'Buz' Dale buz.d...@usg.edu: Only other thing I can think of is autonegotiation... From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] On Behalf Of Martin T [m4rtn...@gmail.com] Sent: Friday, November 11, 2011 6:37 PM To: Erik Soosalu Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] understanding interface traffic counters of Cisco router and Cisco switch Erik, Harold: I already had disabled CDP and BPDU's. At the moment all switch interfaces involved in this setup have following configuration: switchport access vlan 333 switchport mode access switchport nonegotiate no keepalive no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable ..and spanning-tree on VLAN 333 is disabled(no spanning-tree vlan 333). Updated drawing is here: http://img525.imageshack.us/img525/5736/interfacestrafficcounte.png On top of all this I configured SPAN which had Fa0/1 as a source interface and Fa0/3 as a destination one: monitor session 1 source interface Fa0/1 monitor session 1 destination interface Fa0/3 ..and PC with tcpdump -nei eth0 not host 10.10.10.2 running was listening port Fa0/3. Throughout the 900 seconds long test(iperf -c 10.10.11.2 -u -d -b 20m -t 900) all that tcpdump captured were ARP requests and replies. In other words it looks like there are no protocols running on the switch which might cause such overhead.. In this case, as I mentioned, I did a 900s test with 20Mbps in both directions and difference between switch interfaces and router interfaces were 0.3% as usual: Cisco2950#show interfaces Fa0/1 | i packets input|packets output 1530640 packets input, 2320402324 bytes, 0 no buffer 1530646 packets output, 2320409968 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 1530640 packets input, 2320409584 bytes, 0 no buffer 1530636 packets output, 2320402068 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 1530645 packets input, 2320409904 bytes, 0 no buffer 1530641 packets output, 2320402388 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 1530636 packets input, 2320402362 bytes, 0 no buffer 1530641 packets output, 2320409648 bytes, 0 underruns Cisco2950# C3640#show interfaces Fa2/0 | i packets input|packets output 1530641 packets input, 2314279824 bytes 1530645 packets output, 2314287324 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 1530641 packets input, 2314287084 bytes 1530635 packets output, 2314279464 bytes, 0 underruns C3640# Any additional ideas? :) regards, martin 2011/11/11 Erik Soosalu erik.soos...@calyxinc.com: What about all the other control packet stuff that might be running on the switch (CDP, Spanning Tree, VTP, etc)? Thanks, Erik Soosalu -Original Message- From:
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/
Re: [c-nsp] stable image recommendations for asr1001
On Friday, November 04, 2011 11:21:23 PM Brian Roche wrote: Just received a new asr1001 and it showed up without an image. Curious if there are any recommendations out there for a stable image. Thanks We're quite happy with IOS XE 3.4(1)S, a.ka. 15.1(3)S1. It is likely the most current too. Especially great if you're looking at IS-IS LFA/IP-FRR, Stateful NAT64 and Stateful Inter-Chassis Redundancy for NAT44. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Cisco and third party transceivers
On Wednesday, November 09, 2011 08:35:56 PM Jared Mauch wrote: Are you sure they were SFP vs GLC? Some platforms support these differently or not at all. Cisco can't keep this straight themselves. They regularly won't support their own optics in their own product unless you got the right one. Like for us, the ME3600X can swallow both GLC- and SFP- optics, since it's both a switch and router (although more a router). Interestingly, a 7201 we have was able to accept GLC- optics, even though it's always supposed to eat SFP-. We stopped keeping up, unless you're talking about pure classic switches such as the 2960, e.t.c. If memory serves, the RP's on our CRS routers shipped with GLC- optics for the control ports. In this case, I have to praise Juniper's consistency. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] ASA vs. ASR for large Wireless NAT deployment ?
On Saturday, November 12, 2011 06:48:35 AM Johnson, Neil M wrote: One requirement is that the NAT device not mangle IPv6 and only NAT IPv4 traffic destined to the Internet (we route some private address space internally). Any recommendations ? We've deployed some ASR1006's for NAT44 and NAT64. The NAT44 is for our IPTv VoD service (Unicast), while the NAT64 is for IPv6-only customers trying to reach IPv4-only resources. We have the same chassis playing both roles. I don't know about the ASA, but the ASR1000 does support Stateful Inter-Chassis NAT Redundancy, but only for NAT44 at this time. Not sure when NAT64 will be coming, but I'm sure it will. Also, I think the ESP20 should be good for about 2,000,000 NAT translations last time I checked. Of course, the ASR1006 makes lots of sense for us because it's also a router, so we can still IP/MPLS stuff on there without any restrictions. Hope this helps. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] understanding interface traffic counters of Cisco router and Cisco switch
Martin, In my last role, we did some in depth testing for QoS. Some simple tests using specific packet sizes and a bit of maths showed this to be the case. If memory serves it was also confirmed by our Cisco support team! Regards Nigel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Martin T m4rtn...@gmail.com wrote: Saku, yes, SNMP counters show exactly the same results as interface counters under CLI. Counters under CLI: Cisco2950#show interfaces Fa0/1 | i packets input|packets output 510257 packets input, 773479509 bytes, 0 no buffer 510270 packets output, 773484727 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 510232 packets input, 773479047 bytes, 0 no buffer 510229 packets output, 773478942 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 510224 packets input, 773476532 bytes, 0 no buffer 510241 packets output, 773482027 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 510221 packets input, 773476198 bytes, 0 no buffer 510238 packets output, 773481663 bytes, 0 underruns Cisco2950# C3640#show interfaces Fa2/0 | i packets input|packets output 510236 packets input, 771438752 bytes 510232 packets output, 771436264 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 510227 packets input, 771437906 bytes 510222 packets output, 771435374 bytes, 0 underruns C3640# Counters under SNMP: Cisco2950: iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 773479509 iso.3.6.1.2.1.2.2.1.16.1 = Counter32: 773488104 iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 773479047 iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 773478942 iso.3.6.1.2.1.2.2.1.10.23 = Counter32: 773476532 iso.3.6.1.2.1.2.2.1.16.23 = Counter32: 773482545 iso.3.6.1.2.1.2.2.1.10.24 = Counter32: 773476198 iso.3.6.1.2.1.2.2.1.16.24 = Counter32: 773481663 C3640: iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 771438344 iso.3.6.1.2.1.2.2.1.16.1 = Counter32: 771436264 iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 771437906 iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 771435374 Nigel, what makes you think that router counters doesn't include FCS? At least both router interfaces and switch interfaces have CRC field present.. regards, martin 2011/11/12 Harold 'Buz' Dale buz.d...@usg.edu: Only other thing I can think of is autonegotiation... _ From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] On Behalf Of Martin T [m4rtn...@gmail.com] Sent: Friday, November 11, 2011 6:37 PM To: Erik Soosalu Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] understanding interface traffic counters of Cisco router and Cisco switch Erik, Harold: I already had disabled CDP and BPDU's. At the moment all switch interfaces involved in this setup have following configuration: switchport access vlan 333 switchport mode access switchport nonegotiate no keepalive no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable ..and spanning-tree on VLAN 333 is disabled(no spanning-tree vlan 333). Updated drawing is here: http://img525.imageshack.us/img525/5736/interfacestrafficcounte.png On top of all this I configured SPAN which had Fa0/1 as a source interface and Fa0/3 as a destination one: monitor session 1 source interface Fa0/1 monitor session 1 destination interface Fa0/3 ..and PC with tcpdump -nei eth0 not host 10.10.10.2 running was listening port Fa0/3. Throughout the 900 seconds long test(iperf -c 10.10.11.2 -u -d -b 20m -t 900) all that tcpdump captured were ARP requests and replies. In other words it looks like there are no protocols running on the switch which might cause such overhead.. In this case, as I mentioned, I did a 900s test with 20Mbps in both directions and difference between switch interfaces and router interfaces were 0.3% as usual: Cisco2950#show interfaces Fa0/1 | i packets input|packets output 1530640 packets input, 2320402324 bytes, 0 no buffer 1530646 packets output, 2320409968 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 1530640 packets input, 2320409584 bytes, 0 no buffer 1530636 packets output, 2320402068 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 1530645 packets input, 2320409904 bytes, 0 no buffer 1530641 packets output, 2320402388 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 1530636 packets input, 2320402362 bytes, 0 no buffer 1530641 packets output, 2320409648 bytes, 0 underruns Cisco2950# C3640#show interfaces Fa2/0 | i packets input|packets output 1530641 packets input, 2314279824 bytes 1530645 packets output, 2314287324 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 1530641 packets input, 2314287084 bytes 1530635 packets output, 2314279464 bytes, 0 underruns C3640#
