Re: [c-nsp] Alert: Correction
On 6/17/10 5:01 AM, Jun Kemail wrote: An employee of The University of Toledo, Jason Mishka, transmitted a message to this listserv on January 15, 2010, giving his personal opinion about Bluecat Networks products. It has since been published on other listservs and re-transmitted without authorization to other sites/forums. His assessments and statements are his opinion and NOT that of The University of Toledo. If he gave his personal opinion, why does the University of Toledo care? It's not your bell to try to unring. If you disapprove of your employees expressing their personal opinions, then discipline or fire them. And let prospective employees know in advance that you do so. The smart ones may choose to seek work elsewhere. The University of Toledo does not agree with or support his opinion. Did he or you ever state that you did? Does the University of Toledo try to censor everyone publishing an opinion with which it disagrees, or just Mr. Mishka? Businesses deciding whether to utilize Bluecat Networks products should not rely upon his opinion message in any way. Why not? Is it factually inaccurate? We would appreciate it if all remarks were disregarded and if possible, removed from the listserv. Good luck with that. Your comments have almost certainly had the opposite effect. Raise your hand if you, like me, just entered Jason Mishka Bluecat or similar into your favorite search engine and had never read or had long forgotten the five-month-old original post. This isn't by any chance a troll with a misplaced space, is it? Or is the real VP/CIO of the University of Toledo named Jun Kemail and the University's policy is to post official statements via Gmail? -- 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] Continous BGP session resets on SRD3
We have limits of 100 set for as path length on the upstream routers, this did
not solve the problem.
I think the issue almost has to be 32 bit ASNs. The router on our network
that was ingressing the troublesome prefix was/is running
s72033-adventerprisek9_wan-mz.122-33.SXI1.bin and it was unaffected, the
affected routers were all either customers on other non-affected routers or
iBGP peers of the router where the prefix came into the network.
John van Oppen
Spectrum Networks
http://spectrumnetworks.us
Direct: 206.973.8302
Main: 206.973.8300
-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Thursday, June 17, 2010 7:09 AM
To: Gordon Bezzina
Cc: John van Oppen; 'Kostas Fotiadis'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Continous BGP session resets on SRD3
We are working to get some clarification on this.
In the interim...
Can anyone prove they saw this when either:
a) The upstream speaker did not have the AS Path limit configured to
something lower (say less than 200)?
b) The upstream speaker was running with code *newer* than one of these:
15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID
15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l
12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02
12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11
12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15
12.0(32)SY10
From what Shimol and I appear to have gleaned so far it's an issue
between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and*
the 4byte AS (new) upstream speaker is on a version of code older than
one of the ones above.
Can folks confirm/deny if their deployment where they saw this either
did or did not match those conditions above?
Read it carefully as it can be tricky.
Thanks,
Rodney
On 6/17/10 12:19 AM, Gordon Bezzina wrote:
Hi,
The other end is a GSR, but I do not have control on.
Anyhow performed emergency upgrade my 7600 from SRD3 to SRE1, did the trick.
It now works without any problems.
Thanks to all.
Best Regards
Gordon
-Original Message-
From: John van Oppen [mailto:jvanop...@spectrumnet.us]
Sent: L-Erbgħa, 16 ta' Ġunju 2010 17:43
To: Kostas Fotiadis; Gordon Bezzina
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Continous BGP session resets on SRD3
We saw this issue about 8 hours ago too... It appeared to affect GSRs
running anything older than gsr-k4p-mz.120-32.SY9.bin as well as 7200s
running non-current versions of IOS. Our 6500s were all fine but they
are all running at least s72033-adventerprisek9_wan-mz.122-33.SXI1.bin.
This sure looked like it was tickling CSCeh13489 but we already limit the
maximum AS-path length to well-under 255 and that did not seem to protect us.
We ended up doing an emergency upgrade of the GSRs involved.
John van Oppen
Spectrum Networks
Direct: 206-973-8302
Main: 206-973-8300
From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net]
on behalf of Kostas Fotiadis [kostas.fotia...@oteglobe.net]
Sent: Wednesday, June 16, 2010 4:41 AM
To: Gordon Bezzina
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Continous BGP session resets on SRD3
Hi Gordon,
Just hang-up the phone with TAC.
We also had the same issue this morning.
One session was iBGP and the other eBGP.
Engineer said, undocumented bug, needs to do more research and get back to be.
Don't know what he did and fix it. I guess you need to open a case...
Good luck,
Kostas
On 16/6/2010 12:37 μμ, Gordon Bezzina wrote:
Hi,
Since this morning I am experiencing a weird problem on one of my full
feeds link.
My router is a 7606 with dual RSP720-3CXL-GE and running SRD3.
I have a multihop bgp peer to get the full bgp feed from my customer.
Suddenly this morning the connection started flapping. With the
following error message:
Jun 16 07:40:03 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX Up
Jun 16 07:42:36 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX
Down BGP Notification sent Jun 16 07:42:36 CEST: %BGP-3-NOTIFICATION:
sent to neighbor W.X.Y.Z 3/4 (invalid flags for attribute) 3 bytes
00
15w6d: BGP: 217.15.96.9 Bad attributes Jun 16 07:42:36 CEST:
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from
W.X.Y.Z:
012B 0200 0001 1040 0101 02C0
119A
0226
3D77 22E0 04F9 3065 0003 0065 0003 0065 C288
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 4002 4E02
263D
7722
E004 F930 655B A05B A0C2 8822 E422 E422 E422 E422 E422 E422 E422 E422
E422
E422
Jun
Re: [c-nsp] BGP Scanner running amok
On 6/17/10 6:10 AM, Gordon Bezzina wrote: Hi, Following yesterday's issue with BGP full feed, I have updated the IOS from SRD3 to SRE1 on the Cisco 7606 (RSP720-3CXL). The BGP continuous resets have been resolved but now I have a mad BGP Scanner. It is running constantly consuming over 60% of my CPU. also it is sending lots and lot of updates to a number of my peers. Basically I have a particular peer who was sent 6,000,000 updates in 6 hours! External peer? Are you accidentally leaking routes from your external peers to each other? Does show ip bgp nei w.x.y.z advertised-routes for all of your external peers just have your prefixes? If not, you'll want to fix this. -- 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] Continous BGP session resets on SRD3
16.06.2010 19:04, Nick Hilliard пишет: On 16/06/2010 16:57, John van Oppen wrote: We saw this issue about 8 hours ago too... It appeared to affect GSRs running anything older than gsr-k4p-mz.120-32.SY9.bin as well as 7200s running non-current versions of IOS. Interesting. Given that several other people are seeing exactly the same problems right now, I wonder is this is some form of bogus prefix floating around? What about 'bgp dampening'? Some time ago we had similar problem with SRC5 on one of our 7600 (RSP720). Later I found bug CSCtd26215. -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | FreeBSD: The Power to Serve - http://www.freebsd.org ___ 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] Duplicate virtual interface on LNS or no Vi established
C7200P-IPBASE-MZ-12.4(24)T3 Seems to have solved this. Somewhat disappointed that cisco couldn't identify the problem in a reasonable timescale and we had to just keep trying IOS versions until one worked. Always a problem on a production router. -- Best Regards Richard Grimwood - Network Manager ___ 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] Alert: Correction
Seems more like lawyers were involved in this. It is not uncommon for an AUP to have verbiage that restricts you from talking about your experiences with a product. Nothing like drawing attention to something. JD Sent from my Verizon Wireless BlackBerry -Original Message- From: Jay Hennigan j...@west.net Date: Thu, 17 Jun 2010 23:21:36 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Alert: Correction On 6/17/10 5:01 AM, Jun Kemail wrote: An employee of The University of Toledo, Jason Mishka, transmitted a message to this listserv on January 15, 2010, giving his personal opinion about Bluecat Networks products. It has since been published on other listservs and re-transmitted without authorization to other sites/forums. His assessments and statements are his opinion and NOT that of The University of Toledo. If he gave his personal opinion, why does the University of Toledo care? It's not your bell to try to unring. If you disapprove of your employees expressing their personal opinions, then discipline or fire them. And let prospective employees know in advance that you do so. The smart ones may choose to seek work elsewhere. The University of Toledo does not agree with or support his opinion. Did he or you ever state that you did? Does the University of Toledo try to censor everyone publishing an opinion with which it disagrees, or just Mr. Mishka? Businesses deciding whether to utilize Bluecat Networks products should not rely upon his opinion message in any way. Why not? Is it factually inaccurate? We would appreciate it if all remarks were disregarded and if possible, removed from the listserv. Good luck with that. Your comments have almost certainly had the opposite effect. Raise your hand if you, like me, just entered Jason Mishka Bluecat or similar into your favorite search engine and had never read or had long forgotten the five-month-old original post. This isn't by any chance a troll with a misplaced space, is it? Or is the real VP/CIO of the University of Toledo named Jun Kemail and the University's policy is to post official statements via Gmail? -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] How to find the root cause of packet loss
Hello, Getting output drops and packet loss on Catalyst WS-C2960G-48TC-L. The traffic is relatevely small but output drops are growing hundreds per second. GigabitEthernet0/45 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 2893.fe8e.3b2d (bia 2893.fe8e.3b2d) MTU 9000 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 122/255, rxload 14/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:20, output hang never Last clearing of show interface counters never Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops: 32013814 Queueing strategy: fifo Output queue: 0/4096 (size/max) 5 minute input rate 5725 bits/sec, 33933 packets/sec 5 minute output rate 480872000 bits/sec, 47800 packets/sec 2298025991 packets input, 456494816566 bytes, 0 no buffer Received 294650 broadcasts (245203 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 245203 multicast, 0 pause input 0 input packets with dribble condition detected 3306257265 packets output, 4196833602160 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out Buffers statistics: Buffer elements: 1505 in free list (500 max allowed) 1652435 hits, 0 misses, 1024 created Public buffer pools: Small buffers, 104 bytes (total 34, permanent 25, peak 184 @ 18:14:40): 33 in free list (20 min, 60 max allowed) 253962 hits, 72 misses, 207 trims, 216 created 0 failures (0 no memory) Middle buffers, 600 bytes (total 21, permanent 15, peak 81 @ 17:22:12): 19 in free list (10 min, 30 max allowed) 6054 hits, 75 misses, 219 trims, 225 created 0 failures (0 no memory) Big buffers, 1536 bytes (total 53, permanent 50, peak 92 @ 17:22:12): 29 in free list (5 min, 150 max allowed) 315152 hits, 20 misses, 57 trims, 60 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 11, permanent 10, peak 13 @ 09:49:47): 1 in free list (0 min, 100 max allowed) 37614 hits, 2 misses, 3 trims, 4 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 0, permanent 0): 0 in free list (0 min, 5 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 1, permanent 0, peak 2 @ 18:14:30): 1 in free list (0 min, 2 max allowed) 1097 hits, 1 misses, 1 trims, 2 created 0 failures (0 no memory) Interface buffer pools: RxQFB buffers, 2040 bytes (total 150, permanent 150): 141 in free list (0 min, 150 max allowed) 13720 hits, 0 misses RxQ1 buffers, 2040 bytes (total 128, permanent 128): 7 in free list (0 min, 128 max allowed) 231357 hits, 10964 fallbacks RxQ3 buffers, 2040 bytes (total 16, permanent 16): 1 in free list (0 min, 16 max allowed) 42632 hits, 2705 fallbacks RxQ4 buffers, 2040 bytes (total 64, permanent 64): 1 in free list (0 min, 64 max allowed) 3301 hits, 51 fallbacks RxQ6 buffers, 2040 bytes (total 64, permanent 64): 0 in free list (0 min, 64 max allowed) 155 hits, 91 misses RxQ7 buffers, 2040 bytes (total 96, permanent 96): 30 in free list (0 min, 96 max allowed) 581219 hits, 490 misses RxQ8 buffers, 2040 bytes (total 32, permanent 32): 0 in free list (0 min, 32 max allowed) 203101 hits, 202315 misses RxQ10 buffers, 2040 bytes (total 16, permanent 16): 0 in free list (0 min, 16 max allowed) 16 hits, 0 fallbacks RxQ12 buffers, 2040 bytes (total 16, permanent 16): 0 in free list (0 min, 16 max allowed) 16 hits, 0 misses RxQ15 buffers, 2040 bytes (total 4, permanent 4): 0 in free list (0 min, 4 max allowed) 1303978 hits, 1303974 misses RxQ11 buffers, 2040 bytes (total 4, permanent 4): 0 in free list (0 min, 4 max allowed) 4 hits, 0 misses Header pools: Output interpreter says: ERROR: Since it's last reload, this router has created or maintained a relatively large number of 'Big buffers' yet still has very few free buffers. ERROR: Since it's last reload, this router has created or maintained a relatively large number of 'VeryBig buffers' yet still has very few free buffers. The above symptoms suggest that a buffer leak has occurred. Upgrading IOS does not help. I even changed the switch but this did not help either. I also get: #show controllers ethernet-controller gi0/45 Transmit GigabitEthernet0/45 Receive 372161753 Bytes 3922461464 Bytes 3323064978 Unicast frames
Re: [c-nsp] How to find the root cause of packet loss
On Fri, 2010-06-18 at 14:56 +0300, Anton Turygin wrote: Getting output drops and packet loss on Catalyst WS-C2960G-48TC-L. Someone should start selling T-shirts with a pun on that. :-) The traffic is relatevely small but output drops are growing hundreds per second. GigabitEthernet0/45 is up, line protocol is up (connected) [...] Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops: 32013814 Queueing strategy: fifo Output queue: 0/4096 (size/max) 5 minute input rate 5725 bits/sec, 33933 packets/sec 5 minute output rate 480872000 bits/sec, 47800 packets/sec [...] The problem is probably micro-bursts, which the 2960 is exceptionally bad at handling. You can adjust some of the SRR queueing parameters. Look in the list archive for details on the 3560, which has similar problems that have been discussed extensively. Or get another switch. :-) -- 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/
Re: [c-nsp] Continous BGP session resets on SRD3
I've been told by TAC that this problem caused by CSCta33973 Rodney Dunn wrote: We are working to get some clarification on this. In the interim... Can anyone prove they saw this when either: a) The upstream speaker did not have the AS Path limit configured to something lower (say less than 200)? b) The upstream speaker was running with code *newer* than one of these: 15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID 15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l 12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02 12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11 12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15 12.0(32)SY10 From what Shimol and I appear to have gleaned so far it's an issue between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and* the 4byte AS (new) upstream speaker is on a version of code older than one of the ones above. Can folks confirm/deny if their deployment where they saw this either did or did not match those conditions above? Read it carefully as it can be tricky. Thanks, Rodney ___ 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] Alert: Correction
Or is the real VP/CIO of the University of Toledo named Jun Kemail and the University's policy is to post official statements via Gmail? Just had to post this (sorry its Friday!) http://lmgtfy.com/?q=vp%2Fcio+University+of+Toledo+ :o) -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/
Re: [c-nsp] Recieving Dying Gasp notifications
Heir heir This is a feature I would like too see. But via syslog, I dont know if there is enough running time for the switch too create a packet and send it before the psu is drained. Otherwise I guess a regular DG that could be logged if enabled would work aswell. This would save alot of time when trying to narrow down a link down due too powerloss. //Wyatt Gyllenvarg Bredband2 Sweden 2010/6/17 Atif Sid guru6...@gmail.com: http://www.cisco.com/en/US/products/ps9637/index.html ME3400 series support the feature. On Tue, Jun 15, 2010 at 12:27 PM, Kaegler, Mike kaegl...@tessco.com wrote: I have a few remote sites which can be prone to power failures. For various reasons, implementing UPSs with management cards is not suitable and/or desirable. The remote equipment all supports Dying Gasp, however, but I cannot seem to find a way to make my 7200s, 3800s, or 2600s to receive the DG notifications. Google seems to indicate that only the CRS-1 will do it. This seems a pretty simple low-cost feature... is there truly no Cisco support for receiving DG on sub-million-dollar routers? -porkchop ___ cisco-nsp mailing list cisco-...@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-...@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] Weird ACL behaviour
Ben forgot to mention the development engineers are porting it over to the SR train for 7600 as it was one they missed in the cross port of applicable fixes. Rodney On 6/17/10 1:19 PM, Marco Matarazzo wrote: Fantastic Ben, looks like you catched it! Will punch an hole in the ACL, waiting for the next software upgrade cycle then! Cheers, ]\/[arco On Thu, Jun 17, 2010 at 6:38 PM, Benjamin Lovellbelov...@cisco.com wrote: Marco, This looks like CSCtc54878NDE direct export packets are checked by egress ACL When the packets are exported by the SP(MLS netflow) the flag for hardware to ignore ACL checks is not set. Fixed in SXI4. -Ben On Jun 17, 2010, at 11:52 AM, Rodney Dunn wrote: If it is an inconsistency in implementation between the software and hardware generated records it should be clearly articulated as a gotcha in the configuration guide. Ben is checking on both parts for us. Rodney On 6/17/10 11:15 AM, Marco Matarazzo wrote: On Thu, Jun 17, 2010 at 4:29 PM, Benjamin Lovellbelov...@cisco.com wrote: The code path for MLS netflow versus software netflow is not the same. For MLS netflow the export records are created by the DFC/PFC so it's not surprising that they act differently than locally generated traffic. I'm not surprised that the flows are created by different 'entities' inside the 6500. Another evidence is the fact that mls record are created with a source port different than the software created records. I just found it unexpected that this 'entity' was considered external by the point of view of the ACL. Once you know it, I can punch an hole in the ACL, but wanted to be sure this is expected and not actually a bug of some sort (in the software or in the documentation! ;) Thanks! ]\/[arco ___ 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] Alert: Correction
On Jun 18, 2010, at 2:21 AM, Jay Hennigan wrote: This isn't by any chance a troll with a misplaced space, is it? Or is the real VP/CIO of the University of Toledo named Jun Kemail and the University's policy is to post official statements via Gmail? Assuming the internet tubes are correct, this is the VP/CIO of University of Toledo: http://www.utoledo.edu/it/VP/Contact/display_dept_details.asp?Clicked_dept=IT%20Executive%20Office Now, if the VP of IT can't figure out how to post to a mailing list from a non-gmail account, they're the type of person that will type believe anything. http://www.youtube.com/watch?v=wrQUWUfmR_I (Google) and http://www.youtube.com/watch?v=QAUyaELfwBo (Internet) - 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] Continous BGP session resets on SRD3
That's not it. Shimol is formulating an update on the issue and correct bug id. Stand by... On 6/18/10 8:41 AM, Tima Maryin wrote: I've been told by TAC that this problem caused by CSCta33973 Rodney Dunn wrote: We are working to get some clarification on this. In the interim... Can anyone prove they saw this when either: a) The upstream speaker did not have the AS Path limit configured to something lower (say less than 200)? b) The upstream speaker was running with code *newer* than one of these: 15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID 15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l 12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02 12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11 12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15 12.0(32)SY10 From what Shimol and I appear to have gleaned so far it's an issue between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and* the 4byte AS (new) upstream speaker is on a version of code older than one of the ones above. Can folks confirm/deny if their deployment where they saw this either did or did not match those conditions above? Read it carefully as it can be tricky. Thanks, Rodney ___ 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] Weird ACL behaviour
On Fri, Jun 18, 2010 at 3:52 PM, Rodney Dunn rod...@cisco.com wrote: Ben forgot to mention the development engineers are porting it over to the SR train for 7600 as it was one they missed in the cross port of applicable fixes. So are also the 7600 affected? I thought only the 6500 trains were, at least it looked this way from the bug toolkit! Cheers, ]\/[arco ___ 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] Continous BGP session resets on SRD3
Rodney, Luc and myself had a detailed discussion internally on this. Below is our summary of this issue. Sharing for everyone's benefit. We think a large but valid AS PATH was originated by someone/somewhere, which included at-least one 4 byte ASN. When this reached the border router which was 4 byte ASN capable, it corrupted the update when sending it to ASN2 only peer. So the ASN2 peer on receiving it reset the peer-ship to ASN4 peer and logged the notification 3/4 message. This is a bug on the border router. It is addressed via CSCsy27511. The issue can be possibly worked around by configuring bgp maxas-limit # knob on the ASN4 capable upstream(border, box corrupting the packet), but issue with that is there is no right value to use for it. We have been able to reproduce above with a AS path length as small as 35. So recommendation is to upgrade past the above bug. A more compelling reason to upgrade are the more serious issues of: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Shimol On 6/18/10 8:41 AM, Tima Maryin wrote: I've been told by TAC that this problem caused by CSCta33973 Rodney Dunn wrote: We are working to get some clarification on this. In the interim... Can anyone prove they saw this when either: a) The upstream speaker did not have the AS Path limit configured to something lower (say less than 200)? b) The upstream speaker was running with code *newer* than one of these: 15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID 15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l 12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02 12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11 12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15 12.0(32)SY10 From what Shimol and I appear to have gleaned so far it's an issue between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and* the 4byte AS (new) upstream speaker is on a version of code older than one of the ones above. Can folks confirm/deny if their deployment where they saw this either did or did not match those conditions above? Read it carefully as it can be tricky. Thanks, Rodney ___ 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] Weird ACL behaviour
Yes from what development told us. Rodney On 6/18/10 10:12 AM, Marco Matarazzo wrote: On Fri, Jun 18, 2010 at 3:52 PM, Rodney Dunnrod...@cisco.com wrote: Ben forgot to mention the development engineers are porting it over to the SR train for 7600 as it was one they missed in the cross port of applicable fixes. So are also the 7600 affected? I thought only the 6500 trains were, at least it looked this way from the bug toolkit! Cheers, ]\/[arco ___ 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] Continous BGP session resets on SRD3
Rodney, Luc and myself had a detailed discussion internally on this. Below is our summary of this issue. Sharing for everyone's benefit. We think a large but valid AS PATH was originated by someone/somewhere, which included at-least one 4 byte ASN. When this reached the border router which was 4 byte ASN capable, it corrupted the update when sending it to ASN2 only peer. So the ASN2 peer on receiving it reset the peer-ship to ASN4 peer and logged the notification 3/4 message. This is a bug on the border router. It is addressed via CSCsy27511. The issue can be possibly worked around by configuring bgp maxas-limit # knob on the ASN4 capable upstream(border, box corrupting the packet), but issue with that is there is no right value to use for it. We have been able to reproduce above with a AS path length as small as 35. So recommendation is to upgrade past the above bug. A more compelling reason to upgrade are the more serious issues of: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Shimol On 6/18/10 9:59 AM, Rodney Dunn wrote: That's not it. Shimol is formulating an update on the issue and correct bug id. Stand by... On 6/18/10 8:41 AM, Tima Maryin wrote: I've been told by TAC that this problem caused by CSCta33973 Rodney Dunn wrote: We are working to get some clarification on this. In the interim... Can anyone prove they saw this when either: a) The upstream speaker did not have the AS Path limit configured to something lower (say less than 200)? b) The upstream speaker was running with code *newer* than one of these: 15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID 15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l 12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02 12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11 12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15 12.0(32)SY10 From what Shimol and I appear to have gleaned so far it's an issue between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and* the 4byte AS (new) upstream speaker is on a version of code older than one of the ones above. Can folks confirm/deny if their deployment where they saw this either did or did not match those conditions above? Read it carefully as it can be tricky. Thanks, Rodney ___ 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] How to find the root cause of packet loss
On Fri, 18 Jun 2010, Peter Rathlev wrote: On Fri, 2010-06-18 at 14:56 +0300, Anton Turygin wrote: Getting output drops and packet loss on Catalyst WS-C2960G-48TC-L. Someone should start selling T-shirts with a pun on that. :-) The traffic is relatevely small but output drops are growing hundreds per second. GigabitEthernet0/45 is up, line protocol is up (connected) [...] Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops: 32013814 Queueing strategy: fifo Output queue: 0/4096 (size/max) 5 minute input rate 5725 bits/sec, 33933 packets/sec 5 minute output rate 480872000 bits/sec, 47800 packets/sec [...] The problem is probably micro-bursts, which the 2960 is exceptionally bad at handling. You can adjust some of the SRR queueing parameters. Look in the list archive for details on the 3560, which has similar problems that have been discussed extensively. Unfortunately didn't work for me. Or get another switch. :-) Which model/vendor would you advice? Regards, Anton Turygin ___ 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] How to find the root cause of packet loss
Getting output drops and packet loss on Catalyst WS-C2960G-48TC-L. Someone should start selling T-shirts with a pun on that. :-) Any idea how the EOSed 2970 performs in terms of buffers and bursts? I have some of those in stock and wondering where to put them next. -Sascha ___ 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] How to find the root cause of packet loss
Toss a pair of hosts, one at gig, one at faste, on the 2970 -- then run iperf -c -P 50 / -s on either host, and tell *us* what you see for discards out the slower of the two interfaces. If you've got the gear, it should seem that the best information might be from actual testing vs non-existent specs. --Original Message-- From: Sascha Pollok Sender: cisco-nsp-boun...@puck.nether.net To: Peter Rathlev Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] How to find the root cause of packet loss Sent: Jun 18, 2010 12:34 PM Getting output drops and packet loss on Catalyst WS-C2960G-48TC-L. Someone should start selling T-shirts with a pun on that. :-) Any idea how the EOSed 2970 performs in terms of buffers and bursts? I have some of those in stock and wondering where to put them next. -Sascha ___ 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/ -Tk ___ 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] OT - Cisco QoS - FIFO
On Thursday 17 June 2010 12:20:44 pm Christopher O'Shea wrote: He show/told me that in Juniper that always have 5% for Network control traffic even on FIFO JUNOS_plug That's right. JUNOS, by default, has 2 queues enabled on each interface; 'be' and 'nc'. 'be' is assigned 95% of the interface bandwidth while 'nc' takes 5%. Of course, these values can be changed and additional queues can be added, but if QoS isn't explicitly configured by the operator, the above is what the system gives you. /JUNOS_plug 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] BGP routing table !!
On Thu, 17 Jun 2010, Marcus.Gerdon wrote: I'm not sure about RSP720 models available ad hoc, but based on Sup720 the basic hardware only allows for 256k routes at most. Only having a -XL version allows for 1m of (v4) routes. The 1M v4 routes is actually typical cisco marketing BS. Raheel, assuming you can't immediately replace your hardware, I suggest reading the two entries at http://jonsblog.lewis.org/ which I wrote a couple years ago when I knew we were about to hit similar limits. -- 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] Alert: Correction
On Fri, 2010-06-18 at 09:57 -0400, Jared Mauch wrote: Assuming the internet tubes are correct, this is the VP/CIO of University of Toledo: http://www.utoledo.edu/it/VP/Contact/display_dept_details.asp?Clicked_dept=IT%20Executive%20Office I don't see anyone named Jun Kemail on that page. Are you sure? ;-) -- 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/
Re: [c-nsp] CRS-1 MSC utilization
Bas, If you want to look at the forwarding asic utilization, show controllers pse utilization location loc is the command you're looking for.. How should I interpret the output of that command? When I issue it on a single PLIM: - #show controllers pse utilization location 0/0/CPU0 PPE Utilization NodeIngress Egress 0/0/CPU0: 9.2 0.6 From this output I would think there is 10% of capacity ingress and 0.6% egress. [...] Right, but that is forwarding capacity (i.e. pps), rather than bandwidth (bps).. this is why it doesn't match the interface utilization wich you also posted. Generally, you would run into bandwidth rather than PPS/PSE shortage, my bad.. Or what else should/could we monitor to prevent loss due to too much traffic on a PLIM. I did not find a similar simple command to show the other relevant ASIC's util. based on bandwidth, so I guess it is plain interface bandwidth monitoring, possibly using some tools like (M)RTG where you can graph a sum of multiple OIDs so you have a single figure which you can monitor.. oli ___ 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] Hardware Encryption Product for Hub/Spoke Satellite Network
Hi, I am designing a high-security network infrastructure to be setup in a hub and spoke topology. Satellite-based IP communications shall be used for the WAN transmission from remote locations to the central office. Instead of relying on the routers for IPSEC VPN encryption, I am considering the use of dedicated hardware encryption appliances for that purpose. I would appreciate if you would recommend any hardware encryption products in the market that you found reliable and robust. Thanks. Felix ___ 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] Hardware Encryption Product for Hub/Spoke Satellite Network
On Fri, 18 Jun 2010 19:49:14 +, you wrote: Instead of relying on the routers for IPSEC VPN encryption, I am considering the use of dedicated hardware encryption appliances for that purpose. Out of curiosity, why? -A ___ 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] Alert: Correction
On Thu, 17 Jun 2010, Jay Hennigan wrote: Raise your hand if you, like me, just entered Jason Mishka Bluecat or similar into your favorite search engine and had never read or had long forgotten the five-month-old original post. *hand raised* :) I do wonder if it's a competitor who is being very smart about trying to *dis*courage people from going with Blue Cat.. any vendor that will actually whine at you for writing truthful posts about their gear isn't going to get my business. IMHO if a vendor sees something I post and then asks how they can help, it'd greatly increase my chances of working with them again, and if they do a good job, would likely result in an update to the original message saying what the current state is. Heck, Jason's message was even in reply to someone asking about their experiences with Bluecat! If a vendor asked me to retract a statement like the one Jason posted (which is quite reasonable, not libelous or anything), I'd be announcing the fact that they *requested* a retraction wide and far.. ;) ___ 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] Alert: Correction
On 6/18/10 2:43 PM, Nate Carlson wrote: I do wonder if it's a competitor who is being very smart about trying to *dis*courage people from going with Blue Cat. Possible but seems unlikely. Any competitor going to that extent wouldn't post it under such an obviously fraudulent address. any vendor that will actually whine at you for writing truthful posts about their gear isn't going to get my business. Times ten for any vendor who would actually whine at someone's boss for writing truthful posts about their gear. Directing an inquiry to the real CIO/VP asking Did you really do this? and If so, why the ridiculous pseudonym? could possibly get Jason into even more trouble than he may be in now. It could also be someone with a personal grudge against Jason or trying to pull a prank on him. If indeed the University of Toledo is under pressure from a Bluecat landshark to issue a retraction, one would think that they would do one of the following: 1: Post a link to a retraction on their website thus proving that it is real. 2: Post the retraction from a real University of Toledo address. 3: Ask Jason to post the retraction. The bogus address really puts it over the top. I probably wouldn't have remembered the name Bluecat from a single thread so long ago but I will now. If it was a competitor, it worked. On the other hand, if Bluecat is that sleazy, and the real CIO/VP is really smart then he did exactly what they asked, fully knowing the outcome. He and Jason are together in a bar having drinks and laughing about Bluecat right now. One can always hope. -- 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] Specification of RA that responds to RS (applied RA suppress I/F)
Hi, If you're looking to stop the responses to solicitation as well, put in both of these: ipv6 nd ra suppress ipv6 nd prefix default no-advertise When setting Cat65, I was not checking the command ipv6 nd prefix. I have not tested it yet. However, when the command reference is seen, it seems to be effective. To which RFC or Standard (and which parts) will this behavior conform? (RFC2461?) If someone knows, could you please teach? Regards, - nakayama daigo ___ 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/
