Re: [c-nsp] CPE with tracking redundancy and long lived (UDP) nat sessions
The problem is that the session stays active. I want the session to be lost. I believe the rules should be adhered to a bit more strictly. The session DOES NOT stay active. The phone is stupid. It should have realized there's no reply and restart the session. If the current matching nat statement would result in a different value for the inside global address, than a new translation should be called for. It isnt actually all that hard to check for, conceptually. And then you'd complain about the CPU load. What do you think is cheaper: checking the NAT table or NAT rules (including route maps) for every packet? (What would you expect to happen when the DHCP client address changes on the egress interface? Or if you change the ip address on an interface referenced by the ip nat statement?) You'd lose all sessions, obviously. What else would you expect? Apparently, the end stations dont change the source port for new attempts. Proves my point. The phone is stupid ;) There's a reason every new client session should use a new dynamic port number. This behavior has very disruptive end user symptoms. Many stupid implementations have disruptive end-user symptoms. Microsoft Network Load Balancing with unknown unicast MAC addresses immediately comes to mind ;) Ivan Pepelnjak blog.ioshints.info / www.ioshints.info ___ 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] 6509 problem
Hi Pete, Thanks for your response, I think you've confirmed our suspicions. We'll source another chassis:) James G -Original Message- From: Pete Templin [mailto:peteli...@templin.org] Sent: 24 January 2010 19:00 To: James Greig Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 problem James Greig wrote: Anyone else have any other thoughts on this? Could it be a bug or a faulty backplane on the 6500 chassis? It looks similar to what I got when I toasted a chassis in November. I didn't capture the console output, but basically the primary Sup was OK but the rest were all MAJOR failures. 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/
[c-nsp] Wr mem causes massive delay...
So, noticed something weird... Got a 2851 with 512MB or RAM... if I have a constant ping going thru the router and I write mem, the ping goes up by a factor of 5 Cisco 2851 (revision 53.50) with 507904K/16384K bytes of memory. Processor board ID FTX1345A0EY 2 Gigabit Ethernet interfaces 51 Serial interfaces 6 Channelized/Clear T1/PRI ports 1 Virtual Private Network (VPN) Module 4 Voice FXS interfaces DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 126000K bytes of ATA CompactFlash (Read/Write) Reply from 172.16.2.11: bytes=32 time=32ms TTL=60 Reply from 172.16.2.11: bytes=32 time=34ms TTL=60 Reply from 172.16.2.11: bytes=32 time=133ms TTL=60 Reply from 172.16.2.11: bytes=32 time=30ms TTL=60 Reply from 172.16.2.11: bytes=32 time=25ms TTL=60 So, is this normal? Jonathan ___ 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] Wr mem causes massive delay...
So, is this normal? Ours does it. I wouldn't worry about it - it does not mean packet forwarding will be adversely affected. ___ 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] Wr mem causes massive delay...
It is an IP address past the router, on the other side of the WAN... Jonathan On Mon, Jan 25, 2010 at 7:47 AM, Byrd, William w...@collier-byrd.netwrote: Is that IP address on an interface in the router or something behind it? William Collier-Byrd / w...@collier-byrd.net Make note, my e-mail address has changed. On Mon, Jan 25, 2010 at 8:27 AM, Jonathan Charles jonv...@gmail.comwrote: So, noticed something weird... Got a 2851 with 512MB or RAM... if I have a constant ping going thru the router and I write mem, the ping goes up by a factor of 5 Cisco 2851 (revision 53.50) with 507904K/16384K bytes of memory. Processor board ID FTX1345A0EY 2 Gigabit Ethernet interfaces 51 Serial interfaces 6 Channelized/Clear T1/PRI ports 1 Virtual Private Network (VPN) Module 4 Voice FXS interfaces DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 126000K bytes of ATA CompactFlash (Read/Write) Reply from 172.16.2.11: bytes=32 time=32ms TTL=60 Reply from 172.16.2.11: bytes=32 time=34ms TTL=60 Reply from 172.16.2.11: bytes=32 time=133ms TTL=60 Reply from 172.16.2.11: bytes=32 time=30ms TTL=60 Reply from 172.16.2.11: bytes=32 time=25ms TTL=60 So, is this normal? Jonathan ___ 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] Wr mem causes massive delay...
Are you pinging through (i.e. from one device on one side of the router through to another device on the other side of the router) or are you pinging an interface on the router? Packets forwarded through the router really shouldn't be affected. Pinging the router itself will definitely be affected by things that use a lot of CPU. On Mon, 25 Jan 2010, Jonathan Charles wrote: So, noticed something weird... Got a 2851 with 512MB or RAM... if I have a constant ping going thru the router and I write mem, the ping goes up by a factor of 5 Cisco 2851 (revision 53.50) with 507904K/16384K bytes of memory. Processor board ID FTX1345A0EY 2 Gigabit Ethernet interfaces 51 Serial interfaces 6 Channelized/Clear T1/PRI ports 1 Virtual Private Network (VPN) Module 4 Voice FXS interfaces DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 126000K bytes of ATA CompactFlash (Read/Write) Reply from 172.16.2.11: bytes=32 time=32ms TTL=60 Reply from 172.16.2.11: bytes=32 time=34ms TTL=60 Reply from 172.16.2.11: bytes=32 time=133ms TTL=60 Reply from 172.16.2.11: bytes=32 time=30ms TTL=60 Reply from 172.16.2.11: bytes=32 time=25ms TTL=60 So, is this normal? Jonathan ___ 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/ -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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-voip] Wr mem causes massive delay...
Well, it is a voice/BGP gateway with CCME as SRST... two PRIs three multilink T1s... J On Mon, Jan 25, 2010 at 8:14 AM, Rhodium rhodium...@yahoo.co.uk wrote: This is normally because the CPU shoots up to about 100% during the wri mem depending on the platform as it needs to save the config. This especially happens if the config file needs to be compressed as it is too long. Make sure you are running CEF on the router and dont do too many wri mems. :) Alternatively, you can try different IOS versions to determine which ones don't have as much impact on router as the current one but it is one of those things that I dont worry about. Regards, Jason --- On Mon, 1/25/10, Jonathan Charles jonv...@gmail.com wrote: From: Jonathan Charles jonv...@gmail.com Subject: Re: [cisco-voip] [c-nsp] Wr mem causes massive delay... To: Byrd, William w...@collier-byrd..net Cc: cisco-v...@puck.nether.net, cisco-nsp@puck.nether.net Date: Monday, January 25, 2010, 1:49 PM It is an IP address past the router, on the other side of the WAN... Jonathan On Mon, Jan 25, 2010 at 7:47 AM, Byrd, William w...@collier-byrd.net wrote: Is that IP address on an interface in the router or something behind it? William Collier-Byrd / w...@collier-byrd.net Make note, my e-mail address has changed. On Mon, Jan 25, 2010 at 8:27 AM, Jonathan Charles jonv...@gmail.com wrote: So, noticed something weird... Got a 2851 with 512MB or RAM... if I have a constant ping going thru the router and I write mem, the ping goes up by a factor of 5. Cisco 2851 (revision 53.50) with 507904K/16384K bytes of memory. Processor board ID FTX1345A0EY 2 Gigabit Ethernet interfaces 51 Serial interfaces 6 Channelized/Clear T1/PRI ports 1 Virtual Private Network (VPN) Module 4 Voice FXS interfaces DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 126000K bytes of ATA CompactFlash (Read/Write) Reply from 172.16.2.11: bytes=32 time=32ms TTL=60 Reply from 172.16.2.11: bytes=32 time=34ms TTL=60 Reply from 172.16.2.11: bytes=32 time=133ms TTL=60 Reply from 172.16.2.11: bytes=32 time=30ms TTL=60 Reply from 172.16.2.11: bytes=32 time=25ms TTL=60 So, is this normal? Jonathan ___ 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/ -Inline Attachment Follows- ___ cisco-voip mailing list cisco-v...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ 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] Wr mem causes massive delay...
On 25/01/10 13:55, Joe Maimon wrote: Phil Mayers wrote: So, is this normal? Ours does it. I wouldn't worry about it - it does not mean packet forwarding will be adversely affected. ___ Depends if he is pinging the router or pinging through it, as per the OP. If it affects pings through the router, not just pings TO the router, I would check that cef is on. Well, although he said pinging thru the router, I pretty much assumed he meant to. But sure, CEF is worth checking if not. OTOH are there any IOS releases for 28xx series which will *let* you disable CEF? Not a platform we use very much, so I'm not sure. ___ 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] Wr mem causes massive delay...
On (2010-01-25 09:34 -0600), Tony Varriale wrote: If you are pinging through the router, no that is not normal. There will always be some delay while it writes to media. But, it should not affect the forwarding path. It does, but only slightly, 'write' and 'dir' will both do that, as they interrupt. This is true at least for VXR, I don't see why 2800 would be different. To see these, you'd need non-averaging SLA measurments with very frequent polling interval, but if you can do that, you can see from transit SLA graphs e.g. when rancid was ran. When I've been able to see this, I've used some other methods than simple ping as the effect is extremely short and thus hard to see with ping. If OP was pinging once a second, and can reproduce this every time he does 'write', then this is much more likely real issue. -- ++ytti ___ 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] Wr mem causes massive delay...
This is a software based router, and 'wri mem' is very CPU intensive. What does the CPU look like before the wri mem is done? I don't think this is abnormal. Chuck - Original Message - From: Jonathan Charles jonv...@gmail.com To: cisco-v...@puck.nether.net; cisco-nsp@puck.nether.net Sent: Monday, January 25, 2010 7:27 AM Subject: [c-nsp] Wr mem causes massive delay... So, noticed something weird... Got a 2851 with 512MB or RAM... if I have a constant ping going thru the router and I write mem, the ping goes up by a factor of 5 Cisco 2851 (revision 53.50) with 507904K/16384K bytes of memory. Processor board ID FTX1345A0EY 2 Gigabit Ethernet interfaces 51 Serial interfaces 6 Channelized/Clear T1/PRI ports 1 Virtual Private Network (VPN) Module 4 Voice FXS interfaces DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 126000K bytes of ATA CompactFlash (Read/Write) Reply from 172.16.2.11: bytes=32 time=32ms TTL=60 Reply from 172.16.2.11: bytes=32 time=34ms TTL=60 Reply from 172.16.2.11: bytes=32 time=133ms TTL=60 Reply from 172.16.2.11: bytes=32 time=30ms TTL=60 Reply from 172.16.2.11: bytes=32 time=25ms TTL=60 So, is this normal? Jonathan ___ 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] CPE with tracking redundancy and long lived (UDP) nat sessions
Ivan Pepelnjak wrote: The problem is that the session stays active. I want the session to be lost. I believe the rules should be adhered to a bit more strictly. The session DOES NOT stay active. The phone is stupid. It should have realized there's no reply and restart the session. With UDP and other stateless protocols sessions, the router cannot tell that the phone thinks it is doing exactly that. You can view this issue with ping -t from windows stations as well. If the current matching nat statement would result in a different value for the inside global address, than a new translation should be called for. It isnt actually all that hard to check for, conceptually. And then you'd complain about the CPU load. What do you think is cheaper: checking the NAT table or NAT rules (including route maps) for every packet? It would be nice if there were some happy medium somewhere that would not result in sessions that wont die and cant work. (What would you expect to happen when the DHCP client address changes on the egress interface? Or if you change the ip address on an interface referenced by the ip nat statement?) You'd lose all sessions, obviously. What else would you expect? Thats exactly what I would expect. So either there is some validation going on beyond matching existing sessions for the the nat sessions or the event of changing an interface address referenced in nat rules triggers cleanup. I suppose I should pay more attention the next time an opportunity to view this presents itself - it may very well not be the case. Apparently, the end stations dont change the source port for new attempts. Proves my point. The phone is stupid ;) There's a reason every new client session should use a new dynamic port number. Is it a big surprise that IP handsets can have extremely shoddy stacks? How about traceroutes to phones that would have the remainder of the default 30 hops be the phone itself? Voice competency and networking competency seem to have oil/water difficulties. Most of these handsets can cost about as much as many new workstations do. This behavior has very disruptive end user symptoms. Many stupid implementations have disruptive end-user symptoms. Microsoft Network Load Balancing with unknown unicast MAC addresses immediately comes to mind ;) Ivan Pepelnjak blog.ioshints.info / www.ioshints.info So what is the bottom line? Is this the best that can be done with simple end site redundancy with object tracking and without dynamic routing? Thanks for all your help. Joe ___ 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] Wr mem causes massive delay...
On 1/25/10 8:07 AM, Church, Charles wrote: This is a software based router, and 'wri mem' is very CPU intensive. What does the CPU look like before the wri mem is done? I don't think this is abnormal. Very large config on an already busy router with compress-config turned on? ~Seth ___ 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] Wr mem causes massive delay...
It is a big config... cuz of all the voipy stuff. J On Mon, Jan 25, 2010 at 11:14 AM, Seth Mattinen se...@rollernet.us wrote: On 1/25/10 8:07 AM, Church, Charles wrote: This is a software based router, and 'wri mem' is very CPU intensive. What does the CPU look like before the wri mem is done? I don't think this is abnormal. Very large config on an already busy router with compress-config turned on? ~Seth ___ 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] CPE with tracking redundancy and long lived (UDP) nat sessions
Just did a few tests with 12.4(24)T. IOS NAT is extra stupid when it comes to clearing NAT translation table. Even though you have NAT rules tied to an interface (ip nat inside ... interface) they are not cleared when the interface IP address is lost or when the interface is shut down. So (I guess) the best you can do is to catch changes in tracked object's state with an EEM applet that clears all NAT translations. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info So what is the bottom line? Is this the best that can be done with simple end site redundancy with object tracking and without dynamic routing? ___ 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] Res: BGP Hold time expired/ospf dropping 6500 Sup720-3BXL
Hi, My experience with this kind of problem of Dead timer expired on OSPF solve with: - Put in the interface and subinterface all the same MTU. - Configure on the OSPF - ip ospf ignore-mtu - We use the topology 7600 - SWITCH-7600, that almost 100% of the times when this problem happed have been solve with the upgrade of IOS on the switch (Extreme). Normaly is some kind of problem (BUG) with the switch to work with a lot of traffic on the interfaces. I hope that can help with the problem of OSPF - Dead timer expired Regards, Samuel De: Andy B. globic...@gmail.com Para: roy bandwidth.u...@gmail.com Cc: cisco-nsp@puck.nether.net Enviadas: Sexta-feira, 22 de Janeiro de 2010 8:26:39 Assunto: Re: [c-nsp] BGP Hold time expired/ospf dropping 6500 Sup720-3BXL MTU is 1500 on all links: Core 1: #sh int te9/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, #sh int te9/2 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, #sh int te8/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, Core 2: #sh int te4/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, Core 3: #sh int te4/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, Core 4: #sh int te4/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, Core 1 is physically connected to 2,3 and 4 (star topology). BGP is fully meshed - no route reflector. Andy On Fri, Jan 22, 2010 at 11:00 AM, roy bandwidth.u...@gmail.com wrote: We had a somewhat similar problem with ospf/bgp which was eventually resolved by making link mtu uniform across the links. Let me know if this helps. On Friday, 22 January, 2010 04:07 PM, Gergely Antal wrote: just a thought : sh ip bgp neighbors | i Datagrams maybe one router tries to negotiate the session with low datagram size and the update storm floods the connection. On Fri, 22 Jan 2010 02:06:53 +0100 Andy B.globic...@gmail.com wrote: Hi, here we go: Core router that is causing headaches: interface Loopback0 ip address x.x.x.130 255.255.255.255 interface TenGigabitEthernet9/1 ip address y.y.y.1 255.255.255.252 no ip redirects no ip proxy-arp no cdp enable router ospf 1 router-id x.x.x.130 log-adjacency-changes redistribute connected subnets redistribute static subnets passive-interface default no passive-interface TenGigabitEthernet8/1 no passive-interface TenGigabitEthernet9/1 no passive-interface TenGigabitEthernet9/2 network y.y.y.0 0.0.0.3 area 0 network y.y.y.4 0.0.0.3 area 0 network y.y.y.8 0.0.0.3 area 0 Adjacent router (one of them): interface Loopback0 ip address x.x.x.131 255.255.255.255 interface TenGigabitEthernet4/1 ip address y.y.y.2 255.255.255.252 no ip redirects no ip proxy-arp router ospf 1 router-id x.x.x.131 log-adjacency-changes redistribute connected subnets redistribute static subnets passive-interface default no passive-interface TenGigabitEthernet4/1 network y.y.y.0 0.0.0.3 area 0 I hope this helps... Andy On Fri, Jan 22, 2010 at 1:53 AM, Jason LeBlanc jasonlebl...@gmail.com wrote: Can you send yoursnipped OSPF config? On Jan 21, 2010, at 5:28 PM, Andy B. wrote: Hi, I just fell over this thread while doing a little reseach to solve a similar situation. Hardware: - 6509 with SUP720-3BXL on both ends - SXF15a - Uptime: 46 weeks Problem: - OSPF (for the loopback between cores) and BGP (mostly customers whom we send the full table) going up and down all the time: %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.130 on TenGigabitEthernet4/1 from FULL to DOWN, Neighbor Down: Dead timer expired %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.131 on TenGigabitEthernet9/1 from LOADING to FULL, Loading Done %BGP-5-ADJCHANGE: neighbor y.y.y.14 Down BGP Notification sent %BGP-3-NOTIFICATION: sent to neighbor y.y.y.14 4/0 (hold time expired) 0 bytes %BGP-5-ADJCHANGE: neighbor y.y.y.14 Up This keeps going on for several hours, and suddenly it stabilizes itself. Furthermore I use cacti to generate graphs from the core router via SNMP. I have one VLAN that has around 15 GBPS traffic at peak times, and as soon as I hit more than 15 GBPS, no more graphs are drawn, core router console becomes rather unresponsive and OSPF starts to behave strangely. What I can rule out is the fiber capacity. I have multiple circuits and different paths and operators. The OSPF issue happens on all circuits, not just a specific one. No 10 GE link is used more than 60%. In fact, traffic from inside my backbone to any place outside remains unaffected (thank God), but the core router itself is pretty useless. Pinging the core's loopback or any ip loaded on that box results in a 40-60% packet loss. CPU usage is not high, it's stable. No unusual processes, just IP Input and BGP Scanner. More than 50% memory is still free at that time. I've had this many times recently, but it really just happens when my core goes beyond +- 15 GBPS of traffic (outbound). We've been below
Re: [c-nsp] Wr mem causes massive delay...
Assuming the config isn't huge and your router is already oversubbed you shouldn't be able to tell. tv - Original Message - From: Saku Ytti s...@ytti.fi To: cisco-nsp@puck.nether.net Sent: Monday, January 25, 2010 10:06 AM Subject: Re: [c-nsp] Wr mem causes massive delay... On (2010-01-25 09:34 -0600), Tony Varriale wrote: If you are pinging through the router, no that is not normal. There will always be some delay while it writes to media. But, it should not affect the forwarding path. It does, but only slightly, 'write' and 'dir' will both do that, as they interrupt. This is true at least for VXR, I don't see why 2800 would be different. To see these, you'd need non-averaging SLA measurments with very frequent polling interval, but if you can do that, you can see from transit SLA graphs e.g. when rancid was ran. When I've been able to see this, I've used some other methods than simple ping as the effect is extremely short and thus hard to see with ping. If OP was pinging once a second, and can reproduce this every time he does 'write', then this is much more likely real issue. -- ++ytti ___ 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] Wr mem causes massive delay...
On 1/25/2010 11:53, Tony Varriale wrote: Assuming the config isn't huge and your router is already oversubbed you shouldn't be able to tell. Well, he does have 64 interfaces, so it's probably large-ish. ~Seth ___ 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] Wr mem causes massive delay...
A large VoIP config isn't what I consider normal for your platform. As a side note, what's typical utilization and what is the utilization when you typically make changes? So, either you can size the platform appropriately or do config management during non-biz hours. So if you wr mem is taking 60 seconds to complete, yes your spike in latency through the box is expected. Conversely, you would always try it with IP addressing only and see what you get. tv - Original Message - From: Jonathan Charles jonv...@gmail.com To: Seth Mattinen se...@rollernet.us Cc: cisco-nsp@puck.nether.net Sent: Monday, January 25, 2010 11:40 AM Subject: Re: [c-nsp] Wr mem causes massive delay... It is a big config... cuz of all the voipy stuff. J On Mon, Jan 25, 2010 at 11:14 AM, Seth Mattinen se...@rollernet.us wrote: On 1/25/10 8:07 AM, Church, Charles wrote: This is a software based router, and 'wri mem' is very CPU intensive. What does the CPU look like before the wri mem is done? I don't think this is abnormal. Very large config on an already busy router with compress-config turned on? ~Seth ___ 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] Wr mem causes massive delay...
- Original Message - From: Tony Varriale tvarri...@comcast.net To: cisco-nsp@puck.nether.net Sent: Monday, January 25, 2010 1:53 PM Subject: Re: [c-nsp] Wr mem causes massive delay... Assuming the config isn't huge and your router is already oversubbed you shouldn't be able to tell. Should say: Assuming the config isn't huge and your router isn't already oversubbed you shouldn't be able to tell. ___ 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] Wr mem causes massive delay...
On (2010-01-25 14:00 -0600), Tony Varriale wrote: Assuming the config isn't huge and your router isn't already oversubbed you shouldn't be able to tell. It doesn't really matter, interrupt is interrupt, while compiling the config is what you can do, when you don't have packets to push, but the point you're writing it, there is today interrupt and it does interfere measurably with packet pushing, even if your CPU load is very small, in fact it makes the spotting easier, since then your jitter is extremely small and smaller deviation can be reliably picked up from measurements. But again, if OP is seeing this reliably with ping sent every 1s, this is real issue, not expected behaviour. -- ++ytti ___ 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] PPP CHAP spoofed challenges
All, We have a DSL circuit here terminated on an 1801 with IOS 15.1(XB). It's having trouble authenticating through to our ISP's LNS: Jan 25 22:14:42.653: Vi2 PPP: Phase is AUTHENTICATING, by both Jan 25 22:14:42.653: Vi2 CHAP: O CHALLENGE id 1 len 36 from test-php...@a.1 Jan 25 22:14:42.653: Vi2 LCP: State is Open Jan 25 22:14:42.681: Vi2 CHAP: I CHALLENGE id 1 len 29 from sov.lac0 Jan 25 22:14:42.681: Vi2 PPP: Sent CHAP SENDAUTH Request Jan 25 22:14:42.681: Vi2 PPP: Received SENDAUTH Response FAIL Jan 25 22:14:42.681: Vi2 CHAP: Using hostname from interface CHAP Jan 25 22:14:42.681: Vi2 CHAP: Using password from interface CHAP Jan 25 22:14:42.681: Vi2 CHAP: O RESPONSE id 1 len 36 from test-php...@a.1 Jan 25 22:14:44.021: Vi2 LCP: I CONFREQ [Open] id 0 len 15 Jan 25 22:14:44.021: Vi2 LCP:MagicNumber 0x71F64BD1 (0x050671F64BD1) Jan 25 22:14:44.021: Vi2 LCP:AuthProto CHAP (0x0305C22305) Jan 25 22:14:44.025: Vi2 PPP DISC: PPP Renegotiating Jan 25 22:14:44.025: Vi2 LCP: Event[LCP Reneg] State[Open to Open] Jan 25 22:14:44.025: Vi2 LCP: Event[DOWN] State[Open to Starting] ... Jan 25 22:14:44.061: Vi2 PPP: Phase is AUTHENTICATING, by both Jan 25 22:14:44.061: Vi2 CHAP: O CHALLENGE id 1 len 36 from test-php...@a.1 Jan 25 22:14:44.061: Vi2 CHAP: Redirect packet to Vi2 Jan 25 22:14:44.061: Vi2 CHAP: I CHALLENGE id 1 len 30 from doubtless Jan 25 22:14:44.061: Vi2 CHAP: Ignoring spoofed Challenge Jan 25 22:14:44.061: Vi2 LCP: State is Open Jan 25 22:14:46.021: Vi2 CHAP: I CHALLENGE id 1 len 30 from doubtless Jan 25 22:14:46.021: Vi2 CHAP: Ignoring spoofed Challenge Jan 25 22:14:48.021: Vi2 CHAP: I CHALLENGE id 1 len 30 from doubtless Jan 25 22:14:48.021: Vi2 CHAP: Ignoring spoofed Challenge Jan 25 22:14:50.021: Vi2 CHAP: I CHALLENGE id 1 len 30 from doubtless Jan 25 22:14:50.021: Vi2 CHAP: Ignoring spoofed Challenge Jan 25 22:14:52.021: Vi2 CHAP: I CHALLENGE id 1 len 30 from doubtless Jan 25 22:14:52.021: Vi2 CHAP: Ignoring spoofed Challenge Here, sov.lac0 is the DSL provider's LAC, and 'doubtless' is the ISP's LNS - which restarts LCP when it receives a new L2TP session from the LAC. The 1801 here is unhappy at receiving a CHAP challenge from a different hostname, and thus refuses to authenticate. The Dialer interface has 'ppp authentication chap callin' set, and I've tried 'ppp direction dedicated', but it doesn't help. Can any shed some light on this and/or suggest a workaround either on our end or the ISP's end? Regards, Peter ___ 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] Self rebooting pix?
Hi All, I'm having a strange problem and not much diagnostic output so maybe I can get some pointers as to what to look at next. I have a Pix 501 with a non restrictive license that I'm using as a general firewall and nat device. There's a 10 megabit ethernet connection handing a statically routed Internet feed on the WAN side and a 100 megabit fast E which connects to a core switch. We nat probably about 50 - 100 users at a time and the throughput over the public pathway is less than 8 megabits for the most part and generally stays around 3 - 5. The output of show cpu usage shows a usage of between 10 and 20 percent with lows of 4% and highs around 25. Randomly through out the day the connection / device will hang, the switch it's attached to shows the ethernet port go down and come back up a few times then packets start to flow again. After the most recent event I did a show ver on the Pix and saw that the uptime was less than 2 minutes. After each drop this counter returns to 0 which tells me the Pix is rebooting for some reason. Show log doesn't yield anything interesting and the syslog server that captures the log output doesn't have any messages around the time of the outages either. Total traffic disruption lasts for approximately 30 seconds. The time of day is random and it does not seem to increase in frequency with bursts in traffic. I've obviously checked and insure that the power cables are firmly attached and the network cables are securely attached as well. What other things should I try? Are there any other show commands that might yield some more clues? Has anyone else experienced this. The software rev is 6.3. Thanks Scott ___ 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] Self rebooting pix?
We had a similar problem with a PIX-525 (or was it the 520) with 6.3, We assumed it was hardware issues and replaced it, but if you have a computer you can stick on the console port, and have it's terminal program log everything to a file, it may provide more information. Scott Granados wrote: Hi All, I'm having a strange problem and not much diagnostic output so maybe I can get some pointers as to what to look at next. I have a Pix 501 with a non restrictive license that I'm using as a general firewall and nat device. There's a 10 megabit ethernet connection handing a statically routed Internet feed on the WAN side and a 100 megabit fast E which connects to a core switch. We nat probably about 50 - 100 users at a time and the throughput over the public pathway is less than 8 megabits for the most part and generally stays around 3 - 5. The output of show cpu usage shows a usage of between 10 and 20 percent with lows of 4% and highs around 25. Randomly through out the day the connection / device will hang, the switch it's attached to shows the ethernet port go down and come back up a few times then packets start to flow again. After the most recent event I did a show ver on the Pix and saw that the uptime was less than 2 minutes. After each drop this counter returns to 0 which tells me the Pix is rebooting for some reason. Show log doesn't yield anything interesting and the syslog server that captures the log output doesn't have any messages around the time of the outages either. Total traffic disruption lasts for approximately 30 seconds. The time of day is random and it does not seem to increase in frequency with bursts in traffic. I've obviously checked and insure that the power cables are firmly attached and the network cables are securely attached as well. What other things should I try? Are there any other show commands that might yield some more clues? Has anyone else experienced this. The software rev is 6.3. Thanks Scott ___ 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/ -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 ___ 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] Self rebooting pix?
Ah that's a good idea, I can give that a shot. - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Scott Granados gsgrana...@comcast.net Cc: cisco-nsp@puck.nether.net Sent: Monday, January 25, 2010 3:27 PM Subject: Re: [c-nsp] Self rebooting pix? We had a similar problem with a PIX-525 (or was it the 520) with 6.3, We assumed it was hardware issues and replaced it, but if you have a computer you can stick on the console port, and have it's terminal program log everything to a file, it may provide more information. Scott Granados wrote: Hi All, I'm having a strange problem and not much diagnostic output so maybe I can get some pointers as to what to look at next. I have a Pix 501 with a non restrictive license that I'm using as a general firewall and nat device. There's a 10 megabit ethernet connection handing a statically routed Internet feed on the WAN side and a 100 megabit fast E which connects to a core switch. We nat probably about 50 - 100 users at a time and the throughput over the public pathway is less than 8 megabits for the most part and generally stays around 3 - 5. The output of show cpu usage shows a usage of between 10 and 20 percent with lows of 4% and highs around 25. Randomly through out the day the connection / device will hang, the switch it's attached to shows the ethernet port go down and come back up a few times then packets start to flow again. After the most recent event I did a show ver on the Pix and saw that the uptime was less than 2 minutes. After each drop this counter returns to 0 which tells me the Pix is rebooting for some reason. Show log doesn't yield anything interesting and the syslog server that captures the log output doesn't have any messages around the time of the outages either. Total traffic disruption lasts for approximately 30 seconds. The time of day is random and it does not seem to increase in frequency with bursts in traffic. I've obviously checked and insure that the power cables are firmly attached and the network cables are securely attached as well. What other things should I try? Are there any other show commands that might yield some more clues? Has anyone else experienced this. The software rev is 6.3. Thanks Scott ___ 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/ -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 ___ 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] Self rebooting pix?
After each drop this counter returns to 0 which tells me the Pix is rebooting for some reason. [...] experienced this. The software rev is 6.3. We experienced this on a 515E running 6.3 code. A move to the 7.0 series solved this issue. I can't remember what exactly we saw using console but IIRC was something like runaway memory use. ~JasonG -- ___ 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/
