Re: [c-nsp] ECMP v Link Aggregation ofr MPLS
It depends on your platform, traffic and code versions. Aggregated links and MLAG are the better option since they are simpler. However they are more susceptible to bugs on certain platforms and traffic spread of course depends what kind of traffic flows will traversing the links. It’s also easier to remove links from service with ECMP. If you’re a transit AS you probably have enough diversity to ensure an even spread. All things considered I’d choose aggregated links as well. On Mar 13, 2014, at 4:28 PM, Ivan cisco-...@itpro.co.nz wrote: So we are crossing the bridge to 10Gbps for some MPLS core links. I am trying to work out if it is better to use aggregated links or ECMP. If anyone has any experience or recommendation it would be much appreciated. Thanks Ivan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP session going down during DDOS
This is one of those things that isn’t supposed to happen but often does. The first thing I’d look at are the log messages. Are you sure the neighbor went down because of the DDOS attack? Could have been another type of error or even a scheduled change during the attack. Next I’d probably look at QOS settings. BGP packets are marked NC so they are the last to be dropped during periods of congestion. How are NC packets treated on your network? Is there anything else in this queue that could have starved out your updates/hello’s? If BGP updates or packets are being lost the TCP stack will end the BGP session sometimes before the dead timer expires. Lastly, I’d look at your filters and determine if anyone from the outside can send packets to your routers. If CPU was low the routers themselves probably weren’t being attacked, but maybe someone was able to send packets to the BGP port. This isn’t something commonly left open, but stranger things have happened. On Mar 6, 2014, at 1:07 PM, redscorpion69 redscorpio...@gmail.com wrote: Today we had a couple of dozen Gbps traffic to one of our customer. At one point during attack, our PE router where the customer is attached had a BGP session to one of our RR go down, only to go up after half a minute. Our core has juniper/asr9k, our PE router in question is 7600. All our traffic is properly classified from RR to 7600 in both directions. The CPU stayed fairly low on PE, so if traffic is properly classified, how is it possible for router to drop BGP control plane? If input queues are an issue, shouldn't default SPD configuration take care of that on 7600? How to make sure this doesn't happen again? Regards ___ cisco-nsp 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] access lists for cpe protection
Can you move the ACL to a beefier device and/or closer to the source? The 7200 (nonVXR) Isn’t exactly bleeding edge. On Mar 2, 2014, at 2:05 PM, Mike mike-cisconspl...@tiedyenetworks.com wrote: On 03/02/2014 09:33 AM, Nick Hilliard wrote: On 28/02/2014 18:35, Mike wrote: So my question is, can I optimize this to reduce router load? Oh, I have this on 7201. It may help if you enable access-list compiled in global config mode - google for Turbo ACLs for information on how this works. If this doesn't help, then you're gonna need a bigger boat. That's one seriously aggressive ACL you have. I'm glad I'm not at the receiving end of it. I should have said I do have access-list compiled already, I was just wondering if there was something else like ordering of the rules or expressions that might improve it a bit. As fas as the aggressiveness of the acl, yep you are right, but keep in mind this only is blocking inbound requests made TO customer CPE, such as dns queries, snmp, web management interface, and so forth. On the plus side, any customer can request an opt-out and I'll happily remove it for them (its just a radius group they are a member of). The necessity of having to do this in the first place is that customer CPE are under attack and have been hijacked en-mass resulting in massive support calls from folks who are just as ignorant as their equipment manufacturer and who are dissastified with having to bring the device to us so it can be reset, reprogrammed, and secured (update fw or alternate fw like dd-wrt or such). Thanks. Mike- ___ cisco-nsp 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] Can I use BGP instead of any IGP?
2012/5/30 Mark Tinka mark.ti...@seacom.mu On Wednesday, May 30, 2012 03:34:04 AM Andrew Jones wrote: In enterprise WAN environments, you could use BGP as the sole routing protocol, if you treat each individual site as a separate AS (private AS numbers offcourse). Depending on the size / complexity of the campus, you might still need an IGP within the campus. Again you could treat each individual router as a separate AS, forming ebgp peers across links where dynamic peers would ordinarily appear. It didn't sound like this is what the OP was after; you're right, it would work but seems awfully complex :-). I think the OP was after replacing any IGP with BGP, including using BGP for BGP. The latter is easy, the former, not so much. Maybe the name of the thread should be Can/Should I use BGP without an IGP, to which most would answer a clear and resounding no. The original title somehow implies that BGP can replace a normal IGP and it's topology database or that it was designed to do so. BGP as an IGP is technically just as strange as BGP for name resolution. Asking if you can use it without an IGP is a little more accurate. ___ cisco-nsp 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] 4500-E EOL?
Thanks. I thought they were newer than that, but I don't work with alot of these boxes. 2012/5/21 Asbjorn Hojmark - Lists li...@hojmark.org They're dropping support for the redundant (7 and 10 slot) -E chassis for the +E chassis (plus instead of minus). There is no change for the 4503-E and 4506-E. The +E redundant chassis are different primarily in that they support 48G/slot vs the 24G/slot in the older chassis. The -E chassis started shipping in December 2007. -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley Sent: 21. maj 2012 04:26 To: Cisco NSPs Subject: [c-nsp] 4500-E EOL? Browsing cisco.com I found EOS/EOL notices for a few of the 4500E chassis. Someone correct me if I'm wrong but weren't these released in 2010? http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/eol_c51-70 6059.htmlhttp://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/eol_c51-70%0A6059.html ___ cisco-nsp 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] 4500-E EOL?
Browsing cisco.com I found EOS/EOL notices for a few of the 4500E chassis. Someone correct me if I'm wrong but weren't these released in 2010? http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/eol_c51-706059.html ___ cisco-nsp 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] 4500-E EOL?
Are you sure? The only release bulletin I could find was from 2010 and that's the year the EOS'd the non-E chassis. 2012/5/20 Tony Varriale tvarri...@comcast.net On 5/20/2012 9:25 PM, Keegan Holley wrote: Browsing cisco.com I found EOS/EOL notices for a few of the 4500E chassis. Someone correct me if I'm wrong but weren't these released in 2010? http://www.cisco.com/en/US/**prod/collateral/switches/** ps5718/ps4324/eol_c51-706059.**htmlhttp://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/eol_c51-706059.html Nah. They are 5-6 years old IIRC. tv __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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] 4500-E EOL?
Right, but there was no incremental chassis for the 6509's. From what I can tell, they released the4500-E's to upgrade from the legacy 6G backplane to 24G. Then EOS'd them 3 years later when they figured out how to make the boxes line rate. I'm not sure I see the point in this, but I don't have many of these so I haven't been looking very hard. 2012/5/20 Jeff Kell jeff-k...@utc.edu On 5/20/2012 10:54 PM, Keegan Holley wrote: Are you sure? The only release bulletin I could find was from 2010 and that's the year the EOS'd the non-E chassis. They dropped the non-Es for the -Es. Now they're dropping the -Es for the +Es. 6500 non-Es were dropped even earlier (support runs out Nov of this year). Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stacking 3750X vs diverse 4948E
The 3750X is relatively new so I've only seen a few of them. Stackwise in general is pretty solid. I've never seen a whole stack fail. If a member fails the stack just keeps going, if the master tails a new master is elected. One thing to watch out for is the fact that the 3750X isn't intended to be a high performance DC switch. I have seen issues with queue drops because of small packet buffers on the non-X version which leads to trouble if you do alot of 1G at line rate. I haven't checked the X series, but I'm told it's not recommended for high performance environments either. 2012/5/18 David Coulson da...@davidcoulson.net In a datacenter environment, we typically deploy 4948 top-of-rack switches with L2 uplinks to our 6500 core - Systems get connections into two different switches and rely on OS NIC bonding (mostly Linux) to support switch failures. Switches running STP and in the last four years we've had no issues with this design (including failures of systems connected to diverse switches). A new proposed configuration utilizes stacked 3750X switches, where servers would be connected to multiple switches within the same stack. I have next to no experience in the low-end switches that do stacking, but from a general risk management perspective, it seems like a many eggs and single basket configuration. Does anyone have any solid experience with 3750X switches, or stacking in a datacenter in general? I've seen plenty of stacks for closets/end-users, but I don't see many in a top-of-rack config. Is Cisco stacking typically 'reliable', in that when a switch fails it will leave the remainder of the stack functional? What about a software issue? Does the whole stack crap out and reload, or does the master just fail and a new one get elected? I realize it's a pretty broad question, but it boils down to - Is a stacked switch config significantly less reliable/resilient/available than two TOR switches? David __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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] Understanding Out/Input bytes in Interface Counters on 2811
32bit counters would wrap at 4.29GB so it would never get to 300GB. As far as I know most newer devices have 64 bit counters, but I could be mistaken. The last update I could find on cisco.com was from 2007. It would be pretty stupid to have gigabit interfaces on a device with counters that wrap at about 33Gb.The show int command should show the last time the counters were cleared. Even less likely is they are counting in bits and not bytes. I would want to see this kind of data come from a monitoring platform of some sort. If you don't have graphs I would ask for data from the vendor's billing/polling servers. 2012/4/19 Peter Subnovic cnspmail...@googlemail.com Dear List, i am having an Cisco 2811 with IOS (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T Our Provider told us that we had a traffic volume of 300GB last month, but the interface counters do not reflect these values: I am curios, if the reported volume should be reflected in the out/input bytes When i am looking on the counters of the interface which is connected to the Provider Router, the following values are shown: 1089368953 packets input, 744025984 bytes 970733443 packets output, 3196131116 bytes I searched the Open/Resolved Caveats document, but couldnt find anything related. http://www.cisco.com/en/US/docs/ios/12_4t/release/notes/124TCAVS.pdf So my question is: Shouldn't they be at least somewhat near the reported volume? or am i missing something (maybe very basic) here? or are the counters just broken? Unfortunately, i do not have any other possibility to verify the volume (i know this is bad and will be changed). Any pointers to documents or something else is highly appreciated. Thanks for your time. Kind regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] Understanding Out/Input bytes in Interface Counters on 2811
2012/4/19 Peter Subnovic cnspmail...@googlemail.com Thanks Chuck, Bruce and James for your replys, I did clear the counters 6 weeks ago (near the beginning of march) while i was troubleshooting another issue . The router was not rebooted for 15 weeks. Thanks for the hint that the counters are (most probably) 32-bit counters, although the 3 Billion bytes reported as output should fit in the counter. Was it 3GB or 300GB? 300GB would not fit in a 32 bit counter. ___ cisco-nsp 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] channelized ds3 - make a point to point?
The dsx panel isn't active so it wouldn't bundle a circuit for you. Also, there isn't a way (AFAIK) to hand off a T3 clear channel with 26 of the 28 timeslots as dead air. You could bring it in on a more expensive box and hand off ethernet with 2M of bandwidth, but that wouldn't be worth the effort compared to just doing MLPPP. 2012/4/18 Mike mike-cisconspl...@tiedyenetworks.com On 04/18/2012 07:48 AM, Mike wrote: Howdy, I have two ds1's. The end points are two customer locations, while my noc is in the middle. I was wondering if there is a cisco way to create a clear channel ds1 connecting these two customer locations as if they had a telco point to point ds1 between them? I have a 7201 with pa-mc-2t3+. Sorry for replying to my own post, but I am asking if there's anyway to do in the adaptor like a dsx. Otherwise I'd have to bring both ds1's out to a real dsx, which is silly. Mike- __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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] channelized ds3 - make a point to point?
Maybe I misunderstood your question. I thought you had 2 DS1's to the same site and you wanted to some how concatenate them and provide a single link with twice the bandwidth. If you want to use them to connect customer site A with customer site B then yes you can cross connect them in the middle with a DSX panel or use transparent bridging/irb on your router. 2012/4/18 Mike mike-cisconspl...@tiedyenetworks.com On 04/18/2012 09:54 AM, Keegan Holley wrote: The dsx panel isn't active so it wouldn't bundle a circuit for you. Also, there isn't a way (AFAIK) to hand off a T3 clear channel with 26 of the 28 timeslots as dead air. You could bring it in on a more expensive box and hand off ethernet with 2M of bandwidth, but that wouldn't be worth the effort compared to just doing MLPPP. The issue is this: At present, I have a telco point to point circuit connecting 'a' and 'b' locations with cisco 1720's with T1 wic modules on each end. Due to immaterial reasons, it's now cheaper for me to have a point to point from 'A' to my noc, and 'B' to my noc, so if I can cross connect these here, then I can provide the customer with the same level of service at a better price point and make some money in the process. No customer end reconfiguration will be permitted, I can only do this on the provider side or not at all. Mike- __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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] C3550-12T - Gig copper ports won't link at 1Gb
I agree with that. If it doesn't link at all with auto auto then the link pulse frames that control speed negotiation are some how hindered. Since you have three different devices exhibiting the same behavior on newer code I would even skip to the switch being bad. Sent from my iPhone On Apr 16, 2012, at 3:55 AM, John van Oppen jvanop...@spectrumnet.us wrote: Are you saying that the link does not come up with both ends in auto/auto? At least on copper, that would indicate to me that you either have a bad switch or bad cabling... Are you sure the unit you have is good?I am plugged into a 3550-12T here at home with a few machines and auto works fine with every nic I have tried. John ___ cisco-nsp 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] C3550-12T - Gig copper ports won't link at 1Gb
I have a bunch of these in the lab and haven't had a problem. Have you tried enabling auto-negotiation? Have you tried changing port? Also, what is the other side set for? What does it say? The problem sounds kind of vague without an interface config or the exact device or nic you are trying to connect. 2012/4/15 graham gra...@g-rock.net Hi there, Anyone out there still using this older switch? I just pulled one out of the closet - and having a heck of a time getting the switchports to actually link up at 1Gb. I have a couple of 1Gb capable devices (servers, other routers, etc) that do 1Gb all day long on other Cisco switches - but not on the 3550-12T. Remember, this is the switch that has (10) 10/100/1000 BaseTX and (2) 1000 Gbic slots .. I have tried to put the copper interface into speed auto 1000 as well as speed 1000 (with the other side matching) and always results in a not-connect. The command 'speed nonegotiate' doesn't exist. Seems that 100-Full is the best I can get it. It's running the last IOS for it, c3550-ipservicesk9-mz.122-44.SE6.bin. Any guidance would be appreciated. Thanks! -graham ___ cisco-nsp 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] C3550-12T - Gig copper ports won't link at 1Gb
Have you tried removing all commands related to spd/dup on both ends and seeing what it negotiates? Also you haven't mentioned what's on the other end or how its configured. Sent from my iPhone On Apr 15, 2012, at 6:09 PM, graham gra...@g-rock.net wrote: Hi there, Anyone out there still using this older switch? I just pulled one out of the closet - and having a heck of a time getting the switchports to actually link up at 1Gb. I have a couple of 1Gb capable devices (servers, other routers, etc) that do 1Gb all day long on other Cisco switches - but not on the 3550-12T. Remember, this is the switch that has (10) 10/100/1000 BaseTX and (2) 1000 Gbic slots .. I have tried to put the copper interface into speed auto 1000 as well as speed 1000 (with the other side matching) and always results in a not-connect. The command 'speed nonegotiate' doesn't exist. Seems that 100-Full is the best I can get it. It's running the last IOS for it, c3550-ipservicesk9-mz.122-44.SE6.bin. Any guidance would be appreciated. Thanks! -graham ___ cisco-nsp 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] routerperformance
Does anyone have the throughput numbers for the new cisco 29XX/39XX routers? I see they continue to omit them from the website. ___ cisco-nsp 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] routerperformance
Thanks! 2012/3/23 vinny_abe...@dell.com http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf The ISR G2 2901, 3911, 2921, 2951, 3925, and 3945 are all there with PPS and Mbps (based on pps * 64 bytes * 8bits/byte). -Vinny -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley Sent: Friday, March 23, 2012 5:41 PM To: Cisco NSPs Subject: [c-nsp] routerperformance Does anyone have the throughput numbers for the new cisco 29XX/39XX routers? I see they continue to omit them from the website. ___ cisco-nsp 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] NAT on the 3750X
Does cisco support NAT on it's rack mountable switches yet? 3560/3750X etc.. ___ cisco-nsp 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] About a post made from user l...@cisco.com
I think the information you posted pretty much sum's it up. OTV can span layer-3 hops, fabric-path is all layer-2. I'm sure someone from cisco can elaborate further, but the differences are simple since there are existing protocols that do the same things. OTV is like VPLS/L2VPN without mpls (the good and the bad). Last I checked they used ISIS behind the scenes to send mac address information about and handle loop avoidance similar to what VPLS does. Fabric-path is similar to TRILL or DCB/PBB. It just finds a way around the spanning-tree limitations of blocked ports allowing layer-2 domains to scale further. I think fabric-path also supports FCoE. I will admit I know more about the standards based stuff than the cisco proprietary protocols. 2012/3/12 Nargos Ftw nargos...@gmail.com Hello. Hope you read it. I was on google looking for information about differences between OTV and Fabricpath and found this post of yours: http://www.gossamer-threads.com/lists/cisco/nsp/134263?do=post_view_threaded#134263 In that post, you mention that: OTV is a technology that allows us to extend L2 across any L3 (IP) infrastructure. Cisco Fabric Path is in essence the ability to run L2 networks without spanning tree and all links active. I have 2 datacenters and must extend 2 VLANs. So i tought Wow, thats OTV for sure. Then, after researching a little i found that Fabricpath would do the job too. All i need is interconnect 2 DCs with DWDM and 2 VLANs must be extended. Fabricpath is cheaper than OTV. I feel dumb, but i cant see the difference between them. Both maps L2 address dynamically. Both uses routing logic. I know that cisco recommends OTV in this case, but Fabricpath would work fine. *What should i do and could you please show me the differences between OTV and Fabricpath?* All i see on cisco webpage are presales webpages and configuration guides. Thank you so much. ___ cisco-nsp 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] port channel numbering schemes
2012/3/7 Jared Mauch ja...@puck.nether.net On Mar 7, 2012, at 9:23 AM, Nick Hilliard wrote: On 07/03/2012 14:16, chris stand wrote: thoughts/ideas/concerns This works fine until you try it on smaller boxes and you find out that they only support port-channel names up to 48 or whatever. Then you have a moment of extreme facepalm and go back to Po1, Po2 and Po3. I've found 'show interface description' and a well thought out (and machine parseable) standard for naming works well. This way you can just find what you want quickly. CDP and LLDP can also assist you in documenting ports as well, though some people don't like the information leakage. +1 interface descriptions are the way to go here. I try to stay away from clever numbering. I find that it's hard for people other than the person that thought of the scheme to remember it. Not only that what happens to your numbering scheme if you need to move vlan1300 or add it to more than one port channel. Numbers don't convey enough information to be used as an inventory system. ___ cisco-nsp 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] twin-gig converters
I seem to remember someone posting that using twin-gig converters on a 4900M shrinks the buffers on the resulting gig interfaces. I can only find complaints about the 3560 and 3750 (non-x) in the archives though. Can anyone fill in the blanks in my memory. ___ cisco-nsp 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] SSH issue
It usually means the server wasn't listening, was listening on a different port or did not have the proper keys generated and could not negotiate encryption. I don't know the debug options for ssh off the top of my head but they should be simple to find on the interwebs if you need them. If you're on a linux box you can ad verbosity switches (-v -vv or -vvv) to see if you can get some more info. You can also see what happens if you try to ssh to local host on the router. 2012/2/23 Chris Lane clane1...@gmail.com running a 7600 with s72033-advipservicesk9_wan-mz.122-33.SXH7 actually just installed device, added crypto key rsa ~ all normal here, noting unusual to report. but, oddly this is what i am seeing when i try and ssh to box. The remote system refused the connection. I have loaded ssh to 100s of boxes so its not a learning issue... I don't know how to debug, we use radius, i can telnet without issue.. ssh is the culprit.. Yet ssh is running SSH Enabled - version 1.99 i have even zeroized the key and regenerated.. any suggestions would be helpful Thanks Chris -- //CL ___ cisco-nsp 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] Internet BGP autofailover
what do you mean by isn't working. No routes, traceroute dies, routes but no traffic, only a subset of the destinations are reachable,etc.. 2012/2/13 alex nyagah alex.nyaga...@gmail.com Hi Group, I have the following configs in my router but auto failover between two ISP is not working, can someone please help.. interface GigabitEthernet0/1 description Link to ISP_A ip address 10.10.10.205 255.255.255.252 ip accounting output-packets ip flow ingress ip nbar protocol-discovery duplex auto speed auto no negotiation auto ! interface GigabitEthernet0/2 description Connection to ISP_2 ip address 20.20.20.34 255.255.255.252 ip accounting output-packets ip flow ingress ip nbar protocol-discovery load-interval 30 duplex auto speed auto no negotiation auto ! interface GigabitEthernet0/3 description Connection to WALTER LAN ip address 10.20.30.254 255.255.255.0 ip tcp adjust-mss 1420 duplex auto speed auto no negotiation auto ! router bgp 6450 bgp log-neighbor-changes neighbor 20.20.20.33 remote-as 31177 neighbor 20.20.20.33 description ISP_A-BGP neighbor 20.20.20.33 ebgp-multihop 8 neighbor 20.20.20.33 update-source GigabitEthernet0/2 neighbor 10.10.10.206 remote-as 9010 neighbor 10.10.10.206 description ISP_A-Ke-eBGP neighbor 10.10.10.206 update-source GigabitEthernet0/1 maximum-paths 2 ! address-family ipv4 neighbor 20.20.20.33 activate neighbor 20.20.20.33 weight 1000 neighbor 20.20.20.33 prefix-list WALTER-SUBNET out neighbor 20.20.20.33 route-map ISP_B_IMPORT in neighbor 10.10.10.206 activate neighbor 10.10.10.206 weight 100 neighbor 10.10.10.206 prefix-list WALTER-SUBNET out neighbor 10.10.10.206 route-map prepending in maximum-paths 2 no auto-summary no synchronization network 10.20.30.0 mask 255.255.255.0 exit-address-family ! ip route 10.20.30.0 255.255.255.0 Null0 254 name BGP-Advertisement ip flow-export source GigabitEthernet0/1 ip flow-export version 5 origin-as ! no ip http server ! ! ! ip prefix-list DEFAULT seq 10 permit 0.0.0.0/0 ! ip prefix-list WALTER-SUBNET seq 5 permit 10.20.30.0/24 ip prefix-list WALTER-SUBNET seq 10 deny 0.0.0.0/0 le 32 ! route-map ISP_B_IMPORT permit 10 match ip address prefix-list DEFAULT ! route-map prepending permit 10 match ip address prefix-list DEFAULT -- ** ___ cisco-nsp 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] Routing around errors
I've always been nervous about automating something like, but to each his own. There are a few different solution that poll specifically with performance in mind. You should also be able to set the generic pollers to trap based on threshold. From there I'd just let a lowly human decide what to do. My concerns with automation have been things like: How do we make sure the secondary path is clean and has enough bw to handle the load? How do we move things back once the issue is gone? How do we prevent automation from disabling both links if the secondary is down or unusable? Granted I haven't done a wealth of research on tools that would do this, but usually a good NOC will be able to figure something like this out and fix it in 15-20 minutes. Automation may take a while to implement and perfect (even if it's purchased) only to save me 20 minutes of dropped packets. YMMV though. Keegan Holley ▪ Network Architect ▪ SunGard Availability Services ▪ 401 North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪ *keegan.hol...@sungard.com* keegan.hol...@sungard.com Keeping People and Information Connected® ▪ *http://www.availability.sungard.com/ * http://availability.sungard.com/ *Think before you print* CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. 2011/12/9 Geoffrey Pendery ge...@pendery.net We've seen an old nuisance issue becoming more prevalent lately - at dual-homed sites one of the circuits will run errors, but not bad enough to drop the routing protocol neighbor (OSPF in our case). So a site with one good circuit and one error-heavy circuit will continue to route traffic over the circuit with errors. I'm curious what solutions are prevalent out there, anybody want to weigh in? Tune the hellos tight enough in the hopes of dropping the neighbors? PfR/OER? Alerts from monitoring system followed by manual intervention? EEM scripts checking the counters? Thanks, Geoff ___ cisco-nsp 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] Routing around errors
Interesting.. I'm a mostly juniper shop and I haven't done alot of reading on OER/PIR. Thanks 2011/12/12 N. Max Pierson nmaxpier...@gmail.com We're using OER/PfR to achieve this and it works quite well. You can have routing changes on a wealth of triggers from latency increases to errors counting up on interfaces. PfR can be configured with a lot of logic built in so that you don't accidentally blackhole traffic. You can even go as far as using EEM and PfR, but I would lab this up in either case you make sure you get the desired effect. Regards, Max On Mon, Dec 12, 2011 at 11:27 AM, Keegan Holley keegan.hol...@sungard.com wrote: I've always been nervous about automating something like, but to each his own. There are a few different solution that poll specifically with performance in mind. You should also be able to set the generic pollers to trap based on threshold. From there I'd just let a lowly human decide what to do. My concerns with automation have been things like: How do we make sure the secondary path is clean and has enough bw to handle the load? How do we move things back once the issue is gone? How do we prevent automation from disabling both links if the secondary is down or unusable? Granted I haven't done a wealth of research on tools that would do this, but usually a good NOC will be able to figure something like this out and fix it in 15-20 minutes. Automation may take a while to implement and perfect (even if it's purchased) only to save me 20 minutes of dropped packets. YMMV though. Keegan Holley ▪ Network Architect ▪ SunGard Availability Services ▪ 401 North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪ *keegan.hol...@sungard.com* keegan.hol...@sungard.com Keeping People and Information Connected® ▪ *http://www.availability.sungard.com/ * http://availability.sungard.com/ *Think before you print* CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. 2011/12/9 Geoffrey Pendery ge...@pendery.net We've seen an old nuisance issue becoming more prevalent lately - at dual-homed sites one of the circuits will run errors, but not bad enough to drop the routing protocol neighbor (OSPF in our case). So a site with one good circuit and one error-heavy circuit will continue to route traffic over the circuit with errors. I'm curious what solutions are prevalent out there, anybody want to weigh in? Tune the hellos tight enough in the hopes of dropping the neighbors? PfR/OER? Alerts from monitoring system followed by manual intervention? EEM scripts checking the counters? Thanks, Geoff ___ cisco-nsp 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] IOS XR BGP
On Nov 29, 2011, at 5:44 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Nov 28, 2011 at 06:44:48PM -0500, Keegan Holley wrote: 2011/11/28 Gert Doering g...@greenie.muc.de On Mon, Nov 28, 2011 at 11:41:08AM -0500, Keegan Holley wrote: That wasn't centered around aggregates and no. Some of us don't run gigantic intercontinental ISP's :) So yes us lowly Tier-II and Tier-III AS's may on occasion learn our own routes from an external connection. These lowly ASes urgently need to implement anti-bogon filters on their eBGP sessions. NEVER EVER accept prefixes belonging to your address space from the outside. That's crap. In that case: I encourage all my competitors to do so. What's your AS number? Shall we see what happens if I announce the /24 with your name servers in it? (Except that I'm a good guy, and would never do that, of course). Yea sure. I have a better test. Why don't you tell one of your upstreams that you want to advertise a block they've given you to another ISP for redundancy. Just because you accept a few routes with LOA agreements doesn't mean you accept any route from any as path. What's the alternative? Yet another AS with a single /24 and 10 web servers living unit because their provider wouldn't multihome? You will need to do it to have customers multi-home with your ARIN space for one. Secondly those outside AS's may belong to your company a sister company or an acquisition and you may want to use the eBGP path as a backup. Of course there are valid exceptions. But they should be *exceptions*. ASes relying on nobody will do that or (even worse) relying on vague and ill-understood BGP preferences will just feel the pain some day. Nevermind. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ cisco-nsp 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] IOS XR BGP
2011/11/29 Gert Doering g...@greenie.muc.de Hi, On Tue, Nov 29, 2011 at 08:04:42AM -0500, Keegan Holley wrote: That's crap. In that case: I encourage all my competitors to do so. What's your AS number? Shall we see what happens if I announce the /24 with your name servers in it? (Except that I'm a good guy, and would never do that, of course). Yea sure. I have a better test. Why don't you tell one of your upstreams that you want to advertise a block they've given you to another ISP for redundancy. Just because you accept a few routes with LOA agreements doesn't mean you accept any route from any as path. Thanks for making this very clear: it is *very* important to *not* accept just about anything that comes along - and filtering routes from my network blocks plus routes for any exchange points I'm connected to is really basic network stability 101. I agree with that completely. I think there were alot of misunderstandings in our discussion. Most ISPs these days do not seem to have customers that use BGP-based multihoming using networks from the ISP's PA blocks - but of course, exceptions happen (we have one customer that uses an IPv6 /48 from our /32 due to historic reasons). There's no real way to multi-home and not change address space other than multihoming. That's why there are so many wasted /24's and AS numbers out there. What's the alternative? Yet another AS with a single /24 and 10 web servers living unit because their provider wouldn't multihome? Where exactly is the difference between one globally visible route and one globally visible route? And what does this have anything to do with prudent route filtering? It's really the wasted ARIN/RIPE assignment in the IP4 exhaustion phase. You're right though what I said here wasn't 100% accurate. If you multihome ISP number 1 would have to give you a /24 or larger. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp 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 Output Interpretor Help
ERROR: Traceback information was not found. In order to decode the Traceback information, the Stack Decoder requires the platform and version information to be present in the output and precede any Tracebacks or Stack Traces. This could be a clue.. TRY THIS: Collect the output of the 'show version' command, and the Traceback or Stack Trace information and submit it to the Output Interpreter. Here is an example of a Traceback output with version information: ___ cisco-nsp 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] IOS XR BGP
2011/11/28 Mark Tinka mti...@globaltransit.net On Saturday, November 26, 2011 12:01:35 AM Keegan Holley wrote: There's no family aggregate in cisco. That's one of the reasons people buy junipers in the first place. Definitely not us :-). If we're dying for such a feature and it's the only thing standing between us and a Cisco, and the Cisco is the preferred device for 99% of what we need, we'll find a way to get our results with the Cisco. Although this feature is commonly-used by Juniper folk (we don't use it on our Juniper's), it's not worth a deal-break, IMHO. But then again, that's just us :-). I never said it was a deal breaker. Definitely a nice to have though. It's cleaner to have a route type for aggregates than a static null0 route with the same default preference of a static route. Another is not having eBGP routes preferred over iBGP route. At the risk of starting yet another trite cisco vs. juniper thread, what do you mean by preferred device? ___ cisco-nsp 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] IOS XR BGP
2011/11/28 Mark Tinka mti...@globaltransit.net On Tuesday, November 29, 2011 12:06:28 AM Keegan Holley wrote: It's cleaner to have a route type for aggregates than a static null0 route with the same default preference of a static route. Why would it be cleaner? The static route is basically used to pull-up the aggregate into BGP. This points to a Null interface on all BGP- speaking routers, ensuring packets that arrive for subnets not in iBGP or the IGP get dropped, and also announcing said routes to eBGP neighbors. Works. Simple. Effective. You can also apply attributes directly to the aggregate. So you can set origin code, local pref etc. directly on the route. Also, from the non-technical side it's cleaner to know it's an aggregate as opposed to a static route doing something else. Another is not having eBGP routes preferred over iBGP route. Your aggregates would be in your iBGP. Would you expect to learn your aggregates from outside your routing domain? That wasn't centered around aggregates and no. Some of us don't run gigantic intercontinental ISP's :) So yes us lowly Tier-II and Tier-III AS's may on occasion learn our own routes from an external connection. Also, just because the AS number is different doesn't mean it's not yours. It's better (and I fully admit that this is debatable) to have the iBGP vs. eBGP choice much lower in the selection process.. At the risk of starting yet another trite cisco vs. juniper thread, what do you mean by preferred device? What I meant is if we were comparing a Cisco and a Juniper and the Cisco turned to be more preferred save for this one feature the Juniper had. Agreed, this is a nothing feature. I wasn't implying Cisco are better than Juniper, or vice versa. Actually I was. 6509/Nexus vs. EX8200, Cisco ME vs. EX4200, ASR vs. M/MX and CRS vs. T/TX are all different conversations. I thought you were alluding to something like that which I would have agreed with. ___ cisco-nsp 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] IOS XR BGP
2011/11/28 Gert Doering g...@greenie.muc.de Hi, On Mon, Nov 28, 2011 at 11:41:08AM -0500, Keegan Holley wrote: That wasn't centered around aggregates and no. Some of us don't run gigantic intercontinental ISP's :) So yes us lowly Tier-II and Tier-III AS's may on occasion learn our own routes from an external connection. These lowly ASes urgently need to implement anti-bogon filters on their eBGP sessions. NEVER EVER accept prefixes belonging to your address space from the outside. That's crap. You will need to do it to have customers multi-home with your ARIN space for one. Secondly those outside AS's may belong to your company a sister company or an acquisition and you may want to use the eBGP path as a backup. That's just what I can come up with off the top of my head. There are more nefarious uses such as offloading traffic to a partner or an IX to avoid having to upgrade core links. Also, I don't need my routing vendor to try to think for me, I'd rather have one that's flexible. Whether eBGP is preferred over iBGP is completely irrelevant on this topic, as someone could always fat-finger a more specific of your aggregate, and that would always win, no matter what. ... ___ cisco-nsp 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] IOS XR BGP
You can also apply attributes directly to the aggregate. So you can set origin code, local pref etc. directly on the route. Yes, but you can also do that with a regular route-map for your outbound BGP policy toward the route reflectors. you have to admit creating a bunch of static routes, redistributing them into BGP with one set of filters, then maintaing routing policy with another, possibly one for iBGP and yet another for upstreams is can be a bit cumbersome. I'm not saying it's not doable, nor am I saying it's a reason in and of itself to go juniper. Just that if I chose a juniper platform for some other reason I'm happy it's there. Just my personal opinion though. Moreover, you can apply attributes directly to 'network' statements too, so the 'aggregate' feature isn't the only one that brings this. Agreed, but the network statement is part of the problem.. not saying it's a reason to go juniper, blah blah blah, see above re: import policies. Also, from the non-technical side it's cleaner to know it's an aggregate as opposed to a static route doing something else. Well, I hardly find it useful to use the 'aggregate' command as documentation, just because it's originating an aggregate :-). Some other networks might call it something else. I've heard this practice referred to as self-documenting. I'm not proposing we all throw out our various repositories and turn to our configs for enlightenment, but when I see a route that says protocol aggregate I know what it is. When I see a route to null0 with a short mask there's some ambiguity. Maybe I chose a bad example... But to each his own. That wasn't centered around aggregates and no. Some of us don't run gigantic intercontinental ISP's :) So yes us lowly Tier-II and Tier-III AS's may on occasion learn our own routes from an external connection. Hmmh, risky - certainly something I wouldn't advise even for small ISP's. It depends on your requirements. Top of the list is buying someone or getting bought and using their upstreams without changing AS number everywhere. Customers multi-homing with your ARIN/APNIC/RIPE space. I can think of a few others Actually I was. 6509/Nexus vs. EX8200, Cisco ME vs. EX4200, ASR vs. M/MX and CRS vs. T/TX are all different conversations. I thought you were alluding to something like that which I would have agreed with. No, I wasn't alluding to that at all. If not then the statement that a particular platform is 99% preferred for a certain use is arbitrary and will vary from one company to the next. To each his own I guess. ___ cisco-nsp 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] IOS XR BGP
There's no family aggregate in cisco. That's one of the reasons people buy junipers in the first place. If you want it to disappear when the comprising routes are gone you should redistribute and use the aggregate address command. You can also use suppress maps but I can't remember if they work with IGP routes or not. You'll have to look it up. If your internet routes are already in your IGP what's the problem with redistributing them into BGP? Usually the goal is to keep the public routes out of the IGP, but that depends on your topology. 2011/11/25 Nick Ryce nick.r...@lumison.net Hi Vinny, aggregate-address only aggregates routes already in BGP and not from IGP. I was looking for a way to do this ala Junos that doesn't require me to redistribute OSPF routes to BGP. Nick -Original Message- From: Vinny Abello [mailto:vi...@abellohome.net] Sent: 24 November 2011 19:17 To: Oliver Boehmer (oboehmer) Cc: Nick Ryce; Eric Morin; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IOS XR BGP On 11/24/2011 11:04 AM, Oliver Boehmer (oboehmer) wrote: I require the specific to be from IGP. I have a funny feeling all I need to do is redistribute OSPF into BGP then use the aggregate-address as-set summary-only yes, and it looks you can limit the OSPF redistribution to a few (a single?) more specific as you are only interested in the core reachability? Just need confirmation if there is any other way. not to simulate your current solution in XR. But have you thought about orignating the aggregates you advertise to the Internet (and customers) via some central routers in your core, for example some RRs, instead of on the edge(s)? This way you will never advertise them in case your edge devices become isolated (which, if I read you correctly, is the purpose of this exercise?). If you chose this approach, you might also want to advertise these aggregates with a special next-hop (like a private 10.1.1.1), and add a static null0 to 10.1.1.1/32 on all your BGP routers. Then every router seeing the aggregate will automatically create a Null0 and will drop all packets to unallocated address space within these aggregates as soon as it enters your network? I have to agree with Oli here. I've followed this practice originating aggregate routes from extremely well connected core routers at multiple points in my networks. To the best of my memory, I never used network statements at the border or edge. Once or twice when building out to a new geographical area before having all of the redundancy in place, this practice has saved us when a single failed backbone link isolates the new routers in question. They stop announcing anything to their peers and we stop seeing any announcements from them obviously when their iBGP sessions drop with the rest of the network. To me this always seemed like the most simple and effective approach. Is there a reason this would not work in this situation or is there a reason using the aggregate-address commands provides some other benefit I'm missing? -Vinny -- 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. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept 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/
Re: [c-nsp] risks of assigning redundant paths on data link layer to end-customer
2011/11/21 Martin T m4rtn...@gmail.com Lets assume there is a following setup: http://img844.imageshack.us/img844/9133/stp.png ISP manages R1, C3550-24-A, C-355-24-B and C2950-24-A. Customer-SW is fully under customer control. As you can see, there are two paths to Customer-SW. What are the risks with such setups in general? I'm able to name two disadvantages: 1) in case customer configures (accidentally) spanning-tree bpdufilter enable on his ports Fa0/23 - 24 there will be L2 loop which causes very high PPS and CPU load in ISP devices That is a risk, but control plane protection is a must for a router in an environment like that so hopefully you're protected against it. You could also write the config for them or a config guide to keep them from messing things up. Is the environment multi-tennant? If not the only risk is one customer blowing up their own environment. If not you or the ISP should install some protections to contain bridging loops. 2) in case customer switch is a STP root(it's easy to become root switch by changing priority when root guard on ISP side is not configured) and customer VLAN is through many ISP switches, non-optimal paths for traffic can take place You should never connect to a customer network without some protection. Root-guard or setting your priority to extend sys-id +1 or something. You should also manipulate the spanning-tree priorities so that the same links block in every vlan. Are there some other possibilities for L2 loop? Or anyone seen a hub/switch which handles 802.1d/802.1w BPDU's somewhat abnormally and might create a L2 loop(under certain circumstances)? Any other disadvantages which might arise with setups like this? Unidirectional-links, bad-asics/switchports, cables plugged into the wrong ports, bad copper/fiber patch panels. There are several things that could cause a bridging loop. Layer-2 networks aren't to be feared it just needs to be done right like everything else. You can probably find some docs on ISP best practices on google to fill in anything that doesn't come up in this thread. regards, martin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unable to transmit tagged frames over q-in-q tunnel
Your diagram got mangled. I think your PE facing interface has to be a tunnel as well depending on the type of router you are connected to. Are you the provider or is the MPLS transport a managed service? Many platforms have a discard counter that may increment if it's dropping frames because of the vlan tags. That would help you at least figure out what device is dropping the frames. You should also be using 8100 tags (cisco default). 2011/10/27 Gökhan Gümüş ggu...@gmail.com Dear folks, I have an issue with one of our customer service. Gi0/5 Gi0/27 Gi5/13 Fa3/13 Customer SW Customer Edge Switch-A PE1 --MPLS Core --PE 2--Customer Edge Switch-B --Customer SW I am using q-in-q tunneling to enable customer traffic. Before, customer port on Customer SW facing our edge switch was in ACCESS mode and it was working. Now they have decided to configure this interface as a TRUNK to transmit multiple VLANs over the trunk. But they can not. Currently ports are configured as trunk and customer can only transmit traffic when they do not tag frames ( native-vlan config ) For note, i am not using vlan dot1q tag native command which is also double-tagging native vlans. MTU is fine and above 1504 bytes. Please see our configs on Customer Edge Switch below; *Customer Edge Switch A;* A#sh run interface Gigabit Ethernet0/5 Building configuration... Current configuration : 337 bytes ! interface GigabitEthernet0/5 switchport access vlan 1106 switchport mode dot1q-tunnel switchport nonegotiate load-interval 60 speed 100 duplex full l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable end A#sh run interface GigabitEthernet0/27 Building configuration... Current configuration : 251 bytes ! interface GigabitEthernet0/27 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,9,1101,1102,1106 switchport mode trunk switchport nonegotiate end - *Customer Edge Switch B;* B#sh run interface fa3/13 Building configuration... Current configuration : 366 bytes ! interface FastEthernet3/13 mtu 2000 load-interval 60 switchport switchport access vlan 1106 switchport mode dot1q-tunnel switchport nonegotiate l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree bpdufilter enable end B#sh run interface gi5/13 Building configuration... Current configuration : 298 bytes ! interface GigabitEthernet5/13 mtu 2000 load-interval 30 speed nonegotiate switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1101,1102,1106 switchport mode trunk no cdp enable end Is there anybody who had such issue before? Thanks and regards, Gokhan Gumus ___ cisco-nsp 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] Unable to transmit tagged frames over q-in-q tunnel
I wasn't the original poster. :) The PE platform and configuration is important here though. It has to know to send double tagged frames from the remote end. I know for Juniper PE routers we have to turn on q-tunneling on the switch to get it to work for example. 2011/10/27 Laurent Geyer lge...@gmail.com On Thu, Oct 27, 2011 at 12:41 PM, Keegan Holley keegan.hol...@sungard.com wrote: Your diagram got mangled. I think your PE facing interface has to be a tunnel as well depending on the type of router you are connected to. Assuming that the user port was an access port for vlan 1006 before, nothing would really have to change on the PE configuration. The dot1q-tunneling configuration simply stacks a Vlan 1006 tag on top of the frames received from the user port. For all intends and purposes everything else stays the same. Keegan - Your configuration looks fine, are you 100% sure that the customer is sending tagged frames? - Laurent ___ cisco-nsp 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] Incomplete ARP entry
Is it possible that the devices stop talking if they don't get any traffic? So there are two events that happen. One your device disappears, two the arp times out. They may not be happening at the same time though. Your network description is kind of vague so I'm not sure where to go from there. Are there other devices that take the exact same path that are reachable throughout? Is there regular traffic to these devices that times out? 2011/10/27 Faraz Syed farazaz...@gmail.com Hello Everyone, We have few wireless devices which connects to Cisco 6500 series router. We manage those wireless devices by using the trunk ports. We lose the management connectivity to certain hosts (wireless devices) for few hours and then it come back up by its own. Interesting thing is that the wireless link is always up and passing traffic. If I check the arp table and it shows the Incomplete ARP entry for those hosts. It is not related to one wireless device that I can pinpoint there is the issue. There is no common factor in this issue, other than that they are all in VLAN101. I have listed the configuration for two ports as an example, also Vlan101 and the arp table entries. Please, let me know how to troubleshoot this issue and can provide directions to resolve this issue. Thanks // Faraz interface FastEthernet1/14 description NYC03-RDL-210G 5.3_69.38.136.41 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10,101,200-410,800 switchport mode trunk switchport nonegotiate logging event link-status speed 100 duplex full no cdp enable spanning-tree bpdufilter enable end interface FastEthernet1/6 description NYC03-RDL-300D_74.212.168.135 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 101,200-400,701,800 switchport mode trunk switchport nonegotiate speed 100 duplex full no cdp enable spanning-tree bpdufilter enable interface Vlan101 description REDLINE MGMT VLAN ip address 69.38.137.33 255.255.255.224 secondary ip address 69.38.229.225 255.255.255.224 secondary ip address 69.38.136.33 255.255.255.224 secondary ip address 67.216.23.65 255.255.255.224 secondary ip address 74.212.183.33 255.255.255.224 secondary ip address 67.216.20.65 255.255.255.192 secondary ip address 74.212.168.129 255.255.255.224 no ip redirects end cr.nyc0003.C.ny#sh arp | i Incomplete Internet 69.163.59.221 0 Incomplete ARPA Internet 10.0.0.10 0 Incomplete ARPA Internet 69.163.59.220 0 Incomplete ARPA Internet 69.163.59.223 0 Incomplete ARPA Internet 10.0.0.80 Incomplete ARPA Internet 69.163.59.222 0 Incomplete ARPA Internet 10.0.0.90 Incomplete ARPA Internet 74.212.183.42 0 Incomplete ARPA Internet 69.163.59.217 0 Incomplete ARPA Internet 69.163.59.216 0 Incomplete ARPA Internet 69.163.62.222 0 Incomplete ARPA Internet 69.163.59.219 0 Incomplete ARPA Internet 10.0.0.12 0 Incomplete ARPA Internet 69.163.59.218 0 Incomplete ARPA Internet 69.163.59.213 0 Incomplete ARPA Internet 69.163.59.212 0 Incomplete ARPA Internet 69.163.59.215 0 Incomplete ARPA Internet 74.212.183.34 0 Incomplete ARPA Internet 69.163.59.214 0 Incomplete ARPA Internet 10.0.0.10 Incomplete ARPA Internet 69.163.59.209 0 Incomplete ARPA Internet 10.0.0.60 Incomplete ARPA Internet 69.163.59.208 0 Incomplete ARPA Internet 69.163.59.211 0 Incomplete ARPA Internet 69.163.59.210 0 Incomplete ARPA Internet 69.163.59.205 0 Incomplete ARPA Internet 69.163.59.204 0 Incomplete ARPA Internet 74.212.181.58 0 Incomplete ARPA Internet 69.163.59.207 0 Incomplete ARPA Internet 69.163.59.206 0 Incomplete ARPA Internet 69.163.59.201 0 Incomplete ARPA Internet 69.163.59.200 0 Incomplete ARPA Internet 69.38.237.155 0 Incomplete ARPA Internet 69.163.59.203 0 Incomplete ARPA Internet 69.163.59.202 0 Incomplete ARPA Internet 69.38.169.221 0 Incomplete ARPA Internet 69.163.59.197 0 Incomplete ARPA Internet 69.163.59.196 0 Incomplete ARPA Internet 69.163.59.199 0 Incomplete ARPA Internet 69.163.59.198 0 Incomplete ARPA Internet 69.163.59.193 0 Incomplete ARPA Internet 69.163.59.192 0 Incomplete ARPA Internet 74.212.183.55 0
Re: [c-nsp] Downsides of combining P and PE functions into a single box
2011/10/20 Pavel Lunin plu...@senetsy.ru Folks, let me make a tiny semi-philosophical summarization on this :) Any layer of hierarchy in packet networks gives you another chance to benefit from statistical multiplexing (trick, because of which packet switching rules). The more flows from individual users/subscribers you aggregate in a single link/box, the less dispersion of their insensitivity and the denser you pack the packets on a line (the more it's like TDM), thus the bigger the benefits. You could do the same by just adding more links in the same layer. If you have a core layer but only two links to it that is still your bottle neck. Also MPLS doesn't do statistical multiplexing or load-balancing the same way TDM would. Most flows will follow the same path from point A to point B so even though it's packet switched it has some of the constraints of circuit switched topologies. Statistical multiplexing within a box or within the queues in a box is a different discussion. In addition if your core serves users from different time-zones, its efficiency will be even higher because of the 'natural TDM' human biology creates. lol I'm pretty sure people still use their lines at night. Backup traffic has to go somewhere. However you won't earn anything if the streams are already well packed (someone has already skimmed the cream off). As Mark has mentioned, there is no point in selling switched vll/vpn/anything to customers who fully fill their last-miles of capacity close to that of your core-links. Well, at least if the number of such customers is statistically significant. This is what L1 multiplexing is invented for. This depends on your pricing. Hopefully those customers that are allowed to saturate the PE links are paying enough to finance bandwidth/box upgrades. Hopefully, the financials work out so that profit is made if 100 customers fill the pipes or 10 or 2 for that matter. ___ cisco-nsp 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] 6509 port-channel logical interfaces
I need to add a port channel with L3 sub interfaces to a 6509 with a SUP720. Here's the code and a sh mod from the box. This isn't explicitly in the feature navigator. Is this not supported at all or do I just need a different code version or feature set. s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(33)SXH3a, RELEASE SOFTWARE (fc1) Mod Ports Card Type Model Serial No. --- - -- -- --- 1 24 CEF720 24 port 1000mb SFP WS-X6724-SFP 52 Supervisor Engine 720 (Active) WS-SUP720-3B 62 Supervisor Engine 720 (Hot)WS-SUP720-3B Mod Sub-Module Model Serial Hw Status --- -- --- --- --- 1 Centralized Forwarding Card WS-F6700-CFC 4.1Ok 5 Policy Feature Card 3 WS-F6K-PFC3B2.4Ok 5 MSFC3 Daughterboard WS-SUP720 3.2Ok 6 Policy Feature Card 3 WS-F6K-PFC3B 2.4Ok 6 MSFC3 Daughterboard WS-SUP720 3.2Ok ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
2011/10/19 Dobbins, Roland rdobb...@arbor.net On Oct 19, 2011, at 10:46 AM, Keegan Holley wrote: If you can connect all your PE's without adding aggregation and core layers you'd obviously time, money and avoid complexity. On the contrary, while collapsed-core designs have some of the advantages you mention and have certainly been implemented successfully, the need for edge features/functionality *adds* complexity, IMHO. It depends on the features. Whatever features you need on the PE are always going to be there. Whether you connect your PE to a core of P routers or connect the PE routers to each other doesn't affect this in most cases. Mark had a good example with the need for ingress re-marking, but even that is not required in all networks. Beyond that I don't see alot of reasons to go with P routers unless you have a need for route/traffic aggregation which many networks do need. ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
2011/10/19 Mark Tinka mti...@globaltransit.net On Wednesday, October 19, 2011 11:46:53 AM Keegan Holley wrote: If you can connect all your PE's without adding aggregation and core layers you'd obviously time, money and avoid complexity. Correct on time and money, but curious about complexity. I find having a core layer in an IP/MPLS network increases simplicity due to the abstraction and demarcation it provides, but YMMV. In a large network yes. Most larger networks need it simply for traffic and route aggregation. In smaller networks you may only have a few pops and even fewer features. It may make sense to have a network of PE's. It really does depend on the specifics of a company and it's customers. ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
2011/10/19 Mark Tinka mti...@globaltransit.net On Wednesday, October 19, 2011 04:29:50 PM Keegan Holley wrote: It depends on the features. Whatever features you need on the PE are always going to be there. Whether you connect your PE to a core of P routers or connect the PE routers to each other doesn't affect this in most cases. Mark had a good example with the need for ingress re-marking, but even that is not required in all networks. Beyond that I don't see alot of reasons to go with P routers unless you have a need for route/traffic aggregation which many networks do need. The issue with features is they sometimes don't work, or do the opposite of what you expect. Pure MPLS cores are simple, and quite feature-basic. However, it is understood that this may not be sufficient justification to spend $$ a small ISP may not have. +1 on the $$$. Still PE is one network P+PE is essentially two networks. I still don't see how this adds to complexity. For most commonly used features the per-hop-behavior is the same on the PE router whether the packet came from a core P router or another PE router. Maybe I'm missing something, but PE routers are not going everywhere and if we're strictly talking about complexity it's easier to manage one network instead of 2. ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
The real question: Are you selling customer links that are near to or equal to the size of your core links(s). Why would anyone do this on purpose and not upgrade the core? I understand over-subscription but having your edge links the same speed as your core is just asking for trouble. Anyone doing 10GE edge or looking at 100GE for customer-facing handoffs can save significant amounts of money by doing P/PE. While there are tradeoffs, not having the cumulative cost of a packet being A+B+C and perhaps can be localized to a single device has value. I'm surprised that Rolland doesn't see this as an optimization as it would be something the Arbor equipment could help you optimize. Not sure how you save money by buying extra routers. That's a pretty aggressive discount structure. While some may see these cost savings as inelegant, the idea of a core will continue to come under these pressures. Keep in mind the fraction of a chassis you must allocate for these edge - core links and core - core links. These have real world costs. There's a reason everyone didn't go out there and load-up on OC768 hardware and just stuck with N*10G. The finances don't work out. Cards are cheaper than entire routers in most cases especially at N*10 and 40G speeds. Assuming you want chassis based, with redundant control planes and whatever the vendor uses for fabirc blades. I'm not saying everyone should throw their core P routers into a dumpster, but I don't see how having them saves money. You also have to add the cost of service contacts, power, fingers and eyes to keep them running, etc.. I think people who need separate cores should have them. However, I don't see how P routers save money or reduce complexity. - Jared ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
2011/10/19 Jared Mauch ja...@puck.nether.net On Wed, Oct 19, 2011 at 12:58:41PM -0400, Keegan Holley wrote: The real question: Are you selling customer links that are near to or equal to the size of your core links(s). Why would anyone do this on purpose and not upgrade the core? I understand over-subscription but having your edge links the same speed as your core is just asking for trouble. Because the core link sizes are the same as the edge sizes. This means you have to create duplicate links to haul it through more routers vs less. Anyone doing 10GE edge or looking at 100GE for customer-facing handoffs can save significant amounts of money by doing P/PE. While there are tradeoffs, not having the cumulative cost of a packet being A+B+C and perhaps can be localized to a single device has value. I'm surprised that Rolland doesn't see this as an optimization as it would be something the Arbor equipment could help you optimize. Not sure how you save money by buying extra routers. That's a pretty aggressive discount structure. I'm saying buy less routers. If your customer is talking to a peer, place them on the same device. Don't have a 'peering edge' vs 'customer edge'. It may make sense to terminate your 'core' links on the same device as well. It may not. This all depends. The problem here is how people think about the network. There must be a core, or you must transit a P device. Oh... I think we were saying the same thing here. It really depends on the requirements of each individual network. While some may see these cost savings as inelegant, the idea of a core will continue to come under these pressures. Keep in mind the fraction of a chassis you must allocate for these edge - core links and core - core links. These have real world costs. There's a reason everyone didn't go out there and load-up on OC768 hardware and just stuck with N*10G. The finances don't work out. Cards are cheaper than entire routers in most cases especially at N*10 and 40G speeds. Assuming you want chassis based, with redundant control planes and whatever the vendor uses for fabirc blades. I'm not saying everyone should throw their core P routers into a dumpster, but I don't see how having them saves money. You also have to add the cost of service contacts, power, fingers and eyes to keep them running, etc.. I think people who need separate cores should have them. However, I don't see how P routers save money or reduce complexity. They don't in many cases. I think you misunderstood my comments. +1 on the misunderstanding. My apologies. I should be working anyway :) - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net 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/
Re: [c-nsp] Downsides of combining P and PE functions into a single box
2011/10/19 Mark Tinka mti...@globaltransit.net On Thursday, October 20, 2011 12:49:39 AM Keegan Holley wrote: +1 on the $$$. Still PE is one network P+PE is essentially two networks. No. P + P/PE is one network. P + P/PE are two devices. Maybe I was a bit loose with the details here. My only point was that the portion of the network where the P routers live has different rules than the edge. I still don't see how this adds to complexity. For most commonly used features the per-hop-behavior is the same on the PE router whether the packet came from a core P router or another PE router. There are many features that are not turned on on core routers, which are on edge routers. I can't recall the last time I logged into our core routers for anything other than to add a new link. You don't want to know how often our Provisioning team are logging into the PE routers. If one PE router goes down, I don't have to worry about 25% of the country feeling the pinch, as I have that abstraction. Well I think we both can agree that the network you work in requires P routers for a number of reasons. I understand the feature differences between the P and PE routers. The point was that people implement P routers for different reasons, but not for their own sake. I wouldn't use a collapsed core to route 25% of a county let alone a country. Maybe I'm missing something, but PE routers are not going everywhere and if we're strictly talking about complexity it's easier to manage one network instead of 2. It's all one network. What's more than one is the devices, not the network itself. Even if it may seem trivial, it's important to make this distinction, because successful networks are always scaling up, and scaling up means buying more kit whether we like it or not, i.e., device numbers go up, sometimes because you want to delineate functions. +1 I like the pay as you grow model. If you are small just use a collapsed core. As your customer base grows you can move customers to create a core layer or just buy more links and more boxes. Chances are that if the original poster needed a separate core he wouldn't be here asking the question. ___ cisco-nsp 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] Advertising connected subnet in BGP (more specific) - design advise needed
As others have said you should probably make the other route a /25 as well. Also, you may want to advertise both routes from both sides and make one version less preferred. If one of the /25 disappears you'll blackhole traffic. As for outbound traffic if you add a second vrrp group as master on the other CE as a second default gateway you can split the outbound traffic as well if you haven't already done so. Design wise, seems like an IGP would be better here unless this is some kind of L3vpn service. 2011/10/18 David Prall d...@dcptech.com Frank, I just played with this and it appears to be working for me: ip route vrf C1 172.16.1.0 255.255.255.128 GigabitEthernet 0/0 0.0.0.0 I do not have a default route in the table with my configuration. David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Frank Volf Sent: Tuesday, October 18, 2011 8:36 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Advertising connected subnet in BGP (more specific) - design advise needed Hi All, I need some suggestions for solving this problem I'm having. I have a subnet 172.16.1.0/24 (that is stretched over two datacenters) and that is directly connected to two CE routers A and B. The CE routers advertise the subnet in BGP towards the WAN, but for load-balancing reasons they do not only advertise 127.16.1.0/24, but also 172.16.1.0/25 (router A) and 172.16.1.128/25 (router B). So, from the WAN traffic is load-balanced (assuming proper distribution of the server IP's in the subnet half of the servers are reached via CE A and half of the servers are reached via CE B) and if the primary path fails the /25 is removed from BGP and the /24 takes over the routing over the other CE. From the LAN point of view, there are two VRRP groups, one being the master on router A and one master on router B (with some tracking on the uplink). Summarizing, the (simplified) config looks like: interface GigabitEthernet0/0 ip address 172.16.1.2 255.255.255.0 vrrp 10 ip 172.16.1.1 vrrp 10 prio 110 vrrp 10 track 10 decrement 30 vrrp 20 ip 172.16.1.254 vrrp 20 prio 90 vrrp 20 track 10 decrement 30 ip route 172.16.1.0 255.255.255.128 GigabitEthernet0/0 router bgp 65001 neighbor 192.168.1.1 remote-as 65000 network 172.16.1.0 mask 255.255.255.0 network 172.16.1.0 mask 255.255.255.128 And this works fine. Now comes the issue. Another network needs to be connected to the CE router with a separate routing table, hence VRF's. So, I was thinking this must be easy: make a VRF C1, move interface g0/0 into a vrf C1, move the BGP configuration to the C1 address-family and move the ip route to the VRF as well. The last is however a problem: TESTCE(config)# ip route vrf C1 172.16.1.0 255.255.255.128 GigabitEthernet 0/0 % For VPN or topology routes, must specify a next hop IP address if not a point-to-point interface I just can't get it to work and reading Cisco documentation this is not going to be fixed either. The only alternative that I can think of is using BGP inject maps, but apparently they are not working in VRF's either. I could split the subnet in two /25's and use a secondary on the interface, but I consider that quiet ugly because I want to keep /24 on the servers (so server-server communication on the subnet is not going through the router). Does anybody have a suggestion how to solve this problem? Kind regards, Frank ___ cisco-nsp 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] Downsides of combining P and PE functions into a single box
It depends on your routers and your business. People like P routers because they have the option of running just the IGP and a label protocol with a very small table. PE routers have to store an entire table, including L2VPN and L3VPN routes. I would ask the opposite question. Is your network big enough to warrant a core layer? PE routers are always necessary unless you plan to do a way with customers. If you can connect all your PE's without adding aggregation and core layers you'd obviously time, money and avoid complexity. 2011/10/18 Herro91 herr...@gmail.com Hi Group, I'd like to get some feedback from the list as to potential downsides of combining P and PE functionality into a single router. Besides the obvious configuration concerns - i.e. changes being made on an edge box that is also a core, as well as additional heavy lifting for a P router - are there other items to be concerned about? This would be on high end distributed forwarding hardware (not the little stuff). TE is definitely a possibility in addition to L2/L3VPNs/VPLS. Please let me know if you need additional info to make the right conclusions. Thanks in advance! ___ cisco-nsp 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] 7500 Crashes
It looks like your logs start after the boot/switchover. Do you have a syslog server? Anything interesting come in before these messages that may have been wiped on boot? Does your show ver show a strange reboot reason or a traceback? Do you have any thing setup for automated logins to this box? Someone else mentioned an SSH bug. I think it was triggered when two ssh sessions/sockets were started in quick succession IIRC. 2011/10/15 Jason Berenson ja...@pins.net Greetings, I've got a 7500 running with the following: NAME: 7507z chassis, ID:76032590, DESCR: 7507z chassis PID: 4 , VID: Hardware Version : 1.00 Board Revision : B0, SN: 76032590 NAME: Line Card 0, DESCR: Versatile Interface Processor (VIP4-80) PID: VIP4-80 , VID: Hardware Version : 2.04 Board Revision : A0, SN: 21008718 NAME: Card Slot 0, Bay 0, DESCR: Dual Port FastEthernet (RJ45) PID: PA-2FE-TX , VID: Hardware Version : 1.0 Board Revision : B0, SN: MIC050800X2 NAME: Card Slot 0, Bay 1, DESCR: Serial T3+ Port Adapter PID: PA-T3+, VID: Hardware Version : 1.0 Board Revision : B0, SN: 17830995 NAME: Line Card 1, DESCR: Versatile Interface Processor PID: VIP2-50 , VID: Hardware Version : 2.03 Board Revision : A0, SN: 17943843 NAME: Card Slot 1, Bay 0, DESCR: FastEthernet Port Adapter PID: PA-FE-TX-ISL , VID: Hardware Version : 1.0 Board Revision : A0, SN: 06340347 NAME: Card Slot 1, Bay 1, DESCR: Dual Port FastEthernet (RJ45) PID: PA-2FE-TX , VID: Hardware Version : 1.0 Board Revision : C0, SN: JAE070103WM NAME: RSP at Slot 3, DESCR: R5000 PID: RSP4 , VID: Hardware Version : 1.1 Board Revision : D0, SN: 11519637 NAME: Line Card 4, DESCR: Versatile Interface Processor (VIP4-80) PID: VIP4-80 , VID: Hardware Version : 2.04 Board Revision : B0, SN: 28099188 NAME: Card Slot 4, Bay 0, DESCR: Channelized DS3 - single wide, one port PID: PA-MC-T3 , VID: Hardware Version : 1.0 Board Revision : A0, SN: 17832515 NAME: Card Slot 4, Bay 1, DESCR: Channelized DS3 - single wide, one port PID: PA-MC-T3 , VID: Hardware Version : 1.0 Board Revision : A0, SN: 17827319 NAME: Line Card 5, DESCR: Versatile Interface Processor (VIP4-80) PID: VIP4-80 , VID: Hardware Version : 2.03 Board Revision : A0, SN: 25567743 NAME: Card Slot 5, Bay 0, DESCR: Channelized DS3 - single wide, one port PID: PA-MC-T3 , VID: Hardware Version : 1.0 Board Revision : A0, SN: 24501038 NAME: Card Slot 5, Bay 1, DESCR: Channelized DS3 - single wide, one port PID: PA-MC-T3 , VID: Hardware Version : 1.0 Board Revision : A0, SN: 15811547 NAME: Line Card 6, DESCR: Versatile Interface Processor (VIP6-80) PID: VIP6-80 , VID: Hardware Version : 2.01 Board Revision : A0, SN: 29452845 NAME: Card Slot 6, Bay 0, DESCR: GigabitEthernet Port Adapter PID: PA-GE , VID: Hardware Version : 1.0 Board Revision : A1, SN: 18636663 The box keeps switching between the RSPs for some reason. Here's the relevant logs: *Oct 15 01:11:07.175: %HA-5-NOTICE: Suspending initialization pending bulk/config sync... *Oct 15 01:11:07.251: %HA-5-NOTICE: Command line console will unavailable until init completes. *Oct 15 01:11:07.351: %HA-5-NOTICE: Defaulting to hsa mode until sync completed and system restarted. *Oct 15 01:11:07.363: %HA-5-SYNC_NOTICE: Bulk sync started. *Oct 15 01:11:07.675: %HA-5-SYNC_NOTICE: Bulk sync completed. *Oct 15 01:11:11.899: %HA-5-SYNC_NOTICE: Config sync started. *Oct 15 01:11:11.975: %HA-5-NOTICE: Resuming initialization... *Oct 14 20:11:16.987: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:11:16 UTC Sat Oct 15 2011 to 20:11:16 EST Fri Oct 14 2011, configured from console by console. *Oct 14 21:11:16.987: %SYS-6-CLOCKUPDATE: System clock has been updated from 20:11:16 EST Fri Oct 14 2011 to 21:11:16 EDT Fri Oct 14 2011, configured from console by console. Oct 14 21:11:34.274: %HA-5-SYNC_NOTICE: Config sync completed. Oct 14 21:11:34.926: %SYS-5-RESTART: System restarted -- Cisco IOS Software, RSP Software (RSP-JK9O3SV-M), Version 12.4(25), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/**techsupporthttp://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Tue 21-Apr-09 19:28 by prod_rel_team Oct 14 21:11:35.046: %SSH-5-ENABLED: SSH 1.99 has been enabled Oct 14 21:11:39.930: %SNMP-5-COLDSTART: SNMP agent on host CS75-111.1 is undergoing a cold start Oct 15 00:24:04.052: %HA-2-CUTOVER_NOTICE: Cutover initiated. Cease all console activity until system restarts. Oct 15 00:24:04.052: %HA-2-CUTOVER_NOTICE: Do not add/remove RSPs or line cards until switchover completes. Oct 15 00:24:04.052: %HA-2-CUTOVER_NOTICE: Deinitializing subsystems... Oct 15 00:24:04.052: %OIR-6-REMCARD: Card removed from slot 0, interfaces disabled Oct 15 00:24:04.052: %OIR-6-REMCARD: Card removed from
Re: [c-nsp] ASR9k CWDM Optics
2011/10/16 Gert Doering g...@greenie.muc.de Hi, On Sun, Oct 16, 2011 at 06:05:16PM +0200, Mikael Abrahamsson wrote: Make sure whatever discounts you get do not expire. Like our Cisco Powered Network certification, which Cisco revoked because we didn't sell enough boxes right in the middle of the dotcom- crisis? Nah, can't trust vendors to remember any promises made before a sale. I'm the last one to defend cisco but if you want to be literal you promised to buy the boxes when they promised you the discount so I suppose it goes both ways. ;) ___ cisco-nsp 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 on a pair of 7201's
I've done it playing around with 7204's. Is the IGP and RSVP/LDP working? That was usually what broke for me. Stupid question but did you configure the xconnect on the other side? 2011/10/13 Amir Chaudhri amir.chaud...@ascertiva.com has anyone ever successfully got EoMPLS working between a pair of 7201s Commands Im trying to use are below. mpls label protocol ldp interface GigabitEthernetX/X description Link to GR mtu xxx no ip address xconnect [IP Address] 100 encapsulation mpls End Thanks in advance… Amir Chaudhri | Systems Administrator | Ascertiva Group Ltd Warwick House | Houghton Hall Park | Houghton Regis | Dunstable | LU5 5ZX Office: 01582 556137 | Fax: 01582 539090 | Mobile: 07931 846677 Email: amir.chaud...@ascertiva.commailto:amir.chaud...@ascertiva.com | web: www.ascertiva.comhttp://www.ascertiva.com/ Do you need to print out this email? Be green - keep it on the screen! P CONFIDENTIALITY NOTICE The contents of this email and any attachments to it are confidential and are intended solely for the individual(s) and/or organisation(s) to whom this email is addressed. If you are not the intended recipient of this email any use, disclosure, forwarding, printing or copying of this email and any attachments to it by you may be unlawful. If you have received this email in error please notify us immediately by email to postmas...@ascertiva.com Ascertiva Group Warwick House Houghton Hall Park Houghton Regis Dunstable LU5 5ZX Registered Office: Warwick House, Houghton Hall Park, Houghton Regis, Dunstable, LU5 5ZX. Registered in England No. 02513162. Web Site: www.ascertiva.com This e-mail has been scanned for all viruses by Star.(O) The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ cisco-nsp 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] Faster BGP Failover
2011/10/11 Vincent Aniello vincent.anie...@pipelinefinancial.com Can you be a bit more specific about the config? We have two routers, the first router has two Internet connections, ISP A and ISP B. The second router has a backup connection to ISP A. All three connections take a full BGP routing table and the two routers peer with each other via iBGP. The connections to the ISPs are Ethernet. We recently had a failure of ISP B and the Ethernet interface stayed up, but the BGP peer went down, which is what prompted this question. Do you know how fast this needs to be? The best answer is probably to just shorten your timers. Providers aren't running BFD with customers as far as I know. You should be able to set them to 10/30 , or 5/20. BGP timers are negotiated to the lowest value so even if your carrier doesn't like it they won't be able to stop you. This will also save you the trouble of opening a ticket or requesting that this be done. This is presumably an eBGP session across a local interface? Correct. What platform IOS version? 7206 routers running the 12.4T IOS train. Thanks. --Vincent Disclaimer: Any references to Pipeline performance contained herein are based on internal testing and / or historic performance levels which Pipeline expects to maintain or exceed but nevertheless does not guarantee. Congested networks, price volatility, or other extraordinary events may impede future trading activities and degrade performance statistics. Pipeline is a member of FINRA and SIPC. ___ cisco-nsp 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] Faster BGP Failover
2011/10/11 Devon True de...@noved.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2011 1:41 PM, Keegan Holley wrote: BGP timers are negotiated to the lowest value so even if your carrier doesn't like it they won't be able to stop you. This will also save you the trouble of opening a ticket or requesting that this be done. Unless the carrier specified a minimum hold time allowed. router(config-router)#timers bgp 10 10 ? 0-65535 Minimum hold time from neighbor cr Interesting. I would assume there would be a command for this. I've never had 10/30 not work in practice though so I suppose the limit is this or lower. ___ cisco-nsp 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 7200 router with AAA problem and nvram corruption
Do you have a backup of the config? Assuming you're doing all this just to migrate to a new box why not use the backup config to build the new box or migrate? If you are going to fix it why not get the new working NPE and use the backup to rebuild? I'm not sure password hacking the broken one is worth it anymore. Also, if you boot it it may come back in an even worse state. 2011/10/8 root net rootne...@gmail.com Hello, Just want to confirm what should be done. I have a router that resulted in a bad NPE 225. Had a spare NPE 225 but it wouldn't work for some strange reason. So had an old NPE 150 laying around so inserted. When the router came backup noticed that a message flashed nvram corrupt on console. All circuits came up lovely but now I can't access the router to possibly move circuits to different router. I have the router configured with AAA for local and no backup authentication. (Silly) What should be the steps I take to recover access to router so I can setup AAA for local and backup auth? Thanks, rootnet08 ___ cisco-nsp 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] cisco3700 router
It's probably supported given the right IOS since the 7300 was supposed to be a high end platform. I'd be more worried about the fact that it's EOL/EOS if you are rolling it out new. 2011/10/7 Gert Doering g...@greenie.muc.de Hi, On Fri, Oct 07, 2011 at 04:37:37PM -0400, Deric Kwok wrote: but I can't find encapsulation command ! In that case, it's well possible that your IOS version that we don't know anything about, doesn't support 802.1q tagged subinterfaces. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp 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] general question on VRFs and FIBs...
2011/9/27 Robert Raszuk rob...@raszuk.net Hi Keegan, over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. For packets coming from customer (CE) there is no need for any additional lookup as switching vectors of the interfaces (logical/physical) are already locked to a given VRF. /* One exception of the above is Policy Based VRF selection where you are choosing VRF dynamically based on preconfigured policy or even remote radius lookup. in this configuration interfaces are not bounded to any VRF. */ For packets coming from the core to a PE the VPN label directly points to the right VRF (per vrf label/aggregate label case). For per CE or per prefix labels no IP lookup is necessary in the VRFs at all for packets going to the CE. I think you misunderstood. This is all part of the same lookup. The first is matched by the interface, the second by policy and the third by mpls tag. My point is that it is the same operation across multiple FIBs or a single FIB. ___ cisco-nsp 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 Required MTU Size Between Cisco Devices
I think MTU discovery just has to work if you are going to use something smaller than 1500 and fragmentation needs to work if you are going to set it to something small. There are other caveats for specific scenarios. 2011/9/22 Righa Shake righa.sh...@gmail.com Hi, Is there any required MTU Size for Cisco BGP session to work Regards, Righa Shake ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Required MTU Size Between Cisco Devices
5MB of BGP traffic seems strange although I never watched it receive a full table so I may be mistaken. Secondly, your problem is more MTU discovery than specific MTU's if I had to guess. There is alot of info missing though. What kind of traffic? How many hops? Are the other hops larger or smaller than 1600? What is the error you get when BGP drops? What kind of device? interface? provider circuit or dark? 2011/9/22 Righa Shake righa.sh...@gmail.com I had set my Interfaces on an MTU size of 1600 and BGP was unstable and could not pass traffic over 5MB. However when i tested an found that I could pass traffic without any issues when I eliminate the router. When I set the MTU to 1500 the BG was up and am now able to pass traffic without any problem. Regards, Righa Shake On Thu, Sep 22, 2011 at 9:03 PM, Keegan Holley keegan.hol...@sungard.comwrote: I think MTU discovery just has to work if you are going to use something smaller than 1500 and fragmentation needs to work if you are going to set it to something small. There are other caveats for specific scenarios. 2011/9/22 Righa Shake righa.sh...@gmail.com Hi, Is there any required MTU Size for Cisco BGP session to work Regards, Righa Shake ___ cisco-nsp 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] Understanding ethertype
2011/9/17 Jason Lixfeld ja...@lixfeld.ca I'm running into an issue with a carrier NNI circuit that is manifesting itself as one-way traffic over an EoMPLS VC. I believe this behaviour to be the result of the ethertype that the carrier requires us to set on this interface. By and large, the IOS-(XE|XR) default seems to be 0x8100, but in this case, the carrier needs 802.1ad/0x88a8. If I set this ethertype and put an IP address on the subinterface, I can ping across the 802.1ad circuit without issue, like so: I think you may be confusing ethertype and tag type. A change in ethertype means you are using a different ethernet based protocol (0x88a8) mac-in-mac in this case. 0X8100 is a TPID and identifies the type of vlan tag used within the IPv4/ethernet (ethertype 0x8000). The choices are usually 0x8100 for normal 802.1Q vlan tags and 0x9100 for service provider tags. 9100 tags are only used in q-in-q however I think cisco gear simply stacks two 8100 tags by default. http://en.wikipedia.org/wiki/EtherType ! interface GigabitEthernet0/0/2 dot1q tunneling ethertype 0x88A8 ! interface GigabitEthernet0/0/2.3000 encapsulation dot1Q 3000 ip address 1.1.1.1 255.255.255.252 ! router#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 1.1.1.1 - c89c.1d1d.c902 ARPA GigabitEthernet0/0/2.3000 Internet 1.1.1.2 0 001c.25be.63da ARPA GigabitEthernet0/0/2.3000 bpe01.151front711#ping 1.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 58/58/59 ms router# Now if I attach an EoMPLS tail to this subinterface, ie: ! interface GigabitEthernet0/0/2 dot1q tunneling ethertype 0x88A8 ! interface GigabitEthernet0/0/2.3000 encapsulation dot1Q 3000 xconnect 10.10.10.10 69 encapsulation mpls ! With the far end of the vc being port based, like so: ! interface GigabitEthernet0/16 xconnect 11.11.11.11 69 encapsulation mpls ! And I stick a wireshark enabled laptop on Gi0/16, I see traffic coming from behind the 802.1ad link, but they don't see anything coming back from me. That leads me to believe that there is something with the ethertype possibly not being re-written to 0x88a8 when it's trying to exit the carrier NNI port. I don't know enough about Ethertype behavior, so I can't be sure this is plausible. While I wait for a TAC engineer to research and comment on my issue, I figured I'd ask hear to maybe learn something in the mean time. I've never come across an upstream link that required 0x88a8 ethertypes. Most equipment that I've seen that uses 0x88a8 can easily translate to 0x8000 so normal gear can read it. I'd probably start with whoever operates that next hop link and see if they can hand you 0x8000 and translate it on their end. If that's not an option I'd just capture traffic in both directions and see what's different. 0x88a8 traffic uses fields that the IOS-XR device may not support. There are special vlan-id's such as ISID or B-VID that may or may not be generated just by changing the ethertype on the interface. ___ cisco-nsp 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] Q and Q De-encapsulation
On Aug 24, 2011, at 5:12 AM, Arie Vayner (avayner) avay...@cisco.com wrote: Do you want to strip only the outer tag? If yes, then it should be easy... Just configure the port as a trunk, and the egress port as an access port of the VLAN you want to send there (it would work for 1 out tag VLAN at a time) I was wondering about this. You'd essentially be egressing tagged frames from an access port. (that's just weird) Also doesn't q-in-q have a different tpid than regular vlan tags? How does the box know what to do with the frames if the ingress port is just a normal trunk? If you want more flexible QinQ support, you most likely need to look at ES+ modules. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Aumand Sent: Wednesday, August 24, 2011 00:07 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Q and Q De-encapsulation I was wondering if anyone knew if it was possible to have a single gigabitethernet port on a 7609 running Version 12.2(33)SRB5 take in 802.1Q tagged traffic and strip off the outer tag all on the single ingress port? Thanks in advance, Mike Mike Aumand Network Engineer Cornerstone Telephone Company, LLC. Richmond Telephone Company ~ Richmond Networx 2 Third Street, Suite 303 Troy, NY, 12180 518-328-0353 (w) 518-577-8705 (c) 518-860-1860 (f) This message may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ cisco-nsp 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] Q and Q De-encapsulation
2011/8/24 Tóth András diosbej...@gmail.com An egress tunnel port strips the 2-byte Ethertype field (0x8100) and the 2-byte length field and The ethertype field is part of the ethernet header and is set to 0x8000 for all modern ethernet. Did you mean it rewrites the TPID field from 0x9100 to 0x8100? Did you mean it strips the outertag? Likewise the TPID is part of a valid vlan tag and shouldn't be stripped. Also, what happens if the next hop device is using TPID 0x9100? http://en.wikipedia.org/wiki/EtherType http://en.wikipedia.org/wiki/IEEE_802.1Q transmits the traffic with the 802.1Q tag still intact to an 802.1Q trunk port on a customer device. I guess I'd expect a port configured as access not to transmit tagged frames and to not have to go look at the ingress port to figure out what's coming out of it. Still seems strange. The 802.1Q trunk port on the customer device strips the 802.1Q tag and puts the traffic into the appropriate customer VLAN. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dot1qtnl.html Andras On Wed, Aug 24, 2011 at 2:37 PM, Keegan Holley keegan.hol...@sungard.com wrote: On Aug 24, 2011, at 5:12 AM, Arie Vayner (avayner) avay...@cisco.com wrote: Do you want to strip only the outer tag? If yes, then it should be easy... Just configure the port as a trunk, and the egress port as an access port of the VLAN you want to send there (it would work for 1 out tag VLAN at a time) I was wondering about this. You'd essentially be egressing tagged frames from an access port. (that's just weird) Also doesn't q-in-q have a different tpid than regular vlan tags? How does the box know what to do with the frames if the ingress port is just a normal trunk? If you want more flexible QinQ support, you most likely need to look at ES+ modules. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Aumand Sent: Wednesday, August 24, 2011 00:07 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Q and Q De-encapsulation I was wondering if anyone knew if it was possible to have a single gigabitethernet port on a 7609 running Version 12.2(33)SRB5 take in 802.1Q tagged traffic and strip off the outer tag all on the single ingress port? Thanks in advance, Mike Mike Aumand Network Engineer Cornerstone Telephone Company, LLC. Richmond Telephone Company ~ Richmond Networx 2 Third Street, Suite 303 Troy, NY, 12180 518-328-0353 (w) 518-577-8705 (c) 518-860-1860 (f) This message may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ cisco-nsp 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] VPLS on software routers
Have you looked into irb? I'm not sure if it's more important to have vpls in your lab or just to bridge the traffic. IRB is pretty easy and supported on everything. 2011/8/21 Pshem Kowalczyk pshe...@gmail.com On 21 August 2011 21:45, Robert Hass robh...@gmail.com wrote: Hi I just want to build VPLS lab (carry couple of VLANs between 4 routers) for test some solutions. Is VPLS supported on some software routers (7200, ISR G2, ASR1k) ? Performance is not important here - as it's for LAB few mbps is enough. ASR1k will have VPLS support somewhere around 3.5S (Nov this year) if things go according to the plan. BTW - 1k is not a software router. kind regards Pshem ___ cisco-nsp 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] ARP oddness
You didn't mention if the replies are destined for the server you're doing the capture on, IE the mac addressed learned on the port you're sniffing. If not, it might be unknown unicast. Switch flood frames destined for macs that haven't been learned yet. What is the source and dest of the arp replies and where are the two boxes in relation to the server you're on? Sent from my iPhone On Aug 19, 2011, at 4:24 PM, Chuck Church chuckchu...@gmail.com wrote: Anyone, Researching some issues at a remote site, seeing something I don't think should happen. A packet capture on this remote server using wireshark and focusing in on ARP is seeing all the requests (as I'd expect), but I'm also seeing unicast replies that I shouldn't. The MAC address table on the switch I'm attached to shows only the MAC of this remote server on that port. There are no SPAN sessions on the switch either. The destination addresses aren't multicast, they're true unicast. Yet I'm seeing all these unicasts that aren't my mac address. Is there some function built into a Cisco switch that broadcasts these to make them act like gratuitous ARPs, or am I really seeing something that shouldn't happen? It's on a Sup2+ 4500, running 12.2(25)EWA10 (I know it's ancient, vendor owns it...) Thanks, Chuck ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP question : What's the best way for filtering outgoing prefixes?
On Aug 19, 2011, at 11:25 AM, Jay Nakamura zeusda...@gmail.com wrote: While testing, I am wondering, is it standard practice to clear my community strings from routes before going to peer/transit? On Thu, Aug 18, 2011 at 4:00 PM, Jay Nakamura zeusda...@gmail.com wrote: This is a bit complicated. Let's say we are provider X. X is connected to transit provider A and B. X currently uses prefix-list to filter outgoing BGP announcement. We are now getting a customer that wants to multi-home, so their transit provider is X and C. We gave them a /24 from our block, let's call it IP1. I was simulating how I should configure our routers so it was secure and did all the right things when I noticed IP1 route coming in from provider A is getting advertised to provider B through us. It makes sense since it passes our outgoing prefix list. (So, AS path was AS_X AS_A AS_Customer into provider B) What's the best way to prevent this? Here are the two options I was thinking of doing Option 1 Set all routes learned from A and B with unique community, and filter out any routes with that community for outgoing routes to A and B. Option 2 Filter on AS-Path for routes going out A and B with AS-X$ AS-X_(AS_CUSTOMER)+_$ (I think, I haven't looked closely at AS path syntax) With Option 1, I don't have to do anything when we add another BGP customer but not sure what the overhead of tagging all routes coming in with community is. With Option 2, I have to edit the AS-path every time we add a customer. Is there a better option? You could track your RR space and filter the aggregates orlonger. Option 1 requires others to transit your communities which they may not. Option 2 requires you to constantly update prefix lists as customers come and go. Today junk could be tomorrow's paid transit if a certain customer leaves. The only hole is RR space assigned owned by customers would have to be tracked individually which can get cumbersome. ___ cisco-nsp 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] 3750G Terminating a Metro-e circuit
Does anyone know of any issues with 3750G's and metro-e circuits? I vaguely remember hearing of issues where you couldn't disable auto-negotiation on the 3750G so it wouldn't like to transport gear that doesn't autoneg. I'm looking at a couple of metro-e circuits connected to 6509's that won't seem to link. I verified fiber and sfp types and I see light from the provider at both ends. ___ cisco-nsp 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] etherchannel load-balancing and unpredictability
2011/7/19 Steven Pfister spfis...@dps.k12.oh.us I have a question regarding etherchannel load balancing. I've got a 4507R switch connected to a 3560 switch by means of two content filters which are acting as transparent bridges. The two ports on each side that the content filters are connected to are set up as access ports and are in an etherchannel. The load balancing method on each switch is set to src-dst-ip. I was under the impression that each pair of source and destination ip address would select exactly one content filter no matter which direction. this is exactly what is unpredictable about it. The operation is a hash so different src/dst pairs aren't always going to chose different links. For example (a very simple one) if you have a subnet 192.168.100.0/24 and station .1 talks to station .3 and .5 there's nothing to prevent both of those conversations from using the same link. It's based on a mathematical formula that does not vary. If for example you add .2 and it talks to .4 and .6 they may use the second link. However, what if the odd numbered conversations are just above 1G say 1.2G or so. They will drop packets and there will be no way to hash them to a different link other than changing load-balancing algorithms. The being said the other algorithms are just as unpredictable for just the same reasons. It depends completely on your traffic patterns. Adding TCP/UDP port may even this out a bit but I don't believe it is supported on the 3560. ___ cisco-nsp 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] Suspect MTU Issues
2011/7/12 Gert Doering g...@greenie.muc.de Hi, On Tue, Jul 12, 2011 at 07:46:00PM +, Leigh Harrison wrote: There is a legacy layer 2 network which has had an mpls network built over it. A link between two of the data centres is a dark fibre between two Cisco 3750E switches running on the ten gig ports with a variety of vlans passing over a dot1q trunk. Both of these switches are pretty much out of the box and have a standard system mtu of 1500 You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. gert It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 ___ cisco-nsp 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] Suspect MTU Issues
2011/7/13 Gert Doering g...@greenie.muc.de Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. I just wanted to show that 1500 bytes is too big as is 1499, 1498, and 1497, which was also part of the original question. Also, that it get's worse with IPsec or other protocols that would add headers such as tunneled IPv6. We are ultimately saying the same thing. It's not good to run MPLS with the MTU set to 1500. ___ cisco-nsp 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] Suspect MTU Issues
That depends on your use. Some technologies such as certain types of storage replication perform better without jumbo frames. Some won't even use them. Generally speaking the maximum supported by all of your devices would be the best thing to configure as long as it doesn't break some other application. 2011/7/13 Leigh Harrison lharri...@convergencegroup.co.uk This discussion brings me neatly onto my follow on question then:- On the ME3600X switches they will allow me to set interface mtu of up to 9800 bytes. Some of my team are arguing that we only need 1548, some are saying 1600. We've got dark fibre, so should we be going for the maximum mtu size possible on the box (taking into account max mtu of the box it plugs into), or is there a good all rounder for mtu size? What mtu will cause me the least pain in years to come? Thanks for all of the valuable insight so far. Leigh Sent from my iPhone - apologies for any spelling or grammar mistakes On 13 Jul 2011, at 18:57, Keegan Holley keegan.hol...@sungard.com wrote: 2011/7/13 Gert Doering g...@greenie.muc.de Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. I just wanted to show that 1500 bytes is too big as is 1499, 1498, and 1497, which was also part of the original question. Also, that it get's worse with IPsec or other protocols that would add headers such as tunneled IPv6. We are ultimately saying the same thing. It's not good to run MPLS with the MTU set to 1500. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This email has been scanned by Webroot for the presence of known Viruses and Spam. ___ cisco-nsp 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] Suspect MTU Issues
Most switches (not specifically familiar with the ME series) will compensate for dot1q tags by transparently allowing packets of MTU+dot1q tag size. This is not usually true for mpls (again not directly familiar with the ME series) that being said the mpls header is exactly 4 bytes which seems to be your ceiling so I'd say you were right. 2011/7/12 Leigh Harrison lharri...@convergencegroup.co.uk All, I have inherited a network which I feel is having MTU issues, but I cannot be sure and would like a second opinion. There is a legacy layer 2 network which has had an mpls network built over it. A link between two of the data centres is a dark fibre between two Cisco 3750E switches running on the ten gig ports with a variety of vlans passing over a dot1q trunk. Both of these switches are pretty much out of the box and have a standard system mtu of 1500. Connected to these 3750E switches are a set of Cisco ME3600X switches that are talking mpls to each other via an SVI, over a vlan on the trunk between the 3750E switches. Sending packets of 1496 bytes over the mpls works just fine, but when I push 1497, it doesn't work - hence my thoughts of an MTU issue. Have we fallen into a silly trap or is there a straightforward solution? Is this an MTU problem or am I clutching at straws? Thanks in advance, Leigh ___ cisco-nsp 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 7010 SVI issues
2011/7/9 Renelson Panosky panocisc...@gmail.com I have a couple nexus pod up and running so i just created two more SVI in my Nexus 7010 with the following configuratons. All my other SVIs are configured exactly the same way and all of them are UP UP but the two new one i just add. They are all added to all my trunks and all my trunks are UP UP. I do know on some devices in the IOS platform the SVI will not come up until you put a node on it (plug something in oe of the ports assign to that vlan.) but int he same token some the other SVIs have no nodes on them and they are UP UP and i can ping them. Any input would be greatly apprecisted The only requirement is that the vlan the SVI is in actually exists in the switch and that there is a spanning tree instance running for it. If you have those the SVI will show up up even with no ports. (not 100% sure a spanning tree instance will run with no access or trunk ports egressing the vlan though) ___ cisco-nsp 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] [j-nsp] Firewalls as-a-service in an MPLS infrastructure...
I never said it's not possible, just that I've rarely seen it done correctly. Not everyone has your level of skill. Just for arguments sake how did you handle shared bandwidth? In other words how did you keep a DDOS attack on one customers's segment from using up all available bandwidth in some shared segment upstream from the firewall. 2011/7/8 Stefan Fouant sfou...@shortestpathfirst.net On 7/8/2011 12:28 AM, Keegan Holley wrote: Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. Years ago when I had to develop a Network Based Firewall solution for a particular ISP in order to comply with the Federal Government's NetworX bid, we chose Juniper's NS-5400 for precisely this reason. In ScreenOS you have the concept of resource profiles with which you can limit the amount of CPU, Sessions, Policies, MIPs and DIPs (used for NAT), and other user defined objects such as address book entries, etc. that each VSYS can avail. These are essential elements of any multi-tenant firewall solution and evaluated platforms should likewise have similar offerings to contain resource usage for individual customers. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.**net http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ cisco-nsp 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] [j-nsp] Firewalls as-a-service in an MPLS infrastructure...
I think the original point was how best to do firewall as a service not necessarily DDOS attacks. My point was that I've seen this done incorrectly a few times in the past. Mostly issues with design and not the box itself. Also, I seems better to use a virtual appliance and a server platform than an hardware appliance with limited virtual instances. 2011/7/8 Ziv Leyes z...@gilat.net Radware's DefensePro comes in mind when talking about hardware performance during DDOS, you could put the device in the middle of the network, and use some redirector such as CID or Alteon to separate customers that pay for the service and customers that don't and pass only the traffic of the ones you want through the device. We did a pilot with this setup and it worked great, I didn't see any DDoS that could possibly tickle the device's resources... Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Stefan Fouant Sent: Friday, July 08, 2011 1:51 PM To: Keegan Holley Cc: juniper-...@puck.nether.net; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] [j-nsp] Firewalls as-a-service in an MPLS infrastructure... On 7/8/2011 12:28 AM, Keegan Holley wrote: Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. Years ago when I had to develop a Network Based Firewall solution for a particular ISP in order to comply with the Federal Government's NetworX bid, we chose Juniper's NS-5400 for precisely this reason. In ScreenOS you have the concept of resource profiles with which you can limit the amount of CPU, Sessions, Policies, MIPs and DIPs (used for NAT), and other user defined objects such as address book entries, etc. that each VSYS can avail. These are essential elements of any multi-tenant firewall solution and evaluated platforms should likewise have similar offerings to contain resource usage for individual customers. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Firewalls as-a-service in an MPLS infrastructure...
Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. 2011/7/6 Derick Winkworth dwinkwo...@att.net Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] how to block youtube using CLI commands
Lol@ 4.2.2.2 The biggest problem with blocking you tube is that is available from multiple IP's. Anyone smart enough to rind another on and set their dns host file to it will easily get around this. Then there's VPN proxy exploits. The best thing is to implement a web filtering solution. Sent from my iPhone On Jun 26, 2011, at 8:54 AM, Bikash Bhattarai bik...@dristi.com.np wrote: Hi Shetta, You can follow below link for configuration guide. It worked for me. https://supportforums.cisco.com/docs/DOC-8028 Regards, Bikash On Sun, Jun 26, 2011 at 5:17 PM, Ahmed Shetta ahmed.she...@gmail.comwrote: Dear all , can anyone tell me how to block you tube on the cisco router and allow it for me only , Regards, ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Regards, Bikash Bhattarai Dristi Tech (P.) Ltd. Lazimpat, Kathmandu Mob: +977-9851039710 ___ cisco-nsp 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] Service Provider Networks: Cisco vs XYZ
2011/6/24 Derick Winkworth dwinkwo...@att.net 1. Yes there are studies and comparisons. They are usually skewed/biased favorably towards the company that is paying to have the study/comparison done. Agree, I don't think any of the neutral parties care about vendor selection. They are more concerned with the technologies themselves for the most part. 2. Juniper/Alcatel-Lucent I think today are the primary competing vendors you want to look at. Agree. 3. Tackling the service-provider problem is different than the enterprise problem. There is a reason why other vendors have had success in this space. Sometimes they really do make better products for the application/deployment scenario in question. In practice I don't think I've ever seen a completely homogenous network. I think anyone designing a SP style network of significant size should at least consider a multi-vendor solution. Each vendor has it's strengths and weaknesses. There's also the difference in price to consider. I think that the popularity of cisco and their various products is a bit of a hinderance to progress. --- On Thu, 6/23/11, ar ar_...@yahoo.com wrote: From: ar ar_...@yahoo.com Subject: [c-nsp] Service Provider Networks: Cisco vs XYZ To: cisco-nsp cisco-nsp@puck.nether.net Date: Thursday, June 23, 2011, 10:37 PM Hi Peeps. I am pro-Cisco on building IP/MPLS service provider networks. I've proven its capabilities. However, does anyone has a study/comparison or testing with other brands? Brocade,Huawei,Juniper,HP? ___ cisco-nsp 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] DWDM Optics use
I'm struggling with a use for DWDM optics. I understand the concept of DWDM/CWDM and phase shifting to create more links over a single fiber. Once that is done the ASIC/FPGA bandwidth allocated to the port remains the same, correct? So if I create multiple 1G connections on a single port with these magic sfp's am I still limited by the 1g/2g chip in the device. Are all the logical connections forced to be sub-rate? I know the larger equipment handles this differently, so I'm only concerned with the 3750/3560 size boxes. Thanks, ___ cisco-nsp 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] DWDM Optics use
No this is exactly what I was looking for. I can definitely understand the usefulness of having your routers transmit on a specific channel. Thanks! 2011/6/4 Brandon Applegate bran...@burn.net On Sat, 4 Jun 2011, Keegan Holley wrote: I'm struggling with a use for DWDM optics. I understand the concept of DWDM/CWDM and phase shifting to create more links over a single fiber. Once that is done the ASIC/FPGA bandwidth allocated to the port remains the same, correct? So if I create multiple 1G connections on a single port with these magic sfp's am I still limited by the 1g/2g chip in the device. Are all the logical connections forced to be sub-rate? I know the larger equipment handles this differently, so I'm only concerned with the 3750/3560 size boxes. Hmm, I may be misunderstanding - but I think you are misunderstanding how DWDM tuned optics works. A 1g or 10g DWDM optic is still a singe 1 or 10 interface. It's just that that transmit laser is tuned to a channel (i.e. 1546.12). Router#sh int tenGigabitEthernet 7/1 | inc media Full-duplex, 10Gb/s, media type is DWDM-46.12 The reason you may need this is to connect this port directly to a (R)OADM. There are (at least) two ways on the DWDM transport side to handle this: a) Use a *sponder (transponder = 1:1, muxponder = n:1, etc). You can use 'grey' optics now (i.e. good ole SX/LX etc). These cards on the DWDM side are expensive though. or b) Buy DWDM optics, and go directly into the mux/demux on the DWDM. We are doing option b) in parts of our network because the cost of a) was too much, and these links aren't going to do any moving around or going away any time soon. Again, apologies if I've misunderstood you. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 SH1-0151. This is the serial number, of our orbital gun. ___ cisco-nsp 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 peer/customer routes
2011/5/31 vince anton mvan...@gmail.com Hello everyone, need some insight from the list as how to best approach a bgp routing/policy issue, and whats generally done and considered good practise and good policy. Not to be rude but this might actually be the least specific question I've ever heard. A good routing policy takes alot. It also ties into the buisness model of your company. You should be able to find some basic do's and don't via google though. Cisco.com/Juniper.net should have some implementation guides. Then there are third parties like cymru, nanog, etc... I operate a transit AS (say AS10), and I have a customer (AS 5) who buys transit from me. I also peer with AS11 - no transit either way on this, just peering, ie sending my networks to AS11, and receiving AS11's networks Now AS5 also becomes a transit customer of AS11, and so on the peering link with AS11, I now can see the IP Blocks of my customer AS 5 Until you're allowed to fire customers you should block these routes. AS Path length, and Localpref sorts out most routing issues here, except for the case where AS5 advertises a more specific route to AS11, than to me (AS10). Not good.. Block them using prefix lists based on your ARIN assignments and what your other customers are advertising. This will also require you to keep some kind of routing database so you can keep the filteres up to date. Your prefix lists should look something like ip prefix-list ARIN#/20 le 32 that should cover the more specifics. You should also track exactly what your customers can and cannot advertise to you and make them call you to add blocks to that list. What happens if the geniuses in AS5 advertise you a default or a miscofigured /8. So what happens now is that for this more specific customer prefix, I have a specific route saying some AS5 nets are preferable via the peering link than via the direct customer link, and if I want to deliver transit traffic to my customer, my router would choose the peering link. This is not desirable behaviour. yep. bad and potentially expensive. Is the solution here, filtering any customer prefixes from any other links (ie filtering AS5 nets on link to AS11), or is there any other way of going about this ? The only safe thing to do is to control specifically what comes in and out of your AS using specifically designed prefix lists at all peering points. Thanks, anton ___ cisco-nsp 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] 10 GigE traffic generator
Depends on what you're looking for. I've had good results with IXIA ixiacom.com. They will do everything from FC/FCoE to simulated bgp/mpls peerings and IMIX traffic. It's a hardware appliance so it performs very well and is very flexible in the types of data it can create. It also scales pretty high. THey offer a 12slot chassis that gives you a ceiling of 64 10G or 300 + 1G ports. The downside is that it's hardware based and a little more expensive than the some of the other solutions. They have a rental program that's pretty reasonable depending on the length of your test. 2011/5/31 Alan Buxey a.l.m.bu...@lboro.ac.uk Hi, Anyone tested a reliable 10 GigE traffic generator capable of layer 2-7 that can also simulate client server type conenctions? I have purchased one such simulator with mixed results, hopefully someone in the community has had success somewhere else? packetstorm? http://www.packetstorm.com/psc/psc.nsf/site/index there are a whole slew of such tools, some free, some commercialworth a visit to eg google ? there was an interesting one that I heard of and saw demo'd a few weeks back - I'll see if I can dig up the info tomorrow alan ___ cisco-nsp 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] Link/Line Testing
2011/5/31 James Bensley jwbens...@gmail.com Hi list, Is there any way from either a router or L3 switch I can saturate a line/link? I don't want to use a computer or external device. Network appliances just don't have the chops to generate line rate data. You need an external device to get anything accurate. Even the high end platforms have only PIII cpu's most of which is dedicated to something other than packet generation. I wouldn't trust any results based on packets generated from a router. Lets pretend that $provider has given me a 1Gbps up-link to a device which terminates various 100 Mbps links, so having a pc with software to pump out 1Gbps would be no good. You could have a pc with software pump out 100M to match your CIR. iperf and other tools are pretty simple. Then there are ethernet test sets that will generate realistic traffic rates and patterns based on standards link IMIX. I've also generated traffic in the past by causing a contained bridging loop somewhere. Since most people have up links many times faster that most other ports on their routers/switches how can I test the up link throughput from the device. Just set the test parameters to match the CIR/rate-limit and not the port speed. If for what ever reason I had 1Gbps access ports with a 1Gbps up link I could use a pc/hardware traffic generator and test the link and for example routers ability to policy route and filter at 1Gbps but I just want to test the physical link its self for its top end throughput. Which top end the physical 1G or the logical 100M? Again, I'd use some sort of load generation software or an ethernet test set. Even if you had a CRS or something to generate the data I doubt it could generate 1Gbps from the processor without keeling over. HTH, Keegan ___ cisco-nsp 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] Simulate download
yep it has to be processed, process switched and stored somewhere. All things that don't happen with traffic that traverses the router. I wouldn't consider this accurate unless you were using it to test the throughput on a router upstream from the one you are using to download a file. 2011/5/30 Scott Granados sc...@granados-llc.net You can do that but i find many times copy functions to and from the router itself are several orders slower than traffic actually traversing the device. On May 30, 2011, at 7:42 AM, d...@dcptech.com wrote: Copy xxx://yyy null: Hi all can i from a Cisco router simulate a download session? as i am on a laptop and downloading a file to see the transfer speed? Thanks Best Regards, Mohammad Khalil ___ cisco-nsp 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] using RANCID in a CCIE lab
rancid is a good tool. It's also base on expect and perl so it's easy to modify the scripts to do other things. I installed this in a few other labs (non-certification) the biggest problem I ran into was everyone's tendency to blow away the routes,interface IP's and account info that alows RANCID to do it's work. Beyond that it's a great tool. Be careful where you run it. It's a pain to install on certain linux distros. HTH, Keegan 2011/5/29 Saxon Jones saxon.jo...@gmail.com It seems like a good idea to me. I do this manually when building test labs and it works quite well. Doing a config replace http from a cvsweb instance should let you revert to a previous config quite easily, though we use https and authentication so I never bothered to try that part myself. -saxon On 27 May 2011 16:10, Rogelio scubac...@gmail.com wrote: I would like to make a public CCIE lab for friends and have it reset all the configs at pre-set times. Is a tool like RANCID a good way to do this? I know that it can log in and do commands at preset times, and I thought that it's DB snapshots might be helpful as well. -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubac...@gmail.com ___ cisco-nsp 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] using RANCID in a CCIE lab
what platform did you install it on? RANCID was pretty easy to install, but I could never get the cvs viewer they recommended working. I had to switch back to CVS web. 2011/5/29 Scott Granados sc...@granados-llc.net Just to add to this, we use RANCID in both production and lab environments and it works very well. I found the install to be easy and it's very flexable. On May 29, 2011, at 10:25 AM, Ryan West wrote: On Sun, May 29, 2011 at 13:10:57, Keegan Holley wrote: Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] using RANCID in a CCIE lab rancid is a good tool. It's also base on expect and perl so it's easy to modify the scripts to do other things. I installed this in a few other labs (non-certification) the biggest problem I ran into was everyone's tendency to blow away the routes,interface IP's and account info that alows RANCID to do it's work. Beyond that it's a great tool. Be careful where you run it. It's a pain to install on certain linux distros. It can modified pretty easily to allow backup and configuration pushes via a terminal server. Look for user_chat to see the modifications to clogin that allow it. RANCID is great IMO, with all the expect and credential information in place, it's easily adaptable cron jobs and scripts. I'm far from a programmer, but I was able to setup an automated block list for the ASA based off the emerging threats IP list using RANCID to push the changes. -ryan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] using RANCID in a CCIE lab
Yea, that's what I was talking about. I think you can use apt if you install in a debian/ubuntu box. I had to install it on a centos box and I couldn't find a yum repository. Yea they recommended viewvc+mysql both manual installs in centos/fedora/RHEL. websvn is pretty easy to install too. There were alot of steps to manual install in centos, but I get alot less headaches from red hat based utility boxes even if software installs are a pain. 2011/5/29 Ryan West rw...@zyedge.com On Sun, May 29, 2011 at 14:28:34, Keegan Holley wrote: Subject: Re: [c-nsp] using RANCID in a CCIE lab what platform did you install it on? RANCID was pretty easy to install, but I could never get the cvs viewer they recommended working. I had to switch back to CVS web. I've had no issues installing it on Debian boxes, but we've been using websvn. What was the recommended CVS viewer? Viewvc? -ryan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] how many maximum BGP routers can be to reside in one AS？
Not that I'm aware of. BGP doesn't require the same computations as an IGP so it's almost limitless. iBGP isn't much different than eBGP in the way routes are calculated from the perspective of what you are trying to do. The bottleneck is almost certainly going to be the amount of RAM in your boxes. No matter what you decide the best thing you can do is create a through IP addressing and summarization plan. Have you looked at separate AS's instead of confederations. They will allow you better control of traffic. There are some design issues with AS-confed. Anything with that many routers should be very interesting. Best of luck. 2011/5/26 ying-xiang ying-xi...@163.com in another words,is there a limit to be the amount of one AS BGP routers? we have a network design will put 2500+ routers running ibgp session into a single AS.of course,RR or confederation is required.even so, i am not sure it will be done with this design.AFAIK, router’s memory is a import thing to consume of bgp route prefix.apart from this,what else should get my attention? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] how many maximum BGP routers can be to reside in one AS?
Why on gods green earth would anyone fully mesh 2500 routers. Next let's try 2500 switches with spanning tree off. OP said he was using RR's already so I didn't really feel the need to explain that. 2011/5/26 Gert Doering g...@greenie.muc.de Hi, On Thu, May 26, 2011 at 09:36:54AM -0400, Keegan Holley wrote: Not that I'm aware of. BGP doesn't require the same computations as an IGP so it's almost limitless. Try building a fully-meshed network of 2500 routers and be surprised on the amount of computational power you'll need... gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] how many maximum BGP routers can be to reside in one AS?
2011/5/26 Nick Hilliard n...@foobar.org On 26/05/2011 18:20, Keegan Holley wrote: Why on gods green earth would anyone fully mesh 2500 routers. People do the most extraordinary things. A couple of years ago, a well large italian access service provider natted their entire customer range to a handful of public addresses. That was fun, and I expect it taught them some serious lessons about how natting your entire customer range is a really bad idea. But I guess lots of service providers will need to learn this lesson the hard way very soon. Agreed, but hopefully that provider didn't do that based on a vague conversation via a newsgroup with someone halfway across the world with their first message saying that they do not plan to nat their entire customer range. ;) ___ cisco-nsp 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] Thousands of tcp sessions stuck in TIMEWAIT
what ports? can you post some of it? On Fri, May 13, 2011 at 8:46 PM, Kevin Graham kgra...@industrial-marshmallow.com wrote: vty access lists along with login max-failure? (guessing somewhat blindly without visibility into what the active tcb's were) [sent from my mobile] On May 11, 2011, at 7:47 AM, Joe Freeman j...@netbyjoe.com wrote: I have a customer with an 1841 doing webvpn, running advsecurity-12.4-24.T5. They have been randomly loosing the ability to connect to resources through this unit. A show tcp brief reveals that there are thousands of sockets stuck in TIMEWAIT. In fact it took almost six minutes for the show tcp brief to dump it's output to a file in flash:. A clear tcp tcb * will, of course wipe out all the connections and allow the customer to resume making connections for a time. Anyone have any thoughts on how I should troubleshoot this further, or even better, thoughts as to resolution? Thanks- Joe ___ cisco-nsp 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] Thousands of tcp sessions stuck in TIMEWAIT
On Sun, May 15, 2011 at 10:17 AM, Dobbins, Roland rdobb...@arbor.netwrote: On May 15, 2011, at 7:49 PM, Joe Freeman wrote: I about to the point where I'm going to create a TCL script and use the event scheduler just to clear the TIMEWAIT sessions every 12 hours or s It would probably be a good idea to use NetFlow or some other traffic classification mechanism to get some visibility into the traffic targeting the box, first. I would agree with netflow with the addition of an old fashioned packet capture. If you see rst packets for the sessions that are in TIMEWAIT then it could be a bug. If they just are opened but do not close then you could be being DDOS'd. Do you recognize the source IP's of the traffic? I'm not that familiar with webvpn, but is there an idle timer that you could configure? Seems more effective than clearing the sessions periodically. ___ cisco-nsp 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] MBGP for Multicast with VRF-Lite
On 03/05/11 12:49, Arie Vayner (avayner) wrote: James, Why do you need to advertise multicast routes over BGP? We had to do this a while back to comply with upstream policies. They were running multicast AF, and if we didn't advertise our unicast prefixes into the multicast AF as well Huh? That's like advertising v6 routes into a v4 table. Are you sure you don't just need the unicast routes for rpf? I haven't done juniper multicast in a while but it sounds like you just need the unicast routes in inet.2. If all else fails you can always post to the juniper list. ___ cisco-nsp 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] Redistributing certain BGP routes into OSPF
Oh, well if you set next hop self all eBGP routes will come in with DMZ's address. iBGP routes are never modified. They are long overdue for BGP, lots of other boxes already run it and have been for years. On Wed, Apr 27, 2011 at 7:59 PM, Christopher J. Wargaski war...@gmail.comwrote: Hey Keegan-- Yes, I have two routers separated by a firewall (which is incapable of running BGP). The two routers exchange routes via eBGP multi-hop without problem. Now, I would like to take some of those routes advertised by the DMZ-rtr (and learned by the Indy-rtr) and advertise them back to the ASA with the next hop being the DMZ-rtr. Re-advertising the routes is not the problem, I can do that fine. However, making the next-hop be the DMZ-rtr is the thing that I have not been able to do. After some more thought today, I am afraid this will just not work so I think I'll wait until the ASA will run BGP. (Which incidentally is targeted for late 2011.) cjw ___ cisco-nsp 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] Redistributing certain BGP routes into OSPF
I don't understand the drawing, but it looks like you have two routers separated by a firewall and you are trying to send traffic to the DMZ router even though the routes are advertised by the Indy-rtr. This seems to not make sense, but I think it's just because I don't understand your diagram. You could create a loopback on the indy-rtr then set the next hop to it in a route map on the indy-rtr as they are advertised to the DMZ router and configure another static route on the ASA for said loopback. You could also buy a firewall that supports BGP. On Tue, Apr 26, 2011 at 1:11 AM, Christopher J. Wargaski war...@gmail.comwrote: I have eBGP multi-hop set up between a third party provider's router in a DMZ and a branch router as such: Indy-Rtr--ASA inside interface ASA DMZ interface--DMZ-Rtr---(T-1)PSvrs Indy-Rtr = 10.2.1.1 DMZ-Rtr = 10.0.22.50 ASA-inside = 10.2.1.3 ASA-DMZ = 10.0.22.1 The Indy-Rtr and the DMZ-Rtr exchange BGP routes just fine. Some of the traffic from the Indy branch must pass through the ASA and through the DMZ router to access some servers (PSvrs). I presently have static routes on the ASA so it knows which interface to route the traffic bound for the PSvrs. I presently redistribute some of the enterprise network routes from BGP into OSPF as such: router ospf 10 router-id 192.168.254.2 log-adjacency-changes redistribute bgp 65001 subnets route-map BGP-to-OSPF passive-interface FastEthernet0/1 passive-interface Serial0/0/0 passive-interface Serial0/1/0 network 10.2.0.0 0.0.7.255 area 0 network 10.2.8.0 0.0.7.255 area 0 network 192.168.0.0 0.0.0.255 area 0 route-map BGP-to-OSPF permit 10 match ip address 10 access-list 10 remark ACL for BGP route map access-list 10 permit 10.0.0.0 0.7.255.255 access-list 10 permit 10.9.0.0 0.0.255.255 access-list 10 permit 192.168.0.0 0.0.7.255 access-list 10 permit 192.168.9.0 0.0.0.255 access-list 10 permit 10.8.0.0 0.0.255.255 access-list 10 permit 192.0.0.0 0.255.255.255 What I would like to do is take the routes that the Indy-Rtr receives from the DMZ router and send them to the ASA in OSPF. Easy enough, I can match on the IP address for the source of those routes and set the next hop, right? Something like this: route-map Stinky permit 10 match ip route-source 11 set ip next-hop 10.0.22.50 access-list 11 remark ACL for Stinky route map access-list 11 permit host 10.0.22.50 When I apply this route-map (to OSPF), the routes are indeed redistributed, but the next hop is set as 10.2.1.1, the F0/0 IP address configured on the Indy router. Harumph! Am I trying to teach a pig to sing here or do you think this is doable? If the latter, what might I be doing wrong? Regards, cjw ___ cisco-nsp 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] no bgp route from 0.0.0.0 for a interface ip address
Are you asking about a route to 0.0.0.0 or the default or a route with a next-hop of 0.0.0.0? On Tue, Apr 19, 2011 at 10:46 AM, tao liu taosys...@gmail.com wrote: following is the config for bgp and show ip route, thanks router bgp 65453 no synchronization bgp router-id 192.168.96.2 bgp log-neighbor-changes redistribute connected route-map NEW redistribute static route-map NEW neighbor 192.168.2.49 remote-as 65450 neighbor 192.168.2.49 send-community neighbor 192.168.96.1 remote-as 65453 neighbor 192.168.96.1 update-source Loopback0 neighbor 192.168.96.1 next-hop-self no auto-summary ip bgp-community new-format route-map NEW permit 10 set community 65453:100 routerB#show ip route 192.168.2.50 Routing entry for 192.168.2.50/32 Known via connected, distance 0, metric 0 (connected) Redistributing via bgp 65453 Routing Descriptor Blocks: * directly connected, via Multilink1 Route metric is 0, traffic share count is 1 routerB#show ip route connected : C192.168.2.48/29 is directly connected, Multilink1 C192.168.2.49/32 is directly connected, Multilink1 L192.168.2.50/32 is directly connected, Multilink1 routerB#show ip int multilink 1 Multilink1 is up, line protocol is up Internet address is 192.168.2.50/29 Broadcast address is 255.255.255.255 Address determined by non-volatile memory Peer address is 192.168.2.49 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent On Tue, Apr 19, 2011 at 9:12 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: At first blush it looks like 192.168.2.50 can't talk to anyone. Try changing his mask to /31 or something so that 192.168.2.49 is on the same network.. BGP routing table entry for 192.168.2.50/32 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of tao liu Sent: Tuesday, April 19, 2011 8:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ cisco-nsp 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] Non-transit customer AS and prefix leaks
I may be missing something obvious, but shouldn't your prefixes have hit the Internet with a hop count of 1 and the bogus routes a hop count of at least three? If that's the case wouldn't your prefixes be the best path? Assuming I've missed something than the no-export community and as prepend suggestions proposed by others should work. Sent from my iPhone On Apr 18, 2011, at 2:36 AM, Artyom Viklenko ar...@aws-net.org.ua wrote: Hi, list! I had some problem last weekend. Lets say we - ISP-A, announce some prefixes to Customer. Due to some bug or misconfiguration these prefixes reached ISP-B (who provides another uplink to Customer). I'm was surprised that ISP-B received our prefixes from Customer (wrong filters?). And then, these prefixes was announced to Internet and some Exchange Points. This lead to incorrect routing of incoming thrafic towars our prefixes via slow Customer's links. This lead to near 100% packet loss. After several phone calls problem was fixed. But now, I'm trying to find some solution to prevent such problems in future. One solution I thinking of is to mark all announces to such non-transit Customers with no-export community. What do you guys think about this? Is it acceptable or not? Is it any other possible solutions to prevent such cases already in place? Thanks in advance! -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] disabling GigE negotiation on NX-OS
I don't think fiber negotiates. It isn't usually capable of anything but gig-full. Are you sure the carrier is using 1g fiber. Carriers are always provisioning 100m smf interfaces for low-cap connections if you don't tell them otherwise. I had a few customers get bitten by this. Sent from my iPhone On Apr 15, 2011, at 2:07 PM, Gert Doering g...@greenie.muc.de wrote: Hi, yesterday, one of our customers tried to move two GigE-on-fiber circuits from a Catalyst 4507 to a new Nexus 5548. The other end terminates on some carrier gear (and is then multiplexed in whatever ways across the city). After moving the circuit, the link didn't come up on the Nexus, but the carrier gear *did* show link. I wasn't on-site, so I couldn't investigate myself, but it smells very much like GigE link negotiation being disabled on the carrier gear - carriers love that. Of course we do not have access to either the Catalyst nor the Nexus, but it's our duty to make it work (after all, we provide the fiber patches!). So I'd like him to test disabling link negotiation on the Nexus, but don't know how to do that - no access to any NX-OS gear yet. On CatOS, this is set port negotiation x/y disable. On IOS, it's int giga x/y / speed nonegotiate. -- How to do it on NX-OS? http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/BasicEthernet.html refers to Layer 1 autonegotiation, but no word on turning it off... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ cisco-nsp 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] Two Cores connected to same eBGP AS
It depends on your environment, but yes it is safe to connect two internal routers to the same upstream AS. You should also configure iBGP or HSRP (but usually not both) to control outbound traffic to AS xyz. I would also avoid redistributing BGP into your IGP or vice versa. You should statically configure what is advertised into BGP and probably send a default or a subset of routes into your AS internal routers. Something like this should really be tuned to your specific use case though. garbage in garbage out... On Fri, Apr 8, 2011 at 6:24 AM, Chris Knipe sav...@savage.za.org wrote: Hi, I have a quick question... Let's say I have RTR1 and RTR2 interconnected and exchanging routes via EIGRP, on AS abc I now want to connect AS abc from RTR1 as well as RTR2 to AS xyz and broadcast my ranges to them, and receive routes from them. Is it safe to just connect both sessions and let the traffic route via RTR1 as well as RTR2, or, considering RTR2 is for a failover scenario, how would one automatically achieve a Active/Passive failover scenario so that RTR2 will only establish the BGP session when RTR1 is down / inaccessible / etc? Sorry if this is something very common, or very complex - I'm more than willing to do some reading up if there can be pointers given please. Both RTR1 and 2 are 6500 series - the amount of routes exchanged will be minimal 100K prefixes. -- Regards, Chris Knipe ___ cisco-nsp 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] NetFlow for billing on 6500/SUP720-3B
Sent from my iPhone On Apr 6, 2011, at 9:44 PM, Jon Lewis jle...@lewis.org wrote: On Wed, 6 Apr 2011, Wil Schultz wrote: Not netflow, but I use cacti to graph all switchports and aggregate ports as needed into 95th percentile. Works well and there aren't any load concerns on the switchside. That's the easiest way...but the trouble is, cacti can't ignore local traffic (so the customers are only billed for internet traffic). I'm curious to hear what others have to say, but I suspect the OP is SoL. I would assume it's more common to bill based on snmp than netflow unless you deploy specialized hardware. Is there really any local traffic on an Internet feed? Also is there really any local traffic that shouldn't be billed? ___ cisco-nsp 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] recommendation on vendor for 8 Cisco 7201 routers?
Have you tried google? Or better yet wherever you bought your last cisco router? Not to be too rude, but posts like this attract spammers. On Mon, Apr 4, 2011 at 11:05 AM, Rogelio scubac...@gmail.com wrote: Anyone have any recommendations for a Cisco shop that can sell me 8 new Cisco 7201 routers? If so, please email me the best person to contact. Thanks -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubac...@gmail.com ___ cisco-nsp 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] Trouble 6509s, can't establish BGP on point to point link
On Wed, Mar 30, 2011 at 1:33 PM, Neal Rauhauser neal.rauhau...@gmail.comwrote: I have the following two 6509s connected via a short single mode fiber run - they're about a hundred yards apart. Are you sure the fiber and path are ok? patch panels, sfp's etc.. I've replaced good fiber with another piece of good fiber and had problems magically disappear. BGP sessions between them bounce on the BGP timer and never properly establish. This link carries a lot of traffic and it never stumbles, not in terms of anything in logs, no errors on the interface, no visible effect. It's just BGP. I'm not sure I understand. How is traffic forwarding if BGP bounces? NSF? Is it a P-router? One of the machines has a production BGP setup and it works fine. The other knows its world via OSPF. Not sure I get this one either. Is one redistributing into BGP? Is BGP just there for management? Please elaborate. If I issue a “clear ip bgp *” on VT6509 I lose the ability to ping telnet to the machine on the other end of the link. Customers experience no traffic interuption – it appears to be purely a problem with the supervisor's IP stack. I can't reproduce the problem without BGP in the mix. That's strange. Are you peering with an interface address, vlan interface or a loopback? When BGP bounces where does the route to it go? Are you saying that you can't ping something directly connected when BGP is bouncing? Did you try tracing to it? Without any other info it sounds like a routing loop. If it's a vlan interface it could also be a problem with the layer-2 path. What do I do next? Time for a new image? Which one, given these engines and revision levels? We have BGP, OSPF, VRRP, and for reasons I am ashamed to explain one of these devices has NAT running on it. I don't envision the requirements changing all that much. Is neighbor transition logging turned on? What status code do you get when the neighbor bounces? That's usually a dead giveway? Also, how is RAM and proc on the box. I've seen some problems with 720's and full tables despite all the spec sheets. Some words of wisdom here would be greatly appreciated ... If this used to work and suddenly doesn't VP6509 IOS (tm) s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF17a, RELEASE SOFTWARE (fc1) BOOTLDR: s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF17a, RELEASE SOFTWARE (fc1) System image file is disk0:s222-advipservicesk9_wan-mz.122-18.SXF17a.bin cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes of memory. Processor board ID SCA0338003S R7000 CPU at 300Mhz, Implementation 0x27, Rev 3.3, 256KB L2, 1024KB L3 Cache NAME: 1, DESCR: WS-X6K-SUP2-2GE 2 ports Catalyst 6000 supervisor 2 Rev. 4.3 PID: WS-X6K-SUP2-2GE NAME: msfc sub-module of 1, DESCR: WS-F6K-MSFC2 Cat6k MSFC 2 daughterboard Rev. 2.5 PID: WS-F6K-MSFC2 NAME: switching engine sub-module of 1, DESCR: WS-F6K-PFC2 Policy Feature Card 2 Rev. 3.4 PID: WS-F6K-PFC2 NAME: 2, DESCR: WS-X6408-GBIC 8 port 1000mb ethernet Rev. 2.3 PID: WS-X6408-GBIC VT6509 IOS (tm) s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF17a, RELEASE SOFTWARE (fc1) BOOTLDR: s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF17a, RELEASE SOFTWARE (fc1) System image file is disk0:s222-advipservicesk9_wan-mz.122-18.SXF17a.bin cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes of memory. Processor board ID SCA044200US R7000 CPU at 300Mhz, Implementation 0x27, Rev 2.1, 256KB L2, 1024KB L3 Cache NAME: 1, DESCR: WS-X6K-SUP2-2GE 2 ports Catalyst 6000 supervisor 2 Rev. 5.1 PID: WS-X6K-SUP2-2GE NAME: msfc sub-module of 1, DESCR: WS-F6K-MSFC2 Cat6k MSFC 2 daughterboard Rev. 1.2 PID: WS-F6K-MSFC2 NAME: switching engine sub-module of 1, DESCR: WS-F6K-PFC2 Policy Feature Card 2 Rev. 3.5 PID: WS-F6K-PFC2 NAME: 2, DESCR: WS-X6408-GBIC 8 port 1000mb ethernet Rev. 2.4 PID: WS-X6408-GBIC !VP6509 interface Loopback0 ip address 192.168.200.1 255.255.255.255 interface GigabitEthernet2/1 ip address 192.168.200.34 255.255.255.252 no ip redirects ip nat inside ip route 192.168.200.2 255.255.255.255 192.168.200.33 !VT6509 interface Loopback0 ip address 192.168.200.2 255.255.255.255 interface GigabitEthernet2/1 ip address 192.168.200.33 255.255.255.252 load-interval 30 ip route 192.168.200.1 255.255.255.255 192.168.200.34 ___ cisco-nsp 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/
