Re: [c-nsp] Acceptance Test Procedure for New Cisco Devices
But I guess we'll finally opt for letting the Cisco QA be enough as a guarantee the devices work (there's always RMA) and have Alex's suggestion be the winner here, just be as nebulous as you can and follow the ill-defined and metaphysical characteristique of such undefined term as Acceptance Test Procedure I'd ask the customer: Are you married? Did you fill an ATP form before you said Yes, I do ??? No??? Then c'mon, gimme a break!!! It's just a darn router we're talking here, not chaining your entire life with the same woman!! A router can be replaced when malfunctioning, with a wife it's a bit more difficult, isn't it?? Actually there are best practices to that also, see http://www.iambored.co.za/funny/girlfriend-v10-v20/ 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] MPLS fast reroute without full mesh traffic engineering
I'm trying to map US Patent 7230913 (http://www.patentstorm.us/patents/7230913.html) to an specific IOS feature... it sounded to me like AutoTunnel, is that so ? 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/
Re: [c-nsp] MPLS fast reroute without full mesh traffic engineering
Very interesting. After reading the document, though, I couldn't fully understand if primary onehop is enough to achieve low latency switchover(most likely not), or how to create backup onehop tunnels, or if only primary onehop tunnels are allowed and backup tunnels are still full-meshed. Rubens On Mon, Jan 12, 2009 at 12:06 PM, Phil Bedard phil...@gmail.com wrote: autotunnel primary one-hop. The one-hop portion being the important part. Phil On Jan 12, 2009, at 8:38 AM, Rubens Kuhl Jr. wrote: I'm trying to map US Patent 7230913 (http://www.patentstorm.us/patents/7230913.html) to an specific IOS feature... it sounded to me like AutoTunnel, is that so ? 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/ ___ 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] ME3400 IPv6
Could it be IPv6 control-plane support but not forwarding support ? As for IPv6 on the ME-3400, I wonder if it will be hardware (Mpps) or software (kpps) support... ME-3400E most likely has IPv6 hardware forwarding, but as for the ME-3400, it might not. Rubens On Mon, Jan 12, 2009 at 5:19 PM, Clement Cavadore clem...@cavadore.net wrote: Hi, On Mon, 2009-01-12 at 13:28 -0400, Munroe, James (DSS/MAS) wrote: 12.2(50)SE will have IPv6 support for the ME-3400/3400E series. And what about 12.2(25), which actually has IPv6 commands ? Is that a partial support ? Or am I missing something ? Btw, this is a good news for 12.2(50)SE :) Clément ___ 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] EoMPLS VC up on one side, not on the other.
Signaling protocol: LDP, peer 10.200.1.8:0 up MPLS VC labels: local 330, remote 69 Group ID: local 0, remote 0 MTU: local 9000, remote 1500 Try matching the MTU of both ends. Be aware that 3750 has both global and local MTU, and global MTU change on the 3750 require reload. 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/
Re: [c-nsp] SXI out
Making the same file for release notes of SXH and SXI makes /me think that SXH4 won't see the light... what do people have heard about it ? About SXI, does it look deployable or SXI3 or SXI4 is the version to look for ? (may be too soon to tell, I know) One thing we noticed about promised features lacking is REP(Resilient Ethernet) on Cat6K. Rubens On Thu, Nov 13, 2008 at 12:59 AM, Tolstykh, Andrew [EMAIL PROTECTED] wrote: Link to the release notes / new features etc. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/rel ease/notes/ol_14271.html#wp4208036 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Mauch Sent: Wednesday, November 12, 2008 6:53 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] SXI out It appears cisco released SXI already. http://www.cisco.com/cgi-bin/Software/Iosplanner/Planner-tool/iosplanner .cgi?release_name=12.2.33-SXImajorRel=12.2state=:RLtype=Early%20Deplo yment -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ 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/ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ 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] ASR 9000
I think ASR is just the cool name of the moment. The new ASRs could be called CRS-0.5, CRS-0.1, Edge-CRS... Rubens On Tue, Nov 11, 2008 at 8:55 PM, Pete Templin [EMAIL PROTECTED] wrote: Justin Shore wrote: Did anyone else miss an announcement for the ASR 9000 series? http://www.cisco.com/en/US/products/ps9853/index.html How did I miss that bad boy? Anyone have any details? Side to back airflow? Who thought that'd work well? Runs IOS XR, while the recent ASR 1000 series runs IOS XE? Consistency would be nice. Re-uses the RSP nomenclature, just recently put to bed in the 7500 series. However, adding CE (hundred-gig Ethernet) support on the initial datasheet is impressive, along with XE and GE. Skipping LXE is interesting though. pt ___ 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] OER/PfR, 7600, DFZ
What are the current xSP impressions on using Performance Routing (formerly known as Optimized Edge Routing) on the current Internet Default-Free-Zone, manipulating inbound traffic by BGP route control ? Does it add availability and quality or troubles ? Platform is 7600, PFC3BXL. 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/
Re: [c-nsp] ME3400
On Fri, Oct 24, 2008 at 11:18 AM, Marko Milivojevic [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 11:31, David Curran [EMAIL PROTECTED] wrote: We use them as a sort of port replicator for routers like the 7206 where we need a few more ethernet ports. Rock solid little box. The UNI/NNI port configuration is slightly odd but I can see the benefit in a metro application. We're using the ME6524 for our metro stuff though. Doesn't have the same restrictions as the ME-3400. Speaking of ME-6500. Does it have LAN or WAN ports? In other words, does it have decent QoS? All LAN ports. 8 of the ports, the backbone ports, have no oversubscription and more queues, but it's not like OSM, ES-20 or similar WAN ports. VLAN significance is global among all ports, but VLAN translation can do some tricks to improve 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/
Re: [c-nsp] 12.2(33)SXI
Not only postponed, but the feature matrix has been changed, so some roadmapped features won't show up in SXI. Rubens On Wed, Sep 24, 2008 at 4:42 PM, Asbjorn Hojmark - Lists [EMAIL PROTECTED] wrote: * A.* First customer ship is expected in September 2008. I just heard that's been postponed to 'end of October'. -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] Weird OSPF meltdown
On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. hammered by what? We could not get packet traces of all the mishaps, but in one of them there was a flood of mDNS(Multicast DNS) packets. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. Yes, hold time expired. Our current theory is CoPP itself dropping the packets. We have some large ACLs describing critical, normal and undesired traffic; if some OSPF frames don't flow thru the critical ACL, the normal category would only fill up during floods. There are terms on the critical ACL to match OSPF packets, but may be it's not matching all of them. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this hammering is coming from? I'm assuming you mean it's a flood of traffic. The inbound interface for the flood doesn't run OSPF, only the upstream links to other routers. 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/
Re: [c-nsp] Weird OSPF meltdown
The problem with rate limiters is they will drop critical traffic (multicast OSPF) alongside multicast garbage from the customers. There is no hardware CoPP on the path of multicast traffic, so it's up to the CPU to survive such a flooding. Rubens On Tue, Sep 23, 2008 at 6:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: If it's a lot of punts and the hardware rate limiters don't catch them you would overrun the RP cpu or the ibc interface going up to the RP. Rodney On Tue, Sep 23, 2008 at 06:46:38PM -0200, Rubens Kuhl Jr. wrote: On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. hammered by what? We could not get packet traces of all the mishaps, but in one of them there was a flood of mDNS(Multicast DNS) packets. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. Yes, hold time expired. Our current theory is CoPP itself dropping the packets. We have some large ACLs describing critical, normal and undesired traffic; if some OSPF frames don't flow thru the critical ACL, the normal category would only fill up during floods. There are terms on the critical ACL to match OSPF packets, but may be it's not matching all of them. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this hammering is coming from? I'm assuming you mean it's a flood of traffic. The inbound interface for the flood doesn't run OSPF, only the upstream links to other routers. 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/
Re: [c-nsp] SRC2?
But no SXH3a or SHX4 yet... :-( Is SRC2 available to download or just the release notes ? SXHn has been recently released weeks after it appeared on release notes. Rubens On Sun, Sep 21, 2008 at 9:52 AM, Simon Leinen [EMAIL PROTECTED] wrote: SRC2 just appeared on CCO. Release notes: http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html -- Simon. ___ 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] PA-POS-1OC3 vs. PA-A3-OC3SMI
PE-1CHOC3-SMIR-QPP PIC for the Juniper M7i, perhaps ? Rubens On Thu, Sep 18, 2008 at 3:43 PM, David Aldworth [EMAIL PROTECTED] wrote: We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. Something that we can break individual T1's off of. In researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and the second is ATM. Other than price what is the difference? Which is needed? Thanks for any and all advice. David ___ 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] Weird OSPF meltdown
Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. IOS is 12.2(18)ZU2; Sham-Link on this IOS is vulnerable but we are not using it. Any thoughts ? 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/
Re: [c-nsp] MX960 vs Cisco 7600
Cisco 7600 + ES20 are way too expensive on a price/port perspective. Consider distributing smaller Cisco ME6524 boxes (which is not as cheap as it used to be, but it is still lot less than 7600) instead of large boxes like MX 960; if you really have the density to buy MX 960 instead of MX 240, I don't think there is anything on Cisco-land that can match that. Rubens On Tue, Sep 16, 2008 at 6:24 PM, Steven Mark [EMAIL PROTECTED] wrote: hello, We are a small ISP based out of Asia and we are considering above two products for carrier ethernet deployment. If anyone has done a comparitive study or have experience (support, feature-richness, IOS/JUNOS stability etc.). Thanks Steve ___ 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] MX960 vs Cisco 7600
Mark, Even with no full-routing capability, one can still do L3 or L2 VPN so the customer can reach a central Internet router with half million/one million routes if it`s a BGP customer, or follow default if it's a single-homed customer. That works if such a BGP customer are in the few percent exception, not on 90%+ rule... which is the case for our market, but might not be the case for the original poster. Good point. Rubens On Tue, Sep 16, 2008 at 10:33 PM, Mark Tinka [EMAIL PROTECTED] wrote: On Wednesday 17 September 2008 09:24:13 Rubens Kuhl Jr. wrote: Cisco 7600 + ES20 are way too expensive on a price/port perspective. Consider distributing smaller Cisco ME6524 boxes (which is not as cheap as it used to be, but it is still lot less than 7600)... In our consideration for a small box capable of handling a large number of EoMPLS VC's, the ME6524 came up - but sadly, we can only think of it in that function, and not a combined L2VPN + IP termination device. This is because it can only support 256,000 v4 routing entries (PFC-3C). Would advise the OP to look at this if he's thinking of carrying full routes on it. If 0/0 is good enough, then no worries. Mark. ___ 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] Dreaded FIB Exception on Sup2
It's minimal, but RSP720-3CXL is going to require a 7600, though if you are willing to trade the MSFC4 for VSS, you can go with a VS-Sup720-3CXL. Either one is going to force you off of 12.2SXF. Since the difference between 3B and 3C mainly seems to be number of MAC addresses, a Sup720-3BXL will usually do the job well enough. PFC-3BXL is a fine EARL, but MSFC4 has much more memory and processing power, which is something that the years to come might prove useful. 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/
Re: [c-nsp] Dreaded FIB Exception on Sup2
On Wed, Sep 3, 2008 at 2:58 PM, Rick Kunkel [EMAIL PROTECTED] wrote: Well, I've hit the dreaded error message on my Sup2: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched 1) Try filtering on anything less than /24s and pointing default routes to your providers, see if that helps. 2) Try filtering on RIR boundaries, if (1) has failed. 3) Try filtering on overlapping prefixes (will need software to find those), if (2) has failed 4) Try filtering on longer AS paths, which means you are likely to be very far off to do useful traffic engineering, if (3) or (2) failed Beware that pointing a defaul-route might do some damage if you use uRPF, but you use uRPF, you would have probably posted this message some years ago... :-) 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/
Re: [c-nsp] NPE G1, CEF and ACLs and high CPU
Such algorithms are indeed used, as you can see at the IOS reference for the access-list compiled command where the ACL is converted to a data structure that is O(1). I don't know which algorithm they use in IOS nowadays, but for a very good reference on all of those algorithms (using RAM or CAM), I recommend this paper: Survey and Taxonomy of Packet Classification Techniques by David E. Taylor: http://www.cse.seas.wustl.edu/Research/FileDownload.asp?334 Rubens On Tue, Sep 9, 2008 at 2:07 AM, Alex Balashov [EMAIL PROTECTED] wrote: Are you serious? Well, I unhappily and disappointedly stand corrected, then. Indeed, Cisco documentation appears to confirm what you and Bill are saying. There are a variety of known algorithms for traversing hashed structures while taking order of precedence into account. I am, quite frankly, astonished that they are not used, or that it takes some sort of ASIC or TCAM enhancement to make that happen. Adrian Chadd wrote: Bill is practically right. The semantics for Cisco ACLs aren't here's a set of IP ranges, apply this behaviour, they're a linear walk of rules from top to bottom applying behaviour at each step. Collapsing that into the smallest set of possible operations is -not- taught at first/second year computer science. Eg: * permit ssh 1.2.3.0/24 * deny ssh 1.2.4.8/30 * permit ssh 1.2.0.0/16 * deny ssh 1.0.0.0/8 Please yank the first year computer science curriculum bit which provides the student with the clue required to algorithmically determine the smallest set of permit/deny's keeping the above semantics correct. Then do some basic analysis to find out what the resource bounds are on determining that. Oh, then prove that you can evaluate it in more or less O(1) time. Go on, I dare you :) (Note: I -think- the TCAM ACL rule programming in later IOSes can do that? Perhaps Rodney or someone else from Cisco can comment.. :) There's some rule folding (and compiling?) stuff that I've heard about in later software-forwarding IOSes which attempt to mitigate this somewhat but I've never really sat down and (ab)used it. Now, I suggest you go back and read how iptables / ipfw / pf rules are actually -parsed- and -handled- in the various *NIXes you speak of. I've done this exercise and I'll give you a hint - rules are evaluated much the same as they are on the Cisco, except in some cases the evaluation doesn't stop at first hit and there are other gotchas (like match X goto rule Y). Go figure out why. I'll give you an even bigger hint - the best way to get a speedup under *NIX packet filters is to build sets of IP addresses to apply your policies rather than individual rules for each network you want to allow SSH for. The difference between one rule w/ a 200,000 network IP set versus 200,000 entries is pretty staggering - and the latter depends on the rule ordering. Just like Bill said. :) Adrian On Tue, Sep 09, 2008, Alex Balashov wrote: Are you _sure_ that order is important in these ACLs? I ask because I honestly don't know, so don't get me wrong. It just seems rather unlikely. Organising data like that into structures where matching and access can happen at more or less an O(1) formal computational complexity is a basic skill that is taught at the beginning of any undergraduate curriculum in computer science. Students are taught to understand that large amounts of random (non-sorted) data cannot be stored in a linear structure, and that even linear structures with comparatively few elements (such as an access list) can be very slow if the lookup is repeated with very great frequency. That's why such data gets stored in multidimensional and relational data structures: things like binary trees (and their innumerable permutations), undirected string vector graphs for heavy lexical token matching, hash tables, and various relational mechanisms for forming bindings or indices from a quick and superficial glimpse at the data. It's how every firewall/packet filtering engine (such as Linux netfilter, or the FreeBSD packet filter) is implemented, so packets are matched using a hashing strategy rather than linear, iterative comparisons. What you appear to be suggesting in your dwelling upon the significance of rules being at the bottom or top of an access list definition would also imply that these basic algorithmic innovations and elements of the software engineering canon have somehow managed, with great finesse, to escape the notice of the people who wrote IOS. I refuse to believe that. bill fumerola wrote: [ reading through quickly, just some ACL pointers.. ] On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: ! deny rogue IPs (it is interesting how many catches are here) deny ip 10.0.0.0 any deny ip 192... any deny ip host 0.0.0.0 any this breaks PMTUD. icmp messages from poorly addressed routers still need to get back to your hosts.
Re: [c-nsp] Service-Policy on 1800 SVI
Does the same apply to Cisco 881 ? Rubens On Sun, Sep 7, 2008 at 10:47 PM, Brett Looney [EMAIL PROTECTED] wrote: I'm running into an issue on a 1841 router where I have an internet feed coming into one of the integrated switchportsI have the vlan that the switchport is configured in as a EtherSVI with a public IP address. I need to configure a policy-map with QoS but it appears you cannot configure a service-policy on a EtherSVI...Is this correct? That's pretty much correct. You need to put the service policy on a routed port - either one of the two onboard Ethernets or get one of the routed HWIC cards (such as a HWIC-1FE) which are (of course) much more expensive than the HWIC switch cards. Putting a service policy on a SVI just doesn't work. On some platforms you can do it but you are severely limited in what you can do in that policy. B. ___ 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] c7604 starter kit
You might also look at ASR1k as next-gen PE to replace VXR. 7600 has limitation in hardware, especially in terms of IPv6 (no IPv6 uRPF, lookup key size has compromises in ACL usage and others). When you compare 7600 with SIP/SPA, ASR1k is even cheaper solution and much more flexible. One thing to notice is that ASR1k does not currently have EoMPLS support in any software, but other than that, all generally used features are supported. If I'd need non-ethernet interfaces, vlan local signifance or HQoS and I wouldn't need EoMPLS, I'd definitely go with ASR1k rather than 7600. Can an ASR1k handle 3 full-routing transit feeds and a hundred peers ? Would it require ESP5 or ESP10 ? On the MPLS side, beside EoMPLS, can it do MPLS L3 VPN and MPLS-TE ? 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/
Re: [c-nsp] Crash bug in SXH3
We are informed that SXF code also has the route-map bug, but we have more confidence in that code (having removed route-maps in it many times without problems) so we have reverted to SXF6 while awaiting a new SXH build. SHX4 is a quarter away, any sightings of a SXH3a on the horizon ? 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] SXH3 SP memory requirements
My understanding of the SXH3 release notes was that monolithic IOS (Adv. IP Services feature set) requires 256MB of SP(Switching Processor) memory (which is the ME6524 default) and 512MB of RP(Routing Processor) memory (also the ME6524 default). I've opened a TAC case (SR 609292161, if any Cisco employee wants to review) and TAC tells me that 512MB of SP memory is required to run SHX3. I've tested it on the lab and it seems to boot... any comments ? 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/
Re: [c-nsp] Metro / NGN hardware/design
My first issue is with VPLS, aside from requiring very expensive hardware, is it reliable enough for this? (we're the national telco, this will be carrying 999/911/112 calls) Since you are designing the network ground-up, you can use whatever fits best, and VPLS definitively isn't. I think L3 is the tool for this job, but I can see a point in PBB/PBB-TE designs so I would take a (cautious) look at it. Would it make sense to build a seperate highly-reliable layer 2 network just for the voice to focus on getting extreme uptime out it, and another higher-capacity, feature-rich network for the broadband/ethernet services? Only if they are truly separate networks, and the voice load can take over the data network if primary voice network fails. Any suggestions on how to go about building such a layer 2 network with cisco kit? Any opinions of Cisco's REP? ME6524s in each main exchange, ME3400s in each mini-exchange, running REP? ME6524s can't do REP these days; they will soon, but I'm trying for week to know what is Cisco's definition of soon. A gige ring (or several) running around the island linking all of the mini-exchanges? A wdm ring (or several) delivering hub-and spoke connectivity from each mini-exchange to each main exchange? Follow the physical topology, failure modes and outside threats (someone digging near the fiber, drilling oil, chem leakage, local bad guys, outside invasion forces). Because of the voice nature, convergence should be as low as is realistically possible, preferably with the likelyhood of human error reduced as much as possible. Redundant networks can survive equipment failures much easier than human error; simpler networks stand human error better. If you have two networks, and only one of them (the data services network) is being constantly touched by operators to provision new services, the other network will probably survive a long time before someone messes with it. But it can happen, so your procedures should keep changes from being done at both networks in some window (say, a week), so there is always one for the voice traffic to flow. 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/
Re: [c-nsp] Error using VFI with local VLAN's on 7600/RSP720 12.2 SRC1
Can he add VLAN translation to the scenario ? Rubens On Sun, Aug 31, 2008 at 4:13 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Stephen Fulton wrote on Sunday, August 31, 2008 2:03 AM: Hi all, I'm testing out VFI's in a lab, and I've run into the following when I attempt to add a second VLAN to the VFI instance. well, adding a 2nd SVI/Vlan to a VFI doesn't make sense (at least to me), if you want to bridge both segments (and the remote VFIs) together, you would put them into the same broadcast domain (speak: vlan). You can't use VFI/VPLS to create a single bridge domain for two local vlans. 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] best fault management solutions?
Smarts is what used to be BMC Patrol or something else ? How it compares price-wise to Cisco Works ? Rubens On Thu, Aug 21, 2008 at 2:39 PM, [EMAIL PROTECTED] wrote: Hello, Then you want a see this: http://www.emc.com/products/family/smarts-family.htm Smart is a monitoring tools with corolation engine. If you router crashes, you will know about, and you will also know what's behind that router that you just lost and then gives you the impact. It can go up to servers. - dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregori Parker Sent: August 21, 2008 1:29 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] best fault management solutions? I've had it with Ciscoworks. I'm not new to getting LMS working properly, I'm just tired of lowering my expectations. Device discovery is hit and miss, new versions seem progressively worse, and the whole product is about as ergonomic as a pile of broken glass. I've stripped it down to just common services and DFM, but there just isn't enough value there relative to resources. So, I'm looking for DFM-like replacement recommendations - I currently have configuration and performance management covered by rancid, cacti, syslog-ng and a few other open source tools; and I have netflow taken care of - I'm just having trouble finding a good solution for device fault management (i.e. temp, fan, interface errors, queues, broadcast rate, bgp neighbor state changes, etc) for a mostly-Cisco environment. I need something with a little bit of intelligence, not just a simple trap forwarder. Have already evaluated Orion, but it has too many extras that I don't need (i.e. netflow, traffic graphs, configs, et al are already handled) and not enough of what I do need (device awareness, alerting). Not concerned with cost and platform, thanks in advance. - Gregori ___ 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] MPLS VPN Question about PE-CE - Private or Public IP?
If you have 2 two virtual channels on the PE-CE link, one can be used for management and belong to the Management VRF, while the other belongs to the customer VRF. It's easier to do this when the connection is Ethernet, where a virtual channel is a VLAN. On TDM world, running frame-relay encapsulation might do the trick. On ATM, VPI/VCI. Rubens On Tue, Aug 19, 2008 at 10:19 PM, Andy Saykao [EMAIL PROTECTED] wrote: Just wondering from those in the know, whether it's best practice to implement public or private IP's for the PE-to-CE link. What's everyone using and why? For our MPLS network, I've been asked by my Manager to use private IP's for the PE-CE link in order to give the customer the appearance that they are on a secure PRIVATE network due to private IP's being used. Although I tend to be more fond of using public IP's because it's a unique address space so you don't have to worry about overlapping IP addresses on the customer's end and secondly there's no configuration from the Service Provider's end should you need to remove the connection from the VRF to conduct further testing from the Internet becuse the connection is already using public IP's (eg: for cases where the customer is complaining of slow speeds, packet loss, drop outs, etc and you want to test the individual connection and bypass their VPN). Thanks. Andy This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organisation. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email. ___ 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] Cheap STM-1 router
Hi. I'm trying to convince a friend not to use SDH-to-Ethernet mux and instead go for a router-based solution, but I've only found ATM network modules to go with 3xxx series routers. What would the cheapest(new, used, refurbished, all of above) Cisco gear that could: 1) On the remote sites, have STM-1 SDH connection; no sub-channeling, just a single IP interface with all the STM-1 capacity. 2) On the central site, have STM-16 SDH connection; some channeling is required, so each remote STM-1 is a sub-interface. Tks, 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/
Re: [c-nsp] SXI on 6500 (was: SXH on 6500)
That is good news. The other good news would be that SXI monolithic could run with only 256 MB of SP memory and 512 MB of RP memory (default config of ME6524) ,Advanced IP Services. Any guess on this one ? Rubens On Tue, Aug 12, 2008 at 11:11 PM, David Prall [EMAIL PROTECTED] wrote: Both will remain for SX releases as far as I know. Eventually only modular will be available, but that is still a while out. I believe once we start seeing Safe Harbor Modular releases we will be closer to that happening. David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Tuesday, August 12, 2008 9:56 PM To: [EMAIL PROTECTED] Cc: Cisco-nsp Subject: Re: [c-nsp] SXI on 6500 (was: SXH on 6500) Robert, Updating this modular x monolithic thread to SXI, what's the current plan for SXI, modular only or both modular and non-modular ? Rubens On Tue, Oct 2, 2007 at 12:07 PM, Robert Crowe [EMAIL PROTECTED] wrote: SXH was originally planned to be modular only, but a non-modular image was released. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Mayers Sent: Tuesday, October 02, 2007 10:48 AM To: Gert Doering Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] SXH on 6500 On Tue, 2007-10-02 at 11:11 +0200, Gert Doering wrote: Hi, On Tue, Oct 02, 2007 at 09:53:12AM +0100, Phil Mayers wrote: You are aware that SXH is only available in modular? That's news to me and my routers :) -rw-r--r-- 1 gert daemon 77939716 11 Sep 10:26 s72033-advipservicesk9_wan-mz.122-33.SXH.bin -rw-r--r-- 1 gert netmaster 123923108 20 Aug 23:32 s72033-advipservicesk9_wan-vz.122-33.SXH.bin gert You're correct of course. How odd - I'm looking at a pretty recent .ppt from Cisco claiming SXH would be modular-only. I guess they blinked. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SXI on 6500 (was: SXH on 6500)
Latest info I've got is that the ME6500 is under the ISBU, Internet Systems. 7600 is under the ERBU, Edge Routing, and 12000/CRS is under the CRBU, Core Routing. Rubens On Wed, Aug 13, 2008 at 12:14 PM, Justin Shore [EMAIL PROTECTED] wrote: Phil Mayers wrote: You're the 6500 IOS team. You have a large body of upstream IOS code, and you have to back-port it, but at the *same* time you also have to modularise it. I'm really going to dive off into OT land, but does anyone know if the Metro Ethernet 6500 is under the Enterprise BU or if it's the Service Provider BU? I've gotten contradicting answers before. It would seem really odd to me for the ME6524 to be under the Enterprise BU, no matter what its roots are, because on SPs will use it. Likewise I don't understand why it runs SX and not SR if it's in the SP BU. 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/ ___ 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] CLIPS functionality for DHCP clients
I don't think there is any Cisco low-end solution to this; 7200, ASR, 10k and SCE are the platforms I think can do this one way or the other. Consider using Mikrotik or NoCat/NoDog solutions (http://nocat.net/). Rubens On Wed, Aug 13, 2008 at 5:23 PM, Kyle Johnson [EMAIL PROTECTED] wrote: All- I'm trying to create a solution to allow for subscriber management based on client PC MAC address. I see that Redback offers this CLIPS (CPE mac address RADIUS record) method of subscriber management but Redback equipment is pretty pricey... Does anyone have a suggestion on a Cisco equivalent (PPPOE functionality/sessions based off client MAC rather than PPPOE config..) that will run on lower-end gear? Thanks- Kyle ___ 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] 1252ag backwards compatibility
Can it be prevented, i.e, configuring 1252 to only run 802.11n, even in WDS mode ? We are hoping that 802.11n can improve on Wi-Fi tradition of having low pps rate, which is due to the sum of the 802.11b/a/g standard and low speed processors on the devices. Rubens On Wed, Aug 13, 2008 at 7:49 PM, Frank Bulk - iNAME [EMAIL PROTECTED] wrote: Dan: Unless you're running Greenfield mode, which I'm not sure you can even configure on a Cisco AP, there's full backward compatibility such that 802.11b/g clients will operate at b/g and 802.11n clients (with 2.4 GHz support, of course) operate at n. Be aware that mixing 802.11n with 802.11b/g clients will reduce overall performance, but not significantly enough to devalue running 802.11n. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Letkeman Sent: Tuesday, August 12, 2008 8:02 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 1252ag backwards compatibility Hello, I'm wondering if anyone that has deployed 802.11n 1252 AP's can tell me if you have 802.11g clients and some 802.11n clients all on 2.4ghz, do the 802.11n clients run at 802.11n and the 802.11g clients run at 802.11g? Or does everything run at 802.11g? 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/ ___ 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] ME6500
On Tue, Aug 12, 2008 at 8:28 AM, Adrian M [EMAIL PROTECTED] wrote: Hello, I have a cisco ME-C6524GT-8S with software s6523-advipservicesk9-mz.122-18.ZU2 and I don't know how to do some basic things like: How to clear an arp entry clear ip arp 10.10.10.10 doesn't work :( On some platforms, conf t +no arp a.b.c.d can do this, but I haven't tried it on ME6524. Is clear arp interface xxx where xxx is the interface where the arp entry is located won't probably be that hard, unlesss you have thousand of entries on that routed or SVI interface. How to display mac learned on a routed subinterface sh mac-address-table don't display mac addresses for ports like Gi1/10.200 I don`t think routed subinterfaces have mac-address-table, by definition... ping broadcast address of Gi1/10.200 (use both all-zeros and all-ones broadcasts) followed by show ip arp gi1/10.200 will likely show whoever is attached to that interface (even for hosts that don't answer ping, because it's not common to filter out arp requests/responses in host firewalls these days). 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/
Re: [c-nsp] ME6500
On Tue, Aug 12, 2008 at 8:53 AM, Adrian M [EMAIL PROTECTED] wrote: On some platforms, conf t +no arp a.b.c.d can do this, but I haven't tried it on ME6524. Is clear arp interface xxx where xxx is the interface where the arp entry is located won't probably be that hard, unlesss you have thousand of entries on that routed or SVI interface. no arp a.b.c.d doesn't work :( clear arp x.x.x.x doesn't exist either. clear arp-cache interface GigabitEthernet 1/10 is not clearing arp entries from GigabitEthernet1/10.215 clear arp interface GigabitEthernet1/10.215, perhaps ? How to display mac learned on a routed subinterface sh mac-address-table don't display mac addresses for ports like Gi1/10.200 I don`t think routed subinterfaces have mac-address-table, by definition... ping broadcast address of Gi1/10.200 (use both all-zeros and all-ones broadcasts) followed by show ip arp gi1/10.200 will likely show whoever is attached to that interface (even for hosts that don't answer ping, because it's not common to filter out arp requests/responses in host firewalls these days). Ok ! But the box is still a switch. It uses internal vlans. And still one can disable mac-learning on any vlan, whether it has an SVI or not. 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/
Re: [c-nsp] ME6500
There were some platforms like the 7500 where no arp in config mode did work for dynamic ARP entries. As I said, I haven't tested it on the ME6524, neither with SVIs or routed interfaces, neither with ZU2 or SXH IOS. An ARP entry associated with DHCP Snooping / Dynamic ARP Inspection / IP Source Guard may also show a different behavior than a pure dynamic ARP entry. Rubens 2008/8/12 Tassos Chatzithomaoglou [EMAIL PROTECTED]: Justin, no arp in config mode should work for static entries only. -- Tassos Justin Shore wrote on 12/8/2008 4:17 ÎĽÎĽ: The argument for clear arp-cache is an interface or null. 6524-2.brd#clear arp-cache ? interface Clear the entire ARP cache on the interface cr Ruben was correct with 'no arp ip' from global config mode on that platform with the ZU code. Justin Tassos Chatzithomaoglou wrote: clear arp-cache x.x.x.x should work. Just keep in mind that after doing this, the local router will send an arp request to this mac. If it's still active, a reply is sent back and the local arp table will be filled again (you can check the Age counter). -- Tassos ___ 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] SXI on 6500 (was: SXH on 6500)
Robert, Updating this modular x monolithic thread to SXI, what's the current plan for SXI, modular only or both modular and non-modular ? Rubens On Tue, Oct 2, 2007 at 12:07 PM, Robert Crowe [EMAIL PROTECTED] wrote: SXH was originally planned to be modular only, but a non-modular image was released. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Mayers Sent: Tuesday, October 02, 2007 10:48 AM To: Gert Doering Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] SXH on 6500 On Tue, 2007-10-02 at 11:11 +0200, Gert Doering wrote: Hi, On Tue, Oct 02, 2007 at 09:53:12AM +0100, Phil Mayers wrote: You are aware that SXH is only available in modular? That's news to me and my routers :) -rw-r--r-- 1 gert daemon 77939716 11 Sep 10:26 s72033-advipservicesk9_wan-mz.122-33.SXH.bin -rw-r--r-- 1 gert netmaster 123923108 20 Aug 23:32 s72033-advipservicesk9_wan-vz.122-33.SXH.bin gert You're correct of course. How odd - I'm looking at a pretty recent .ppt from Cisco claiming SXH would be modular-only. I guess they blinked. ___ 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/
[c-nsp] PFC-based EoMPLS and MPLS-TE
I was wondering if anybody has mixed EoMPLS and MPLS-TE, running on PFC-based MPLS (Sup720, ME6524 and related platforms) in a scenario like this: PE1 MPLS Cloud with TE affinity bits PE2 PE1 and PE2 have an EoMPLS xconnect with each other, targeted at each router loopback. Affinity bits are configured on the links on the cloud based on whether they support Jumbo-frames or not. First part, a tunnel is created with affinity requirements such as it will always use interesting links; then, a static ip route other routers loopback tunnelxxx makes all traffic between PE1 and PE2 go thru that tunnel. Can this scenario work ? WIll LDP run thru the tunnel, as EoMPLS opens an LDP session between PE1 and PE2 ? Running thru the tunnel or not, will LDP correctly allocate labels so the EoMPLS connection goes thru ? Will this adversely impact the other traffic between those PEs, besides the fact that all PE-to-PE traffic will now follow the tunnel ? 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/
Re: [c-nsp] Crash bug in SXH3
Phil, Are there any memory issues with SXH3 on your lab ? It seems SXH3, modular or monolithic, requires more SP/RP memory than SXH2a. Rubens On Thu, Aug 7, 2008 at 7:00 PM, Phil Mayers [EMAIL PROTECTED] wrote: All, Just a warning, there is a fatal crash bug in SXH3 related to using SCP. Considering the release notes claim fixes in that very area, this is highly amusing (note: issue may not actually be amusing) Does anyone else think the 6500 software train is becoming a bad joke? SRC claims *today* ISSU using dual sups / SSO, a much larger chunk of (33) features e.g. 6vpe etc. and one presumes a faster rate of ports from mainline IOS because they don't need to modularise everything. SXH on the other hand has... erm... buggy modularity. And... buggy monolithic too. I haven't got a TAC case open because we've rolled back to SXH2a (which has its own set of crash bugs, but less frequent ones...) and it's late - a task for tomorrow I feel. ___ 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] MPLS PE Routers for a Mobile Carrier?
12000. ME6524 seems a good fit for this environment, J-2320/6350 could be the J-land options to explore (although ISR 38x5 are their counterparts at C-land, not the ME6524). QoS in PE and catalyst doesn't seem good fit to me. Unless you have dedicated port to each customer. But in view most all PE usages include customers in VLAN, in which case, to do any QoS, you need HQoS, which LAN cards can not do. They are cheap for a reason. mls qos vlan-based can be turned on to do PFC-QoS on VLANs... (at least on PFC3C, but I thought it was supported on other PFC3 releases). HQoS is nice for building services like 25% of the bandwidth has voice priority, if no voice traffic present you can go up to 100%, if more than 25% is voice than only 25% will have expedite forwarding, but if you provide simple CIR/PIR services per VLAN, differentiating needs by different VLANs, what could be achieved by HQoS that PFC-QoS would do only by dedicating a port ? Rubens 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/
Re: [c-nsp] MPLS PE Routers for a Mobile Carrier?
AFAIK, ASR 1000 or 4500/Sup6-E don't support MPLS in current software releases, so your Cisco-land options are ISR 38x5, 6500, 7600 and 12000. ME6524 seems a good fit for this environment, J-2320/6350 could be the J-land options to explore (although ISR 38x5 are their counterparts at C-land, not the ME6524). Rubens On Sat, Aug 2, 2008 at 5:20 PM, Felix Nkansah [EMAIL PROTECTED] wrote: Hi, I am working on an MPLS proposal for a mobile carrier (with 2mil+ customers). I need to decide on what routers to use as PE and P for their backhaul between 5 sites. I am torn between proposing the Cisco ASR 1000 OR the Cisco 7600 series as PE/P. Please let me know what your expert opinion is on this matter. They require MPLS VPN, TE, and QoS. Regards, Felix ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] 7603-S
Hi. CCO datasheets weren't heplful where a 7603-S can or cannot - Be ordered with Advanced IP Services IOS - Be ordered with AC power - Be ordered with a XL sup (either SUP720-3BXL or RSP720-3CXL) (Product Configurator access has been cut off for our CCO account, so we couldn't otherwise validate the claims of our sales rep. that 7603-S cannot have Adv. IP Services or AC power) 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/
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] 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/
Re: [c-nsp] ME6524 alternative
Cost issues and the relationship wit the local subsidiary; we have very little problems with the ME6500, one being the BFD with SVIs issue that you don't like either if I recall correctly. Cost is high but it can cut both ways. That leads to a long discussion for another day and I'm sure you're already familiar with all the talking points. Yeap, but we've got a 3x price hike on the ME6500 from our initial purchase to current quotes, which left us no choice but to evaluate alternatives. 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. Are you sure ME3750s are doing good for your network ? We had tons of issues with 3750-Metro, a product that I strongly recommend for my competitors... we haven't tested ME3400 which sound very nice (but doesn't have MPLS) or 4500 with Sup-VI (no MPLS on the software yet). We haven't had any problems with them. I just returned from the MetroE training course in SJC and the ME3750 played an important role in the course. It worked fine in the class. I think it's important that people understand what the ME devices were designed for and deploy them with that in mind. This is something that I failed at initially. The ME3750 wasn't designed to be a generic DC-powered L3 switch. It was purpose-built for L2VPN termination and some aggregation. When people like myself think that it's an all-encompassing MPLS box then they get sorely disappointed. I was. But it works well for what it was designed to do. 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. 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/
Re: [c-nsp] ME6524 alternative
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 the access ring, tuning STP/RSTP/MST, etc. It's a good class if you're interested. I think such rings would be better served by using REP (Cisco) or EAPS(Extreme); ME6524 doesn't support REP today, but that's probably just one version away. 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] ME6524 alternative
Hi. After an initial deployment with many ME6500's (ME6524-24GT-8S to be exact), we are finding too difficult to deal with Cisco for the expansion. What clear alternatives are available from other vendors or either from Cisco as a nice MPLS router with Ethernet only interfaces, even with less backplane or with 10/100 access interfaces ? 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/
Re: [c-nsp] ME6524 alternative
After an initial deployment with many ME6500's (ME6524-24GT-8S to be exact), we are finding too difficult to deal with Cisco for the expansion. What clear alternatives are available from other vendors or either from Cisco as a nice MPLS router with Ethernet only interfaces, even with less backplane or with 10/100 access interfaces ? Out of curiosity, what problems are you having? Is it a hardware issue or a service issue? I have a couple ME6524s and have been happy with them. We also have some ME3750s and they've been good too. The MEs are designed for specific solutions. Cost issues and the relationship wit the local subsidiary; we have very little problems with the ME6500, one being the BFD with SVIs issue that you don't like either if I recall correctly. Are you sure ME3750s are doing good for your network ? We had tons of issues with 3750-Metro, a product that I strongly recommend for my competitors... we haven't tested ME3400 which sound very nice (but doesn't have MPLS) or 4500 with Sup-VI (no MPLS on the software yet). 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/
Re: [c-nsp] Shared Support versus Smartnet
On Sun, Jul 6, 2008 at 4:18 PM, Paul Stewart [EMAIL PROTECTED] wrote: Hi Rubens... Sorry if this is sidetracking the conversation a bit - apologies. But, what can folks tell me about shared support in general? I always thought it was Smartnet or nothing hence why I'm asking... is this 3rd party Cisco support that I've seen advertised a few times? Don't know for sure, but probably yes. With shared smartnet, do you lose the ability to contact TAC directly? Yes, according to CCO docs. L1 and L2 are done by partner, TAC gets involved from L3 and above. What about software updates - from Cisco or from the partner?? Partner, according to CCO docs. I'll only know for sure in a few weeks when we renew our contracts. Cisco Shared Support looks very similar to the old PICA contracts; Cisco and partners insist they are different, but the more I look, more I feel they are the same. 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/
Re: [c-nsp] Support versus warranty/RMA
Smartnet or nothing hence why I'm asking... is this 3rd party Cisco support that I've seen advertised a few times? With shared smartnet, do you lose the ability to contact TAC directly? What about software updates - from Cisco or from the partner?? To go along with Paul's question, what about hardware warranty RMA? Shared Support gives you support level hardware maintenance, not warranty level. Shared Support is usually same day ship/next business day, but could give a faster replacing policy if the partner can afford the logistics to do it and you can afford to buy the service. Usually they cannot, so if want 4h or 12h you probably need to stick with Smartnet, but that is up to the partner so they might do it. 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/
Re: [c-nsp] WS-X6748-SFP 7600 MPLS
You didn't mention if is a DFC-equipped WS-X6748-SFP or not, but I don't think it matters: the card doesn't have service capabilities and will fall-back to PFC-based MPLS, which might satisfy your requirements or not. No FlexWAN/OSM/ES20 services, just plain vanilla MPLS. Rubens On Mon, Jul 7, 2008 at 5:23 AM, Mark Tech [EMAIL PROTECTED] wrote: Hi Can the WS-X6748-SFP support MPLS on a 7600 chassis? Regards Marl ___ 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] 7600 vs MX experience?
On a recent event I could meet with lots of people from carriers of all sizes in the LAC region, so I will summarize based on the overall experience: - There were far more stories of instability on the 7600 than on Juniper, even from those that uses both as Ps and PEs. I can't precise whether the Junipear gear was M-, MX- or T- series. IOS versions that solved that bug that was annoying but introduced some different bugs of their own were also a popular quote. - On the other hand, people with simpler 7600 configurations had less problems and could use more IOS versions that the others. That's my direct experience: with no FlexWAN, OSMs or ES-20s service cards, you have much more flexibility in adopting newer software and has fewer bugs to deal with. - Support experience with Cisco from carriers that had either Cisco SmartNET contracts or Cisco Shared Support from one Cisco Partner (let's name them and reward their good service: NEC) was rather good, but other Cisco Shared Support partners were awful at supporting carrier needs. Support experience with Juniper was good whether they called a partner(the same partner serves most or all of Juniper carrier customers in the region) or Juniper directly. Based on that experience, may I suggest some ideas ? 1) If you are going to avoid using 7600 with service cards, then don't get a 7600. Get a ME6500 or some other Catalyst with the port density you need. No VPLS, some restrictions on EoMPLS (port or subinterface but no VLAN-based EoMPLS), but they cost much less, are stable and made by a friendly BU. ME6500 has H-VPLS, so you can provide VPLS services if you have a VPLS concentrator somewhere, which then would be a pricier 7600, or a Juniper with low port density (M7i-2GE for instance). 2) If you buy Cisco gear and don't know wether you Shared Support partner will do a good job, buy some boxes with SmartNET and some boxed with Shared Support for the 2nd year. On the 1st year you will probably get SmarNET because of Cisco sales policies, so you will already have a quality to compare to. From 2nd year on, Shared Support will be much cheaper and you will be tempted to buy all support in this flavor, but beware of the provider you don't know yet. 3) Think a lot before doing VPLS services, as the customer may think it's good due to no subnetting or renumbering, but point-to-multipoint is something that I really prefer to see routed. IP VPN with Multicast can probably fit most customer needs instead of VPLS. Rubens On Sun, Jul 6, 2008 at 1:00 AM, Kris Price [EMAIL PROTECTED] wrote: Hi, We're looking at 7600 + RSP720 platform and the MX from Juniper for our MPLS needs and I was interested in hearing feedback from people about their experiences - both positive and negative - with either platforms. Whatever is selected will be used both as Ps and PEs w/ all 10GE on the core side. This is a fairly large (continental) deployment, and it will set the standard internationally for this customer. Main use will be for IP VPN and EoMPLS, but VPLS may show up in the future too. Looks like they both will work for our needs. So what it really comes down to is important things like *stability*, support experience, etc. Please contact me off list if you'd rather not express something in public. Feedback is very much appreciated. :) Cheers Kris ___ 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] 12.2(33)SXH
After less than enthusiastic responses to 12.2(33)SXH2a (see the two messagens in the cisco-nsp archives about it), have anyone got a timetable to SXH3 or SXH2b ? 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] IOS JUNOS MPLS-TE interoperability
Hi, Does anyone has experience with MPLS-TE interoperability between IOS (specifically ME6500, but it's probably like any other 12.2SX IOS) and JUNOS (recent/stable/good-for-service-providers version) ? I was wondering about 2 cenarios in particular: 1) JUNOS as head-end or tail-end, but not middle-point 2) JUNOS as head-end, tail-end and middel-point All routers would be in the same OSPF area 0, within the same AS #; TE is done by explicit naming of both primary, secondary paths, and a dynamic backup path. AUTOBW is desired. On IOS, traffic is injected on the tunnel using static route to the loopback address; OSPF contains only link states and loopbacks, directly-connected, customer static routes or customer dynamic routes are propagated via IBGP. Tks, 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/
Re: [c-nsp] Any 3xxx Switches support MPLS?
It has port-group based oversubscription, each group has 1 ASIC serving 3 ports (and it's not 1-3, they are L-shaped port groups looking at the physical ports). A good port assignment strategy can make management ports and slow customers grouped with a single high speed customer, or leaving it alone in a port group altogether. The backbone ports, on the other hand, are not over subscribed. So you can call it a 16-port Gigabit switch or an 8GE+8GE+16FE switch... Rubens On Wed, May 7, 2008 at 5:39 AM, Tima Maryin [EMAIL PROTECTED] wrote: But keep in mind that it has oversubscription on non uplink ports Rubens Kuhl Jr. wrote: 2) Buy ME6524, which is a very good box ___ 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] Internet vrf, pros and cons
The issue with VRFs is that it can't do policy routing, because it's already a routing table selection... I agree that box security should be taken care with CoPP. Put Internet customers on the main VRF, but carefully design ACL, policy-routing and CoPP to reach your security goals. VRFs are great with overlapping IP spaces, but on the Internet where everybody on the world agrees on an addressing plan, just use plaing routing. Rubens On Tue, May 6, 2008 at 6:08 AM, Mark Tech [EMAIL PROTECTED] wrote: Hi We area going to deploy a new MPLS network which will be used for Internet customers and IP/VPN customers. I understand that there are two options with running these networks: 1. Run the internet natively across all boxes and secure them down against DoS attacks etc 2. Create an Internet VRF whereby all internet traffic is simply seen as a large IPVPN network, thereby utilising some of the inherent security factors associated with IPVPNS My question is whether anyone has other pros and cons from real life experience, associated with the two options previously stated. I would like to add that the platforms will be provisionally Cisco 6500s with SUP720s (edge) and Cisco XR 12406's (core) Regards Mark Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ 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] Any 3xxx Switches support MPLS?
Only 3750 Metro supports MPLS, badly. Filling the annual customer satisfaction survey section about the 3750 Metro always inspires me a death-wish that I would rather not have. May be the the Juniper EX boxes will have MPLS in a year or two, but for the mean time, you can consider 1) Using Multi-VRF instead of MPLS to provide IPVPN services, and then use something like the 3400ME with METROIPACCESS image 2) Buy ME6524, which is a very good box 3) Combine Juniper EX with Juniper J routers so you can have density, L2 backplane, L3 routing on the EX box, but enough MPLS routing capacity on the J box to provide services to a growing POP Option 2 is what we do today, considering wether to use option 1 or 3 to grow the network. Rubens On Tue, May 6, 2008 at 7:41 PM, Skeeve Stevens [EMAIL PROTECTED] wrote: Any 3xxx Switches support MPLS? i.e. 3550, 3560, 3750, and so on? .Skeeve -- Skeeve Stevens, RHCE [EMAIL PROTECTED] / www.skeeve.org Cell +61 (0)414 753 383 / skype://skeeve eintellego - [EMAIL PROTECTED] - www.eintellego.net -- I'm a groove licked love child king of the verse Si vis pacem, para bellum ___ 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] Wanting to learn Juniper...
Still, I almost fell out my chair at the Cisco is flawless comment. Look, those people with all those headaches with the 6500 on the 6500 vs 7600 thread... they're not lying. The split got off to a shaky start and it aggravated a lot of people. A lot of those boxes got ripped out of networks because every new IOS was deferred or redacted. I personally spent a lot of time at my previous job banging my head against the wall troubleshooting them. I guess its a lot better now that time has passed and some wrinkles got ironed out, but man... I'm pretty sure the Cisco is flawless comment had 101% of sarcasm. Who wrote it seems to have suffered the same we all have. 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] Smartnet x SP Base
After reviewing a handful of documents on CCO, I couldn't find the difference between the Smartnet and the SP Base service contract offerings. There are documents comparing each one to warranty, but they seem to have the same differences to warranty... - Does anybody know what is different between those service offerings in terms of service and pricing ? - What ended up being your choice and why ? As usual, private replies will be anonymized and summarized to the list. 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/
Re: [c-nsp] ASR 1000
I see no netflow word in the ASR 1000 RP datasheet... :( It is mean no hardware support available or just in future software releases? P.S Seems good replace for 7200 series: software and PXF-based! The ASR 1006 seems to be a 1 replacement; disappointed 1 users will probably welcome the box if it actually works. 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/
Re: [c-nsp] EoMPLS between 7600 7200 config clarification
Is this the only way to get EoMPLS to work between these two devices? I'm sure I've seen the xconnect command used on VLAN interfaces before and it has worked fine. Use VLAN interfaces on both sides, or subinterfaces on both sides, or ports on both sides. Some platforms/versions also don't support VLAN-based EoMPLS, only port or subinterface; 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/
Re: [c-nsp] BFD aware VRF
I did try with an ethernet link between PE and CE, and bfd config looks good. Unless you're Ethernet links are 1Q trunks like what you'd have between a site with a pair of redundant routers doing both L3 and access layer connections (FHRPs). SRC removed BFD on SVI support, as did SXH on the ME6524s. Yes, I'm beating a dead horse but it aggravates me nonetheless. I need to upgrade to SRC but I am going to lose BFD support as soon as I do, pushing my recovery times up into seconds; far from the milliseconds Cisco sold us on when they blessed this design. And I'm still waiting for the reason why this has been removed from the code, or why it's an issue to support BFD with SVI. And I'll keep beating both dead horses, at least till Cisco or Juniper (EX series) comes up with a solution. 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/
Re: [c-nsp] Netflow Export Problem
Packets originating from the router can be controlled by: ip local policy route-map name of the route map One thing I would try, but I have no idea if it works, is policy routing the traffic to a loopback interface that belongs to a VRF. The netflow export address would be the one inside the VRF, the source will be inside the global routing table, but the PBR would match udp to that address and port and set the next-hop to the loopback interface. Let's repeat: it's just an idea, not something from a reference or that had real testing. Rubens On Feb 3, 2008 12:06 PM, Phil Mayers [EMAIL PROTECTED] wrote: Checking my own MLS NDE configurations, it looks very similar - *but* I am not exporting to a VRF. So a possible issue could be that the PFC export isn't VRF capable. It isn't. Annoyingly. ___ 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] Nexus 7000
What about NX-OS ? Is it built upon qnx ? No. It is a linux kernel. The core system management HA infrastructure is taken from SAN-OS (ie MDS) with Ethernet L2 L3 functionality laid on top. As the Linux kernel and some code commonly used on embedded Linux devices are GPL'ed, what is the URL for the part of the code that Cisco is now publishing to comply with the GPL license ? 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/
Re: [c-nsp] Cisco ME-6524 platform architecture
The part I'm struggling with is how this relates to the fixed configuration of the ME-6524. I appreciate that its based upon the SUP-720, and utilises MSFC2A with PFC3C, but I when I issue a show Actually it's closer to SUP-32, as the ME-6524 is a classic-bus only device. KUMA 1 (2.0) HYPERION 1 (6.0) R2D2 1 (2.0) DHANUSH 2 (2.0) VISHAKHA 8 (1.0) My guess is the Vishakha ASICs are the ones connected to the customer ports; it's documented that there 8 ASICs for the customer ports, each 1 serving groups of 3 ports. 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/
Re: [c-nsp] BGP load sharing accross 2 different providers
On Cisco-land, best way is probably using OER (Optimized Edge Routing): http://www.cisco.com/go/oer Be aware that OER has changed a lot in the recent versions, so if you don't have maintenance contract it would probably better to do manually. Rubens On Jan 22, 2008 2:30 PM, Mohamed Ahmad [EMAIL PROTECTED] wrote: Hi everyone, I was wondering what's the best way of load sharing traffic across 2 bgp sessions with 2 different isp's (different AS numbers) but same bandwidth (1 Gbps). I found this article but not sure if anyone has tried this before: http://www.ccnalab.net/load_sharing_bgp.php I have also found this Cisco article which uses a different method: http://www.cisco.com/warp/public/459/40.html#conf4 Any thoughts? Thanks, Mo ___ 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] Bug Toolkit on CSCsj08713
I've filled the feedback form on bug toolkit for CSCsj08713, the bug that someone here on cisco-nsp pointed out for BFD x BVI support. They simply doesn't get it that the bug isn't something that wasn't working before, is that it's now disabled, they think it's now working on fixed versions. Someone clueful at Cisco could try fixing this from the inside, please ? It's already very frustrating that the boxes don't do what most of the nsp community needs, and then the support knowledge is reverse documented ? Too bad. Rubens -- Forwarded message -- From: Bug Toolkit Support [EMAIL PROTECTED] Date: Jan 21, 2008 11:40 PM Subject: RE: Feedback Submitted for Bug Toolkit To: , btk-support(mailer list) [EMAIL PROTECTED] Cc: rne-feedback (mailer list) [EMAIL PROTECTED] Please work with TAC on this. They need to communicate your needs to the development teams directly. The data looks correct on this end. Bug Toolkit Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 12:13 PM To: btk-support(mailer list) Cc: rne-feedback (mailer list) Subject: Re: Feedback Submitted for Bug Toolkit Actually it's the other way around: updating from 12.2(18)ZU2, which had support for BFD BVI, to 12.2(33)SXH(main or SXH1), which hasn't, disable BFD BVI. The same happened with 12.2(33)SRC, which no longer has BFD BVI support, and previous 7600 IOS versions, which had. The solution was to disable a very useful feature. Rubens On Jan 21, 2008 2:25 PM, Bug Toolkit Support [EMAIL PROTECTED] wrote: It's not supported because it's a bug in the software (it should work). Please update your IOS to a version containing the fix. Bug Toolkit provides access to the latest raw bug data so you have the earliest possible knowledge of bugs that may affect your network, avoiding un-necessary downtime or inconvenience. Because you are viewing a live database, sometimes the information provided is not yet complete or adequately documented. To help you interpret this bug data, we suggest the following: . This status of this bug is fixed. The problem described in the bug report is fixed-in all release versions targeted to be fixed, and all changes have been successfully tested. . Check for a software release later than these listed in the Fixed-in versions in software download center. . The fixed-in version may not be available for download yet until all the other bugs targeted to be fixed for that major release are processed. No release date information is available to Bug Toolkit. Please check the software download section frequently to look for a new version. . Sometimes the bug details, when available, contain the fixed-in version information or link to the upgrade or patch. . Always check the software release notes before performing any upgrade to understand new functionality and open bugs not yet fixed. . Any workaround listed in the bug details section is generally provided as a way to circumvent the bug until the code fix has been completed; often in lieu of downgrading to a non-affected version of code. . In certain rare circumstances, we are unable to fix the bug in all versions in which it is found. The bug will still have a 'fixed' status. Please open a service request with the Technical Assistance Center if you are being impacted by a bug in this condition. . Obscure version references are usually internal builds and may never be posted as a full release. Please watch for a release version later than the interim build displayed. -Original Message- From: FeedbackTool [mailto:[EMAIL PROTECTED] Sent: Sunday, January 20, 2008 12:25 PM To: rne-feedback (mailer list) Subject: Feedback Submitted for Bug Toolkit Bug ID: CSCsj08713 Doc Url: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet chBugDetailsbugId=CSCsj08713 Please rate this release note: 1 This release note solved my problem: no Suggestions for improvement: The details on why BFD is not supported on SVI interfaces are lacking. ___ 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] BFD for static routes
2008/1/20 Tassos Chatzithomaoglou [EMAIL PROTECTED]: This has happened to me twice and the answers i got from Cisco were : 1) the feature wasn't supposed to work from the beginning That is a very dog ate my homework excuse... heard the something about SXH. 2) the feature was causing conflict with other, more important features But that's a good reason. If Cisco tell us what these conflicts are, we can suggest a way to solve the conflict in each particular scenario in favor of BFD or in favor or something else. Just give us the power to choose. 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/
Re: [c-nsp] Blocking IS-IS traffic
IS-IS is carried by OSI, not IP; you should try finding the ethertype it's using (maybe 00FE or FEFE) and use a MAC ACL to filter the OSI traffic. Converting to an IP routerport without IS-IS attached would achieve better isolation, is it possible on this scenario ? We strongly prefer to use routerports on connections to customers/peers/upstreams, and even there we filter IP multicast traffic. Rubens On Jan 18, 2008 9:39 AM, Ulysses Maciel da Costa [EMAIL PROTECTED] wrote: Hi, I have a vlan in my router's switchport, and I receive a link from other company. Last week my network goes down. I analyze my network and saw a lot of IS-IS packets. By the way, my routes inside this vlan are static. I've tried to create an ACL inside my vlan to block these IS-IS packets attached with his ports(2042,2043), without success. Someone could help me to do an efficient ACL to block this traffic? ___ 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] BFD for static routes
Is there BFD support for static routes on anything besides IOS XR? Is there a timeline for such support? If we're doing BFD feature requests how about getting back BFD for SVIs on the ME6524s. It worked perfectly on 12.2(18)ZU2 but was removed with 12.3(33)SXH as an unintended feature. It may have been unintended but it was certainly useful. It works fine on our 7600s running SBR as well. I second that. Real world doesn't have only routerports, but a lot of switchports where the underlying media needs to be shared among different applications, customers or both. 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/
Re: [c-nsp] 7600 SRA vs. SRB
Hmm, just to ractify, it's a pair of 7603s with Sup 720 and a legacy 48 100TX bus linecard. No SIPs, no OSMs or any DFC-enabled card. Rubens On Dec 27, 2007 11:33 PM, Rooney, Randy [EMAIL PROTECTED] wrote: Agreed, SRB2 seems to have fixed the high CPU bug during large BGP updates but SRB2 has significant problems with SIP-400. At least in our environment any box with 6704 and SIP-400 w SPA-OC48 is affected. TAC still working on a bug fix. If you have any SIP-400s then I would stay away from SRB2. Randy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Wednesday, December 26, 2007 11:37 AM To: Peter Rathlev Cc: cisco-nsp Subject: Re: [c-nsp] 7600 SRA vs. SRB Upgrading from SRB to SRB2 made two 7600/Sup720s that were showing constant high CPU usage and routing protocol flapping to drop CPU usage to a few percent and become much more stable. No experience with SRB1, though. Rubens On Dec 26, 2007 12:45 PM, Peter Rathlev [EMAIL PROTECTED] wrote: Hi everyone, We're running 12.2(33)SRB1 on a couple of 7600/Sup720's acting as core switches in an MPLS network. We've recently seen strange symptoms where traffic apparantly crosses VRFs unexpectedly, although we don't have enough data to say for sure. Reload solved the problem both times it occurred. We're about to upgrade to SRB2 and see if the problem continues, but are thinking about using SRA instead. I can see the SRA6 earned the Limited Deployment tag, but I'm unsure if this is better or worse or neither compared to Early Deployment. Can anyone shed some light on that? We can live without the SRB features (according to Feature Navigator). Regards, Peter Rathlev ___ 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] 7600 SRA vs. SRB
Upgrading from SRB to SRB2 made two 7600/Sup720s that were showing constant high CPU usage and routing protocol flapping to drop CPU usage to a few percent and become much more stable. No experience with SRB1, though. Rubens On Dec 26, 2007 12:45 PM, Peter Rathlev [EMAIL PROTECTED] wrote: Hi everyone, We're running 12.2(33)SRB1 on a couple of 7600/Sup720's acting as core switches in an MPLS network. We've recently seen strange symptoms where traffic apparantly crosses VRFs unexpectedly, although we don't have enough data to say for sure. Reload solved the problem both times it occurred. We're about to upgrade to SRB2 and see if the problem continues, but are thinking about using SRA instead. I can see the SRA6 earned the Limited Deployment tag, but I'm unsure if this is better or worse or neither compared to Early Deployment. Can anyone shed some light on that? We can live without the SRB features (according to Feature Navigator). Regards, Peter Rathlev ___ 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] confederation same as peer
Is it protocol-wise allowed to configure a BGP confederation like this ? router(config)#router bgp 65010 router(config-router)#bgp confederation identifier 42 router(config-router)#bgp confederation peers 42 router(config-router)#neighbor 1.1.1.1 remote-as 42 Reading the RFC on BGP Confeds didn't enlighted me to answer that; if it is RFC-ok do to such thing, does IOS allow it ? Tks, 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/
Re: [c-nsp] ME 6524 and RAM options, do I need them?
On Nov 20, 2007 2:57 PM, Alexander Koch [EMAIL PROTECTED] wrote: Folks, since surely some of you know - what are the RAM options for detailed on the bottom of http://www.cisco.com/en/US/products/ps6845/products_data_sheet0900aecd8040657e.html ? What do I need this RAM for, what are the hidden implications here? As the forwarding engine is a PFC3C, not an -XL class PFC, you are limited to 256,000 IPv4 routes no matter how much RAM you put into the route processor or the switch processor. I see very little reason to upgrade RAM in such a box. Also any chance I can use third- party RAM and be better off? Any recommendations on a useful IOS image for those boxes? Version-wise or feature-set-wise ? In features, the IP Base version is a very expensive CPE... Advanced IP Services is probably what operators want. 12.2(18)ZU2 seems the most common choice among current ME6524 users, but the 12.2(33)SXH has lots of interesting features we are looking to deploy. Just waiting for 12.2(33)SXH1 to be released to start testing it; SXH1 is not currently (2007-Nov-20 1900 GMT) available on CCO, but as VSS 1440 requires SXH1, it's probably just a matter of days. 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/
Re: [c-nsp] VS-S720-10G-3C
The homepage is here: http://www.cisco.com/go/vss There is a very interesting white paper about how it works: http://www.cisco.com/en/US/products/ps9336/products_white_paper0900aecd806ee2ed.shtml From the above URL: Additionally, note that no Cisco 7600 Series chassis will be supported after the system is converted to Cisco Virtual Switching System mode. Revenge of the Cat6K BU ? :-) 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/
Re: [c-nsp] Inbound redundancy with two ISPs
Cisco has OER feature on some routers, but that wouldn't fulfill the requirements on this scenario. Radware LinkProof is a good but expensive solution, so you might consider making your own Linux box that can be customized to work in a similar fashion. If Vyatta folks are reading this list, that would be a killer feature that could make a Vyatta box leapfrog Cisco ISR. Rubens On 11/1/07, The Father [EMAIL PROTECTED] wrote: One of our customers is looking to us to provide a failover method for their two internet access links. Normally this wouldn't be a problem but the customer has public IPs that were assigned to them from ISP-A (we're ISP-B) and they use them for servers behind ISP-B's connection. They would like it so that when ISP-A goes down, the link that we provide becomes primary and inbound and outbound traffic. Does anyone know of a Cisco (or other vendor) solution that could take care of this? I've tried explaining that for customers in these situations, BGP and public ASN/CIDR blocks are what's normally required for this to work. Thanks. Jose ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Replacing proper planning with dirty hacks (VLAN extension over GRE L2TP)
Beware that all tunneling methods have overheads that will make packets that are of valid size on the client-side (IP MTU 1500, Ethernet MTU 1518 with no .1q, 1522 with .1q) generate packets that when tunneled will overflow the mesh radios MTUs, which is usually Ethernet 1522 but maybe 1518 considering their lack of VLAN transport support. Before going into decision phase on how to fix this mess, it's good to do a field test on what MTU size you can pass from one point of the a network to a neighbor hop and to a far end hop. Your problems may be bigger than you think. Rubens One of our clients has found themselves in a position where they have purchased and implemented an extremely expensive mesh radio network which doesn't meet their requirements - primarily, to allow end to end carriage of VLANs from the main wired network to remote wired segments via the radio mesh. They want a solution to this without throwing away/trading in the existing kit and starting the analysis and design process from scratch - the latter is not going to happen for various reasons, and management won't allow me to apply a LART. In a nutshell, each client site has 10-20 VLANs, a 6509 at the core which provides inter-VLAN routing and WAN access and a mixture of 3560, 3750, 2950 and other switches at the access layer, all operating in Layer 2 mode only. Typically the topology is as follows: [6509 core] | 802.1q trunk | [3560 L2 access] | access port [local radio unit] | wireless mesh - one or more L3 hops | [remote radio unit 1][remote radio unit n] | access port [remote L2 switch 1].[remote L2 switch n] | [PCs and other devices] The challenge is that while the customer wishes to trunk VLANs from end to end (6509 all the way to the remote L2 switch) the radio network in the middle is a routed network due to the radio solution selected. We're looking at whether we can use GRE or L2TP, probably on dedicated routers at the headend (between L2 access switch and local radio unit) and around 10 remote ends (between remote radio unit and remote L2 switch) to hack a solution into place that will effectively allow the VLANs to be trunked over the L3 mesh. From the brief thoughts I've had about this, L2TP is looking more feasible than GRE because as as far as I can tell we'd need a GRE tunnel per VLAN/IP subnet to be transported and management would become [more of] a nightmare due to the number of tunnels. Support for L2TP in various Cisco kit looks more restrictive though. The various issues questions which come to mind are: * With L2TP - can we terminate multiple tunnels on a headend router, and dump these out a single physical interface (a dot1q trunk to an edge or core switch) probably via a xconnect? Or does each tunnel need a dedicated phy interface? * Is the above a valid topology? Essentially a hub and spoke scenario with L2TP tunnels carrying multiple 802.1q tagged frames between the hub and the spoke routers, bearing in mind that each remote 'spoke' segment would be sharing the same VLAN IDs and IP subnets * If yes to the question above, wouldn't the headend router need to maintain a MAC address table based on the tunnelled, 802.1q tagged frames received from each remote router? (since a frame received by the headend on the dot1q trunk to the L2 switch could need to be sent out to any of the 10 or more remote endpoints/tunnels) * If GRE were to be used (along with VRF-lite to segregate the so-called VLANs if necessary), we'd need tunnels from each remote router to the headend router, for every VLAN to be transported, would we not? * Are any of these options feasible on moderately low-end hardware (say a 7200 or 3845 at the headend and 1841s(ish) at the remote end) to keep the solution affordable? Aggregate throughput at the headend really only needs to be 10-20Mbps. * I know the scenario is fairly stupid to begin with, but other than designing a /real/ L2 radio solution, living with a routed network, or finding a job where I'm not involved in after-the-fact cleanups, have I missed any options here? Any sharing of knowledge and/or experience would be appreciated. (I don't ask questions often, but when I do, I obviously ask the world) Regards, Brad ___ 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] GE-WAN x SIP-x00 + n-Gig port-adapter
Folks, For 7600 routers, what are your thoughts about GE-WAN (4x Gig-E OSM) or using a SIP host (-200,-400 or -600) with 2, 4, 5 GigE port-adapters ? I'm considering price, performance, features and future IOS support. 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/
Re: [c-nsp] 12.2(33)SXH1 - Release Date?
From a 10/22/07 viewpoint, what are the resolved caveats and behaviour changes supposed to be in SXH1 ? (Always subject to change, naturally) Rubens On 10/22/07, Ian MacKinnon [EMAIL PROTECTED] wrote: Thanks Rodney. Rodney Dunn wrote: Estimate (always subject change) 11/23/07. Rodney On Mon, Oct 22, 2007 at 02:32:43PM +0100, Ian MacKinnon wrote: Anybody heard of an SXH1 release date yet? The date on the current release notes keeps updating with no visible changes to the content... Ian MacKinnon wrote: Phil Mayers wrote: On Sun, 2007-09-16 at 08:46 +0200, Gert Doering wrote: Hi, On Sat, Sep 15, 2007 at 05:28:35PM -0500, mack wrote: Does anyone have a tentative release date for 12.2(33)SXH1? I haven't, sorry. But you have made me curious - anything wrong with SXH that we should be aware of? (There must be a reason why you ask for SHX1). We're planning to go to modular SXH really soon now... On that topic: does anyone know whether SXH contains some or all of the bugfixes from SRA? SRB? To which minor revisions? I know the release notes state that 12.2(33)SXH contains all fixes that are in 12.2(33)SXF10 but obviously that doesn't cover all the new features. The release notes also say to check the bug toolkit for outstanding bugs. But when I chose 12.2(33)SXH as the release there are no known bugs at all. Thats all statuses, all severity everything Given there are no bugs, it does not need a SXH1 :-) ___ 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/ -- Ian MacKinnon Lumison t: 0845 1199 900 d: 0131 514 4055 PS. Do you know that we have opened a new datacentre in London? Click https://www.lumison.net/services/pdfs/colo_croydon.pdf or give me a call if you want to know more. ___ 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] MPLS network on 3750 switches - ISIS or OSPF which is scalable?
I can't emphasize enough how far you should stay from 3750 Metro running MPLS. If you add up the cost of Advanced IP Services license fees, you probably can think on good things to do with such money buying hardware that actually works with MPLS, Cisco or non-Cisco. Rubens On 10/15/07, Vikas Sharma [EMAIL PROTECTED] wrote: Hi, I have approx. fifty 3750 switches and I have to implement MPLS network on that. I am planning for OSPF in a single area as there will be only loopback IPs and connected routes in global IP routing table. But I am not sure abt he LSA flooding as my network is a full mesh. Though I can use database-filter command but to configure this command on every router is cumbersome. 2nd though is to implement ISIS with L2 level across the network. I want to understand which is more scalable with the kind of 3750 switches, ISIS with level 2 or OSPF with area zero? Any help is appreciated.. regards Vikas Sharma ___ 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] l2tpv3 support in 12.2(33)SXH
According to Feature Navigator, l2tpv3 is supported in 12.2(33)SXH. I couldn't find any mention on the release notes: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html But I couldn't find any documentation on how to configure this feature on the Sup720. I've tried this version in our 6500 and it looks like l2tpv3 isn't available. It probably requires WAN modules, not being supported on the PFC. 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/
Re: [c-nsp] 3750 Metro MPLS
Be aware that MPLS support in 3750ME is a mess, with lots of limitations, unsolved issues and broken promises. 3750 is a good L3 switch in the Ethernet+IP arena, and just that. On the other hand, ME6500 is a very good MPLS box. Besides doesn't supporting VPLS (can be a member of an H-VPLS architeture, but doesn't do VPLS) and limitations with EoMPLS requiring routerport instead of switchport that can be designed around, it's simply a lot of routes, labels, ACLs that can be handled with very little effort. Good product, indeed. Rubens On 9/17/07, Justin Shore [EMAIL PROTECTED] wrote: From reading the data sheet I think you're right. http://www.cisco.com/en/US/partner/products/ps6580/products_data_sheet0900aecd8034fef3.html I don't see any mention of MPLS. I was thinking that most of the MEs had at least basic MPLS features on the uplinks across all models. I was actually thinking about ordering a couple. Good thing this Chris posed his question. Thanks for the info Justin Munroe, James (DSS/MAS) wrote: The Cisco ME-3400 series do not support MPLS (RFC 2547 VPNs, EoMPLS, VPLS, TE, etc...). The ME-3400 only supports Multi-VRF CE (aka VRF-Lite). They do not support LDP for label exchange, and from what I've been told by the PLM they never will. 12.2.40SE adds Multicast VRF (mVRF) lite support and SSM if you're interested. This support was also added to the 3750ME. ___ 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] High traffic/CPU utilization - 6509
The error message is about the symptom, not the cause. There is an unfortunately usual condition with switches and port-channels: unidirectional links causing layer 2 loops that bypass spanning-tree controls. The balancing decision of each side may give one direction a working path, and the other direction a bad path at some moment (bad cable, bad port etc.) Putting UDLD (unidirectional link detection) in place can deal with the issue by shutting down the path, but it won't solve the problem, just contain it before the network flaps. Some C6509 modules have also cable diagnostic features, which may be useful to find out the problem. Rubens On 9/16/07, virendra rode // [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This has happened twice in a row when we configured port-channels on our core switches (C6509). We saw RP utilization jump to almost 90% and at one point it hit 100% causing our network to flap. We are able to calm it down by shutting the port-channel but we are still scratching our heads as to what could have caused this spike. We've found this to be spurious and we were unable to track down what was spiking the cpu. The error message decoder off CCO is stating that this message is informational and that no action is required head scratching? core-1# Sep 16 00:43: %CONST_DIAG-SP-6-HM_MESSAGE: High traffic/CPU util seen on Module 6 [SP=16%,RP=86%,Traffic=0%] 62 Supervisor Engine 720 (Active) WS-SUP720-BASE 6 000d.. to 000d.. 3.0 7.7(1) 12.2(17a)SX1 Ok 6 Policy Feature Card 3 WS-F6K-PFC3A hw 2.0Ok core-1#sh ver | incl IOS IOS (tm) s72033_rp Software (s72033_rp-PSV-M), Version 12.2(17a)SX1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Any pointers will be appreciated. regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7X+IpbZvCIJx1bcRAlC7AKDKbHu9WY9DrFG25Mk0f61o6WykjQCgnbOX kNYOtzqXSZWCQRkyEW6TU54= =H9v0 -END PGP SIGNATURE- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] Anybody else hit by 7600 RIP bug (CSCsi66768)
On 5/23/07, Rodney Dunn [EMAIL PROTECTED] wrote: The title of that bug is: CSCsi66768 odr route can not be redistributed into ospf On Wed, May 23, 2007 at 02:04:47AM -0300, Rubens Kuhl Jr. wrote: We have been suffering a RIP bug on C7600, IOS 12.3(33)SRB, that causes ugly tracebacks, with no public description yet; The TAC engineer is entitled and it's part of their job to fix that if they find a bug like that. The one exception is if there are security/PSIRT implications and then they can't say anything as it's under the control of PSIRT. the lack of a public description on the most likely bug is making our assigned TAC engineer not tell us what this is about, so we can't think whether it applies to us or not, or design an workaround. The reason you can't see the bug is because it was found in our testing organization on pre-released code and was marked as Unreproducible Symptom: A traceback is seen in the log and ODR redistribution is affected: %IPRT-3-NDB_STATE_ERROR: NDB state error (BAD EVENT STATE) (0x0) 10.0.0.0/24, state 7, event 2-1, nh_type 1 flags 4 -Process= CDP Protocol, ipl= 0, pid= 256 -Traceback= 40675A28 40675F6C 40D45D88 40D46B98 40D4854C 40D48690 40D43B24 40D44F68 40ACC158 42E34B34 40ACBA84 40ACBB0C 404D2074 404CCB08 404CC05C 41674FA0 In our case the traceback occurs in the RIP process, and it's not redistributing the routes to any other router process. Conditions: The problem is seen on a 7600 router running 12.2.33SRB. Workaround: none Is that the symptom you are seeing? If so, tell the TAC engineer to reopen the bug, make it viewable on CCO, and attach your SR to the bug so DE can investigate it again. The SR has been attached to the bug now, but I don't think it's really the case, as changing the RIP timers made the problem disappear. The curious thing is the same configuration with the same version on the same hardware doesn't generate tracebacks on the other router. 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/
Re: [c-nsp] More 6500 questions... Optimized ACL Logging
Cisco Optimized ACL logging, what is it good for? I have 6500s with Sup32, so PFC3B as required according to http://www.cisco.com/univercd/cc/td/doc/product/metro/me6500/122zu/sg/acl.htm#wp1035490 This document is for ME6500, which uses PFC3C, not PFC3B. Is OAL supported on PFC3B ? 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] %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE on 3750 Metro
Does anyone know what OCE stands for ? Hardware is 3750 Metro, context is the following error message: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE 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/
