Re: [c-nsp] IPv6 on C3550, finally? (12.2(44)SE)
On Fri Feb 01, 2008 at 08:56:59AM +0100, [EMAIL PROTECTED] wrote: And what's the point, anyway? As far as I know the 3550 *hardware* can't do IPv6 routing. As long as you're talking about *software* IPv6 routing, a suitable 2800 router would probably give you better performance... The point is that I've got a whole load of 3550's providing customer-edge for colo'd servers, and customers are starting to ask for IPv6. Given the volume of IPv6 traffic I'll see in the short term, I'm happy enough with process switched. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director|* Domain Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: [EMAIL PROTECTED] * ___ 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] IPv6 on C3550, finally? (12.2(44)SE)
On (2008-02-01 08:56 +0100), [EMAIL PROTECTED] wrote: And what's the point, anyway? As far as I know the 3550 *hardware* can't do IPv6 routing. As long as you're talking about *software* IPv6 routing, a suitable 2800 router would probably give you better performance... I'd never plan to route IPv6 in 3550, MGMT via IPv6 on the other hand might be interesting in foreseeable future. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP - Older routes?
Hello list, I have a BGP router with 2 eBGP peers (upstreams). This morning one of the two upstreams (say A) had a scheduled maintenance, and most of the outgoing traffic went to B. But when A came back up 4 hours longer, outgoing traffic mostly kept going through B, and traffic towards A did not reach back its previous level. As a consequence, there currently is now too much traffic going to B (given the current CDR). I have no reason to believe that A has made any configuration change; so I believe this behaviour is due to older route first criterium of the BGP route selection algorithm (as described in step 10 of http://www.cisco.com/warp/public/459/25.shtml). Does that sound like a reasonable? How do I check this is indeed the cause? If it is, would a soft in clear be enough to fix the problem? Vincent ___ 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] ARP flooding prevention
Hi Michel, Using CoPP protects the RP, i.e. traffic that the PFC decides has to be punted to the MSFC. Here's a simplified and somewhat wrong picture of how the forwarding paths work: Interfaces RP Gi4/1 --\ +-+ CoPP +--+ Gi4/2 ---+--| PFC |--| MSFC | GE3/1/2 / +-+ +--+ Decisions about hardware forwarding, made by the PFC, never reaches the MSFC. If the PFC cannot decide how to forward it though, it sends the packets along the control-plane to the MSFC. (This is not entirely correct terminology, but it should be okay for this purpose.) This punting, as it's called, is what can be policed with CoPP. Things like ARP lookup, routing protocol traffic, ICMP packets to the RP (e.g. pinging an interface address), VTY access, logging, non hardware assisted tunnels and so on are all examples of things the PFC can't handle by itself and has to have the MSFC do. It's the PFC doing the CoPP, so it's done in hardware and what is policed does not stress the RP of course. Regarding your question: Yes, the PFC can also do policing per interface. You can create policies similar to the CoPP policies and attach them to the interfaces. You can of course also use simple access-lists if you just want to block something specific. Most of the things you can do in service policies are done in hardware, but beware that some types of policies (e.g. weird policy based routing or other things that won't fit in the TCAM) results in more punting and thus just make things worse. You can read more about Sup720 QoS Policing with interface examples and much more here: http://www.cisco.com/en/US/customer/products/hw/switches/ps700/products_ tech_note09186a00801c8c4b.shtml http://tinyurl.com/c8el4 Regards, Peter On Fri, 2008-02-01 at 13:49 +0100, Michel Renfer wrote: Ok, thanks all for feedback. It seems that the configurations are always generic for the whole router. It is possible to add limiting only for a specific interfaces? cheers, michel -Original Message- From: Peter Rathlev [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 1:05 PM To: Michel Renfer Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP flooding prevention Agreed, CoPP with a service-policy and maybe also using the mls rate-limit unicast cef glean pps and so on. Just remember that to limit these things is to limit the services that the supervisor is meant to deliver. You can easily put yourself in a situation where the DoS scenario becomes a problem earlier because of your rate-limiting, and then it's irrelevant that your supervisor is only at 50% cpu. Look at this for CoPP for Sup720: http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1838/product s_feature_guide09186a008052446b.html http://tinyurl.com/9sutt And for MLS rate-limiting for Sup720: http://www.cisco.com/en/US/customer/prod/collateral/switches/ps5718/ps7 08/prod_white_paper0900aecd802ca5d6.html http://tinyurl.com/297d48 ___ 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] Filtering packets by content
Konstantin Barinov wrote on Friday, February 01, 2008 2:48 PM: Hello! Which platform will be able to filter more than 2 Gbit/sec bandwidth by packet contents? For example, I need to drop all outgoing http and udp according to some rules. Sup32-PISA can only do up to 2Gbps. What is the next step, load balance between them only? I don't know the platform, but SCE 2000 (up to 4Gbps) seems like the next step if PISA is not powerful enough. Depending on your application, load-sharing over multiple PISA's could be an option as well, as you've already indicated. 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/
Re: [c-nsp] Spanning-Tree question
Though you using 2 different VTP domains/VLAN databases, are the VLANs per business unit at least unique so the VLAN databases don't have overlapping VLANs? What's the purpose of interconnecting the 4 switches? What are the connections between the 4 switches? access port (same vlan on each side or every switch)? trunk? L3? -- Tom Sands Chief Network Engineer Rackspace (210)312-4391 -- Aaron R wrote: Hi Guys, Ive got a problem that I am hoping someone can have a look at. I currently have four 3750's. Two belonging to one business unit and two belonging to another. Each group of switches is running a separate VTP domain / VLAN database. I am running PVST however when I connect the final link between the four switches there is a loop and spanning tree doesn't block any of the ports. Would anyone have any clue as to why this would be happening? Could it have something to do with the link between the Business units being on separate VLANs? We don't want the possibility of VLAN corruption occurring hence the different VTP domains. Currently I am shutting down one of the uplink ports to Business A to remedy this problem. Please see the diagram below. Cheers, | 3750 Switch 1 |--- Trunk -- | 3750 Switch 2 | | Business A || Business A | -- | VL 50 | VL 50 | | | VL 100 |VL 100 | 3750 Switch 3 |--- Trunk -- | 3750 Switch 4 | | Business B || Business B | -- Aaron. ___ 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/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at [EMAIL PROTECTED], and delete the original message. Your cooperation is appreciated. ___ 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] Nexus 7000
I am interested in this feature, also, so asking around I've heard something about VSS in NX-OS 4.1, maybe in the summer (?!?) - On Thursday 31 January 2008 15:53:54 Tim Durack wrote: No mention of VSS after they've been talking it up recently. Nice if they can make it all work reliably. Tim: ___ 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] IPv6 on C3550, finally? (12.2(44)SE)
On Fri, 1 Feb 2008, Saku Ytti wrote: On (2008-02-01 08:56 +0100), [EMAIL PROTECTED] wrote: And what's the point, anyway? As far as I know the 3550 *hardware* can't do IPv6 routing. As long as you're talking about *software* IPv6 routing, a suitable 2800 router would probably give you better performance... I'd never plan to route IPv6 in 3550, MGMT via IPv6 on the other hand might be interesting in foreseeable future. Alternaively you could choose 3560 or 3750 series (not ME) that is capable for IPv6 routing in a limited way. No BGP IPv6 support... When I asked about the IPv6 BGP support plan - no plan currently. This is very bad :( Regards, Janos ___ 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] ARP flooding prevention
Ok, thanks all for feedback. It seems that the configurations are always generic for the whole router. It is possible to add limiting only for a specific interfaces? cheers, michel -Original Message- From: Peter Rathlev [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 1:05 PM To: Michel Renfer Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP flooding prevention Agreed, CoPP with a service-policy and maybe also using the mls rate-limit unicast cef glean pps and so on. Just remember that to limit these things is to limit the services that the supervisor is meant to deliver. You can easily put yourself in a situation where the DoS scenario becomes a problem earlier because of your rate-limiting, and then it's irrelevant that your supervisor is only at 50% cpu. Look at this for CoPP for Sup720: http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1838/product s_feature_guide09186a008052446b.html http://tinyurl.com/9sutt And for MLS rate-limiting for Sup720: http://www.cisco.com/en/US/customer/prod/collateral/switches/ps5718/ps7 08/prod_white_paper0900aecd802ca5d6.html http://tinyurl.com/297d48 ___ 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] IPv6 on C3550, finally? (12.2(44)SE)
Yeah, that's what I was thinking too. We use these for layer 2 everywhere. Being a US govt network, we're required to have IPv6 support on those as well. V6 management is all we really need on 3550. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Saku Ytti Sent: Friday, February 01, 2008 8:15 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IPv6 on C3550, finally? (12.2(44)SE) On (2008-02-01 08:56 +0100), [EMAIL PROTECTED] wrote: And what's the point, anyway? As far as I know the 3550 *hardware* can't do IPv6 routing. As long as you're talking about *software* IPv6 routing, a suitable 2800 router would probably give you better performance... I'd never plan to route IPv6 in 3550, MGMT via IPv6 on the other hand might be interesting in foreseeable future. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Spanning-Tree question
Separate VLANs (not overlapping) The four switches are connected for redundancy purposes. Business unit A has resources upstream that business unit B must be able to access (but still needs to remain separate administratively) As the shabby diagram depicts, each business unit switch is trunked together to share vlan info but the links between business unit switches are access links in separate vlans. The problem I believe im facing here is the fact that portfast was enabled (bad mistake) and causing the ports to forward straight away and not listen to bpdu's in order to block one of the links. Cheers, Aaron. -Original Message- From: Tom Sands [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 9:36 PM To: Aaron R Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Spanning-Tree question Though you using 2 different VTP domains/VLAN databases, are the VLANs per business unit at least unique so the VLAN databases don't have overlapping VLANs? What's the purpose of interconnecting the 4 switches? What are the connections between the 4 switches? access port (same vlan on each side or every switch)? trunk? L3? -- Tom Sands Chief Network Engineer Rackspace (210)312-4391 -- Aaron R wrote: Hi Guys, Ive got a problem that I am hoping someone can have a look at. I currently have four 3750's. Two belonging to one business unit and two belonging to another. Each group of switches is running a separate VTP domain / VLAN database. I am running PVST however when I connect the final link between the four switches there is a loop and spanning tree doesn't block any of the ports. Would anyone have any clue as to why this would be happening? Could it have something to do with the link between the Business units being on separate VLANs? We don't want the possibility of VLAN corruption occurring hence the different VTP domains. Currently I am shutting down one of the uplink ports to Business A to remedy this problem. Please see the diagram below. Cheers, | 3750 Switch 1 |--- Trunk -- | 3750 Switch 2 | | Business A || Business A | -- | VL 50 | VL 50 | | | VL 100 |VL 100 | 3750 Switch 3 |--- Trunk -- | 3750 Switch 4 | | Business B || Business B | -- Aaron. ___ 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/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at [EMAIL PROTECTED], and delete the original message. Your cooperation is appreciated. ___ 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] Filtering packets by content
Hello! Which platform will be able to filter more than 2 Gbit/sec bandwidth by packet contents? For example, I need to drop all outgoing http and udp according to some rules. Sup32-PISA can only do up to 2Gbps. What is the next step, load balance between them only? br -- Konstantin Barinov INFONET AS, Tallinn, Estonia ___ 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] Check out my Facebook profile
I set up a Facebook profile with my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Junaid Here's the link: http://www.facebook.com/p.php?i=1011954991k=SYG5ZZPYWXTBZ1CCXJXTrv=2 ___ This e-mail may contain promotional materials. If you do not wish to receive future commercial mailings from Facebook, please click on the link below. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. http://www.facebook.com/o.php?u=552739878k=df6634 ___ 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] 2611XM throughput
Thanks for the responses I received on and off list to this post. Consensus is: 2611XM will not do 10Mbps or above. I'll look into a 18xx or 28xx upgrade. Thanks! Adam - Original Message - From: Justin Shore [EMAIL PROTECTED] To: Adam Greene [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Tuesday, January 29, 2008 8:09 PM Subject: Re: [c-nsp] 2611XM throughput Adam, I had an identically configured 2611XM in service a couple years ago. The CPU maintained 70-90% during peak times. At the time that was with about 8Mbps passing through it. One night when the router reached just under 10Mbps the CPU pegged at 100% (usually I only see Cisco IOS devices report 99% but this one said 100%) and fell off the network (I'm assuming that OSPF timed out). The ensuing flood of packets from behind the router (cable modem network with about 400 users) easily exceeded the pps of the router and kept the CPU pegged generating ICMP Destination Unreachables. Even consoling into the poor thing was pointless as it took a couple minutes to output a single character to the CLI. It had 2 ACLs of about 40 lines combined and was running OSPF with one neighbor (50 routes). I had a replacement 2821 overnighted to me the next day and I replaced the 2611XM that night. The performance difference was very noticeable, even with the same approximate throughput. The 2611XM introduced significant delay. IMHO the 10Mbps ceiling is absolute if not exceedingly generous. The 2611XM is good as a CE with a couple T1s. Beyond that toss it on your pile of 2500s and go buy an ISR. Justin Adam Greene wrote: Hi, I'm trying to determine what kind of throughput we can expect from a 2611XM currently in production (IOS 12.3(24), 128MB RAM). The router is doing eBGP to two peers but only advertises one network and receives default routes only. Other than that it's plain vanilla. Cisco's router performance guide rates this router at 10.24Mbps (is that one direction at a time or bidirectional, I wonder) with an avg packet size of 64bytes. Judging from the # of packets and the # of bytes transferred on the unit's WAN interface, I'm calculating average packet size at about 154bytes per packet. Based on these specs, would it be realistic to expect the router could push about 25Mbps aggregate (for example, 12.50Mbps in both directions simultaneously)? Thanks for your insight. ___ 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] Filtering packets by content
Hi, If you just need L4 access-lists, like blocking all port 80/tcp traffic and not all HTTP (which could use another port and thus needs a more thorough examination of the flows), you can use regular hardware based access-lists on a Sup720/PFC3 and all will be well. If you need inspection (like the PISA gives you) Oliver's options seem like the way to go. Regards, Peter On Fri, 2008-02-01 at 15:47 +0200, Konstantin Barinov wrote: Hello! Which platform will be able to filter more than 2 Gbit/sec bandwidth by packet contents? For example, I need to drop all outgoing http and udp according to some rules. Sup32-PISA can only do up to 2Gbps. What is the next step, load balance between them only? br -- Konstantin Barinov INFONET AS, Tallinn, Estonia ___ 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] 3750ME L2/MPLS combined scenario
We've tried that with 3750ME, and the half a million bugs and
architectural flaws made us drop that line of devices out of MPLS
altogether. Keeping the PW with L2 on 3750ME will make your customer
happier.
I don't know yet the price point and MPLS FCS for Juniper EX, but if
it's really cheaper than ME6524, it may be a good alternative.
Rubens
On Feb 1, 2008 8:43 AM, Tomas Daniska [EMAIL PROTECTED] wrote:
Hi team
does anyone run 3750MEs in combined L2/MPLS setup? We are considering
various designs for a customer at the moment, they are rebuilding their
MPLS network from scratch to support both L2 and L3 MPLS services.
Having 7600/ES20 as N-PE, and 3750ME based L2 access rings, L3 services
(IPv4, IPv6, IPv4 multicast) will be terminated at the 7600. But - for
plain Ethernet pseudowire services at least - we are considering running
MPLS up to the 3750MEs and providing the PW service from those boxes.
This means running MPLS over a VLAN and terminating it on SVI, ('no
switchport' is not possible in access as we need L2 Ethernet
access/aggregation to transport other services to the 7600). The access
topologies are always rings with REP based redundancy.
I'd appreciate any real-life experience with such setup.
thanks much
--
Tomas Daniska
systems engineer
Soitron, a.s.
Plynarenska 5, 829 75 Bratislava, Slovakia
tel: +421 2 58224111, fax: +421 2 58224199
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.
___
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] BGP - Older routes?
Guten Tag Vincent De Keyzer, am Freitag, 1. Februar 2008 um 16:22 schrieben Sie: Hello list, I have a BGP router with 2 eBGP peers (upstreams). This morning one of the two upstreams (say A) had a scheduled maintenance, and most of the outgoing traffic went to B. But when A came back up 4 hours longer, outgoing traffic mostly kept going through B, and traffic towards A did not reach back its previous level. As a consequence, there currently is now too much traffic going to B (given the current CDR). try to use local-prefs for it. For example: route-map PREFFERED permit 1 set local-preference 501 neighbor xxx remote-as neighbor xxx description GHOSTnet-PEER-KL neighbor xxx next-hop-self neighbor xxx route-map in PREFFERED Note: Its not a quagga config maybe u have to use neighbor xxx route-map PREFFERED in give it a try -- Mit freundlichen Grüßen Daniel mailto:[EMAIL PROTECTED] ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF router gets separated from a broadcast domain
Peter Rathlev wrote: That makes sense. But our experience in a real life scenario is that the partitioning of OSPF speaking transport network creates the blackhole as well. I will try to build this in the lab. May the root cause of the blackhole wasn't the network separation, but something else... If you only use these networks as OSPF transport networks, it's not a big problem if they're black holed. Since they're not destinations, neither clients nor servers ever see them in anything but a trace. But not only the transport network itself get blackholed, but all the networks which are reachable through it. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Line Code Violations on DS3
On Wed, 30 Jan 2008, Nick Voth wrote: Try putting a 12 db attenuator on the transmit portion, then re-try your loopback. We've found that the PA-MC-T3 cards tend to overdrive the DS3 a bit, and the only way that we've been able to get rid of the errors is attenuating the transmit load. Interesting, you're saying to put an attenuator on the transmit portion of the card. Some of the Cisco documentation is saying to put it on the receive portion. Is there any way using the show controller output to tell which one has the hot signal? He meant on the PA's receive (the telco's transmit). PA-MC-T3s are somewhat notorious for being sensitive to overly hot signals...where cisco's definition of 'overly hot' is 'normal' to several other vendors. In a pinch, if you can't find a suitable attenuator, you can use a really long service loop and/or multiple DS3 cables connected together using barrel connectors. We have at least one installation where after switching from a CAC Widebank28 to an Adtran mux, we ended up needing a coiled up 50' service loop sitting on top of the mux to keep the PA-MC-T3 happy. -- 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] IPv6 on C3550, finally? (12.2(44)SE)
On (2008-02-01 14:40 +0100), Mohacsi Janos wrote: Alternaively you could choose 3560 or 3750 series (not ME) that is capable for IPv6 routing in a limited way. No BGP IPv6 support... When I asked about the IPv6 BGP support plan - no plan currently. This is very bad :( Yes, I've been running IPv6 in them since day 1. However, replacing working 3550 to 3560 just to get IPv6 MGMT typically isn't viable option. Knowing that lot of people still happily use XL switches, we'll probably see 3550's as pure switches in many years to come, when perhaps majority of your network has been migrated to IPv6. I fear we're going to have 'telnet/ssh issue' all over again, replacing fully functioning boxes just to comply with mgmt requirements. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] bridging two eth for ip flow
Hello, I have a 2621 lying around that I would like to use as a transparent bridge and enable ip flow exports on. So the basic idea is to bridge the two ethernet interfaces, then put the device inline with a network. Can this be done? Thanks, Dan ___ 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] IPv6 on C3550, finally? (12.2(44)SE)
Actually you might be pleasantly surprised with an IPv6 attack on a 3550 - I suspect the IPv4 traffic would just keep on truckin', less any routing updates that might arrive during the event. I had a customer with about 14k public IP addresses passing through a 3550. The machine was crazy stressed and the management engine was crashing several times a day - management would report it down for the duration of a reboot, but traffic otherwise kept moving. The processor seems to instruct the ASICs to forward as needed, then it sits quietly ... On Feb 1, 2008 3:07 AM, Richard A Steenbergen [EMAIL PROTECTED] wrote: On Fri, Feb 01, 2008 at 08:00:41AM +, Simon Lockhart wrote: On Fri Feb 01, 2008 at 08:56:59AM +0100, [EMAIL PROTECTED] wrote: And what's the point, anyway? As far as I know the 3550 *hardware* can't do IPv6 routing. As long as you're talking about *software* IPv6 routing, a suitable 2800 router would probably give you better performance... The point is that I've got a whole load of 3550's providing customer-edge for colo'd servers, and customers are starting to ask for IPv6. Given the volume of IPv6 traffic I'll see in the short term, I'm happy enough with process switched. Yes but I wonder how much the v4 customers on that switch will appreciate it the day someone gets a DoS or even tries to do an FTP over IPv6. :) FastE is more than enough to do in a 3550 CPU. Then again it's a lot easier than moving the v6 requesters to 3560s, and besides doing dual-stack on 3560s does bad things to your available v4 TCAM. Some things you just can't win. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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/ -- mailto:[EMAIL PROTECTED] // GoogleTalk: [EMAIL PROTECTED] IM: nealrauhauser ___ 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] IPv6 on C3550, finally? (12.2(44)SE)
Simon Lockhart wrote: Noticed that 12.2(44)SE was recently released for the Cat3550 switch, and feature navigator lists a whole load of IPv6 support. Yay! However, it doesn't seem to work very well... interface Loopback0 no ip address ipv6 address 2001:4B10::100/128 ipv6 enable end lab-sw.rbsov#ping 2001:4b10::100 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:4B10::100, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/2/4 ms However, if I try to do IPv6 over an ethernet port, it's less successful... interface Vlan515 no ip address ipv6 address 2001:4B10:0:2::2/64 ipv6 enable end lab-sw.rbsov#ping 2001:4b10:0:2::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:4B10:0:2::1, timeout is 2 seconds: . Success rate is 0 percent (0/5) Running debug ipv6 packet on both ends of the link shows packets being sent by lab-sw, and replies being sent by the upstream switch (a 3560), but the 3550 never learns any neighbours, and pings don't work... lab-sw.rbsov#show ipv6 nei lab-sw.rbsov# Have I missed something needed to make this work, or is it just a work in progress, released prematurely? Simon Can you do a tcp dump/wireshark for ether proto 0x86dd and see whether neigh discoveries are happening? Atleast in my network, when I ping 3750 with unicast routing enabled and ipv6 nd enabled, from within a VLAN I see neigh solicitation and neighbor discovery happening followed by echo req and echo reply. When you do show ipv6 nei and nothing is happening, I believe neighbor discovery has not happened for some unknown reason The following may be relevant to you or may not be, but this is what I am seeing command(s) used: sudo tcpdump -ennNSXxv -s 1518 -i pcn0 ether proto 0x86dd $ ping6 fdc2:c2cd:d343:39a6:21c:fff:fea6:6348 PING6(56=40+8+8 bytes) fdc2:c2cd:d343:39a6:20c:29ff:fe20:b1ff -- fdc2:c2cd:d343:39a6:21c:fff:fea6:6348 16 bytes from fdc2:c2cd:d343:39a6:21c:fff:fea6:6348, icmp_seq=0 hlim=64 time=3.565 ms 16 bytes from fdc2:c2cd:d343:39a6:21c:fff:fea6:6348, icmp_seq=1 hlim=64 time=1.056 ms ^C --- fdc2:c2cd:d343:39a6:21c:fff:fea6:6348 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.056/2.310/3.565/1.255 ms 10:14:10.752467 00:0c:29:20:b1:ff 33:33:ff:a6:63:48 86dd 86: fdc2:c2cd:d343:39a6:20c:29ff:fe20:b1ff ff02::1:ffa6:6348: icmp6: neighbor sol: who has fdc2:c2cd:d343:39a6:21c:fff:fea6:6348(src lladdr: 00:0c:29:20:b1:ff) (len 32, hlim 255) : 6000 0020 3aff fdc2 c2cd d343 39a6 ` :ÿýÂÂÍÓC9¦ 0010: 020c 29ff fe20 b1ff ff02 ..)ÿþ ±ÿÿ... 0020: 0001 ffa6 6348 8700 4f59 ÿ¦cH..OY 0030: fdc2 c2cd d343 39a6 021c 0fff fea6 6348 ýÂÂÍÓC9¦...ÿþ¦cH 0040: 0101 000c 2920 b1ff ) ±ÿ 10:14:10.752504 00:1c:0f:a6:63:48 00:0c:29:20:b1:ff 86dd 86: fdc2:c2cd:d343:39a6:21c:fff:fea6:6348 fdc2:c2cd:d343:39a6:20c:29ff:fe20:b1ff: icmp6: neighbor adv: tgt is fdc2:c2cd:d343:39a6:21c:fff:fea6:6348(RSO)(tgt lladdr: 00:1c:0f:a6:63:48) [class 0xe0] (len 32, hlim 255) : 6e00 0020 3aff fdc2 c2cd d343 39a6 n :ÿýÂÂÍÓC9¦ 0010: 021c 0fff fea6 6348 fdc2 c2cd d343 39a6 ...ÿþ¦cHýÂÂÍÓC9¦ 0020: 020c 29ff fe20 b1ff 8800 f5e7 e000 ..)ÿþ ±ÿ..õçà... 0030: fdc2 c2cd d343 39a6 021c 0fff fea6 6348 ýÂÂÍÓC9¦...ÿþ¦cH 0040: 0201 001c 0fa6 6348 .¦cH 10:14:10.753431 00:0c:29:20:b1:ff 00:1c:0f:a6:63:48 86dd 70: fdc2:c2cd:d343:39a6:20c:29ff:fe20:b1ff fdc2:c2cd:d343:39a6:21c:fff:fea6:6348: icmp6: echo request (len 16, hlim 64) : 6000 0010 3a40 fdc2 c2cd d343 39a6 `.:@ýÂÂÍÓC9¦ 0010: 020c 29ff fe20 b1ff fdc2 c2cd d343 39a6 ..)ÿþ ±ÿýÂÂÍÓC9¦ 0020: 021c 0fff fea6 6348 8000 5833 1e9c ...ÿþ¦cH..X3 0030: 47a3 6172 000b 7499 G£ar..t. 10:14:10.753926 00:1c:0f:a6:63:48 00:0c:29:20:b1:ff 86dd 70: fdc2:c2cd:d343:39a6:21c:fff:fea6:6348 fdc2:c2cd:d343:39a6:20c:29ff:fe20:b1ff: icmp6: echo reply (len 16, hlim 64) : 6000 0010 3a40 fdc2 c2cd d343 39a6 `.:@ýÂÂÍÓC9¦ 0010: 021c 0fff fea6 6348 fdc2 c2cd d343 39a6 ...ÿþ¦cHýÂÂÍÓC9¦ 0020: 020c 29ff fe20 b1ff 8100 5733 1e9c ..)ÿþ ±ÿ..W3 0030: 47a3 6172 000b 7499 G£ar..t. 10:14:11.088588 00:1c:0f:a6:63:48 33:33:00:00:00:05 86dd 90: fe80::21c:fff:fea6:6348 ff02::5: OSPFv3-hello 36: rtrid 10.57.127.2 backbone V6/E/R ifid 0.0.8.186 pri 1 int 10 dead 40 dr 10.57.127.2 nbrs [class 0xe0] [hlim 1] (len 36) : 6e00 0024 5901 fe80 n$Y.þ... 0010: 021c 0fff fea6 6348 ff02 ...ÿþ¦cHÿ... 0020: 0005 0301 0024 0a39 7f02 ...$.9.. 0030: 6e54 08ba 0100 0013 nT.º 0040: 000a 0028 0a39 7f02 ...(.9.. 10:14:11.760100
Re: [c-nsp] Line Code Violations on DS3
Try putting a 12 db attenuator on the transmit portion, then re-try your loopback. We've found that the PA-MC-T3 cards tend to overdrive the DS3 a bit, and the only way that we've been able to get rid of the errors is attenuating the transmit load. Interesting, you're saying to put an attenuator on the transmit portion of the card. Some of the Cisco documentation is saying to put it on the receive portion. Is there any way using the show controller output to tell which one has the hot signal? He meant on the PA's receive (the telco's transmit). PA-MC-T3s are somewhat notorious for being sensitive to overly hot signals...where cisco's definition of 'overly hot' is 'normal' to several other vendors. In a pinch, if you can't find a suitable attenuator, you can use a really long service loop and/or multiple DS3 cables connected together using barrel connectors. We have at least one installation where after switching from a CAC Widebank28 to an Adtran mux, we ended up needing a coiled up 50' service loop sitting on top of the mux to keep the PA-MC-T3 happy. Jon, yes.. thank you .. that was exactly what I was getting at.. We, too, have several DS3's w/ 75 feet of coiled up cable sitting in the bottom of a cabinet to get the Adtran MX-2800s and the PA-MC-CT3's to play nice together. I know that to most people that sounds counter intuitive, but keep in mind the signals were meant to be driven over much longer distances than the typical 6 foot Patch Panel to CPE that exists in lots of data center installations. ___ 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] bridging two eth for ip flow
Dan Letkeman wrote: Hello, I have a 2621 lying around that I would like to use as a transparent bridge and enable ip flow exports on. So the basic idea is to bridge the two ethernet interfaces, then put the device inline with a network. Can this be done? Thanks, Dan ___ 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/ I think this can be done using BVI interface if my memory serves right. I had to configure a 2800 series router for the same, too bad I dont have the configs. Hope this helps! Prabhu - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPF router gets separated from a broadcast domain
On Fri, 2008-02-01 at 18:04 +0100, Gabor Ivanszky wrote: Peter Rathlev wrote: If you only use these networks as OSPF transport networks, it's not a big problem if they're black holed. Since they're not destinations, neither clients nor servers ever see them in anything but a trace. But not only the transport network itself get blackholed, but all the networks which are reachable through it. If it's just a transport network, OSPF should take care of this. When the Dead Interval expires, it will think of the neighbor as down and invalidate all routes learned from it. Only the still connected network is left and announced, but since there are no other OSPF routers on that segment (seen from each of the two) no paths are learned through this segment. If you don't want to wait for a long Dead Interval to expire, you can use BFD or OSPF Fast Hellos. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP - Older routes?
Vincent De Keyzer wrote on Friday, February 01, 2008 4:22 PM: Hello list, I have a BGP router with 2 eBGP peers (upstreams). This morning one of the two upstreams (say A) had a scheduled maintenance, and most of the outgoing traffic went to B. But when A came back up 4 hours longer, outgoing traffic mostly kept going through B, and traffic towards A did not reach back its previous level. As a consequence, there currently is now too much traffic going to B (given the current CDR). I have no reason to believe that A has made any configuration change; so I believe this behaviour is due to older route first criterium of the BGP route selection algorithm (as described in step 10 of http://www.cisco.com/warp/public/459/25.shtml). Does that sound like a reasonable? How do I check this is indeed the cause? If it is, would a soft in clear be enough to fix the problem? It does sound like the likely cause, you can paste a show ip bgp prefix for one of the prefixes to make sure all decision steps up to #10 return equal. Not sure if a soft in would help, maybe a route-refresh (clear ip bgp ... in) will. If you require a deterministic decision, enable bgp best path compare-routerid (as mentioned in the doc you've quoted).. 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/
Re: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN
Hi Jeff, I still did not have opportunity to test it over L3. However, I tested it over L2 VPNs. The result was pretty good, specially when using the more complex algorithm available in the command ip multicast multipath Each IPTV program took a different interface when using the following: -Different sources and multicast group -Same source and different multicast group I believe the limitation advised in Cisco page were removed, or I am not using exactly the same PFC described in the restriction. Br, Alaerte -Original Message- From: ext Jeff Tantsura [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 11:25 AM To: Vidali Alaerte (NSN - BR/Rio de Janeiro) Subject: RE: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN Hi Alaerte, Would be interested in your test results. Thanks, Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: woensdag 23 januari 2008 12:29 To: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN Thanks Oli. I will test today on PFC3xx with SRB2 and post the result. Br, Alaerte -Original Message- From: ext Oliver Boehmer (oboehmer) [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:01 PM To: Vidali Alaerte (NSN - BR/Rio de Janeiro); cisco-nsp@puck.nether.net Subject: RE: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN [EMAIL PROTECTED] wrote on Tuesday, January 22, 2008 6:09 PM: Hi, PIM considers source of multicast to perform load splitting when the command ip multicast multipath is entered. When using multicast over L3 MPLS VPN, the source IP is the IP of PEx for any customer group connected to PEx. Any way to overcome this limitation and achieve load splitting of multicast over L3 MPLS VPN? For example, consider this scenario: Sender for group G1 and G2---CE1-PE1--P1-PE2CE2receiver of G1 and G2 | | |___P2__| The goal is having one G1 taking path PE1--P1--PE2 and G2 taking path PE1--P2--PE2. (but without using GRE encapsulation to have multicast encapsulated into unicast) 12.2SRB for the 7600 introduced ip multicast multipath s-g-hash basic which allows you to do the hash on source+group.. Platform support for this is still limited, not sure about your environment. 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/ ___ 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 - Older routes?
On Feb 1, 2008 9:22 AM, Vincent De Keyzer [EMAIL PROTECTED] wrote: Hello list, I have a BGP router with 2 eBGP peers (upstreams). This morning one of the two upstreams (say A) had a scheduled maintenance, and most of the outgoing traffic went to B. But when A came back up 4 hours longer, outgoing traffic mostly kept going through B, and traffic towards A did not reach back its previous level. As a consequence, there currently is now too much traffic going to B (given the current CDR). I have no reason to believe that A has made any configuration change; so I believe this behaviour is due to older route first criterium of the BGP route selection algorithm (as described in step 10 of http://www.cisco.com/warp/public/459/25.shtml). Does that sound like a reasonable? Yep, very much so. I've seen this before many times. If both your eBGP upstreams are of the same tier level, more than likely this is it. How do I check this is indeed the cause? show ip bgp nei x.x.x.x Check the remote router-id of both peers. Bet you a dollar the preferred route has a lower RID (assuming it's two different upstream provider AS's). If it is, would a soft in clear be enough to fix the problem? I believe you have to hard clear to have the BGP RIB re-learn that same prefix and rerun the path selection process. Even so, it'll still come back at the next peering flap, so that's not a good solution. You should probably set up policy for your learned routes to avoid this in the future. ___ 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] Line Code Violations on DS3
On 2/1/08, Gregory Boehnlein [EMAIL PROTECTED] wrote: Try putting a 12 db attenuator on the transmit portion, then re-try your loopback. We've found that the PA-MC-T3 cards tend to overdrive the DS3 a bit, and the only way that we've been able to get rid of the errors is attenuating the transmit load. Interesting, you're saying to put an attenuator on the transmit portion of the card. Some of the Cisco documentation is saying to put it on the receive portion. Is there any way using the show controller output to tell which one has the hot signal? He meant on the PA's receive (the telco's transmit). PA-MC-T3s are somewhat notorious for being sensitive to overly hot signals...where cisco's definition of 'overly hot' is 'normal' to several other vendors. In a pinch, if you can't find a suitable attenuator, you can use a really long service loop and/or multiple DS3 cables connected together using barrel connectors. We have at least one installation where after switching from a CAC Widebank28 to an Adtran mux, we ended up needing a coiled up 50' service loop sitting on top of the mux to keep the PA-MC-T3 happy. Jon, yes.. thank you .. that was exactly what I was getting at.. We, too, have several DS3's w/ 75 feet of coiled up cable sitting in the bottom of a cabinet to get the Adtran MX-2800s and the PA-MC-CT3's to play nice together. I know that to most people that sounds counter intuitive, but keep in mind the signals were meant to be driven over much longer distances than the typical 6 foot Patch Panel to CPE that exists in lots of data center installations. Ok this might sound weird but I LOVE YOU GUYS. We've been having this problem using an adtran mux. Line code violations and P-bit errors all over the place on only one end. I was just about to email the list when I thought I'd better search for this problem. I'm going to try the stuff suggested now. Thanks! Joseph ___ 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/
