Re: [c-nsp] OT: Console cables on new platforms
You can get a Cisco original cable for 18 bucks here: http://goo.gl/nM7nQ Or, if you don't really think you need the original, you can buy a regular USB Type-A to Mini-USB Type-B for one buck here: http://goo.gl/fV5br You'll still need to install the driver on your PC to make the USB port act as a serial port, more info about this and links to download the driver here: http://www.networkworld.com/community/blog/cisco-usb-console-ports Hope this helps Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jim McBurnett Sent: Tuesday, June 28, 2011 7:58 PM To: Nikolay Shopik; cisco-nsp Subject: Re: [c-nsp] OT: Console cables on new platforms They are now a $30 list price option. Jim -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nikolay Shopik Sent: Tuesday, June 28, 2011 4:56 AM To: cisco-nsp Subject: [c-nsp] OT: Console cables on new platforms Hey everyone, We just received our 3560X and no console cables included at all, is this new policy for new platforms? I mean no RS-232-RJ45 or new mini-usb console cable at all. ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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: Console cables on new platforms
I wonder what kind chip Cisco using, usual Prolific pl2303?. Just don't wanna mess with drivers on OS differ from Windows. On 29/06/11 10:54, Ziv Leyes wrote: You can get a Cisco original cable for 18 bucks here: http://goo.gl/nM7nQ Or, if you don't really think you need the original, you can buy a regular USB Type-A to Mini-USB Type-B for one buck here: http://goo.gl/fV5br You'll still need to install the driver on your PC to make the USB port act as a serial port, more info about this and links to download the driver here: http://www.networkworld.com/community/blog/cisco-usb-console-ports Hope this helps Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jim McBurnett Sent: Tuesday, June 28, 2011 7:58 PM To: Nikolay Shopik; cisco-nsp Subject: Re: [c-nsp] OT: Console cables on new platforms They are now a $30 list price option. Jim -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nikolay Shopik Sent: Tuesday, June 28, 2011 4:56 AM To: cisco-nsp Subject: [c-nsp] OT: Console cables on new platforms Hey everyone, We just received our 3560X and no console cables included at all, is this new policy for new platforms? I mean no RS-232-RJ45 or new mini-usb console cable at all. ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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] Cisco ASA,VPN license and VPN client behaviour
Hello folks, Can someone advise me when you reach your license limit for VPN users and connection got refused because of that, if Cisco VPN client will try another gateway which is set up as backup server within .pcf file ? I don't have opportunity test behavior right now and would appreciate if someone know the answer :) Thanks, Tomas Best Regards, Tomas Kovac -- Tomas Kovac NW NDM Implementation Team EMEA NDM Central Delivery Hewlett-Packard Slovakia Telephone: +421 2 5752 5884 Mobile: +421 917 866 160 Email: tomas.ko...@hp.com Shall we not receive any communication within 7 days we will consider the issue resolved. After this closure if an additional configuration due to possible issue arise, new implementation date has to be communicated, a new ticket has to be raised. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as HP CONFIDENTIAL. smime.p7s Description: S/MIME cryptographic signature ___ 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] Recall: Cisco ASA,VPN license and VPN client behaviour
Kovac, Tomas (Networks) would like to recall the message, Cisco ASA,VPN license and VPN client behaviour. ___ 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] view oversubscribed ports on Cisco 4500 platform
Hi, I have a Cisco WS-C4506 switch with one linecard in slot 5: 548 10/100BaseTX (RJ45)WS-X4148-RJJAE063105RC ..and other linecard in slot 6: 648 10/100/1000BaseT (RJ45)WS-X4448-GB-RJ45 JAE0849GVW0 According to documentation(http://mcaf.ee/63paj), WS-X4148-RJ has all ports in wirerate and WS-X4448-GB-RJ45 is an oversubscribed card and should have 8-to-1(8 1GE ports share 1Gbps channel to backplane). How to see in switch, which ports are oversubscribed into which 1GE group? If I use show platform chassis module 6 command, I can see following output: StubId StubType StubPortId ConnectorType PortName 0Lemans 0 RJ-45 Gi6/2 0Lemans 1 RJ-45 Gi6/1 0Lemans 2 RJ-45 Gi6/4 0Lemans 3 RJ-45 Gi6/3 0Lemans 4 RJ-45 Gi6/6 0Lemans 5 RJ-45 Gi6/5 0Lemans 6 RJ-45 Gi6/8 0Lemans 7 RJ-45 Gi6/7 1Lemans 0 RJ-45Gi6/10 1Lemans 1 RJ-45 Gi6/9 1Lemans 2 RJ-45Gi6/12 1Lemans 3 RJ-45Gi6/11 1Lemans 4 RJ-45Gi6/14 1Lemans 5 RJ-45Gi6/13 1Lemans 6 RJ-45Gi6/16 1Lemans 7 RJ-45Gi6/15 2Lemans 0 RJ-45Gi6/18 2Lemans 1 RJ-45Gi6/17 2Lemans 2 RJ-45Gi6/20 2Lemans 3 RJ-45Gi6/19 2Lemans 4 RJ-45Gi6/22 2Lemans 5 RJ-45Gi6/21 2Lemans 6 RJ-45Gi6/24 2Lemans 7 RJ-45Gi6/23 3Lemans 0 RJ-45Gi6/26 3Lemans 1 RJ-45Gi6/25 3Lemans 2 RJ-45Gi6/28 3Lemans 3 RJ-45Gi6/27 3Lemans 4 RJ-45Gi6/30 3Lemans 5 RJ-45Gi6/29 3Lemans 6 RJ-45Gi6/32 3Lemans 7 RJ-45Gi6/31 ..etc, which looks like an oversubscription map, but show platform chassis module 5 gives me very similar information about WS-X4148-RJ, which actually isn't an oversubscribed card. Is it possible at all to view in Cisco 4500 series switch, which ports are oversubscribed? regards, martin ___ 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] web redirection
is there a way to to redirect a web page when requested to another web page ? ___ 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] FW: OT: Console cables on new platforms
I think my previous mail was filtered and perhaps blocked? I didn't see it coming back to my inbox... Let's try again, please read below Ziv -Original Message- From: Ziv Leyes Sent: Wednesday, June 29, 2011 9:55 AM To: cisco-nsp Subject: RE: [c-nsp] OT: Console cables on new platforms You can get a Cisco original cable for 18 bucks here: http://goo.gl/nM7nQ Or, if you don't really think you need the original, you can buy a regular USB Type-A to Mini-USB Type-B for one buck here: http://goo.gl/fV5br You'll still need to install the driver on your PC to make the USB port act as a serial port, more info about this and links to download the driver here: http://www.networkworld.com/community/blog/cisco-usb-console-ports Hope this helps Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jim McBurnett Sent: Tuesday, June 28, 2011 7:58 PM To: Nikolay Shopik; cisco-nsp Subject: Re: [c-nsp] OT: Console cables on new platforms They are now a $30 list price option. Jim -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nikolay Shopik Sent: Tuesday, June 28, 2011 4:56 AM To: cisco-nsp Subject: [c-nsp] OT: Console cables on new platforms Hey everyone, We just received our 3560X and no console cables included at all, is this new policy for new platforms? I mean no RS-232-RJ45 or new mini-usb console cable at all. ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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] web redirection
It's easy to do it on the webpage itself, if that's what you're asking for You can use html code on the page to redirect to another webpage, search google for meta http equiv refresh If you're talking about doing it with a Cisco device, then look at this PDF http://cisco.biz/en/US/docs/ios/isg/configuration/guide/isg_l4_redirect.pdf; Hope this helps, Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil Sent: Wednesday, June 29, 2011 11:56 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] web redirection is there a way to to redirect a web page when requested to another web page ? ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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] view oversubscribed ports on Cisco 4500 platform
Maarten, I understand this, but is it possible to view inside the switch, which ports are assigned into which 1GE groups? Or is it just to count 8 ports from the firs port of the linecard and so on? :) And for aggregation/server switches in the data center the Cisco 6500 series is probably a better solution? regards, martin 2011/6/29 Maarten Carels li...@carels.info: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Jun 2011, at 10:10 , Martin T wrote: Hi, I have a Cisco WS-C4506 switch with one linecard in slot 5: 5 48 10/100BaseTX (RJ45) WS-X4148-RJ JAE063105RC ..and other linecard in slot 6: 6 48 10/100/1000BaseT (RJ45) WS-X4448-GB-RJ45 JAE0849GVW0 Backplane connections in the 4000 (and 4500) chassis are 6 connections of 1G each per slot. So in the 48 port blades 8 ports share the same 1G connection. This was fine in the past, as 8 100Mb ports fit nicely. 4000/4500 Catalysts were never positioned as server of aggregation switches, they are access switches for a bunch of desktops. - --maarten -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOCueZAAoJEHXc8jAmoaIoDNUH/A3ErTOGe2CXnWCEi8iaOGgU 5+eeXpR7nxoOaZidwxrfB11yZzrKz5gXwgkMBjjBe6LJuaD7xpnUhhklJ0JCLCHT oW1CVMHbbfli+36i9+lJIxa1Va4G3jpc1+DeLxUTEu1e4oKvBLvNtj3Q9//osJDA wnq/gFiwCjW38m6Dl0XXY25UCNICa0qe8AIwuWUfEIjMG6qJhoW12oKSsjFa0WcH rjHsYxD5dMcevB+aDX+FnfSbkICf2qPAZ4VCx9SDCif+83PDSTdZZJT1dUnuNwOt GlrCiZ+WtEw7pNokImiQVxdTiS3CSa7oXxnHqdqscBSXGsAyB3DWR6EGIWzcdQ0= =EI88 -END PGP SIGNATURE- ___ 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] view oversubscribed ports on Cisco 4500 platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Jun 2011, at 10:10 , Martin T wrote: Hi, I have a Cisco WS-C4506 switch with one linecard in slot 5: 548 10/100BaseTX (RJ45)WS-X4148-RJJAE063105RC ..and other linecard in slot 6: 648 10/100/1000BaseT (RJ45)WS-X4448-GB-RJ45 JAE0849GVW0 Backplane connections in the 4000 (and 4500) chassis are 6 connections of 1G each per slot. So in the 48 port blades 8 ports share the same 1G connection. This was fine in the past, as 8 100Mb ports fit nicely. 4000/4500 Catalysts were never positioned as server of aggregation switches, they are access switches for a bunch of desktops. - --maarten -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOCueZAAoJEHXc8jAmoaIoDNUH/A3ErTOGe2CXnWCEi8iaOGgU 5+eeXpR7nxoOaZidwxrfB11yZzrKz5gXwgkMBjjBe6LJuaD7xpnUhhklJ0JCLCHT oW1CVMHbbfli+36i9+lJIxa1Va4G3jpc1+DeLxUTEu1e4oKvBLvNtj3Q9//osJDA wnq/gFiwCjW38m6Dl0XXY25UCNICa0qe8AIwuWUfEIjMG6qJhoW12oKSsjFa0WcH rjHsYxD5dMcevB+aDX+FnfSbkICf2qPAZ4VCx9SDCif+83PDSTdZZJT1dUnuNwOt GlrCiZ+WtEw7pNokImiQVxdTiS3CSa7oXxnHqdqscBSXGsAyB3DWR6EGIWzcdQ0= =EI88 -END PGP SIGNATURE- ___ 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] view oversubscribed ports on Cisco 4500 platform
Maarten, port oversubscription map for WS-X4448-GB-RJ45 is just as you guessed: * Ports 1, 2, 3, 4, 5,6, 7, 8 * Ports 9, 10, 11, 12, 13, 14, 15, 16 * Ports 17, 18, 19, 20, 21, 22, 23, 24 * Ports 25, 26, 27, 28, 29, 30, 31, 32 * Ports 33, 34, 35, 36, 37, 38, 39, 40 * Ports 41, 42, 43, 44, 45, 46, 47, 48 Source: http://mcaf.ee/t7q4c However, maybe those show platform chassis module 6 or show platform chassis module 5 actually show port groups if you say each module(even 48xFa ones) have this 6x 1GE architecture. For example beginning of the show platform chassis module 5 output: StubId StubType StubPortId ConnectorType PortName 0 Astro 0 RJ-45 Fa5/1 0 Astro 1 RJ-45 Fa5/2 0 Astro 2 RJ-45 Fa5/3 0 Astro 3 RJ-45 Fa5/4 0 Astro 4 RJ-45 Fa5/6 0 Astro 5 RJ-45 Fa5/5 0 Astro 6 RJ-45 Fa5/7 0 Astro 7 RJ-45 Fa5/8 1 Astro 0 RJ-45 Fa5/9 1 Astro 1 RJ-45Fa5/10 1 Astro 2 RJ-45Fa5/11 1 Astro 3 RJ-45Fa5/12 1 Astro 4 RJ-45Fa5/14 1 Astro 5 RJ-45Fa5/13 1 Astro 6 RJ-45Fa5/15 1 Astro 7 RJ-45Fa5/16 2 Astro 0 RJ-45Fa5/17 2 Astro 1 RJ-45Fa5/18 2 Astro 2 RJ-45Fa5/19 2 Astro 3 RJ-45Fa5/20 2 Astro 4 RJ-45Fa5/22 2 Astro 5 RJ-45Fa5/21 2 Astro 6 RJ-45Fa5/23 2 Astro 7 RJ-45Fa5/24 3 Astro 0 RJ-45Fa5/25 3 Astro 1 RJ-45Fa5/26 3 Astro 2 RJ-45Fa5/27 3 Astro 3 RJ-45Fa5/28 3 Astro 4 RJ-45Fa5/30 3 Astro 5 RJ-45Fa5/29 3 Astro 6 RJ-45Fa5/31 3 Astro 7 RJ-45Fa5/32 4 Astro 0 RJ-45Fa5/33 4 Astro 1 RJ-45Fa5/34 4 Astro 2 RJ-45Fa5/35 Should the StubId mean one 1GE connection to backplane? regards, martin 2011/6/29 Maarten Carels li...@carels.info: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Jun 2011, at 11:16 , Martin T wrote: Maarten, I understand this, but is it possible to view inside the switch, which ports are assigned into which 1GE groups? Or is it just to count 8 ports from the firs port of the linecard and so on? :) And for aggregation/server switches in the data center the Cisco 6500 series is probably a better solution? There should be docs somewhere on the cisco site. Don't know if you can ask the switch, I had a lot of 4500's in the past, but now I've changed jobs, and can't access one. It may be 1-8, 9-16 and so on. That looks reasonable, also if you take a look on the physical board itself (it's almost empty). There have been some mixed interface cards in the past, they always reflect the architecture of 6 separate connections of 1G to the backplane. Works fine in the wiring closet, less for datacentre. The 6500 is better for aggregation / datacentre, but is quite a bit more expensive - --maarten -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOCvC2AAoJEHXc8jAmoaIoU9gH/RAbDa553DXABjAtiD/vd/Xu vUptEOiWVXblZ1BFhGzmpP1Ac4ayhxozcgXMBIPm0VMNJxNV3XeIzCx/Fb5Ku6Vz 9pEgeTPqGUGr2oTwNhsbdL9Yup3nPACBNEAOMmg1/+WE/NT9vHwHZb0cb4GUKWvn jxWpYpGCDUoFuORT5jESBa3HbLav7y/1taHKCgqSaIN4Im7I3qjdOFtWxQH1fuP9 wzZY6uElZUEa5qnzzdsq/YIhujCbDd6i84i12xJ4Eecil4V/yn8sThy6wtuzATzD ikvCGTDBAKxZ+4LGGiKlk6iUJJ1UFEg08TFLkjtRrEdkPx9VP8Fe/tVre2cIvMo= =Xvwv -END PGP SIGNATURE- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
Re: [c-nsp] OT: Console cables on new platforms
I think my previous mail contained too many hyperlinks and it was filtered and perhaps blocked? Let's try again, please read below You can get a Cisco original cable for 18 bucks at www.fullsourcesecurity.com, go to HomeCable and find Cisco CAB-CONSOLE-USB Console Cable 6 ft with USB Type A and mini-B Or, if you don't really think you need the original, you can buy a regular USB Type-A to Mini-USB Type-B for around $1! Just google the cable type in shopping and you'll find tons of websites to buy from You'll still need to install the driver on your PC to make the USB port act as a serial port, more info about this and links to download the driver here: http://www.networkworld.com/community/blog/cisco-usb-console-ports; Hope this helps Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jim McBurnett Sent: Tuesday, June 28, 2011 7:58 PM To: Nikolay Shopik; cisco-nsp Subject: Re: [c-nsp] OT: Console cables on new platforms They are now a $30 list price option. Jim -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nikolay Shopik Sent: Tuesday, June 28, 2011 4:56 AM To: cisco-nsp Subject: [c-nsp] OT: Console cables on new platforms Hey everyone, We just received our 3560X and no console cables included at all, is this new policy for new platforms? I mean no RS-232-RJ45 or new mini-usb console cable at all. ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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] Transport PVCs using pseudowire?
hello, what would be the best practice to deliver to a router of an ISP some PVCs you have configured on an ATM OC3 installed on your c7206 NPEG2? in other words, that ISP would like to carry some dsl customers on its own router and to assign them its own IPs without dealing with atm interfaces. wondering if pseudowire could help here. thank you -- antonio D4FC CD28 261D 8EE3 13FF 3B6B 9564 00FA 90F7 142F ___ 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] 6500 CoPP + IPv6 fragments
Hi, I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. I know that IPv6 fragments are not well supported in PFC3B, but is this sort of behaviour expected? Are there any workarounds? Best Regards, Bernhard ___ 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
Hi, Our Internet BGP tier is currently provided by a pair of 7206VXR routers with NPE-G1s which are getting quite long in the tooth. We've recently been able to reclaim a pair of Sup720-3BXLs and the associated 6509 chassis'. Its our intention to retire the 7206s and replace them with the 6509s /w Sup720s but we require 6 GigE interfaces per box. We have a pair of WS-X6408A-GBIC 'classic bus' linecards on the shelf (no spare 65XX or 67XX modules unfortunately) but my question is whether using the WS-X6408A-GBIC to provide port capacity is a good or bad idea in this scenario? I appreciate that using a WS-X6408A-GBIC means that the classic 32Gbps shared bus will be used (with a max of 15Mpps per system) but in raw performance numbers this is a significant increase on the 7206VXR/NPE-G1s ~2Gbps backplane and ~1Mpps forwarding rate. My real concern is that I've found two different Cisco documents that describe the Forwarding-Engine Architecture differently for classic linecards. This link :- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html states that the Supervisor engine CPU makes forwarding decision and this link:- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html states that Centralized Cisco Express Forwarding engine located on supervisor policy feature card (PFC) makes forwarding decision As the 6500 series is a hardware-based platform I'm keen to make use of hardware-supported features where available and not experience unexpected issues from high CPU utilisation. Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? Thanks in advance, Matthew ___ 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
Its all forwarded by the supervisor. I wouldn't be worried about that too much. I'd be more worried about the full internet table being on the 6500. It will probably be okay but 6500s aren't great high scale routers. They don't have much CPU power. On Jun 29, 2011 11:17 AM, matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Hi, Our Internet BGP tier is currently provided by a pair of 7206VXR routers with NPE-G1s which are getting quite long in the tooth. We've recently been able to reclaim a pair of Sup720-3BXLs and the associated 6509 chassis'. Its our intention to retire the 7206s and replace them with the 6509s /w Sup720s but we require 6 GigE interfaces per box. We have a pair of WS-X6408A-GBIC 'classic bus' linecards on the shelf (no spare 65XX or 67XX modules unfortunately) but my question is whether using the WS-X6408A-GBIC to provide port capacity is a good or bad idea in this scenario? I appreciate that using a WS-X6408A-GBIC means that the classic 32Gbps shared bus will be used (with a max of 15Mpps per system) but in raw performance numbers this is a significant increase on the 7206VXR/NPE-G1s ~2Gbps backplane and ~1Mpps forwarding rate. My real concern is that I've found two different Cisco documents that describe the Forwarding-Engine Architecture differently for classic linecards. This link :- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html states that the Supervisor engine CPU makes forwarding decision and this link:- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html states that Centralized Cisco Express Forwarding engine located on supervisor policy feature card (PFC) makes forwarding decision As the 6500 series is a hardware-based platform I'm keen to make use of hardware-supported features where available and not experience unexpected issues from high CPU utilisation. Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? Thanks in advance, Matthew ___ 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
Thanks. I had (perhaps foolishly) assumed that moving from an NPE-G1 to a Sup720-3BXL-based platform would represent an upgrade from the 7206VXR (as well as having the advantage of bringing our Internet BGP tier in-line with the rest of our core network from a hardware perspective). When comparing the NPE-G1 to a Sup720-3BXL for the purposes of being an internet-facing BGP router am I actually proposing a backwards step? From: Peter Rathlev pe...@rathlev.dk To: matthew.coleman-hamil...@servicebirmingham.co.uk Cc: cisco-nsp@puck.nether.net Date: 29/06/2011 16:38 Subject: Re: [c-nsp] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC On Wed, 2011-06-29 at 16:14 +0100, matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? The PFC3B on the supervisor will make the forwarding decisions. Throughput is limited by the 32 Gb/s (simplex) bus and the 15 Mpps per system as you mention. You should also look into buffer sizes and the card's ability to handle bursts. I don't know the 6408 card, but we've used 6516 (CEF256) cards with success for many years. You should also beware that the Sup720 route processor is quite weak compared to a NPE-G1, and things like BGP processing might take somewhat longer than usual. This white-paper explains the forwarding architecture quite well, though it has little information on classic bus forwarding: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html http://tinyurl.com/2w7yu3 (same link) If you try searching for BRKARC-3465.pdf in your favorite search engine you could find a presentation from a breakout session that explains things in more detail. I'm not sure it's an official document, so I'd rater not link directly to anthing. But it's worth a read. -- 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
The supervisor is actually a split brain system...with the MSFC handling routing calculations/manipulation and the PFC handling packet switching. I expect your new setup will handle things just fine...and at least for the moment, a Sup720-3BXL can handle full tables. One annoyance, probably minor, is that none of cisco's GigE ports for the 6500 have a whole lot of output buffer, so if you're doing much traffic, you will likely see some output drops, but not enough to cause problems. On Wed, 29 Jun 2011, Chris Evans wrote: Its all forwarded by the supervisor. I wouldn't be worried about that too much. I'd be more worried about the full internet table being on the 6500. It will probably be okay but 6500s aren't great high scale routers. They don't have much CPU power. On Jun 29, 2011 11:17 AM, matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Hi, Our Internet BGP tier is currently provided by a pair of 7206VXR routers with NPE-G1s which are getting quite long in the tooth. We've recently been able to reclaim a pair of Sup720-3BXLs and the associated 6509 chassis'. Its our intention to retire the 7206s and replace them with the 6509s /w Sup720s but we require 6 GigE interfaces per box. We have a pair of WS-X6408A-GBIC 'classic bus' linecards on the shelf (no spare 65XX or 67XX modules unfortunately) but my question is whether using the WS-X6408A-GBIC to provide port capacity is a good or bad idea in this scenario? I appreciate that using a WS-X6408A-GBIC means that the classic 32Gbps shared bus will be used (with a max of 15Mpps per system) but in raw performance numbers this is a significant increase on the 7206VXR/NPE-G1s ~2Gbps backplane and ~1Mpps forwarding rate. My real concern is that I've found two different Cisco documents that describe the Forwarding-Engine Architecture differently for classic linecards. This link :- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html states that the Supervisor engine CPU makes forwarding decision and this link:- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html states that Centralized Cisco Express Forwarding engine located on supervisor policy feature card (PFC) makes forwarding decision As the 6500 series is a hardware-based platform I'm keen to make use of hardware-supported features where available and not experience unexpected issues from high CPU utilisation. Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? Thanks in advance, Matthew ___ 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/ -- Jon Lewis, MCP :) | 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
On Wed, 29 Jun 2011 matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Thanks. I had (perhaps foolishly) assumed that moving from an NPE-G1 to a Sup720-3BXL-based platform would represent an upgrade from the 7206VXR (as well as having the advantage of bringing our Internet BGP tier in-line with the rest of our core network from a hardware perspective). When comparing the NPE-G1 to a Sup720-3BXL for the purposes of being an internet-facing BGP router am I actually proposing a backwards step? It may not have as much CPU power as a G1, but it's a switch and was designed to switch packets at line rate...lots of them, lots more than a VXR can do. BGP convergence may go a little slower, but the platform will forward more traffic (PPS or Mbps) than the VXR. -- Jon Lewis, MCP :) | 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] Transport PVCs using pseudowire?
On 6/29/11 8:01 AM, Antonio Prado wrote: hello, what would be the best practice to deliver to a router of an ISP some PVCs you have configured on an ATM OC3 installed on your c7206 NPEG2? in other words, that ISP would like to carry some dsl customers on its own router and to assign them its own IPs without dealing with atm interfaces. wondering if pseudowire could help here. What is your transport to that ISP? If ethernet, VLANs would be the most logical choice. If a serial link such as a DS3, you could use frame-relay encapsulation and a PVC per customer. -- 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
Hi, On Wed, Jun 29, 2011 at 04:14:20PM +0100, matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Our Internet BGP tier is currently provided by a pair of 7206VXR routers with NPE-G1s which are getting quite long in the tooth. We've recently been able to reclaim a pair of Sup720-3BXLs and the associated 6509 chassis'. Its our intention to retire the 7206s and replace them with the 6509s /w Sup720s but we require 6 GigE interfaces per box. We have a pair of WS-X6408A-GBIC 'classic bus' linecards on the shelf (no spare 65XX or 67XX modules unfortunately) but my question is whether using the WS-X6408A-GBIC to provide port capacity is a good or bad idea in this scenario? It will work just fine, given that you're not going to max out the bus with a single 8G card :-) [..] My real concern is that I've found two different Cisco documents that describe the Forwarding-Engine Architecture differently for classic linecards. This link :- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html states that the Supervisor engine CPU makes forwarding decision That's not fully correct - it's the Supervisor engine (as opposed to the DFC card on a 6700 module+DFC) but not the CPU. and this link:- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html states that Centralized Cisco Express Forwarding engine located on supervisor policy feature card (PFC) makes forwarding decision The PFC is part of the Supervisor engine. As the 6500 series is a hardware-based platform I'm keen to make use of hardware-supported features where available and not experience unexpected issues from high CPU utilisation. Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? Bus, PFC, Hardware. Unless you hit one of the (rare) feature combinations that require CPU-based CEF on the Sup720. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpDq9MwSbeua.pgp Description: PGP signature ___ 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] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
Hi, On Wed, Jun 29, 2011 at 04:49:12PM +0100, matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Thanks. I had (perhaps foolishly) assumed that moving from an NPE-G1 to a Sup720-3BXL-based platform would represent an upgrade from the 7206VXR (as well as having the advantage of bringing our Internet BGP tier in-line with the rest of our core network from a hardware perspective). When comparing the NPE-G1 to a Sup720-3BXL for the purposes of being an internet-facing BGP router am I actually proposing a backwards step? The CPU on the Sup720 is slower, so load a full BGP table from 5 peers will take longer. OTOH, 100% CPU due to BGP on the Sup720 doesn't impact packet forwarding capacity, as that's done by other bits of the hardware - so depending on traffic mix and BGP churn (and number of peers) the Sup720 will vastly outperform the NPE-G1 :-) As a reference: we're currently using Sup720s as peering and upstream routers, and we've been quite happy most of the time. Major causes for unhappiness: software bugs (can happen on all platforms), hardware limitations (some things the hardware just cannot do), political issues inside Cisco (6500/7600 in-fighting). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp3BSWwjfFVm.pgp Description: PGP signature ___ 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] 6500 CoPP + IPv6 fragments
On 06/29/2011 04:04 PM, Bernhard Schmidt wrote: Hi, I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. I know that IPv6 fragments are not well supported in PFC3B, but is this sort of behaviour expected? Are there any workarounds? What does your CoPP policy look like? ___ 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] 6500 CoPP + IPv6 fragments
Phil Mayers p.may...@imperial.ac.uk wrote: I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. I know that IPv6 fragments are not well supported in PFC3B, but is this sort of behaviour expected? Are there any workarounds? What does your CoPP policy look like? It's longish, I'll cut a few duplicates to make it easier to read. ip access-list extended CoPP-critical-in remark Control plane critical traffic - inbound permit ospf 169.254.0.0 0.0.0.255 any ! OSPFv2 permit tcp 169.254.0.0 0.0.1.255 eq 179 169.254.0.0 0.0.1.255 ! iBGP permit tcp 169.254.0.0 0.0.1.255 169.254.0.0 0.0.1.255 eq 179 ! iBGP permit tcp 169.254.0.0 0.0.0.255 eq 646 169.254.0.0 0.0.0.255 ! LDP permit tcp 169.254.0.0 0.0.0.255 169.254.0.0 0.0.0.255 eq 646 ! LDP permit udp any host 224.0.0.2 eq 646! LDP permit icmp host 169.254.1.36 any echo deny ip any any ip access-list extended CoPP-important-in permit ip host 169.254.1.36 any permit tcp 169.254.0.0 0.0.1.255 any eq 22 permit tcp 169.254.0.0 0.0.1.255 any eq 23 permit udp host 169.254.1.224 eq ntp any permit udp host 169.254.1.225 eq ntp any permit tcp host 169.254.1.224 eq tacacs any established permit tcp host 169.254.1.225 eq tacacs any established permit udp 169.254.1.64 0.0.0.7 any eq snmp permit udp host 0.0.0.0 host 255.255.255.255 eq bootps permit udp any eq bootps any eq bootps someeBGPsessions deny ip any any ip access-list extended CoPP-normal-in remark Control plane normal traffic - inbound remark ICMP permit icmp any any echo permit icmp any any echo-reply permit icmp any any parameter-problem permit icmp any any time-exceeded permit icmp any any unreachable deny ip any any ip access-list extended CoPP-reflexive-in remark Control plane traffic due to reflect filter statements deny ip any any ip access-list extended CoPP-unwanted-in remark Control plane unwanted traffic - inbound permit udp any any eq 137 ! NETBIOS Name Service permit udp any any eq 631 ! CUPS Browsing permit udp any any eq 161 permit tcp any any eq bgp permit tcp any eq bgp any deny ip any any ip access-list extended CoPP-default-in remark Control plane default traffic - inbound permit ip any any ipv6 access-list CoPP-critical-in-IPv6 remark Control plane critical traffic - inbound IPv6 permit 89 FE80::/32 any ! OSPFv3 permit tcp 2001:DB8::/64 eq bgp 2001:DB8::/64 ! iBGP permit tcp 2001:DB8::/64 2001:DB8::/64 eq bgp ! iBGP someeBGPsessions permit udp FE80::/64 FF02::66/128 eq 2029! IPv6 HSRP permit udp FE80::/64 FF02::9/128 eq 521 ! RIPng deny ipv6 any any ipv6 access-list CoPP-important-in-IPv6 remark Control plane important traffic - inbound IPv6 permit tcp 2001:DB8:0::/48 any eq 23 permit tcp 2001:DB8:100:3::/64 any eq 23 deny ipv6 any any ipv6 access-list CoPP-normal-in-IPv6 remark Control plane normal traffic - inbound IPv6 permit icmp any any echo-request ! Ping permit icmp any any nd-ns ! Neighbor discovery permit icmp any any nd-na ! Neighbor discovery deny ipv6 any any ipv6 access-list CoPP-reflexive-in-IPv6 remark Control plane normal traffic - inbound IPv6 deny ipv6 any any ipv6 access-list CoPP-unwanted-in-IPv6 remark Control plane unwanted traffic - inbound IPv6 permit 89 any any ! OSPFv3 deny any any ipv6 access-list CoPP-default-in-IPv6 remark Control plane default traffic - inbound IPv6 permit ipv6 any any class-map match-any CoPP-critical-in description things that should never ever be dropped (e.g. routingprotocols) match access-group name CoPP-critical-in match access-group name CoPP-critical-in-IPv6 class-map match-any CoPP-important-in description Important stuff for administration match access-group name CoPP-important-in match access-group name CoPP-important-in-IPv6 class-map match-any CoPP-reflexive-in match access-group name CoPP-reflexive-in match access-group name CoPP-reflexive-in-IPv6 class-map match-any CoPP-normal-in match access-group name CoPP-normal-in match access-group name CoPP-normal-in-IPv6 class-map match-any CoPP-unwanted-in match access-group name CoPP-unwanted-in match access-group name CoPP-unwanted-in-IPv6 class-map match-any CoPP-arp-in match protocol arp class-map match-any CoPP-default-in match access-group name CoPP-default-in match access-group name CoPP-default-in-IPv6 policy-map CoPP-in class CoPP-critical-in class CoPP-important-in class CoPP-reflexive-in class CoPP-normal-in police 128000 16000 16000 conform-action transmit exceed-action drop class CoPP-unwanted-in police 128000 16000 16000 conform-action drop exceed-action drop class CoPP-arp-in police
Re: [c-nsp] 6500 CoPP + IPv6 fragments
On 29-06-11 17:04, Bernhard Schmidt wrote: I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. Bernhard, We have had the same issue for last ~week, however our v6 copp has been quite good for last couple of months. We also saw transit traffic being dropped. Had to remove the default copp class-map to get things working. When did you install v6 copp? Have you had the issue since the very beginning or just recently? -- Grzegorz Janoszka ___ 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] 6500 CoPP + IPv6 fragments
Sup720 appears to be unable to handle the ipv6 fragments in HW, therefore they will be sent to the CPU to be processed, if CoPP is on and there are matching entries they will be matched and potentially policed/dropped. CSCsa78144 covers some of the details of this. HTH, Rich On Jun 29, 2011, at 15:22 , Grzegorz Janoszka wrote: On 29-06-11 17:04, Bernhard Schmidt wrote: I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. Bernhard, We have had the same issue for last ~week, however our v6 copp has been quite good for last couple of months. We also saw transit traffic being dropped. Had to remove the default copp class-map to get things working. When did you install v6 copp? Have you had the issue since the very beginning or just recently? -- Grzegorz Janoszka ___ 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] 6500 CoPP + IPv6 fragments
Grzegorz Janoszka grzeg...@janoszka.pl wrote: On 29-06-11 17:04, Bernhard Schmidt wrote: I have a few 6500 Sup720/3BXL boxes running various releases of 12.2(33)SXI and SXJ that seem to drop all IPv6 fragments in transit as soon as CoPP is enabled. There are no CoPP drops logged. Even when I remove all police lines from the policy-map the packets still get dropped. As soon as I disble CoPP the packets get through. We have had the same issue for last ~week, however our v6 copp has been quite good for last couple of months. We also saw transit traffic being dropped. Had to remove the default copp class-map to get things working. Is your CoPP similarly structured to mine? When did you install v6 copp? Have you had the issue since the very beginning or just recently? I have been running this or a similar configuration in two networks for ... uh ... several years I think. One of them is quiet regarding IPv6 traffic, but the other one has a few thousand heavy IPv6 users in it. I only noticed it because a) Netalyzr (http://netalyzr.icsi.berkeley.edu/) complains about fragments being dropped b) I started using DNSSEC-signed SSHFP DNS records by default with an IPv6 DNS resolver, where the response is 1500 bytes and thus fragmented I'm not aware of any other impact, ever. Bernhard ___ 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] 6500 CoPP + IPv6 fragments
Richard Gallagher rgall...@cisco.com wrote: Sup720 appears to be unable to handle the ipv6 fragments in HW, therefore they will be sent to the CPU to be processed, if CoPP is on and there are matching entries they will be matched and potentially policed/dropped. CSCsa78144 covers some of the details of this. I was aware of this hardware limitation, but in my case the fragments are always dropped when CoPP is enabled. Even if there is no policing for any class or all IPv6 traffic is classified into a not-policed class. Bernhard ___ 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] ASA 8.3 full-tunnel VPN paradox...
I'm working on replacing an old PIX VPN setup with a new ASA, and having a bear of a time with a full tunnel setup. The PIX (old 6.x software) has setups for both split-tunnel and full-tunnel profiles. It is *not* the outbound gateway for internet-destined traffic. Our internet traffic goes from the border to a pair of active/active ASAs along with our perimeter protection, IPS, and other assorted goodies, so that is the desired path for the full-tunnel traffic. Since the active/active pair can't do VPN, another ASA is serving that purpose (inside the other ASAs), also connected to our core. On the PIX, there is a default route on both the outside and inside interfaces thusly: utc-pix# sho route | i 0.0.0.0 outside 0.0.0.0 0.0.0.0 aaa.bbb.ccc.246 1 OTHER static inside 0.0.0.0 0.0.0.0 aaa.bbb.ccc.20 10 OTHER static Anything connecting to the VPN (or otherwise hitting the outside interface) follows the outside route. Any VPN-originated traffic on the full tunnel follows the inside route. The ASA is not behaving this way... it wants to always follow the outside route for the VPN-originated full-tunnel traffic if I include both routes (with unequal weights, as it doesn't allow them to be the same). If I define an explicit outside route to where I VPN from, and remove the default outside route, it works perfectly. Is there something obvious I'm missing here to make it behave like the PIX does? 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] 6500 CoPP + IPv6 fragments
On 29-06-11 21:31, Bernhard Schmidt wrote: Is your CoPP similarly structured to mine? More or less it is. Richard Gallagher's suggestion about CSCsa78144 was really helpful in our case and helped. Thanks! -- Grzegorz Janoszka ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA 8.3 full-tunnel VPN paradox...
On Wed, Jun 29, 2011 at 16:30:13, Jeff Kell wrote: Subject: [c-nsp] ASA 8.3 full-tunnel VPN paradox... I'm working on replacing an old PIX VPN setup with a new ASA, and having a bear of a time with a full tunnel setup. The PIX (old 6.x software) has setups for both split-tunnel and full-tunnel profiles. It is *not* the outbound gateway for internet-destined traffic. Our internet traffic goes from the border to a pair of active/active ASAs along with our perimeter protection, IPS, and other assorted goodies, so that is the desired path for the full-tunnel traffic. Since the active/active pair can't do VPN, another ASA is serving that purpose (inside the other ASAs), also connected to our core. On the PIX, there is a default route on both the outside and inside interfaces thusly: utc-pix# sho route | i 0.0.0.0 outside 0.0.0.0 0.0.0.0 aaa.bbb.ccc.246 1 OTHER static inside 0.0.0.0 0.0.0.0 aaa.bbb.ccc.20 10 OTHER static Anything connecting to the VPN (or otherwise hitting the outside interface) follows the outside route. Any VPN-originated traffic on the full tunnel follows the inside route. The ASA is not behaving this way... it wants to always follow the outside route for the VPN-originated full-tunnel traffic if I include both routes (with unequal weights, as it doesn't allow them to be the same). If I define an explicit outside route to where I VPN from, and remove the default outside route, it works perfectly. Is there something obvious I'm missing here to make it behave like the PIX does? Try the keyword 'tunneled' at the end of the route statement. -ryan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA 8.3 full-tunnel VPN paradox...
On 6/29/2011 4:45 PM, Ryan West wrote: Try the keyword 'tunneled' at the end of the route statement. -ryan Oh!! Schweeet!! That's the ticket... Thanks so much, I've wasted the better part of the day trying workarounds :) 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] 6500 CoPP + IPv6 fragments
Grzegorz Janoszka grzeg...@janoszka.pl wrote: Richard Gallagher's suggestion about CSCsa78144 was really helpful in our case and helped. Thanks! FWIW, platform ipv6 acl fragment hardware forward fixed the drop for me as well. But I still cannot see why it dropped before, since CoPP was not dropping a single packet according to show policy-map control-plane. Or is enabling CoPP somehow changing the default to drop? Bernhard ___ 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] 6500 CoPP + IPv6 fragments
On 29-06-11 23:08, Bernhard Schmidt wrote: FWIW, platform ipv6 acl fragment hardware forward fixed the drop for me as well. But I still cannot see why it dropped before, since CoPP was not dropping a single packet according to show policy-map control-plane. According to Wikipedia there can be no fragmented packets on IPv6. So what is the whole issue about? What can be the source of v6 fragments? Can they be safely dropped? -- Grzegorz Janoszka ___ 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] 6500 CoPP + IPv6 fragments
Grzegorz Janoszka grzeg...@janoszka.pl wrote: Hi, On 29-06-11 23:08, Bernhard Schmidt wrote: FWIW, platform ipv6 acl fragment hardware forward fixed the drop for me as well. But I still cannot see why it dropped before, since CoPP was not dropping a single packet according to show policy-map control-plane. According to Wikipedia there can be no fragmented packets on IPv6. So what is the whole issue about? What can be the source of v6 fragments? Can they be safely dropped? You either misunderstood the Wikipedia article or it is wrong (haven't checked). There is no in-transit fragmentation in routers in IPv6. Which basically means the DF-bit is implicitly set and path-mtu-discovery is mandatory. If the packet is too big, the router will return an ICMP error message and the sending host may fragment the packet. If your network drops it, you might get into trouble. For example see my case about DNSSEC, DNS answers regularly get 1500 bytes with DNSSEC. The difference here is, in IPv4 the load issue is actually fragmenting the packet, in IPv6 there is apparently some shortcoming in PFC3B and ACL checking on already fragmented packets. Bernhard ___ 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] Transport PVCs using pseudowire?
On Wed, Jun 29, 2011 at 7:16 PM, Jay Hennigan j...@west.net wrote: What is your transport to that ISP? If ethernet, VLANs would be the most logical choice. If a serial link such as a DS3, you could use frame-relay encapsulation and a PVC per customer. hi jay, yes, transport to ISP is ethernet. actually I couldn't get the VLANs choice. maybe you can elaborate a little bit more on it or point out some url for me? thank you so much -- antonio ___ 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] IOS-XR and MRTG interface counters not working
Hello, Has anyone had problems getting MRTG to pull counters from a 12410XR? We have it configured to poll interface counters and while the Gig interfaces have 80-100Mbps on them at all times, yet MRTG shows between 5.9bps and 7.2bps. Have not seen this on any of our IOS gear, so wondering if there is something different that has to be setup besides the snmp community to get this data. We are running XR version 4.0.1. Thanks, Lee. ___ 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] Fwd: IOS-XR and MRTG interface counters not working (SOLVED)
Actually, it looks like the tech I had setup the mrtg config for this particular router had used the IP of one of the gig interfaces instead of the loopback interface. Changing it to use the loopback interface IP has it polling the correct data. It was running 64bit counters, but was just getting some bogus counters data using the interface IP. While I'm not sure why it would get the bogus counter data using that IP, it should have using the loopback IP in the first place. Anyway, thank you everyone who replied. -Lee -- Forwarded message -- From: jkre...@usinternet.com Date: Wed, Jun 29, 2011 at 8:30 PM Subject: Re: [c-nsp] IOS-XR and MRTG interface counters not working To: Lee Starnes lee.t.star...@gmail.com What snmp version is mrtg using to poll your router? When near 100 megs or above you need to use at least snmp v2c or later and the 64 bit counters aka HC counters. --Original Message-- From: Lee Starnes Sender: cisco-nsp-boun...@puck.nether.net To: cisco-nsp Subject: [c-nsp] IOS-XR and MRTG interface counters not working Sent: Jun 29, 2011 9:45 PM Hello, Has anyone had problems getting MRTG to pull counters from a 12410XR? We have it configured to poll interface counters and while the Gig interfaces have 80-100Mbps on them at all times, yet MRTG shows between 5.9bps and 7.2bps. Have not seen this on any of our IOS gear, so wondering if there is something different that has to be setup besides the snmp community to get this data. We are running XR version 4.0.1. Thanks, Lee. ___ 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/ Sent via BlackBerry from T-Mobile ___ 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/
