Re: [c-nsp] Need advise on Cisco Switch/Fibre Connectivity
Hi Paul, Thanks for the advice! and yes, 3750's look like their a tad overkill. 2960's are just what i need. Need to ask somemore noob questions. Based on the product lit, i need to get a device with an SFP transceiver to plug in a fibre connector?. And SFP ports are included in switches that have dual-purpose uplinks? So my choices right now are: WS-C2960-24PC-L • 24 Ethernet 10/100 PoE ports and 2 dual-purpose uplinks • 1 RU fixed-configuration • LAN Base Image installed WS-C2960-24TC-L • 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active) • 1 RU fixed-configuration • LAN Base Image installed I'm terribly confused. Any help on this matter is much appreciated. Any site that actually deciphers these PC-L or TC-L or any of the cisco abbreviations? Paul Stewart wrote: Any special requirements for the switch? 3750 seems like a bit of overkill in my opinion but it depends on what you want the switch to do? If you're just looking for 24 ports 10/100 and a fiber uplink then a 2960 would work just as well for basic switch requirements... the SFP determines that kind of fiber connectors, and mode.. in this case single mode LX (1000BASE-LX) sounds like all you need for 5km especially http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/product_da ta_sheet0900aecd80322c0c.html Hope this helps... Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nimal David Sirimanne Sent: Tuesday, July 22, 2008 10:54 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Need advise on Cisco Switch/Fibre Connectivity Hi guys, Need some advise. I am looking to acquire some 24 port ethernet LAN switches that also have fibre connectors. The fibre connections are going to be long distance (apprx 5km ++) and single mode . I was looking at the cisco website, and think the Catalyst 3750 series might fit the need. The product data sheet says it supports the following connectors: 1000BASE-SX, -LX/LH, -ZX, and CWDM SFP-based ports: LC fiber connectors (single- mode, or multimode fiber) I believe we would need to order the switch toghether with these additional connectors? Am i right in this? Would this switch fit my basic needs for fibre connectivity? Thanks! Nimal ___ 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] QoS VLAN trunk Port
Hi Guys, I found out that the parameter set cos is only available for atm and frame relay interfaces. Does anyone knows, how to change the Cos values on a trunk interface ? Is that not possible ? I can't believe that no one had a similar issue. Hints are appreciated. Regards, Ahmad Sitz der NK Networks Services GmbH: Von-der-Wettern-Straße 15, 51149 Köln Registergericht: Amtsgericht Köln, Registernummer HRB 30805 Geschäftsführer: Tonis Rüsche ___ 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] REP (was: ME6524 alternative)
Hi, On Tue, Jul 22, 2008 at 06:14:46PM -0300, Rubens Kuhl Jr. wrote: I think such rings would be better served by using REP (Cisco) or EAPS(Extreme) You've made me curious, so I went and looked what REP is, hoping for great innovation - and I find myself somewhat disappointed, it seems to be something similar to RPVST or MST, just incompatible. Since it still disables a port (instead of using all links available in the network, using L2 SPF 'routing', like HP's mesh technology does), I can't see an immediate advantage of REP vs. RPVST or MST...? curious, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgpefVSoVeTi9.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] Need advise on Cisco Switch/Fibre Connectivity
Hi Nimal, On Wed, 2008-07-23 at 14:20 +0800, Nimal David Sirimanne wrote: Need to ask somemore noob questions. Based on the product lit, i need to get a device with an SFP transceiver to plug in a fibre connector?. And SFP ports are included in switches that have dual-purpose uplinks? So my choices right now are: WS-C2960-24PC-L • 24 Ethernet 10/100 PoE ports and 2 dual-purpose uplinks • 1 RU fixed-configuration • LAN Base Image installed WS-C2960-24TC-L • 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active) • 1 RU fixed-configuration • LAN Base Image installed I'm terribly confused. Any help on this matter is much appreciated. Any site that actually deciphers these PC-L or TC-L or any of the cisco abbreviations? The WS-C2960-24TC-L is a plain switch, whereas the WS-C2960-24PC-L has PoE ports (Power over Ethernet). It is the only difference bewteen these two switches. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] SVI or Subinterfaces?
Dear all We are ISP and have Catalyst 6513. And I want to terminate Trunks on it. Can someone tell me what is the better approach to achieve this. 1) using Subinterfaces on Trunk links. or 2) Using SVIs Which will provide more flexibility and scalability and what are the limitations of each method? Best Regards, Asad Ul-Islam ___ 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] combining multiple dsl lines
On Wed, Jul 23, 2008 at 5:18 AM, Ben Steele [EMAIL PROTECTED] wrote: Depends a lot on the adsl connections, are they ppp ? does the remote end support multilink? if so then multilink ppp is a good option providing all 4 lines are the same characteristics. Otherwise other options are cef load balancing, what type will depend on whether you are using NAT or not as you want to make sure the packet flow takes the right path, load balancing using the source/dest port algorithm works quite well though, probably wouldn't reccomend per packet over adsl. The route-map way is ok but wouldn't utilise the links as well as cef load balancing or ppp multlink could. Another option worth throwing in is the use of ip sla on your routes so as to remove them from the equation should one link go down, can also be done with the route-map using verify-availability on the next-hop option. Ben We have used cef per packet with great success on PPPoA DSL links here in the UK, we use radius to add/remove the extra routes when a connection bounces. The CPE is a linux box which is not running any NAT. Works for us Wayne ___ 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] SVI or Subinterfaces?
Hi Asad, On Wed, 2008-07-23 at 15:56 +0500, Asad Ul-Islam wrote: We are ISP and have Catalyst 6513. And I want to terminate Trunks on it. Can someone tell me what is the better approach to achieve this. 1) using Subinterfaces on Trunk links. or 2) Using SVIs Which will provide more flexibility and scalability and what are the limitations of each method? On LAN cards on the Catalyst 6500 platform there is no local VLAN significance, which means that with a subinterface definition like this: interface GigabitEthernet1/1.100 encapsulation dot1q 100 ! you can't use VLAN 100 anywhere else on the box. This also means that you cannot do local switching, i.e. using this VLAN on more than one physical port. You can't do this: interface GigabitEthernet1/1.100 description CPE A encapsulation dot1q 100 ! interface GigabitEthernet1/2.100 description CPE B encapsulation dot1q 100 ! You'd get a Command rejected: VLAN 100 not available when defining the second port. On the other hand, with LAN cards facing the core, you cannot use EoMPLS on SVIs, only on subinterfaces and physical ports. With the MUX-UNI feature (SXH and newer) you can combine regular switchport trunks and subinterfaces, using the latter for subinterface based EoMPLS. You cannot do any L3 termination on them though, they can only be used for EoMPLS. We use regular switchport trunks and SVIs everywhere and then of course make sure to limit VLANs to ports where they are relevant. (No open trunks.) We only use physical ports where we do EoMPLS. Hope this helps, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Changes to show policy-map interface
I was just looking at a router running a recent version of IOS and I noticed that the output of show policy-map int has changed quite a bit. Here is the output: Router# sho policy-map interface Serial0/0/0 Service-policy output: voip Class-map: VoIP (match-any) 1354294 packets, 93771165 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 102 1354294 packets, 93771165 bytes 5 minute rate 0 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 100 (kbps) Burst 2500 (Bytes) (pkts matched/bytes matched) 5717/457522 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 54794552 packets, 12108835008 bytes 5 minute offered rate 3000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/2728/0 It used to just show the output under Class-map: VoIP (match-any), but now it appers that there is a new section labeled Queueing where there is some new data that doesn't match the data above it. Any idea how the pkts matched under queueing relates to the packets under the VoIP class-map itself? They aren't even close to the same. ___ 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] REP
I think such rings would be better served by using REP (Cisco) or EAPS(Extreme) You've made me curious, so I went and looked what REP is, hoping for great innovation - and I find myself somewhat disappointed, it seems to be something similar to RPVST or MST, just incompatible. Since it still disables a port (instead of using all links available in the network, using L2 SPF 'routing', like HP's mesh technology does), I can't see an immediate advantage of REP vs. RPVST or MST...? The fact that REP and EAPS are explicitly *not* compatible with regular IEEE spanning tree is one of the great attractions of these protocols. This means that a customer who sends STP traffic into your network can *not* influence your ring topology/failover. Additionally, REP and EAPS are explicitly made for a ring architecture, and can therefore be made simpler and/or converge more rapidly. We have lots of EAPS rings. It works for us. We might be interested in using ME3400 with REP for the same type of rings if it had decent CAM size. Unfortunately, it doesn't - 8K MAC addresses is uncomfortably close to the number of MAC addresses we already have in many of our rings. Steinar Haug, Nethelp consulting, [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] REP
[EMAIL PROTECTED] wrote: The fact that REP and EAPS are explicitly *not* compatible with regular IEEE spanning tree is one of the great attractions of these protocols. This means that a customer who sends STP traffic into your network can *not* influence your ring topology/failover. Honestly this is a moot point anyway because only a mis-configured network would ever allow a customer to interact with the SP's STP. If a SP is dropping MetroE at the edge without bpdufilter enabled then something is seriously wrong. If the SP is doing L2VPN then dot1g-tunnel and L2PT take care of inhibiting interaction between the CE and PE with STP. Otherwise in all other cases the SP should explicitly enabled bpdufilter on all Ethernet CE-facing interfaces as part of the standard template that a SP deploys. Additionally, REP and EAPS are explicitly made for a ring architecture, and can therefore be made simpler and/or converge more rapidly. I have never seen the point in more STP-like protocols when you can configure 802.1w or 1s w/ 1w to converge just as quickly with uniform support on all platforms to boot. EAPS does not offer any benefits and in fact it offer serious limitations thanks to its infancy. Every vendor has interpreted RFC 3619 differently since it was published nearly 5 years ago. For example Pannaway supports EAPS but their implementation is limited to not allowing EAPS rings to cross VLANs. That's a serious design limitation. We have lots of EAPS rings. It works for us. We might be interested in using ME3400 with REP for the same type of rings if it had decent CAM size. Unfortunately, it doesn't - 8K MAC addresses is uncomfortably close to the number of MAC addresses we already have in many of our rings. Are you learning customer MACs for the service you're offering? That would be the case if you're simply transporting PtP VLANs. However if you're doing L2VPN or dot1q-tunnels then you shouldn't be learning MACs. Justin ___ 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] Changes to show policy-map interface
What code is it? On Wed, Jul 23, 2008 at 07:20:25AM -0500, Peder @ NetworkOblivion wrote: I was just looking at a router running a recent version of IOS and I noticed that the output of show policy-map int has changed quite a bit. Here is the output: Router# sho policy-map interface Serial0/0/0 Service-policy output: voip Class-map: VoIP (match-any) 1354294 packets, 93771165 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 102 1354294 packets, 93771165 bytes 5 minute rate 0 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 100 (kbps) Burst 2500 (Bytes) (pkts matched/bytes matched) 5717/457522 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 54794552 packets, 12108835008 bytes 5 minute offered rate 3000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/2728/0 It used to just show the output under Class-map: VoIP (match-any), but now it appers that there is a new section labeled Queueing where there is some new data that doesn't match the data above it. Any idea how the pkts matched under queueing relates to the packets under the VoIP class-map itself? They aren't even close to the same. ___ 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] Changes to show policy-map interface
It is 12.4.3 from Nov 2007. I guess it isn't really recent, but it is a 12.4 revision. Rodney Dunn wrote: What code is it? On Wed, Jul 23, 2008 at 07:20:25AM -0500, Peder @ NetworkOblivion wrote: I was just looking at a router running a recent version of IOS and I noticed that the output of show policy-map int has changed quite a bit. Here is the output: Router# sho policy-map interface Serial0/0/0 Service-policy output: voip Class-map: VoIP (match-any) 1354294 packets, 93771165 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 102 1354294 packets, 93771165 bytes 5 minute rate 0 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 100 (kbps) Burst 2500 (Bytes) (pkts matched/bytes matched) 5717/457522 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 54794552 packets, 12108835008 bytes 5 minute offered rate 3000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/2728/0 It used to just show the output under Class-map: VoIP (match-any), but now it appers that there is a new section labeled Queueing where there is some new data that doesn't match the data above it. Any idea how the pkts matched under queueing relates to the packets under the VoIP class-map itself? They aren't even close to the same. ___ 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] REP
list of points why STP shouldn't interact ...the key thing being should not, rather than will not. Using an entirely different protocol protects to a degree against human or machine error e.g. forgetting the bpduguard config. I have never seen the point in more STP-like protocols when you can configure 802.1w or 1s w/ 1w to converge just as quickly with uniform support on all platforms to boot. EAPS does not offer any benefits and in fact it offer serious limitations thanks to its infancy. Every vendor has interpreted RFC 3619 differently since it was published nearly 5 years ago. For example Pannaway supports EAPS but their implementation is limited to not allowing EAPS rings to cross VLANs. That's a serious design limitation. We've tuned metro rings for 100ms convergence. I've *never* seen STP come anywhere even close to that, and I frankly doubt it has the capability. 802.1s is (IMNSHO) a bad joke. There are topologies where it's not just worse than PVST, it's actively harmful. This would be significantly alleviated if: * Cisco could run 1 MST process * 802.1s had some way of versioning the config, as opposed to breaking the 802.1s domain into pieces every time you update the config (or mandating you decide on vlan-instance mappings on day 0 and never change it - yeah, right...) EAPS (and Foundry MRP) aren't universal solutions, but correctly applied they bring significant benefits in my experience. In addition, there are cases where might want STP to pass through a ring topology without being either tunnelled or blocked. We're running an architecture like that in our datacentre, where the two DC routers with ACE modules see: r1 -- p2p -- r1 | | \-- CLOUD --/ ...but the cloud is actually a ring of 5 (soon to be 6) Foundry switches, protected with an MRP ring. If you don't need such, then all fine and well, but other people do find uses for non-STP protocols, and vendors sell boxes on the back of that - so there is clearly market demand. Are you learning customer MACs for the service you're offering? That would be the case if you're simply transporting PtP VLANs. However if you're doing L2VPN or dot1q-tunnels then you shouldn't be learning MACs. When you say L2VPN, you mean point-to-point? What about multipoint e.g. VPLS? It's difficult to see how you could avoid MAC learning in a multipoint case. ...which is one reason I prefer L3VPNs, but there's a market for L2VPN. ___ 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] ME6524 alternative
Not to push this thread off topic, But we *hate* the Cisco model of the 'valueless' reseller. We deal with a Cisco rep, we deal with a Cisco SE, our discount is set by Cisco, we deal with Cisco's TAC - but when it's time to buy something, we get shuffled off to some twit that does absolutely nothing and makes a cut? It drives us nuts. It's confusing, and unnecessarily complicated. We'll never be able to get away from Cisco completely, but when possible this stupid crap drives us to the point we will do anything to avoid buying from Cisco, and look to their competitors. Rubens Kuhl Jr. wrote: Ouch. Are you dealing with a partner or Cisco Direct? There isn't any excuse for the price to go up, period. If you like I could hook you up with our Cisco Direct guys. If you got your order in this week you might be a decent discount simply because their fiscal year ends this month and the sales folks are hungry. Thru partner. Cisco insists to tell us that there is no Cisco Direct in our country, although I know there is and know some customers that use such channel. The partner is trying very hard to sell us this month, but they can only work on their margins. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. I would really love to just hear what Cisco says about why BFD on SVIs are a bad thing. They might have a good point. What I was told was that it was an unintended feature. Basically that means that while it worked it wasn't ever part of the intended design and wasn't ever tested. It could have adverse affects on other things; then again it also might not affect anything. They simply wouldn't know unless they incorporated that into the QA procedures and there has to be demand for that to happen. So tell your account team every chance you get. In fact I would recommend having your account team hook you up on a call with the product manager responsible for BFD support on your hardware and ask for it yourself (because often times I think requests like that tend to get overlooked). They seem to be listening about this, but the only real measure is the latency till it's implemented. It's good to know that Cisco changed the speech regarding this product. I think that if one uses only as PE (no other P or PEs relying on it for LDP of a critical backbone), and it uses only 2 uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it might work. In the mean time, I'm glad that all the 3750-Metro we've got were operational leases: we will return them all, so I won't have to write [EMAIL PROTECTED]@ on the customer satisfaction surveys anymore. Yeah, it's good to know what they're meant for. I was thinking like a dumbass when I bought a pair of ME6524s for the core in a very small pop. I didn't know much about the underlying platform and didn't even think about the TCAM on that box. I was just thinking that they'd be a decent device for the price and throughput in that small POP and that they didn't need to be too fancy. I ran out of TCAM back in January when the global route table exceeded the Sup2's limited reach. I'll be replacing them in the future and pushing them closer to the edge where they belong. That's the only place in the network we have 7600s with PFC XL... but you could try filtering some routes down to the non-XL TCAM capacity and pointing a default route to the these prefixes. The ME3750 was really meant primarily as a PE device but also as a P in a MetroE access ring. In our training lab the ME3750 was used mainly as the After the MPLS bugs we've seen here, you wouldn't even try using it as P even for the ring only. May be the 3750 IP Services, with no MPLS, combined with 2 ME6524 on the ring would be a good fit. That's the option we're exploring for some cities where we can do ring-only: using L2 (Extreme Summit X150 is the most likely candidate, but Cisco ME3400 with METROACCESS would do the job if one prefers to stick to Cisco); some cities are too complex to cover with ring-only, so in those we need full L3/MPLS. access edge. Most of the labs used it as a L2 edge switch essentially but a few labs had us extended the IGP to it, enable MPLS and push VCs all the way Humm, 3750s do L2 like a charm... to it. It worked fine, except for when I skipped an important step in the instructions... They intended for it to be deployed in GigE rings too. As they put it in the class, fiber is expensive. You can't home-run every PE to an aggregation router. It's just not cost-effective or reasonable. But But then you need a PE you can trust for being a P, even for a limited number of PEs. it is cost-effective to have half a dozen of them ringed together and home-run the edges back to the aggregation layer (ME6524s or larger hardware. In fact much of the class dealt with building
Re: [c-nsp] ME6524 alternative
I don't have a problem with a reseller getting a piece of the action if it's a vendor choice to do so. I always tell vendors that we will compare the product by the price we can get it, no matter how many hands it come across... on a competitive market like selling networking gear to service providers, they know that... every time Cisco or a reseller complains it has no margins, say something like it's not my problem, that's a self-inflicted pain and so forth... either they stop wining and gives you the discount you want, or you buy from someone else. The math they make is that sometimes a channel will bring a customer; if that probability is higher than the discount you have to give to put the middle man, they make a profit on an aggregate level. Not Cisco, but many other vendors considers us to be a channel as we buy CPEs to provide them as service, and let us buy directly from distributors or from the manufacturer, which puts more pressure on Cisco. Sometimes it doesn't work (as it didn't in this 3x price hike for the ME6524), sometimes it does. Rubens On Wed, Jul 23, 2008 at 11:10 AM, Dan Armstrong [EMAIL PROTECTED] wrote: Not to push this thread off topic, But we *hate* the Cisco model of the 'valueless' reseller. We deal with a Cisco rep, we deal with a Cisco SE, our discount is set by Cisco, we deal with Cisco's TAC - but when it's time to buy something, we get shuffled off to some twit that does absolutely nothing and makes a cut? It drives us nuts. It's confusing, and unnecessarily complicated. We'll never be able to get away from Cisco completely, but when possible this stupid crap drives us to the point we will do anything to avoid buying from Cisco, and look to their competitors. Rubens Kuhl Jr. wrote: Ouch. Are you dealing with a partner or Cisco Direct? There isn't any excuse for the price to go up, period. If you like I could hook you up with our Cisco Direct guys. If you got your order in this week you might be a decent discount simply because their fiscal year ends this month and the sales folks are hungry. Thru partner. Cisco insists to tell us that there is no Cisco Direct in our country, although I know there is and know some customers that use such channel. The partner is trying very hard to sell us this month, but they can only work on their margins. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. I would really love to just hear what Cisco says about why BFD on SVIs are a bad thing. They might have a good point. What I was told was that it was an unintended feature. Basically that means that while it worked it wasn't ever part of the intended design and wasn't ever tested. It could have adverse affects on other things; then again it also might not affect anything. They simply wouldn't know unless they incorporated that into the QA procedures and there has to be demand for that to happen. So tell your account team every chance you get. In fact I would recommend having your account team hook you up on a call with the product manager responsible for BFD support on your hardware and ask for it yourself (because often times I think requests like that tend to get overlooked). They seem to be listening about this, but the only real measure is the latency till it's implemented. It's good to know that Cisco changed the speech regarding this product. I think that if one uses only as PE (no other P or PEs relying on it for LDP of a critical backbone), and it uses only 2 uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it might work. In the mean time, I'm glad that all the 3750-Metro we've got were operational leases: we will return them all, so I won't have to write [EMAIL PROTECTED]@ on the customer satisfaction surveys anymore. Yeah, it's good to know what they're meant for. I was thinking like a dumbass when I bought a pair of ME6524s for the core in a very small pop. I didn't know much about the underlying platform and didn't even think about the TCAM on that box. I was just thinking that they'd be a decent device for the price and throughput in that small POP and that they didn't need to be too fancy. I ran out of TCAM back in January when the global route table exceeded the Sup2's limited reach. I'll be replacing them in the future and pushing them closer to the edge where they belong. That's the only place in the network we have 7600s with PFC XL... but you could try filtering some routes down to the non-XL TCAM capacity and pointing a default route to the these prefixes. The ME3750 was really meant primarily as a PE device but also as a P in a MetroE access ring. In our training lab the ME3750 was used mainly as the After the MPLS bugs we've seen here, you wouldn't even try using it as P even for the ring only. May be the 3750 IP Services, with no MPLS,
Re: [c-nsp] Changes to show policy-map interface
I suspect that is packets classified vs. the queueing engine acutally kicking in for the packets (ie: there was congestion and we had to queue those 5717) briefly. On Wed, Jul 23, 2008 at 09:13:29AM -0500, Peder @ NetworkOblivion wrote: It is 12.4.3 from Nov 2007. I guess it isn't really recent, but it is a 12.4 revision. Rodney Dunn wrote: What code is it? On Wed, Jul 23, 2008 at 07:20:25AM -0500, Peder @ NetworkOblivion wrote: I was just looking at a router running a recent version of IOS and I noticed that the output of show policy-map int has changed quite a bit. Here is the output: Router# sho policy-map interface Serial0/0/0 Service-policy output: voip Class-map: VoIP (match-any) 1354294 packets, 93771165 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 102 1354294 packets, 93771165 bytes 5 minute rate 0 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 100 (kbps) Burst 2500 (Bytes) (pkts matched/bytes matched) 5717/457522 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 54794552 packets, 12108835008 bytes 5 minute offered rate 3000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/2728/0 It used to just show the output under Class-map: VoIP (match-any), but now it appers that there is a new section labeled Queueing where there is some new data that doesn't match the data above it. Any idea how the pkts matched under queueing relates to the packets under the VoIP class-map itself? They aren't even close to the same. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] REP
On Wed, Jul 23, 2008 at 11:54 AM, Phil Mayers [EMAIL PROTECTED] wrote: list of points why STP shouldn't interact ...the key thing being should not, rather than will not. Using an entirely different protocol protects to a degree against human or machine error e.g. forgetting the bpduguard config. I agree. It's an extra protection that doesn't hurt... but I prefer to do bpudfilter, as the customer won't interfere with our STP and vice-versa. spanning-tree portfast bpdufilter default (or something like that) is a good tool do impose that beyond normal human error (forgetting to insert a command) but not advanced human error (configuring a customer interface as a backbone interface, for instance). I have never seen the point in more STP-like protocols when you can configure 802.1w or 1s w/ 1w to converge just as quickly with uniform support on all platforms to boot. EAPS does not offer any benefits and in fact it offer serious limitations thanks to its infancy. Every vendor has interpreted RFC 3619 differently since it was published nearly 5 years ago. For example Pannaway supports EAPS but their implementation is limited to not allowing EAPS rings to cross VLANs. That's a serious design limitation. We've tuned metro rings for 100ms convergence. I've *never* seen STP come anywhere even close to that, and I frankly doubt it has the capability. It hasn't, and we discovered that the bad way, with a loop that took us a painful downtime. And that's why we are looking at non-standard ring protocols, not because our customers also use STP. One point that could be argued, is what would be the performance of Rapid PVST+ or their IEEE counterparts on a ring-only topology. 802.1s is (IMNSHO) a bad joke. There are topologies where it's not just worse than PVST, it's actively harmful. This would be significantly alleviated if: * Cisco could run 1 MST process * 802.1s had some way of versioning the config, as opposed to breaking the 802.1s domain into pieces every time you update the config (or mandating you decide on vlan-instance mappings on day 0 and never change it - yeah, right...) We tried to migrate to MST, but just couldn't find a way to migrate gradually from Rapid PVST+. EAPS (and Foundry MRP) aren't universal solutions, but correctly applied they bring significant benefits in my experience. Also in the market, Allied Telesis has EPSR or something like that. It would be a Good Thing if all those Ethernet ring protocols were replaced by a standard one, but that doesn't prevent a network from running different rings with different vendors, as they all provide similar performance. When you say L2VPN, you mean point-to-point? What about multipoint e.g. VPLS? It's difficult to see how you could avoid MAC learning in a multipoint case. ...which is one reason I prefer L3VPNs, but there's a market for L2VPN. I second that. Rubens ___ 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] Port-Channel Setup Issues
Hi All I am trying to setup a 4 port port-channel between a Cisco 7609 and a Cisco ME3400, despite various attempts to complete this I keep running into the same issue, although the physical ports come up the Port-channel wont at all, looking at the port channel itself it remains in a down/down status on the 7609. The ME3400 is setup with the physcial interfaces as follows. inter Fa0/1 switchport access vlan xxx switchport mode dot1q-tunnel speed 100 duplex full channel-group 1 mode on The 7609 is setup as follows. interface Port-channel1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan xxx switchport mode trunk mtu 9216 no ip address load-interval 30 end Anyone got any ideas? This communication together with any attachments transmitted with it (this E-Mail) is intended only for the use of the addressee and may contain information which is privileged and confidential. If the reader of this E-Mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing or copying of this E-Mail is strictly prohibited. Addressees should check this E-mail for viruses. The Company makes no representations as regards the absence of viruses in this E-Mail. If you have received this E-Mail in error please notify the sender immediately by e-mail. Please then immediately delete, erase or otherwise destroy this E-Mail and any copies of it. Any opinions expressed in this E-Mail are those of the author and do not necessarily constitute the views of the Company. Nothing in this E-Mail shall bind the Company in any contract or obligation. For the ! purposes of this E-Mail the Company means The Carphone Warehouse Group Plc and/or any of its subsidiaries. The Carphone Warehouse Group Plc (Registered in England No. 3253714) 1 Portal Way, London W3 6RS. AOL Broadband, [AOLBroadband.co.uk] [AOLbb.co.uk] and AOL logos are trade marks of AOL LLC and are used under licence. The AOL Broadband service is provided to customers in the UK by TPH Services SARL, a Carphone Warehouse plc company. 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] Port-Channel Setup Issues
What does int po1 look like on the ME3400. What do the physical interfaces look like on the 7600. The physical on the ME3400 is configured as an etherchannel without any negotation, if the otherside is configured any other method it won't come up. David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Kilian Sent: Wednesday, July 23, 2008 12:39 PM To: 'cisco-nsp@puck.nether.net' Subject: [c-nsp] Port-Channel Setup Issues Hi All I am trying to setup a 4 port port-channel between a Cisco 7609 and a Cisco ME3400, despite various attempts to complete this I keep running into the same issue, although the physical ports come up the Port-channel wont at all, looking at the port channel itself it remains in a down/down status on the 7609. The ME3400 is setup with the physcial interfaces as follows. inter Fa0/1 switchport access vlan xxx switchport mode dot1q-tunnel speed 100 duplex full channel-group 1 mode on The 7609 is setup as follows. interface Port-channel1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan xxx switchport mode trunk mtu 9216 no ip address load-interval 30 end Anyone got any ideas? This communication together with any attachments transmitted with it (this E-Mail) is intended only for the use of the addressee and may contain information which is privileged and confidential. If the reader of this E-Mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing or copying of this E-Mail is strictly prohibited. Addressees should check this E-mail for viruses. The Company makes no representations as regards the absence of viruses in this E-Mail. If you have received this E-Mail in error please notify the sender immediately by e-mail. Please then immediately delete, erase or otherwise destroy this E-Mail and any copies of it. Any opinions expressed in this E-Mail are those of the author and do not necessarily constitute the views of the Company. Nothing in this E-Mail shall bind the Company in any contract or obligation. For the ! purposes of this E-Mail the Company means The Carphone Warehouse Group Plc and/or any of its subsidiaries. The Carphone Warehouse Group Plc (Registered in England No. 3253714) 1 Portal Way, London W3 6RS. AOL Broadband, [AOLBroadband.co.uk] [AOLbb.co.uk] and AOL logos are trade marks of AOL LLC and are used under licence. The AOL Broadband service is provided to customers in the UK by TPH Services SARL, a Carphone Warehouse plc company. ** ** 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/
Re: [c-nsp] REP
Rubens, Rubens Kuhl Jr. wrote: Also in the market, Allied Telesis has EPSR or something like that. It would be a Good Thing if all those Ethernet ring protocols were replaced by a standard one, Fortunately, there is hope in this regard. Take a look at ITU G.8032. http://www.ieee802.org/1/files/public/docs2008/liaison-itut-g8032-overview-0308.pdf There are a number of vendors that are already in the process of implementing this. It would be good if people find value in it to encourage their particular vendors to implement it as well. This would help SP's move away from the proprietary ring protection protocols like: Extreme EAPS, Foundry's MRP, Force10's FRRP, Cisco's REP, etc. (When you have at least 4 different vendors doing nearly the same thing in incompatible ways, it's surprising there isn't a standard). It should be noted that the above is the first version of G.8032. Take a look at p. 13 in that URL for planned enhancement to future revisions of G.8032. -shane but that doesn't prevent a network from running different rings with different vendors, as they all provide similar performance. ___ 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] Renaming interfaces on a PIX 525
We have a pair of PIX 525s (active/standby), and the 2900 switch they're attached to is going to be replaced very shortly. The outside interface, which is currently Ethernet0, will then be moved to GigabitEthernet1. What's the best way to do this? Can I just rename the Ethernet0 interface to outside.old, and rename the GigabitEthernet interface to outside, then move the ip addressing? Will that work? Thanks! --Steve Steve Pfister Technical Coordinator, The Office of Information Technology Dayton Public Schools 115 S. Ludlow St. Dayton, OH 45402 Office (937) 542-3149 Cell (937) 673-6779 Direct Connect: 137*131747*8 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] Cisco 6500 Chassis PDU
Relying on a breaker in another room, that someone else might flip without your knowledge, seems like a recipe for getting hurt. Does anyone actually do this? We do this in our telco room, but it's only a few hundred sf and the BDFB is under 40' away from any direct connected equipment (and on the same aisle)- although we are in the process of replacing these with FAPs to save fuse positions on the BDFB (since we'd really rather not have to add another main distribution panel onto a live DC bus...) In any case, it's not that much different than what AC electricians have to deal with since most of the time your switchboard/panelboard isn't in the same room as the equipment you're working on, just deal with it the same way they do- by locking/tagging out the circuit while you're working on it. Hell even if it's same-rack work you should probably do this lest you step away for a few minutes and some other guy comes along and says oh, fuse popped out with no tag, let me just stick that back in... ~Matt ___ 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] Renaming interfaces on a PIX 525
Hello Steve, when I remember correctly - when you rename the interface, then also the related config parts, where the interface name is used, are changed. Regards, Mathias From: Steven Pfister [EMAIL PROTECTED] To: cisco-nsp@puck.nether.net Date: 23.07.2008 20:39 Subject: [c-nsp] Renaming interfaces on a PIX 525 We have a pair of PIX 525s (active/standby), and the 2900 switch they're attached to is going to be replaced very shortly. The outside interface, which is currently Ethernet0, will then be moved to GigabitEthernet1. What's the best way to do this? Can I just rename the Ethernet0 interface to outside.old, and rename the GigabitEthernet interface to outside, then move the ip addressing? Will that work? Thanks! --Steve Steve Pfister Technical Coordinator, The Office of Information Technology Dayton Public Schools 115 S. Ludlow St. Dayton, OH 45402 Office (937) 542-3149 Cell (937) 673-6779 Direct Connect: 137*131747*8 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/ 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/
Re: [c-nsp] Renaming interfaces on a PIX 525
Mathias Spoerr wrote: Hello Steve, when I remember correctly - when you rename the interface, then also the related config parts, where the interface name is used, are changed. Keep a good backup of the config just in case, especially if you're talking about trying this with PDM/ASDM. They don't rename/change very well, they really try to delete/re-add, and the delete part deletes all associated configuration references to the original. 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] Renaming interfaces on a PIX 525
I think I'm probably going to do this from the command line. Would I be able to have two interfaces marked as outside? Do something like: int gig1 nameif outside security-level 0 int eth0 nameif old.outside security-level 6 no ip address int gig1 ip address address from eth0 standby standby address from eth0 (after backing up the config, of course...) Thanks! Steve Pfister Technical Coordinator, The Office of Information Technology Dayton Public Schools 115 S. Ludlow St. Dayton, OH 45402 Office (937) 542-3149 Cell (937) 673-6779 Direct Connect: 137*131747*8 Email [EMAIL PROTECTED] Jeff Kell [EMAIL PROTECTED] 7/23/2008 4:50 PM Mathias Spoerr wrote: Hello Steve, when I remember correctly - when you rename the interface, then also the related config parts, where the interface name is used, are changed. Keep a good backup of the config just in case, especially if you're talking about trying this with PDM/ASDM. They don't rename/change very well, they really try to delete/re-add, and the delete part deletes all associated configuration references to the original. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Renaming interfaces on a PIX 525
Hello Steven: -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Steven Pfister Sent: Wednesday, July 23, 2008 11:35 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Renaming interfaces on a PIX 525 We have a pair of PIX 525s (active/standby), and the 2900 switch they're attached to is going to be replaced very shortly. The outside interface, which is currently Ethernet0, will then be moved to GigabitEthernet1. What's the best way to do this? Can I just rename the Ethernet0 interface to outside.old, and rename the GigabitEthernet interface to outside, then move the ip addressing? Will that work? You will have to rename the Ethernet interface first, which will break a lot of stuff, then name the Gigabit Ethernet interface, which will *not* un-break anything. After you change the name you will have to do the following: 1) Reenter your statics (they will go away when you un-name E0) 2) Re-apply your access-group command for any ACL's your outside ACL 3) Re-enter any admin outside access (ssh, http, etc.) 4) Re-apply your global statement if used. 5) Clear ARP on your upstream device(s). Make sure you have a backup and that you're doing this from either console or the inside network. Regards, Mike PGP.sig 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] IS-IS: Ignore Attached Bit
r(config)#router isis r(config-router)#ignore-attached-bit r(config-router)# When/why would you want to do that? -A ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IS-IS: Ignore Attached Bit
Asbjorn - This is useful in the case of L2--L1 Route-Leaking where you *may* not want L1-Router to use its default to point to L1L2 router and L1L2 end up in dropping the traffic. With Route-Leaking, L1-Router does get the specific routes. This way, for any traffic that L1 doesn't know, it will drop itself rather than sending to L1L2 and then L1L2 dropping it. Hope it is clear. -Shankar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asbjorn Hojmark - Lists Sent: Wednesday, July 23, 2008 2:19 PM To: Oliver Boehmer (oboehmer); [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IS-IS: Ignore Attached Bit r(config)#router isis r(config-router)#ignore-attached-bit r(config-router)# When/why would you want to do that? -A ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] combining multiple dsl lines
The adsl connections are PPPoE and they do not support multilink. I am using nat on the router as well. I guess I will stick with route-map's for now as I know how to configure it and it works well in this configuration. Thanks for the info! Dan. On Tue, Jul 22, 2008 at 11:18 PM, Ben Steele [EMAIL PROTECTED] wrote: Depends a lot on the adsl connections, are they ppp ? does the remote end support multilink? if so then multilink ppp is a good option providing all 4 lines are the same characteristics. Otherwise other options are cef load balancing, what type will depend on whether you are using NAT or not as you want to make sure the packet flow takes the right path, load balancing using the source/dest port algorithm works quite well though, probably wouldn't reccomend per packet over adsl. The route-map way is ok but wouldn't utilise the links as well as cef load balancing or ppp multlink could. Another option worth throwing in is the use of ip sla on your routes so as to remove them from the equation should one link go down, can also be done with the route-map using verify-availability on the next-hop option. Ben On 23/07/2008, at 1:39 PM, Dan Letkeman wrote: I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/ ___ 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] uRPF and IPSec SPA compatibility issues?
I enabled uRPF on a couple SVIs on our 7600s last week remotely while in training. I was trying to track down some RFC 1918 traffic leaking into our network between lectures. I was going to use an ACL with an explicit deny w/ log-input to locate it. One of the SVIs was for one of our SP server farms. The other was connected to a pair of ASAs for our corporate LAN. Incidentally I never found the source of the traffic and was distracted by more important things. I did not remove the uRPF config because it was something I forgot to add during the deployment and as an access edge interface it really should be there. The uRPF config is simple: Late in the week I got a report that an internal admin couldn't access devices in our data center via VPN. VPN connections terminate on the same 7600s using IPSec SPAs running in VRF mode. The DC devices that he was trying to access were in a management VRF downstream from the 7600s in the DC itself. All L3 interfaces in the 7600s have been explicitly configured with the 'crypto engine slot' command and outside. Specifically: crypto engine slot 3/0 outside ___ 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] uRPF and IPSec SPA compatibility issues? part 2
Whoops. I somehow told Thunderbird to send the message (ctrl-enter I think) and couldn't find a way to stop it. Here's the uRPF config: ip verify unicast source reachable-via rx 150 ACL 150 has a permit for DHCP traffic and a deny any w/ log-input for everything else. So I was troubleshooting the problem today, now that I'm back in the office. I could VPN in and successfully authenticate. I got the expected routes and everything looked fine. However I couldn't ping anything. Looking at the IPSec counters on the primary 7600 showed 0 packets in or out and no errors for my VPN connection. I assumed that the IPSec SPA was hosed again and in need of some TLC with a hammer but before I reset it I thought I'd look for another possible cause. Looking back through my RANCID logs the only things that changed on the 7600s last week prior to Friday (problem was reported Thursday) was the uRPF changes I made. I couldn't imagine that being the cause but for grins I decided to try it anyway. I removed the uRPF config from the corporate LAN SVI and ping across my connected VPN session started working instantly. I can not for the life of me figure out why uRPF was causing the packets to be dropped. The verification drop counters were incrementing so I think it's safe to assume that this is where the traffic went. Actually I can think of a possible cause. What is the order of operation for processing frames coming in a SVI when crypto is configured on the interface? If the IPSec payload was decrypted first and then the packets were placed back in the interface's buffer to be run through the uRPF checks then the decrypted payload is what uRPF would see and in that case it should drop the packets. My understanding of the IPSec SPAs running in VRF mode is that uRPF and all the other normal interface actions (QoS, netflow, ACLs, etc) would happen and then the encrypted packets would be sent over to the ingress interface of the IPSec SPA for processing. Coming out the backside of the SPA the traffic would be dropped into the appropriate inside VPN VLAN that's associated with the VRF in question. That's how I thought it was supposed to work but clearly that's not what's happening, or I'm missing something. Any thoughts? We're nearing the end of our SmartNet renewal process so next week I should be able to ask TAC. I thought I'd check here first. Thanks Justin ___ 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] combining multiple dsl lines
If you really want to use route-maps to force your traffic down a certain interface at least use it with verify-availability incase your hop goes down so you have a back up path, no point forcing traffic down a dsl line that has died. http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtpbrtrk.html - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Ben Steele [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Thursday, July 24, 2008 7:42 AM Subject: Re: [c-nsp] combining multiple dsl lines The adsl connections are PPPoE and they do not support multilink. I am using nat on the router as well. I guess I will stick with route-map's for now as I know how to configure it and it works well in this configuration. Thanks for the info! Dan. On Tue, Jul 22, 2008 at 11:18 PM, Ben Steele [EMAIL PROTECTED] wrote: Depends a lot on the adsl connections, are they ppp ? does the remote end support multilink? if so then multilink ppp is a good option providing all 4 lines are the same characteristics. Otherwise other options are cef load balancing, what type will depend on whether you are using NAT or not as you want to make sure the packet flow takes the right path, load balancing using the source/dest port algorithm works quite well though, probably wouldn't reccomend per packet over adsl. The route-map way is ok but wouldn't utilise the links as well as cef load balancing or ppp multlink could. Another option worth throwing in is the use of ip sla on your routes so as to remove them from the equation should one link go down, can also be done with the route-map using verify-availability on the next-hop option. Ben On 23/07/2008, at 1:39 PM, Dan Letkeman wrote: I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/ ___ 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] Renaming interfaces on a PIX 525
Michael K. Smith - Adhost wrote: You will have to rename the Ethernet interface first, which will break a lot of stuff, then name the Gigabit Ethernet interface, which will *not* un-break anything. After you change the name you will have to do the following: 1) Reenter your statics (they will go away when you un-name E0) 2) Re-apply your access-group command for any ACL's your outside ACL 3) Re-enter any admin outside access (ssh, http, etc.) 4) Re-apply your global statement if used. 5) Clear ARP on your upstream device(s). Make sure you have a backup and that you're doing this from either console or the inside network. Steven, These guys pretty much summed it up already. Renaming an interface on a PIX/ASA sucks. I've been bit by this before too, only I didn't have the opportunity to ask if the PIX would freak out before I made the change. An hour later I had everything working again. I've made the feature request before for a simple way to change interface names but there hasn't been enough demand for it to warrant the work I'm afraid. You would think it would be a fairly easy thing to implement though. Michael's list is right on. The only commands that I can think of that are missing from his list are mtu, ip verify, crypto isakmp enable. Basically every single instance of the word outside in the config with the exception of ACL remarks, object-groups, and names (ie, instances that aren't CLI elements that require an interface name but are more textual in nature) will have to be re-entered. You might be thinking that you can simply download a copy of the startup-config to a tftp server, modify it and upload it back over top of the startup-config (or running-config). First off I can't remember where the startup-config is located on the PIX/ASAs or if it can be accessed. Second, copying over top of the running-config merges the configs together. You won't get the desired results. In theory you could load all of your changes into a config file beginning with all the no's to all the statics and whatnot and follow that up with the new config. Then when you do the tftp merge you should get what you want, I think. I never found a quick way to modify the config. If you could delete the config, reload and paste modified config back in via the console then that would be the fastest. Good luck. Justin ___ 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] combining multiple dsl lines
Yes, I have done that before and it works well. Thanks Dan. On Wed, Jul 23, 2008 at 6:37 PM, Ben Steele [EMAIL PROTECTED] wrote: If you really want to use route-maps to force your traffic down a certain interface at least use it with verify-availability incase your hop goes down so you have a back up path, no point forcing traffic down a dsl line that has died. http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtpbrtrk.html - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Ben Steele [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Thursday, July 24, 2008 7:42 AM Subject: Re: [c-nsp] combining multiple dsl lines The adsl connections are PPPoE and they do not support multilink. I am using nat on the router as well. I guess I will stick with route-map's for now as I know how to configure it and it works well in this configuration. Thanks for the info! Dan. On Tue, Jul 22, 2008 at 11:18 PM, Ben Steele [EMAIL PROTECTED] wrote: Depends a lot on the adsl connections, are they ppp ? does the remote end support multilink? if so then multilink ppp is a good option providing all 4 lines are the same characteristics. Otherwise other options are cef load balancing, what type will depend on whether you are using NAT or not as you want to make sure the packet flow takes the right path, load balancing using the source/dest port algorithm works quite well though, probably wouldn't reccomend per packet over adsl. The route-map way is ok but wouldn't utilise the links as well as cef load balancing or ppp multlink could. Another option worth throwing in is the use of ip sla on your routes so as to remove them from the equation should one link go down, can also be done with the route-map using verify-availability on the next-hop option. Ben On 23/07/2008, at 1:39 PM, Dan Letkeman wrote: I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/ ___ 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] combining multiple dsl lines
You're still going to need something on the CPE side to detect a failed route unless you plan on running a routing protocol to your customers, I won't bother going into the Linux side of things seeing as this is a Cisco list but in my experience per-packet is only good if the lines are really well matched or you don't plan on running any/much real-time traffic over it, ie voip, unfortunately with the nature of dsl and its vulnerability to weather and various other nasties in your last mile copper run things just have to many variables for me to consider it a reliable inplementation for someone planning to use it with per-packet and real time traffic where out of order packets can become a problem. Good to hear you are having success with it though. We have used cef per packet with great success on PPPoA DSL links here in the UK, we use radius to add/remove the extra routes when a connection bounces. The CPE is a linux box which is not running any NAT. Works for us Wayne ___ 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] combining multiple dsl lines
We use per-packet all the time, in our experience the lines tend to all degrade together since the degradation seems to be in the building trunk or off somewhere in the ATM cloud on the provider (qwest in this case)...We do also run eBGP with private ASNs to all customers who have multiple links as well to detect failed lines. That being said, it sounded like the original requester did not have control of both ends of the line which makes most real solutions a bit moot. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Steele Sent: Wednesday, July 23, 2008 4:47 PM To: Wayne Lee; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] combining multiple dsl lines You're still going to need something on the CPE side to detect a failed route unless you plan on running a routing protocol to your customers, I won't bother going into the Linux side of things seeing as this is a Cisco list but in my experience per-packet is only good if the lines are really well matched or you don't plan on running any/much real-time traffic over it, ie voip, unfortunately with the nature of dsl and its vulnerability to weather and various other nasties in your last mile copper run things just have to many variables for me to consider it a reliable inplementation for someone planning to use it with per-packet and real time traffic where out of order packets can become a problem. Good to hear you are having success with it though. We have used cef per packet with great success on PPPoA DSL links here in the UK, we use radius to add/remove the extra routes when a connection bounces. The CPE is a linux box which is not running any NAT. Works for us Wayne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] combining multiple dsl lines
www.cisco.com/go/oer ios performance routing as it's known now might work for you -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Letkeman Sent: Wednesday, 23 July 2008 12:10 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] combining multiple dsl lines I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/ ___ 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] Renaming interfaces on a PIX 525
Justin Shore wrote: You might be thinking that you can simply download a copy of the startup-config to a tftp server, modify it and upload it back over top of the startup-config (or running-config). First off I can't remember where the startup-config is located on the PIX/ASAs or if it can be accessed. It can be done on an ASA by copying the new configuration to a different filename in flash, and issuing a 'boot config flash:filename' directive to the current config. Not sure if the PIX supports this convention. 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] unable to ping from some source IP
Hi guys, I have a very strange issue encountered. I am not able to ping to one of customer's WAN IP (203.192.163.162) from some source IP. I am 100% sure that is nothing filtering it from our side. Anything wrong prohibiting it from below customer router's config? Cheers, Jimmy Current configuration : 1340 bytes ! version 12.1 no service single-slot-reload-enable service timestamps debug datetime service timestamps log datetime localtime service password-encryption ! hostname PAC_3640 ! no logging rate-limit no logging monitor ! clock timezone gmt 8 ip subnet-zero ! ! no ip finger no ip domain-lookup ! call rsvp-sync ! ! ! interface FastEthernet1/0 ip address 122.152.143.225 255.255.255.224 no ip redirects no ip unreachables no ip proxy-arp no keepalive speed 100 full-duplex no cdp enable ! interface Serial1/0 -- WAN Interface bandwidth 2048 ip address 203.192.163.162 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp fair-queue no cdp enable ! no ip classless ip route 0.0.0.0 0.0.0.0 203.192.163.161 no ip http server ! no cdp run ! dial-peer cor custom --- ___ 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 WLC 4404 Snmp problems
Hi list, Anyone encountered not able to get SNMP data from a Cisco WLC 4404? I got a no response when I do: [10:18:31 [EMAIL PROTECTED]~]# snmpwalk -v 2c 192.168.1.2 -c public Timeout: No Response from 192.168.1.2 all snmp settings are activated via web config, all versions are enabled. When I did a similar query in one of my switches I get the response I need. [10:18:40 [EMAIL PROTECTED]~]# snmpwalk -v 2c 192.168.1.253 -c public SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(25)SEE3, RELEASE SOFTWARE (fc2) Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Thu 22-Feb-07 14:40 by myl SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.564 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (68954835) 7 days, 23:32:28.35 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: Switch SNMPv2-MIB::sysLocation.0 = STRING: SNMPv2-MIB::sysServices.0 = INTEGER: 6 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00 IF-MIB::ifNumber.0 = INTEGER: 55 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.5 = INTEGER: 5 IF-MIB::ifIndex.10001 = INTEGER: 10001 SNIP - Any IDeas? regards, Chris ___ 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] 6509e upgrades to native ios
I have been reading and following the following document for upgrading from cat os to native ios http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note 09186a008015bfa6.shtml#conv_32 I am stuck at reloading the router, I get this error ( I am consoled into the console port on the sup 32) Router#reload Reload to the ROM monitor only allowed from console line unless the configuration register boot bits are non-zero I do a sh bootvar and it shows me Router#sh bootvar BOOT variable = c6msfc2a-ipbase_wan-mz.122-18.SXF8.bin,1; CONFIG_FILE variable = BOOTLDR variable = Configuration register is 0x2102 (will be 0x0 at next reload) How do I reload the sup32 ? If is reset the config-register back to 0X2102 I am allowed to reload it... Any ideas ?? ___ 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] unable to ping from some source IP
Hi! Hi guys, I have a very strange issue encountered. I am not able to ping to one of customer's WAN IP (203.192.163.162) from some source IP. I am 100% sure that is nothing filtering it from our side. Anything wrong prohibiting it from below customer router's config? Your customer uses *classful* routing (no ip classless), so when the router tries to forward icmp responses back to your host it DOES NOT consider default route *if* your host's ip_addr belongs to 203.192.163/24 or 122/8. Cheers, Jimmy Current configuration : 1340 bytes ! version 12.1 no service single-slot-reload-enable service timestamps debug datetime service timestamps log datetime localtime service password-encryption ! hostname PAC_3640 ! no logging rate-limit no logging monitor ! clock timezone gmt 8 ip subnet-zero ! ! no ip finger no ip domain-lookup ! call rsvp-sync ! ! ! interface FastEthernet1/0 ip address 122.152.143.225 255.255.255.224 no ip redirects no ip unreachables no ip proxy-arp no keepalive speed 100 full-duplex no cdp enable ! interface Serial1/0 -- WAN Interface bandwidth 2048 ip address 203.192.163.162 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp fair-queue no cdp enable ! no ip classless ip route 0.0.0.0 0.0.0.0 203.192.163.161 no ip http server ! no cdp run ! dial-peer cor custom --- ___ 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/ -- Best Regards, Yuri Selivanov -- [URI2-RIPE] ___ 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/
