Re: [c-nsp] Cisco IOS ping utility reports lower RTT than possible
On 5/3/19 5:14 AM, Martin T wrote: > Hi Octavio, > > instead of a two-card laptop I used the available ports in server > named "svr", but in principle I built the setup you described: > > CISCO1921[Gi0/0] <-> [eno1]test-br[eno2] <-> [eno3]svr I intended to have an independent measurement tool (including an independent clock) but that should be good enough too, as it's highly unlikely that you have serious clock drifting issues. > Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms > As seen above, minimum measurement was 8ms and average was 9ms. I don't know how far (in ms) is the router from the server but max=12ms also looks way off. > Cisco IOS ping command inserts the timestamp into the payload of the > ICMP "echo request" message and at least it seems to increment it, i.e > that part seems to be fine. Does it? If you are referring to the -ttt output than that is done by tcpdump. Good experiment. Sorry to say that I don't know why the measurements are so inaccurate. I kow the Cisco ISR 1912 is a very low-end device but I don't know if so enough to get into this level of inaccuracy. Octavio. ___ 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 IOS ping utility reports lower RTT than possible
On 5/2/19 10:11 AM, Martin T wrote: >>> Gi0/0 in Cisco 1921 ISR has 10.66.66.2/24 configured and eno3 in Linux >>> server has 10.66.66.1/24 configured. RTT on this link is 10ms: >> >> How do you know this to be 100% correct - have you OTDR/iOLM tested this >> link? >> > I can't OTDR it because this delay is made with Linux netem qdisc. > However, I can compare it with for example using Juniper RPM(Cisco IP > SLA analogue): https://i.imgur.com/i8jccwh.png ..or Linux ping > utility: https://i.imgur.com/NeubqAV.png On both graphs I have plotted > 21600 measurements. None of those are below 10ms. Hi, I am curious about what do you see if you placed a two-card laptop in the middle as a bridge, do a tcpdump capture on the server-facing NIC and analyze the times with Wireshark. Best regards, Octavio. ___ 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] RAM for 4431 with full BGP table?
On 12/28/2017 04:10 PM, Gert Doering wrote: > Hi, > > On Thu, Dec 28, 2017 at 08:54:03PM +, Nick Cutting wrote: >> I would also like to know the answer to this. >> >> I always get scared and buy 16 gig if I'm taking in the full routing table. >> (4431/4451/4351 so far) >> >> I'm sure I could get away with 8. Not sure about 4, would love to know > > So how much memory do your routers use, if you have full tables? > > That should easily answer the question on whether 8 or 4 would suffice... > > A 7301 will take a full table in 1G RAM :-) https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/white-paper-c11-734550.html "13. Scalability Tests [...] All Cisco 4000 platforms support a full Internet routing table (500,000 prefixes) @ 8-GB DRAM. The 4451 supports two full Internet routing tables (1 million prefixes) @ 16-GB DRAM." However, be careful: first, the full table is around 700K nowadays; second, the interpretation of "route". For an ASR 1K a "route" means "an entry in the RIB for each protocol" instead of "an entry in the routing table" so if your router has 2 upstreams, each sending its full-table through BGP it actually means you must size your router RAM to fit 2 full routing tables, not one. Best regards, Octavio. ___ 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] Forcing BGP to propagate only after route is in the FIB
Hello. We are noticing our ASR 1002 is propagating BGP-learned routes to its neighbors after the path is chosen but before the route gets installed in the FIB. With the increasing size of the BGP table, this is causing race conditions that turn into traffic loops during convergence. The router attracts traffic but returns it back to somebody else because the route is not yet in the FIB or it is outdated in the FIB. Is there a way to force the router to wait until a route is installed all the way in the FIB before having it propagated to the neighbors? Thanks. ___ 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] ISR4431 integrated "POE" ports
On 05/10/2016 05:24 PM, CiscoNSP List wrote: > > Thanks Nathan - The device has 8 ports as per the doc here: > > http://www.cisco.com/c/en/us/td/docs/routers/access/4400/hardware/installation/guide4400-4300/C4400_isr/Overview.html#32890 It's 4 dual-port interfaces, not 8 interfaces. You can use the SFP *or* RJ-45 port for that interface (you choose using "media-type" in interface config mode) but it's only one interface. Ports 0 and 1 (only on RJ-45) can additionally be set as PoE if certain conditions are met. So you can not use the two ports of the same interface simultaneously. Best regards. ___ 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] Dual SPAN port support on C2960-X
On 07/04/15 09:46, Matthew Crocker wrote: Can anyone confirm the Cisco Catalyst 2960X-48LPS-L supports dual monitor sessions (SPAN)? I need to monitor 4 ports (Tx Rx) to two different recording devices i.e. two monitor sessions, same 4 source ports, 2 different destination ports. You may want to take a look at the following links: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/network_management/configuration_guide/b_nm_15ex_2960-x_cg/b_nm_15ex_2960-x_cg_chapter_0111.html#reference_0720E9CF194D4936ACD4E803A7834575 http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-x-series-switches/qa_c67-728348.html#wp9000525 Best regards. ___ 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] Changing Peer IP of VPN headend
On 01/04/15 08:05, Michael Malitsky wrote: I need to change the public IP of my VPN headend, which will necessitate corresponding Peer IP changes on all N remote peers. We already have the new IP space, currently configured as a secondary address. Problem is that N-1 of the peers are completely outside of our control, and scheduling all of them to cut over within a narrow window (one day?) is going to be very challenging to say the least. Is there a way to cut them over one-by-one, perhaps a way to bind another crypto map to the secondary ip address? My searching on google and cisco lead me to believe the answer is NO, but I am hoping I missed something. I would try using a different physical interface in the router to have another crypto map (you can even use crypto map local-address). If you don't have another physical interface you could --depending on your topology-- change your output interface to an 802.1Q trunk and have two subinterfaces. Router in question is a 2801. All VPNs are site-to-site IPSEC. Best regards. ___ 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 transceiver's maintenance service
On 11/29/2014 10:40 PM, Xuhu NSP wrote: Hi folks, just want to check that if we just purchase few new transceivers from Cisco, how are you going to purchase the maintenance service, because I didn't see the list price only for transceivers, normally purchase with line cards or chassis. It's covered by the service contract for the device to which the transceiver is attached [1]. [1] Cisco SFP Modules for Gigabit Ethernet Applications http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/gigabit-ethernet-gbic-sfp-modules/product_data_sheet0900aecd8033f885.pdf Best regards. ___ 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 Duplex
On 18/11/14 02:16, M K wrote: Is it true that this interface can handle 100Mbps send and 100Mbps receive at the same time? Yes. It's 100 Mbps full-duplex. like it is 200Mbps ? No. It's 100 Mbps full-duplex. It's the same as DSL: If you have a 10 Mbps download speed and a 1 Mbps upload speed, you don't call that an 11 Mbps link. If I found a vendor that did that, I would run away from it for lying. ___ 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 Duplex
On 11/22/2014 11:43 AM, Mark Tinka wrote: On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. This is different. A line card can support 60 Gbps of *processing power* if it can handle a full-duplex 30 Gbps interface because it has to process all the data at the same time in the worst case. This is correct. And so on: consider a two full-duplex 30 Gbps port line card: it would need the necessary power to handle 120 Gbps of data if you want it to not block or oversubscribe. It's not the same as selling a full-duplex 30 Gbps link as a 60 Gbps link. This is incorrect. ___ 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 Duplex
On 11/22/2014 12:17 PM, Octavio Alvarez wrote: On 11/22/2014 11:43 AM, Mark Tinka wrote: On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. This is different. A line card can support 60 Gbps of *processing power* if it can handle a full-duplex 30 Gbps interface because it has to process all the data at the same time in the worst case. This is correct. And so on: consider a two full-duplex 30 Gbps port line card: it would need the necessary power to handle 120 Gbps of data if you want it to not block or oversubscribe. Before anything else happens: I guess I misread your message. I get your point now. The line card itself is only 30 Gpbs, but because the traffic is not full-duplex (and it will never be) they sell it as a 60 Gbps. Yeah, that sucks too. Sorry for my confusion and the generated noise. ___ 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] Sup720 - FIB full, software switching
On 02/03/2014 06:09 AM, Rolf Hanßen wrote: But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. That pretty much sums it up. You can set up some inbound filtering to prevent a lot of routes to go into the routing table in the first place, and thus, protecting the FIB. There was some discussion in Pepelnjak's blog about the filtering, precisely for the same problem with a Sup720: [1] and its followup post [2] some time ago. [1] http://blog.ipspace.net/2012/01/how-could-we-filter-extraneous-bgp.html [2] http://blog.ipspace.net/2012/01/filter-inbound-bgp-prefixes-summary.html ___ 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 6503 Sup2T Engine block outbound TCP or UDP Port traffic
On 02/01/2014 08:28 PM, Joseph Hardeman wrote: Hi Everyone, I have a SUP2t engine running IOS s2t54-ADVIPSERVICESK9-M version and I am wondering if there is a way to filter or block TCP or UDP port traffic. I know how to NULL route IP 's but I don't know if there is a way to block or deny traffic based on destination port's also based on IP ranges. Any ideas would be much appreciated. Look for Access Control Lists. Just remember that all ACLs have a deny everything implicitly at the end. It may bite you a few times but you won't have trouble getting the hang of it. ___ 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] ASA5520 latency OSPF drops
On 02/01/2014 08:27 AM, Adam Greene wrote: Every so often (it started three months ago, about once per month, now it's about once per week, but it's not regular), we're getting very high latency on pings from our Internal Network to the ASA5520, and the OSPF adjacency between the 3750 and the ASA5520 is dropping. The issue was lasting about 60 seconds each time up to this morning, when it lasted about 3 hours. Ugh! Pings from the Internal Network to the 3750 and 2950G are fine. What about pings from the external world to the ASA? ALso, I'd increase logging verbosity to a Syslog server with an interface connected to each side of the ASA. And I'd also be prepared to do a packet capture on both sides of the ASA for the next time it happens. You mention spares (I assume cold spares) but also OSPF, do you have your devices HA? ___ 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] TAC hits a new record level of aggravation...
On 02/01/2014 09:46 AM, Jeff Kell wrote: Could we petition for an HTML 1.0, old-school, no-javascript, no Java apps, alternative TAC site? Add an explicit no JavaScript to the mix and I sign. :) ___ 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] Effect of simultaneous TCP sessions on bandwidth
On 11/10/2013 11:11 AM, Youssef Bengelloun-Zahr wrote: - TCP traffic reaches up to 90 Mbits/s for one way streams (both ways), - TCP traffic hits some kind of limit and isn't able to achieve more than 40-60 Mbits/s in average === That's the problem we are facing If you are trying to saturate the link in both directions each of the acknowledge packets will compete against the other stream and will have a hard time reaching back. If the device has too small buffers, the ACKs for stream 1 may be dropped, which may cause retransmits in stream 1, aggravating the problem for session 2, which will retransmit too, further aggravating the problem for stream 1. If the device has too large buffers, the BW*DLY product of the link will increase a bit which will lower the performance of the TCP session. A good balance must be found. Try controlling your tests and see if you can reduce the max BW per session. See how far you can go. I'd try tweaking the buffers and repeating. Also, as a measure, ping to the other end and measure RTT. Now, with both sessions open, repeat the RTT measurement. ___ 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] ip tcp adjust-mss
It's not *necessarily* a buggy device. I meant to explain why could the problem be anywhere. That said, if negotiation is being kept at 1460, you possibly have a link (like DSLs do) that has a lower MTU but the router doesn't know. Just follow Juergen's advice: set MSS to conservative values on a far end and see if it helps. Then play with the value to see how high you can go. On 11/04/2013 09:54 PM, Methsri Wickramarathna wrote: I have captured and analyzed the packets from wireshark and it shows MSS agreement is set to 1460. Is there any convenient way to track the buggy device ??? On Tue, Nov 5, 2013 at 10:39 AM, Octavio Alvarez alvar...@alvarezp.ods.org mailto:alvar...@alvarezp.ods.org wrote: It could be anywhere. I remember seeing buggy devices that didn't dynamically adapt to intermediate TCP MSS modifications. We had to analyze the TCP headers on the streams to find this out. It was a reflected symptom. I've also seen it on DSL links that didn't had ip tcp adjust-mss 1452 in place. On 11/04/2013 08:09 PM, Methsri Wickramarathna wrote: Thanks Blake Tony, Is this issue with My end core router , destination end device or intermediate device ??? Is there any way I can find this ??? On Tue, Nov 5, 2013 at 7:22 AM, Blake Dunlap iki...@gmail.com mailto:iki...@gmail.com wrote: Yes. Don't do that. On Mon, Nov 4, 2013 at 6:59 PM, Methsri Wickramarathna mmethw2...@gmail.com mailto:mmethw2...@gmail.com wrote: Thanks Tony , John and Juergan... This has been issue for many sites mainly towards yahoo.com http://yahoo.com. Can any one explain why this is happening for particular IPs in a subnet ??? We are using access list inbound Outbound to prevent ICMPs cumming inside to our network, will it be creating this problem On Tue, Nov 5, 2013 at 3:23 AM, c...@marenda.net mailto:c...@marenda.net wrote: Hi, this looks like a CPE-device With static IP-adresses and routing. You may really want to set ip tcp adjust-mss 1280 on _both_ your WAN and your (probably natted) LAN (L3) Interfaces. (_both_ sides, yes !) This will help you in most cases with MTU restrictions on - your link - home-webservers behind Broadband links etc. Yes, the value is not optimized but very computerish ( 2**10 + 2**8 ), but it is good for - pppoe (1500-8=1492) - l2tp forwarded dial-in sessions (l2tp overhead+pppoe leads to 1456) - even with an additional vlan tag ( so MTU will be 1452 found in most literature) - some other tunneled environments Iff you are an ISP, you will configure this _only_ on the virtual-template interfaces on your LNSes for broadband-termination . Keep it out of your core, You will not want to modify your valued customer's ip packets in your core network; here you want to use a MTU greater than 1500 while on your BGP up/downstreams will stay at Ethernet-default 1500 . Sorry, very conservative, but will avoid may problems. Just my 0.01 $ on this Juergen. -Ursprüngliche Nachricht- Von: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net mailto:cisco-nsp-boun...@puck.nether.net] Im Auftrag von Methsri Wickramarathna Gesendet: lundi 4 novembre 2013 17:55 An: Pete Lumbis Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net Betreff: Re: [c-nsp] ip tcp adjust-mss Thanks Pete, If not a problem can any one look in to following mturoute taken ??? :) E:\mturoute -t www.ubnt.com http://www.ubnt.com mturoute to www.ubnt.com http://www.ubnt.com, 30 hops max, variable sized packets * ICMP Fragmentation is not permitted. * * Speed optimization is enabled. * * Maximum payload is 1 bytes. * 1 +- host: 116.12.78.1 max: 1500 bytes
Re: [c-nsp] ip tcp adjust-mss
It could be anywhere. I remember seeing buggy devices that didn't dynamically adapt to intermediate TCP MSS modifications. We had to analyze the TCP headers on the streams to find this out. It was a reflected symptom. I've also seen it on DSL links that didn't had ip tcp adjust-mss 1452 in place. On 11/04/2013 08:09 PM, Methsri Wickramarathna wrote: Thanks Blake Tony, Is this issue with My end core router , destination end device or intermediate device ??? Is there any way I can find this ??? On Tue, Nov 5, 2013 at 7:22 AM, Blake Dunlap iki...@gmail.com wrote: Yes. Don't do that. On Mon, Nov 4, 2013 at 6:59 PM, Methsri Wickramarathna mmethw2...@gmail.com wrote: Thanks Tony , John and Juergan... This has been issue for many sites mainly towards yahoo.com. Can any one explain why this is happening for particular IPs in a subnet ??? We are using access list inbound Outbound to prevent ICMPs cumming inside to our network, will it be creating this problem On Tue, Nov 5, 2013 at 3:23 AM, c...@marenda.net wrote: Hi, this looks like a CPE-device With static IP-adresses and routing. You may really want to set ip tcp adjust-mss 1280 on _both_ your WAN and your (probably natted) LAN (L3) Interfaces. (_both_ sides, yes !) This will help you in most cases with MTU restrictions on - your link - home-webservers behind Broadband links etc. Yes, the value is not optimized but very computerish ( 2**10 + 2**8 ), but it is good for - pppoe (1500-8=1492) - l2tp forwarded dial-in sessions (l2tp overhead+pppoe leads to 1456) - even with an additional vlan tag ( so MTU will be 1452 found in most literature) - some other tunneled environments Iff you are an ISP, you will configure this _only_ on the virtual-template interfaces on your LNSes for broadband-termination . Keep it out of your core, You will not want to modify your valued customer's ip packets in your core network; here you want to use a MTU greater than 1500 while on your BGP up/downstreams will stay at Ethernet-default 1500 . Sorry, very conservative, but will avoid may problems. Just my 0.01 $ on this Juergen. -Ursprüngliche Nachricht- Von: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] Im Auftrag von Methsri Wickramarathna Gesendet: lundi 4 novembre 2013 17:55 An: Pete Lumbis Cc: cisco-nsp@puck.nether.net Betreff: Re: [c-nsp] ip tcp adjust-mss Thanks Pete, If not a problem can any one look in to following mturoute taken ??? :) E:\mturoute -t www.ubnt.com mturoute to www.ubnt.com, 30 hops max, variable sized packets * ICMP Fragmentation is not permitted. * * Speed optimization is enabled. * * Maximum payload is 1 bytes. * 1 +- host: 116.12.78.1 max: 1500 bytes [...] -- -- ´`_,,,_ ___´$$$`_´$$$` `$$$`__,,,,___´´ _`$$$`´$$`_´$$`´$´ __`$$$`_´$`_´$`__´$$$´ ___`$$$_$$$_$$$_´$$$´_ `$$_$$$_$$$`´$$´_ ___,,__`$$_$$$_$$$_$$´_ _´$``$$_$$$_$$$_$$´_ ´$`´$$$_$$$_$$$_$´_ ´$$_$$$_$$$_$´_ ___`$$$_$$$_$$_$$´_ __`$_$__$$_$$_$$´_ ___`,___,,_,$´_ _`$´_ __`$$$´_ `´_ ___`´_ ~~( ŊëŌ )~~ ___ 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] TAC hits a new record level of aggravation...
The annoyance could be avoided by removing Java requirements from the website. On 11/02/2013 08:20 PM, Alex Presse wrote: It's the new java update - unsigned code gets user verification windows. Cisco (and everybody else) will need to update all their java delivered user interfaces to avoid this annoyance. Sent from mobile; please excuse brevity typos. On Nov 2, 2013, at 19:46, chris tknch...@gmail.com wrote: Also make sure you use IE6, because apparently thats what most users prefer. Those pesky newer version and non MS browsers can be a real heachache. :) On Sat, Nov 2, 2013 at 9:23 PM, Engel engel.lab...@gmail.com wrote: Have you try using MS Explorer? Sent from my iPhone On 2013/11/03, at 7:53, Jeff Kell jeff-k...@utc.edu wrote: I had the opportunity to open a TAC case last week... and was greeted by the new website... I use Firefox with NoScript, Ghostery, AdBlock, and some other plugins that require their own unique whitelisting to get cisco.com to work at all, and even more if you need to login to anything. I have the most current Java 1.7 installed as of the last round of updates. So... going to open a TAC case... I'm presented by at least four (maybe five?) Java permissions warnings/windows asking me if they can run. I bear with this, enter a case, and everything I carefully formatted and pasted into the case was compressed down into a block of continuous text, forget my newlines, everything crammed into one piece. I submit the case, and more Java permissions windows. I go to review the case... still MORE permissions windows. Of course I have to go upload a show tech (first request for any case)... and STILL MORE permissions windows. THIS IS RIDICULOUS !!! Anyone else had the pleasure of hitting the new case management site? I have NEVER experienced such a technical challenge such as that presented by the TAC website... I also now get Java warnings/permissions windows for ASDM for ASA, ASDM for FWSM, oh the list just keeps on growing for this Java crap. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] reload command doesn't check command line parameters
According to [1], reload reason was added in 15.0(1)M. [1] Cisco IOS Configuration Fundamentals Command Reference, R through setup: http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_r1.html#wp1078590 On 10/10/2013 04:04 AM, Luis Miguel Cruz Miranda wrote: Which IOS are you using? El 08/10/13 09:53, Octavio Alvarez escribió: Wait a minute... My router supports reload reason already and rejects reload int 10. Check later IOS versions. On 10/07/2013 12:05 PM, Pete Lumbis wrote: The two outputs do have different warnings: reload reason: === Router#reload Proceed with reload? [confirm] === === Router#reload in 5 Reload scheduled in 5 minutes by console Reload reason: Reload Command Proceed with reload? [confirm] === On Mon, Oct 7, 2013 at 11:46 AM, Octavio Alvarez alvar...@alvarezp.ods.org mailto:alvar...@alvarezp.ods.org wrote: On 10/07/2013 05:30 AM, Pete Lumbis wrote: If we fix the behavior what does the fix look like? Do we not allow any reason that starts with i(in) c (cancel) or a(at)? But then what if you want a reload reason of reload installing new software? Should this be blocked? Create reload reason blahblah and deprecate reload blahblah. Issue a warning each time reload blahblah happens. Also have different confirmation messages. Reload in 10 could have Proceed with reload in 10? while the other could be Proceed with immediate reload? ___ 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] reload command doesn't check command line parameters
Wait a minute... My router supports reload reason already and rejects reload int 10. Check later IOS versions. On 10/07/2013 12:05 PM, Pete Lumbis wrote: The two outputs do have different warnings: reload reason: === Router#reload Proceed with reload? [confirm] === === Router#reload in 5 Reload scheduled in 5 minutes by console Reload reason: Reload Command Proceed with reload? [confirm] === On Mon, Oct 7, 2013 at 11:46 AM, Octavio Alvarez alvar...@alvarezp.ods.org mailto:alvar...@alvarezp.ods.org wrote: On 10/07/2013 05:30 AM, Pete Lumbis wrote: If we fix the behavior what does the fix look like? Do we not allow any reason that starts with i(in) c (cancel) or a(at)? But then what if you want a reload reason of reload installing new software? Should this be blocked? Create reload reason blahblah and deprecate reload blahblah. Issue a warning each time reload blahblah happens. Also have different confirmation messages. Reload in 10 could have Proceed with reload in 10? while the other could be Proceed with immediate reload? ___ 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] reload command doesn't check command line parameters
On 10/07/2013 05:30 AM, Pete Lumbis wrote: If we fix the behavior what does the fix look like? Do we not allow any reason that starts with i(in) c (cancel) or a(at)? But then what if you want a reload reason of reload installing new software? Should this be blocked? Create reload reason blahblah and deprecate reload blahblah. Issue a warning each time reload blahblah happens. Also have different confirmation messages. Reload in 10 could have Proceed with reload in 10? while the other could be Proceed with immediate reload? ___ 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] Don't NAT a Subset of Traffic
On Sun, 22 Aug 2010 02:29:28 -0700, Sridhar Ayengar ploops...@gmail.com wrote: I have a Verizon FiOS connection with 5 IP addresses attached to my 7505. So because it's excluded from the access-list, traffic from my private network 172.16.16.0 to my public IP addresses is not NATed. I still can't figure out how to pass this traffic without NATing it. If I remove the deny line from the access-list, the traffic is correctly passed NATed. Anyone have any ideas for me? I would go for: it is passing but you don't have return routes on your external hosts. Octavio. ___ 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 duplex mismatch speed - dynamips
On Tue, 17 Aug 2010 19:03:44 -0700, Jeferson Guardia jefers...@gmail.com wrote: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up Force it speed and duplex. I find that preferrable over disabling CDP. -- Octavio. ___ 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] NATIVE_VLAN_MISMATCH
On Fri, 28 May 2010 16:41:16 -0700, Rick Kunkel kun...@w-link.net wrote: I've connected a switch of mine to a provider's switch, and I'm getting CDP-4-NATIVE_VLAN_MISMATCH warnings... but everything works fine. Is this just a harmless warning? I'm not doing any VLANs with them. Their connection is going into a 3550 that has just had the nvram erased and NO setup done, so it's ridiculously stock. I would try setting both switches to different VTP domains. -- Octavio. ___ 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] DMVPN scalability question on the 28XX ISR's
On Wed, 21 Apr 2010 06:35:37 -0700, Luan Nguyen l...@netcraftsmen.net wrote: In this case, a dual hub (loadshare/backup) for 1000+ spokes would be just fine. Single-hub, dual-cloud scales and performs and converges better than dual-hub, single-cloud and are not even recommended by Cisco. Therefore, I would stick to the dynamic routing protocol approach. -- Octavio. ___ 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] quick spanning tree question
On Fri, 26 Mar 2010 23:47:47 -0700, Cord MacLeod cordmacl...@gmail.com wrote: 3 days ago traffic started showing up on the trunk port connecting my top of rack switches. Each of these switches has it's own better trunk path to the root bridge. I can't see why any traffic at all would traverse these links unless the other trunk on g0/45 was down, which it isn't. Also, spanning tree doesn't claim any topology changes. There's very little information. I could even think your traffic is real and STP doesn't have anything to do with it. -- Octavio. ___ 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/
