[c-nsp] Firepower Threat Defense Geolocation DB
I've been going back and forth with cisco support for 2 weeks on this and gotten nowhere. Does anyone know of a way to verify (and update if needed) Cisco's IP Geo data for the FTD platform? I've been trying to get support to let me download the DB files from https://software.cisco.com/download/home/286322194/type/286321931/release/GeoDB but as I don't have the appropriate service contract, that seems to not be happening. We have an IP block (57.135/16) that is former RIPE space. We've had some IP Geo issues with it, but thought those were behind us. Recently, we've run into IP Geo based filtering/redirection issues with this space. The first was a network that admitted it was an issue with their FTD blocking our traffic & needing an update. So, I assume the latest IP Geo data from cisco has 57.135/16 correctly listed as ARIN/US, but I'd like to be sure of that and also look back at past versions of the DB to see how far behind someone needs to be to have it listed as RIPE/EU space. ------ Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
On Mon, 3 Apr 2023, Mike Hammett via cisco-nsp wrote: We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? Flowspec rules? Policy routing? Bugs? :) ------ Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] An attribute with less priority than local preference for choosing a best path.
On Fri, 3 Jun 2022, Drew Weaver wrote: Hello, We have a few edge routers with multiple connections to multiple geographically diverse locations from the same AS number (for example we have a router that connects to Lumen in both Cleveland and Cincinnati). Since the routes from both peers have mostly the same AS PATHs all of the traffic was going through one of the connections. In order to control that I was using: if community matches-any LUMEN-CLEVE then set local-preference 150 endif Makes perfect sense that any route tagged with a community in the list LUMEN-CLEVE would be preferred regardless of the AS-PATH. My question is what is considered the right attribute to modify that won't override the AS-PATH length? Would it be better to adjust MED? Yep. That's what we use to nudge traffic when everything else ties. Make sure you also have consistent origin though...you may need to look at setting origin on all routes received from transits/peers to the same value to keep individual drains from winning due to their setting origin igp. ------ Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Ode to the old days
On Thu, 8 Dec 2016, Howard Jones wrote: The good old days of absolutely shocking software testing... e.g. the Ascend Max software build that never released IPs from the assigned client IP pool - 200 user connections later, the helpdesk goes crazy. Or the awesome Nortel Baystack bugs where pressing the "wrong" key in the "wrong" menu would just crash the whole stack. Both in GA firmware. Nortel had a whole selection of similar issues in their errata. Reminds me of a bit of consulting I did way back on a SCO Unix server. Being used to Linux, and curious what was in the /etc/hosts file, I half-typed/half-tab completed "cat /etc/host" and hit enter, not noticing that it'd stopped short of the s. The system immediately crashed / locked up. Realizing, what I'd done, (on SCO, /etc/host is a binary), I expected crap in my terminal...but not that the system should crash from that. It's owner called SCO support, explained what happened, and was told it was a known bug...and "would you like to buy the update that fixes it?" WTF?!? ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Regex to allow ISP customers
On Mon, 17 Oct 2016, Nick Cutting wrote: Thank you for your answer. The problem is I do not know the ASN's of the ISP's customers. Robert - I am afraid that this particular ISP does not have a community for this, nor can they send me just their customer routes. Since you don't know the ISP's customer ASN's, if they're a small enough ISP (few to no peers, and just a couple of transits), you could do an as-path ACL like deny _100_transitA_ deny _100_transitB_ deny _100_peer1_ etc., ending with permit _100_ It's not really clear what you're trying to accomplish though. If you just want customer routes from them, why not ask them to only send customer routes? The obvious answer to which, I suppose, is that if they don't have communities that would indicate which routes are customer routes, they're probably incapable of making that route advertisement decision on their end. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SUP720's memory, looking at options..
On Mon, 4 Jul 2016, Howard Leadmon wrote: I knew with the 720-3BXL's I was running, that eventually the TCAM would become an issue, but it seemed like I still had a little bit of breathing room left. Then I saw the chatter here about the RAM on the RP exhausting before the TCAM, so went peeking at the switch after reading an earlier thread. Sure enough, though TCAM was starting to get full, to my surprise when I looked at memory, it was at 92%, so even closer than the TCAM by far to exhaustion. I know I can't just up the RAM on the board, so that now leads me to wonder what are reasonable options to resolve this before it becomes a very real and big problem. First let me say, compared to many here we are small guys, we have a limited budget, and our 6509 has served us well for a great many years, I think it's about to pass the 5yr uptime mark. We have 2-3 full feeds as uptime is important, and we also peer at the Equinix IX, so have a bunch of additional peering sessions. Some of the software versions for the 6500 have had BGP related memory leaks, and if you've got an uptime of 5yrs, that means you're not exactly running recent code, and have had a lot of time for memory to get misplaced. I no longer have access to a 6500 with full feeds, so I don't know if 3 full feeds + an IX should be running you out of memory. An upgrade/reboot might be worth a try though. I'd stay in whatever major version you're in though...not try jumping to a much later version that might be even more memory hungry. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 6506E 4Byte ASN IOS Support
On Thu, 7 Apr 2016, Jason Berenson wrote: Greetings, We're currently running a handful of 6506E's in our network for edge routers. We're running this IOS: s72033-advipservicesk9_wan-mz.122-18.SXF6.bin I need to upgrade it to support 4Byte ASN's. We're running some basic BGP/OSPF with 10G interfaces and full tables. If anyone has any recommendations on which IOS to upgrade to I'd greatly appreciate it. Looking for stability over everything and 4Byte ASN support. s72033-advipservicesk9_wan-mz.122-33.SXI8.bin Good luck with the reboots. You are aware of the "bad memory" issue you might run into causing cards working today to not make it through a reload? ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] C6509 Fabric Switch Capacity
On Wed, 13 Jan 2016, Nick Hilliard wrote: Alireza Soltanian wrote: My questions are is What will happen if we exceed capacity(Egress or Ingress) in Channel#0 of Slot#2? Will device use Capacity of Channel#1? no - the traffic will be dropped. slot 2 looks like a 6708 card. There's been a reasonable amount of discussion in the past on cisco-nsp about oversubscription on this and other 10G line cards on the c6500/c7600 platform. Overall, the platform isn't good at handling 10G. That's a little harsh. It handles 10G fine...you just have to carefully plan your port layout if you use the [oversubscribed] 8-port cards and have some links that you expect/want to carry line-rate traffic. cisco.com has documentation online that will tell you which ports share capacity (and should not both be used by high traffic links). ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Upgrading Catalyst 6500 from 720-3B to 720-3BXL
On Tue, 28 Apr 2015, [utf-8] Fernando García Fernández wrote: Hello all Iÿÿve tried to google the solution to one doubt I have, but couldnÿÿt find it. Iÿÿm going to upgrade a Catalyst 6509 from a 720-3B to a new 720-3BXL so we can use it for BGP routing with full Internet route table. The procedure Iÿÿm designing is: - create a CF for the 720-3BXL with the same IOS of the 720-3B - Insert the 720-3BXL y the second slot of the 6500 - activate redundancy: conf t redundancy mode sso end show redundancy - switch processing to 720-3BXL redundancy force-switchover - disable redundancy conf t redundancy mode none end - remove 720-3B Iÿÿm almost sure that a 720-3B and a 720-3BXL can coexist in a chassis. Is correct? Also is the procedure correct? Even if this worked, you'd still end up having to reboot. In order to put full routes on the 3BXL, you're going to have to manually tune the v4/v6 mls cef maximum-routes split (which requires a reboot to take affect). According to http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/107258-C6K-PFC-DFC-CFC.html your plan is not going to work. Q. Can the Supervisors with different PFC versions form redundancy? A. You cannot use one type of PFC3 (PFC3BXL, PFC3B, or PFC3A) on one supervisor engine and a different type on the other supervisor engine for redundancy. You must use identical policy feature cards for redundancy. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP dram confusion
On Wed, 11 Mar 2015, Erik Klaassen wrote: Hi all, We use a 7600 with a sup720xl and we receive 3 full bgp tables, some partial transit and some peering. According to sh bgp sum bgp is using: ipv4 ~250MB ipv6 ~30MB But the 1GB dram is almost full. sh memory summary Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 46ABB9D0 894682672 785658748 109023924 54382492 48475720 Sh proc mem shows the bgp proces is using a lot more memory the ~300MB PID TTY Allocated FreedHoldingGetbufsRetbufs Process 496 0 799340392 180557004 517282488 0 0 BGP Router how does this come and is this normal? I was expecting i could use some more full tables on this router. Cisco never could count :) You have about 104mb free, what's more worrying is the memory fragmentation such that your largest contiguous block of free memory is 46mb. I wouldn't add any more full views to that router. It's time to start thinking about what's going to replace the 7600. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Max-Prefix - Notification Data Decode Options ?
On Tue, 10 Mar 2015, Mark Tinka wrote: On 10/Mar/15 19:24, Nick Hilliard wrote: then, your provider is lying. Well, the provider may not be lying about their "max-prefix range", whatever that means. But certainly, the OP wants to start considering other providers. I've seen people get confused as to what the "values" following maximum-prefix mean, so it's possible the person the OP talked to was a jr. NOC worker and misread the config thinking the warning % threshold was the top end value for the max-prefixes. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ios aaa
Multiple brands document it that way, but the coders weren't listening. As mentioned, I encourage anyone doing this to test thoroughly, but on Brocade and Cisco, my experience has been that local group radius will work contrary to the docs. I just hope they never fix this glitch...or fix it in the docs rather than in the code. On Sun, 1 Mar 2015, Clint Wade wrote: Counter to how I've always understood it, if you put local first it will never attempt to use RADIUS. It's Sunday morning I'm way too lazy to lab this up. Again this list is "IF AVAILABLE" not "if-authenticated". http://www.cisco.com/c/en/us/support/docs/security-vpn/terminal-access-controller-access-control-system-tacacs-/10384-security.html#login_auth Configuring Authentication The Cisco IOS software uses the first method listed to authenticate users. If that method fails to respond (indicated by an ERROR), the Cisco IOS software selects the next authentication method listed in the method list. This process continues until there is successful communication with a listed authentication method, or all methods defined in the method list are exhausted. It is important to note that the Cisco IOS software attempts authentication with the next listed authentication method only when there is no response from the previous method. If authentication fails at any point in this cycle, meaning that the AAA server or local username database responds by denying the user access (indicated by a FAIL), the authentication process stops and no other authentication methods are attempted ~ One option you have assuming this a shared local account is to create the account on the RADIUS server as well as local. Would only make sense for shared accounts, depending on your security posture this may not be allowed. On Sun, Mar 1, 2015 at 11:22 AM, Jon Lewis wrote: Flip the "local" "group radius" order and it'll do what you're looking for. i.e. check the local db first (allowing non-radius users in) and if not found in the local db, radius is tried. Keep in mind, there are some additional config hoops to jump through to get radius auth working for console logins. So, test your config...don't just assume it'll work and find out at the worst time that it doesn't quite. On Sun, 1 Mar 2015, John Brown wrote: Hi Thomas, Thats what I have, but it doesn't ever fail over to the local user on the box. Hence my confusion On Sun, Mar 1, 2015 at 7:55 AM, Thomas Toquothty wrote: aaa authentication login group radius local This is how we have ours and it will roll over to local if connectivity is down or whatever reason. On Sat, Feb 28, 2015 at 9:24 PM John Brown wrote: Hi, I'm trying to have our cisco boxes use two different methods for authentication. Radius and local. At present we have Radius working nicely. What I would like to do is also have local username function. So that if the user is NOT in radius, but IS on the device locally it will authenticate and let that user on. In addition, if radius is dead, the local username will allow a person on. This would be via serial console, or ssh, or telnet (for those few devices we have left that don't support ssh) I haven't found anything that is clear and makes sense. I'm hoping someone has a cut and paste, or a pointer to a working setup. If this is possible. 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/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ios aaa
Flip the "local" "group radius" order and it'll do what you're looking for. i.e. check the local db first (allowing non-radius users in) and if not found in the local db, radius is tried. Keep in mind, there are some additional config hoops to jump through to get radius auth working for console logins. So, test your config...don't just assume it'll work and find out at the worst time that it doesn't quite. On Sun, 1 Mar 2015, John Brown wrote: Hi Thomas, Thats what I have, but it doesn't ever fail over to the local user on the box. Hence my confusion On Sun, Mar 1, 2015 at 7:55 AM, Thomas Toquothty wrote: aaa authentication login group radius local This is how we have ours and it will roll over to local if connectivity is down or whatever reason. On Sat, Feb 28, 2015 at 9:24 PM John Brown wrote: Hi, I'm trying to have our cisco boxes use two different methods for authentication. Radius and local. At present we have Radius working nicely. What I would like to do is also have local username function. So that if the user is NOT in radius, but IS on the device locally it will authenticate and let that user on. In addition, if radius is dead, the local username will allow a person on. This would be via serial console, or ssh, or telnet (for those few devices we have left that don't support ssh) I haven't found anything that is clear and makes sense. I'm hoping someone has a cut and paste, or a pointer to a working setup. If this is possible. 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/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] cisco memory bug / propabilities?
On Fri, 31 Oct 2014, Gert Doering wrote: Hi, On Fri, Oct 31, 2014 at 08:51:33AM -0400, Jon Lewis wrote: AFAIK, the problem is with the removable 1gb DIMMs on the cards...so you don't have to get spare Sups and line cards...you could just buy a couple of spare 1gb memory modules for them (if you have hands on-site you trust to do surgery on a card). Unfortunately, on a card like the 6708, getting to that memory module is a PITA as it's under the DFC. Mmmh, this might be worth a try :-) - I'm feeling a bit lazy today - is there a list of part numbers somewhere (particularily sup720, sup720-10G and 6704/6708)? Quick googling didn't turn up anhyting useful... Are you asking about part numbers affected by this defect or part numbers for the memory modules themselves? When I contacted one of our parts sources for pricing on spare memory modules, I was kind of surprised to be told the 1gb module for a Sup720 is a different part than the same size module for a 6708. I don't know if they're really not interchangeable or if cisco just slapped different part numbers on the same modules for different uses. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] cisco memory bug / propabilities?
On Fri, 31 Oct 2014, Gert Doering wrote: there's the infamous cisco memory bug "reboot and see your boxes die" - with the recent IOS software fixes, I have a couple of 6500s that need a reboot now, and I'm a bit scared - read: do I plan for "I reboot as usual, and there is a remote chance that hardware will not come back, so ensure a longer-than-planned outage is acceptable", or "I really should have a full set of spare boards sitting beside the to-be-rebooted box, because 90% of all boards will die"...? If at all possible, I wouldn't do the reboots unless you have spares on-hand for the at-risk cards. What are *your* experiences with dieing cisco memory, in particular on 6500s? I've rebooted 3 6500s with at-risk cards in the past year or so. The first two were done before I was aware (I think before cisco announced) this issue. Each of those first two lost a 6708. For the last one, I was aware of the issue and had spares shipped to the site in advance. Of course, that one didn't have any cards fail. AFAIK, the problem is with the removable 1gb DIMMs on the cards...so you don't have to get spare Sups and line cards...you could just buy a couple of spare 1gb memory modules for them (if you have hands on-site you trust to do surgery on a card). Unfortunately, on a card like the 6708, getting to that memory module is a PITA as it's under the DFC. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP route filtering question about upstreams
On Tue, 7 Oct 2014, Andrew (Andy) Ashley wrote: I¹m hoping someone can provide a bit of insight here with a BGP route filtering scenario: AS100 is an end-customer stub AS, multi-homed to upstreams AS200 and AS300. AS200 also buys transit from AS300, amongst others. AS100 does not want AS300 to learn its routes from AS200, since that can cause redundancy issues (2 supposedly diverse upstreams effectively become 1). AS100 still wants to receive a full table from AS200 (but not routes that transit AS300). AS200 might have BGP communities you can use to tell them not to share routes with AS300. If not, there's always as-path poisoning. It should be possible for AS200 to tag prefixes learned from AS300 at ingress, then implement a policy to filter these tagged prefixes on outbound announcements to AS100. But, how can AS100 still receive a full table from AS200 with such filtering in place? Short of AS200 doing some pretty serious router separation games (i.e. not going to happen just for one customer requesting it), they can't. A BGP router can only share its best path for each route. If AS200's best paths to certain prefixes are via AS300, and you don't want those routes from AS200, you can't have AS200 send you their "second best" routes. Even if that were an option, once you used those routes, how would you expect AS200's router to "know" that you wanted them to use the 2nd best path rather than their best path (via AS300)? This isn't really an issue, since if you learn a route from AS200 and from AS300, and AS200's path is via AS300, that will likely be your secondary path automatically due to the longer as-path...unless you've applied other policy that forces a different best path selection. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Moving a BGP session to different interface
On Sun, 28 Sep 2014, Nick Hilliard wrote: On 25/09/2014 18:19, Randy wrote: I'm tasked with moving a BGP session on a 6500 from a 1GE to a 10GE interface (live environment). BGP session details are staying the same. The BGP peer IPs (both v4 and v6) are assigned directly to the existing 1GE interface (no SVI, ect). Is it as simple/possible as configure the new interface with the same IP's but in a shutdown state, move the x-connect, shut the old interface and unshut the new interface? Or will IOS block me from doing this (two interfaces with the same IP) -- in other words, the IPs will need to be removed from the old interface first? yes, they will need to removed. Thanks for any advise or tips on keeping downtime / CLI work to a minimum :) if BGP uses the address defined on an interface that you need to migrate, you will have downtime on that bgp session. Standard best practice is to block all inbound and outbound prefixes on the session, then gracefully shut down the session, then migrate the interfaces, then bring bgp back up again. If this is an ebgp session, you will briefly lose connectivity due to your upstreams' non-zero MRAIs, so you will need to do this in a scheduled maintenance window. Wouldn't "even better practice" be to use new IPs on the new interface, get the interface up, establish BGP (verify at both ends that routes are sent/received/accepted), then shut the old session and relinquish the old interface IPs? Done carefully, there should be no downtime. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] "Cisco'€™s Commitment to Customers"
On Mon, 30 Jun 2014, Antonio Soares wrote: You need to have spares before doing any major changes to your network. Virtually all Cisco Products are affected by this issue: http://www.cisco.com/web/about/doing_business/memory.html#~field The problem is that if you order via RMA several similar parts, you may get this: We have spares. The difficulties are 1) gear is geographically spread out quite a bit...so we're apparently going to have to ship spares to each site before doing the reloads. 2) most of our spares are parts pulled from service when other routers were decommissioned. Due to the nature of this type of failure, we don't know for sure that those spares are any good. I'm going to have to have someone test each "spare" card, and then hope that the testing power-up wasn't its final successful one. And, since 6708s still cost / are still worth some $, I figured if cisco is willing to replace defective ones, doing so, and getting some reliable spares in exchange for the dead ones, beats the heck out of scrapping them. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] "Cisco's Commitment to Customers"
I'm currently dealing with TAC on the failure of a WS-6708 that I believe is connected with the defective memory component issue talked about here: http://blogs.cisco.com/news/ciscos-commitment-to-customers/ i.e. it was working fine...the router was rebooted, after which, the card no longer passes boot-up diagnostics. This passage: Despite many of these products being out of warranty, Cisco has decided to take a charge of $655m related to the expected cost of managing these issues. We are taking this action to support our customers and partners. This charge was excluded from our non-GAAP financials, as we do not believe it is reflective of ongoing business and operating results. implies to me that Cisco plans to replace such cards regardless of smartnet coverage. I thought I was about to get a replacement shipped out when the TAC rep sent this: I couldn't find any valid contract for RMA based on serial number of module 8, can you please provide contract number for the RMA so that I can proceed further. So, what's the real deal with these time-bomb cards? Will cisco replace them as they fail, or only if they're covered by a current smartnet contract? If the latter, what was the point of the blog post? In the comments and responses to comments, Curtis has been evasive when asked what cisco will do for people with affected products and no smartnet coverage. I've got a number of 6500s that need reloads to change the v4/v6 routing split, and after seeing a 6708 fail in each of the last two 6500s I've reloaded, I'm not feeling really good about proceeding. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RAM thing
Does anyone know if this affects the 6708 10gb cards for the 6500 series? -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM
Your paste formatting got all screwy, but it looks like the Sup2TXL claims it can do both 1M v4 routes _and_ half a million v6 routes simultaneously. I've heard that from others, but also read the specs to be the same as the 3BXL. I wonder if anyone from cisco can shed some light on this? On the Sup2T-XL, had you done any mls cef maximum-routes tuning? The page below both states that the PFC4XL has no more FIB capacity than the PFC3XL, and that the default split on the PFC4XL is 512k IPv4 routes. This doesn't appear consistent with what you're seeing. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-676346.html The FIB in the PFC4 contains 256 K entries, while the FIB in the PFC4XL contains 1 million entries. These are the same as their PFC3x forwarding engine counterparts. The FIB in the PFC4 contains prefix entries for IPv4 and IPv6 global address, IPv4 and IPv6 multicast addresses and MPLS label entries. There is a level of partitioning that exists to ensure there is always some space available for different types of forwarding entries. There is some flexibility from a user configuration standpoint that allows these partition boundaries to be changed to accommodate more of one type of forwarding entry. For example, in the PFC4XL, the default setting provides for 512 K IPv4 entries, and this can be increased through configuration control to support up to 1 M entries if required. On Tue, 5 Nov 2013, Christian Schmit wrote: Today I tested a Sup2T-XL and a Sup720BXL in the lab with full bgp feeds for ipv4 and ipv6. To my understanding the hardware capacity for the FIB TCAM is the same for Sup720-BXL and Sup2T-XL. Sup2T-XL output of "sh platform hardware capacity":CAT6500-RC2TXL#sh platform hardware capacity | begin L3 Forwarding Resources L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 1048576 465980 44% 144 bits (IP mcast, IPv6) 524288 14903 3% 288 bits (IPv6 mcast) 262144 11% detail: ProtocolUsed %Used IPv4 465978 44% MPLS1 1% EoM 1 1% IPv614894 3% IPv4 mcast 9 1% IPv6 mcast 1 1% Adjacency usage: TotalUsed %Used 1048576 32018 3% Sup720BXL output of "sh platform hardware capacity": (FIB TCAM partitioned with "mls cef maximum-routes ip 768") CAT6500-RC720BXL#sh platform hardware capacity | begin L3 Forwarding Resources L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 802816 467348 58% 144 bits (IP mcast, IPv6) 122880 14970 12% detail: ProtocolUsed %Used IPv4 467338 58% MPLS 9 1% EoM 1 1% IPv6 14963 12% IPv4 mcast 4 1% IPv6 mcast 3 1% Adjacency usage: TotalUsed %Used 10485761481 1% The release notes say: -XL mode: · IPv4 and MPLS: Up to 1,007,000 routes · IPv4 multicast and IPv6 unicast and multicast: Up to 503,000 routes "These are the theoretical maximum numbers of routes for the supported protocols (the maximums are not supported simultaneously):" The above output of the Sup2T-XL seems to say that the Sup2T-XL has a larger FIB TCAM (2M) than the Sup720-BXL. Christian ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ------ Jon Lewis, MCP :) | I route | therefore you are _ http:
[c-nsp] 6500 IOS recommendation?
I noticed in email from cisco today: END-OF-LIFE NOTIFICATIONS Cisco IOS Software Release 12.2(33)SXJ - Cisco has announced the end-of-sale and end-of-life dates for the Cisco IOS Software Release 12.2(33)SXJ. Customers are encouraged to migrate to the Cisco IOS Software Release 15.1(2)SY. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/end-of-life-notice-c51-729742.html SXI is similarly affected (earlier dates). Are people actually upgrading to 15.1SSY, or just running late 12.2(33)SXI or SXJ until these boxes run out of resources? -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SC to LC converter
That'd do. The first fiber supplier I checked didn't have that in appropriate fiber. On Tue, 15 Oct 2013, Andrew Miehs wrote: Why not just http://www.amazon.com/gp/aw/d/B002DG18MI ? But honestly - I would install a patch panel on either end and run proper fixed installation type fibre. Sent from a mobile device On 15 Oct 2013, at 10:01, Jon Lewis wrote: On Mon, 14 Oct 2013, Kenny Kant wrote: I have an older multi-mode fiber connection coming into our 7206VXR / NPE-G1 with a SC end. We are moving this fiber to a new router which requires a LC/SFP. Due to some other challenges I cannot have this cable re-run.Can I get some recommendations for SC to LC conversion? Any web links to what you have used in the past one be greatly appreciated. SC/LC patch cable and SC/SC coupler. If you have the parts/tools to terminate your own fiber, you can make your own SC/LC jumper...but it's cheaper to just order them pre-made. http://www.fibercables.com/products/0-2m-0-66ft-multimode-duplex-fiber-optic-cable-62-5-125-lc-to-sc.html http://www.fibercables.com/products/fiber-optic-adapter-sc-to-sc-multimode-duplex.html ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SC to LC converter
On Mon, 14 Oct 2013, Kenny Kant wrote: I have an older multi-mode fiber connection coming into our 7206VXR / NPE-G1 with a SC end. We are moving this fiber to a new router which requires a LC/SFP. Due to some other challenges I cannot have this cable re-run.Can I get some recommendations for SC to LC conversion? Any web links to what you have used in the past one be greatly appreciated. SC/LC patch cable and SC/SC coupler. If you have the parts/tools to terminate your own fiber, you can make your own SC/LC jumper...but it's cheaper to just order them pre-made. http://www.fibercables.com/products/0-2m-0-66ft-multimode-duplex-fiber-optic-cable-62-5-125-lc-to-sc.html http://www.fibercables.com/products/fiber-optic-adapter-sc-to-sc-multimode-duplex.html ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] old 6509 trying to drive me insane :-)
On Mon, 16 Sep 2013, Joe Pruett wrote: so, i'm hoping someone here can provide one of the following: 1. old 7.1 rommon image i can flash I suspect cat6000-sup2-rm2.7-1-1.srec is what you're looking for. I also suspect nobody but cisco can legally provide it to you. OTOH, I bet if you looked for it, you'd find that file somewhere online. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 real world (sampled) netflow
On Mon, 2 Sep 2013, Dobbins, Roland wrote: On Sep 3, 2013, at 4:34 AM, Jon Lewis wrote: Having used it exactly for that, I disagree and am curious why you say it's useless. Because in any Internet-facing environment with any kind of traffic diversity, it's non-deterministically skewed. So, in a network environment of any scale, you can't actually know whether or not a given source or destination is sending/receiving unusual volumes of traffic, as you don't know what is usual. Maybe if you're talking about using it in an IDS sort of way, I'd agree, but for detecting the sort of huge scale anomoly found in DoS attacks, no. At least for a "smaller" network that normally deals with traffic on the order a gbit/s or so, the Sup720's netflow data definitely is useful for DoS traffic characterization/investigation. I haven't looked at netflow from one doing tens or hundreds of gbit/s. I think your employer is clouding your vision. Sure, netflow from a Sup720 isn't great, but if it's what you've got, it can be used and relied upon. Maybe it doesn't play well with Arbor's products, but that only makes it useless to Arbor. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 real world (sampled) netflow
On Sun, 1 Sep 2013, Dobbins, Roland wrote: On Sep 1, 2013, at 7:57 AM, Randy wrote: It would only be used for detecting inbound UDP floods and other high PPS anomalies so there is no need for full flows or even much details, just ip src/dst. It's useless for this or any other application because of the limitations of the EARL7. NetFlow isn't useful on 6500s until you get to Sup2T/DFC4. Having used it exactly for that, I disagree and am curious why you say it's useless. It can be hard to quantify exactly what the numbers mean (translating sampled flow data to mbit/s), but it can certainly tell you which IP or IPs are the source or destination of unusual traffic volumes, which is the first step in mitigating inbound or outbound DoS traffic. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Tx Queue for 7609 WS67xx cards
On Fri, 30 Aug 2013, Victor Lyapunov wrote: Hello all Got a question about queuing functionality in WS67xx cards. We have a typical 7609 setup with TenG uplink and GigE downlink interfaces. During the day we see an increase in packet drops on the GigE downlink interfaces. The average bandwidth is kept around 750Mbps but I suppose short bursts may result in dropped packets. Is there any way to improve this behavior? (e.g increase output buffer?) Have you touched ip spd queue max-threshold and ip spd queue min-threshold? Some investigating I was doing recently suggested you might want to greatly increase these from the defaults. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500, 7600 or ASR
On Fri, 30 Aug 2013, "Rolf Hanßen" wrote: Hello, just for my interest: what amount of routes are we discussing ? show platform hardware capacity: L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 1048576 460874 44% 144 bits (IP mcast, IPv6) 524288 14178 3% 288 bits (IPv6 mcast) 262144 1 1% Do you expect to have more than 1M IPv4 / 512k IPv6 routes or is there some other limitation I do not see ? Is that a Sup-2T with PFC4XL? Everything I'd read about it said it had the same FIB as the PFC3XL. i.e. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-676346.html The FIB in the PFC4 contains 256 K entries, while the FIB in the PFC4XL contains 1 million entries. These are the same as their PFC3x forwarding engine counterparts. The FIB in the PFC4 contains prefix entries for IPv4 and IPv6 global address, IPv4 and IPv6 multicast addresses and MPLS label entries. There is a level of partitioning that exists to ensure there is always some space available for different types of forwarding entries. There is some flexibility from a user configuration standpoint that allows these partition boundaries to be changed to accommodate more of one type of forwarding entry. For example, in the PFC4XL, the default setting provides for 512 K IPv4 entries, and this can be increased through configuration control to support up to 1 M entries if required. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500, 7600 or ASR
On Thu, 29 Aug 2013, chip wrote: Let's all also remember the TCAM limitations on the 7600/Sup2T platform. With the BGP table growing like it is, you'll need to carve up IPv4/IPv6 TCAM allocation and could likely run out in the not-so-distant future. IMHO, unless something amazing happens for the 7600/Supervisor platform, this thing is dead as a DFZ BGP router and people should be looking elsewhere moving forward. Both ASR lines (1k/9k) offer much better "router" capabilities and growth paths. The 6500/7600 platform has had a helluva run, but I believe its time has passed. The TCAM limitation will kill the 6500/7600 platform for BGP router use _unless_ cisco comes out with a new PFC and DFCs that raises the limit. I still wonder what they were thinking with the Sup2T and why it didn't get any more routing slots than the Sup720-3BXL. This platform is the cheapest way to get lots of gigabit (or even 10 gigabit) ports and line rate performance in a BGP capable router...but sometime in the next couple of years, the current Sups and DFCs probably won't handle a full table. More TCAM and faster CPUs could keep the 6500 series viable for a long time. I haven't followed the thread closely enough to know if "netflow" was ever elaborated. The 6500 does netflow. Whether the netflow it does is sufficient for the OPs needs is the question. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] source for "supported" 3rd party CF for sup-720
A number of years ago, there were a couple of threads about use of 3rd party CF cards in Sup-7203bxl. I know that I was able to use 1gb and 2gb cards without issue, 4gb cards had cosmetic (integer overflow) issues in displaying size / free space. A that time, someone responded that some cards in the 1-2gb range didn't work, and the theory was they were too new a type (higher speed) of card and were unrecognized as CF by the sup. I now have a need for a handful of CFs for some Sup-7203bxl's, and <=2gb CF aren't as common as they were several years ago. I'd like to order half a dozen or so, but I'd hate to end up with a stack of cards "too new" for the Sup-7203bxl and have them fail to be usable. Has anyone shopped for these recently, and can suggest a brand / model that's still offered, reasonably priced, and can be formatted and used to boot a Sup720-3bxl? ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 6500 mounting with cables
On Sun, 21 Jul 2013, Aled Morris wrote: On 21 July 2013 19:42, Gert Doering wrote: Hi, On Sun, Jul 21, 2013 at 05:17:15PM +0100, Aled Morris wrote: It's interesting that even the Cat 6500 family now has a "fabric extender" option for distributing switching capability into smaller/more localised wiring closets. It has? I missed that, could you point me to more details? http://www.cisco.com/en/US/products/ps13198/index.html "This solution connects Cisco Catalyst 6800ia access switches to Cisco Catalyst 6500 or 6800 Series core switches. The entire configuration works as a single extended switch with a single management domain." That must be pissing off the Nexus unit. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 6500 mounting with cables
On Mon, 8 Jul 2013, chris stand wrote: Does anyone mount 6500s directly under the patch panels ? If you do, do the cables run to the left and right and would you share a photo or two ? I've run cables in from both sides. You can get cable management bars that rack mount on top of the 6500 chassis rack ears. These are literally a steel bar with 2 radiused 90* bends, the ends of which are welded to "rack ears". Mounting these in front of the line cards, you can then use velcro to secure the cables on their way to the line card ports. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Drawing Tool
On Thu, 20 Jun 2013, M K wrote: What other options we have to draw network diagrams other than visio and edraw max ? Depends on how fancy you want the diagrams to look. For Linux (free), there's Dia. For OSX (not free), there's Omnigraffle. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 Sup720-3BXL Showing Max CEF table of 256K
You have non-XL DFC line cards...so the system falls back to the best operating mode your worst card can do. On Mon, 29 Apr 2013, Dan Benson wrote: Good day all, As we all know, the Sup720 has it's limitations with regards to it's ability to handle large routing tables. Looking today, I was surprised to see that two of my Sup720-3BXLs are showing that I only have a MAX cef ability of 239K when all the docs I read show they should be defaulting to 512K. Did I get screwed on hacked together SUPs or do I have a line card effecting my ability to scale my CEF table? IOS version limitation? Info pasted below. Thanks for the insight as always. db ISO version: c7600s72033-advipservicesk9-mz.151-1.S1 Show mod: Mod Ports Card Type Model Serial No. --- - -- -- --- 1 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX 4 20 7600 ES+ 7600-ES+20G3C 62 Supervisor Engine 720 (Active) WS-SUP720-3BXL Mod Sub-Module Model Serial Hw Status --- -- --- --- --- 1 Centralized Forwarding Card WS-F6700-CFC # 4.1Ok 4 7600 ES+ DFC LITE 7600-ES+3C #1.1Ok 4 7600 ES+ 20xGE SFP 7600-ES+20G #1.1Ok 6 Policy Feature Card 3 WS-F6K-PFC3BXL #1.11 Ok 6 MSFC3 Daughterboard WS-SUP720 #5.1Ok Mod Online Diag Status --- 1 Pass 4 Pass 6 Pass sho mls cef maximum-routes FIB TCAM maximum routes : === Current :- --- IPv4 + MPLS - 192k (default) IPv6 + IP Multicast - 32k (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/ ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Route map matching, tags and community question
On Mon, 22 Apr 2013, Gert Doering wrote: Hi, On Mon, Apr 22, 2013 at 04:25:11PM -0400, David Hubbard wrote: route-map upstream-one permit 10 set community 1:123 "set community 1:123 additive" OTOH, if you're having them RTBH an IP, do you really care about any of the other community tags to do various TE "stuff"? For each neighbor that supports RTBH, the output route-map for that neighbor should have as its first permit entry, a check for your internal blackhole community with a set community for whatever that neighbor needs for RTBH. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] UP Link / http://www.spamhaus.org/
On Tue, 16 Apr 2013, Ahmed Hilmy wrote: Dear Friends, I am advertising some prefixes that are belong to my end user to one of my UP Links. They said, these prefixes listed in CBL/XBL as a Spam IPs at this Website : http://www.spamhaus.org/ So what does it mean ? i think there is no nee to block them as long as i am Transit circuit ? Would you please clarify this issue CBL/XBL suggests IPs in those prefixes are infected with spam sending bot software. You should contact your end user and have them deal with their infected systems. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DNS amplification
On Mon, 18 Mar 2013, Phil Mayers wrote: On 03/18/2013 02:25 AM, Dobbins, Roland wrote: On Mar 18, 2013, at 1:40 AM, Jon Lewis wrote: Cisco SNMP counters count packets before they're dropped by QoS...so all those dropped packets still "count" if you're billing by the byte. Same for NetFlow, except on crippled pre-Sup2T/DFC4 6500s/7600s and pre-Sup7 4500s. I'm not hugely sure what QoS has to do with BCP 38, but ACL- and RPF-dropped flows have output interface of 0 on sup720, IME. Not sure what I was thinking when I typed that. Either brain fart or assumption. I suspect like 'over service-policy dropped packets', ACL/rpf dropped packets still increment the interface/snmp counters...so for billing purposes, all packets count...whether they're forwarded or dropped. ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DNS amplification
On Sun, 17 Mar 2013, Gert Doering wrote: To play the devil's advocate - if I bill my customers by the GByte on their port, I don't mind if it's spoofed or not... "traffic is traffic, they pay for it, I transport it"... Cisco SNMP counters count packets before they're dropped by QoS...so all those dropped packets still "count" if you're billing by the byte. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DNS amplification
uRPF stops your network from initiating such attacks. Closing down your open recursive DNS servers stops you from being used / participating in the attacks. Other than having infinite bandwidth capacity, there's not much you can do to defend against being attacked by a DNS amplification attack. On Sat, 16 Mar 2013, Laurent Geyer wrote: Curious, how does uRPF help under this scenario? Although the source address is spoofed, the target is stil valid destination address. ÿÿ Laurent On Sat, Mar 16, 2013 at 6:38 PM, David Rothera wrote: Depends on whether you want to defeat being the person being attacked or the person being "tricked" into being the person doing the amplification attack. For stopping being attacked without taking services from your upstream provider the only thing you can do really is police DNS traffic as uRPF isn't going to be of much help as it will generally be coming from the correct ingress interface. As far as stopping being the attacker as others have said use uRPF and limit your resolvers to only allow access from hosts within your own AS. David On Saturday, March 16, 2013, harbor235 wrote: Can anyone provide insight into how to defeat DNS amplification attacks? 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/ -- David Rothera ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ------ Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DNS amplification
On Sat, 16 Mar 2013, Robert Joosten wrote: Hi, Can anyone provide insight into how to defeat DNS amplification attacks? Restrict resolvers to your customer networks. And deploy RPF uRPF / BCP38 is really the only solution. Even if we did close all the open recursion DNS servers (which is a good idea), the attackers would just shift to another protocol/service that provides amplification of traffic and can be aimed via spoofed source address packets. Going after DNS is playing whack-a-mole. DNS is the hip one right now. It's not the only one available. Many networks will say "but our gear doesn't do uRPF, and maintaining an ACL on every customer port is too hard / doesn't scale." Consider an alternative solution. On a typical small ISP / small service provider network, if you were to ACL every customer (because your gear won't do uRPF), you might need hundreds or even thousands of ACLs. However, if you were to put output filters on your transit connections, allowing traffic sourced from all IP networks "valid" inside your network, you might find that all you need is a single ACL of a handful to several dozen entries. Having one ACL to maintain that only needs changing if you get a new IP allocation or add/remove a customer who has their own IPs really isn't all that difficult. As far at the rest of the internet is concerned, this solves the issue of spoofed IP packets leaving your network. ---------- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] HSRP/VRRP/GLBP Dual Stack on Cat6500/Sup720 3BXL?
On Thu, 28 Feb 2013 vinny_abe...@dell.com wrote: Hello, Is there dual stack support in any redundancy protocol (HSRP/VRRP/GLBP) on the Catalyst 6500 with a Sup720 3BXL? If so, which protocols are supported and beginning in what IOS releases? I haven't utilized it in v6, but SXI appears to have v6 capable HSRP and GLBP. VRRP doesn't appear to have any v6 support. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP route won't advertise
On Thu, 28 Feb 2013, Jerry Bacon wrote: On 2/27/2013 7:45 PM, Jon Lewis wrote: On Wed, 27 Feb 2013, Jay Hennigan wrote: You could simplify that to: ip as-path access-list 10 deny _11xx1_ ip as-path access-list 10 permit .* <- Dangerous outbound to transit connections. Or simplify things more by using prefix filters / route-maps on the customer BGP sessions to deny/accept+tag routes with communities that tell the rest of your network what to do with the routes (i.e. whether a route gets advertised to your transit providers, etc.). That ends up being much saner as you have smaller filters in more places rather than monster filters at the border where you'll lose track of why things are there. I do have filters on the customer BGP sessions, but I have to disallow his AS from my upstreams, or I become a transit for those routes. So this is a BGP peering...but you're not providing transit? We have a cummunity string for that. The above advice still stands. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP route won't advertise
On Wed, 27 Feb 2013, Jay Hennigan wrote: On 2/27/13 4:07 PM, Jerry Bacon wrote: I've tried with and without next-hop-self on R3, it doesn't seem to make any difference. ip as-path access-list 10 permit ^11xx1 ip as-path access-list 10 deny _11xx1_ ip as-path access-list 10 permit .* You could simplify that to: ip as-path access-list 10 deny _11xx1_ ip as-path access-list 10 permit .* <- Dangerous outbound to transit connections. Or simplify things more by using prefix filters / route-maps on the customer BGP sessions to deny/accept+tag routes with communities that tell the rest of your network what to do with the routes (i.e. whether a route gets advertised to your transit providers, etc.). That ends up being much saner as you have smaller filters in more places rather than monster filters at the border where you'll lose track of why things are there. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Next step-up from 7206VXR
On Wed, 20 Feb 2013, Pete Lumbis wrote: There are two pieces: control plane processing power and TCAM. Sup720 CPU can't really keep up with the average churn of the internet anymore. RSP720's and Sup2T CPUs can still keep up. I'm using Sup720s, and not seeing that. Both RSP720-3CXL and Sup2T-XL can support 1 million routes* The Sup720 can do 1 million routes too. Can you point out where cisco says the implementation is any different between the Sup720, RSP720, and Sup2T that makes the latter capable of handling more v4/v6 routes than the former. Everything I've seen says the FIB TCAM space has not been improved. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Next step-up from 7206VXR
The Sup720-3bxl (and Sup2T and RSP720) will run out of tcam before the "churn of [a couple of] full feeds" makes them non-viable. We're getting close to a repeat of 2008, where lots of 6500s (those still running Sup2s) were inching up against their maximum supported routes when dealing with full views. Sometime in the next year or so, the default IPv4/IPv6 split on the best Sups you can get today are going run out of IPv4 FIB TCAM. Some will tune (or already have tuned) the split to buy another year or so, others will do so only after some head scratching when their 6500s fall over. The question is, will cisco release a bigger FIB TCAM sup for the 6500, or will they allow this product line to end its useful life as a full view internet router in order to push people into ASRs or competitors' products? On Tue, 19 Feb 2013, Pete Lumbis wrote: Both Sup2t and RSP720 (to a lesser extent but still much better than Sup720) can handle the churn of full feeds. On Tue, Feb 19, 2013 at 5:10 PM, Tony Varriale wrote: On 2/19/2013 2:57 PM, Jon Lewis wrote: On Tue, 19 Feb 2013, Eric A Louie wrote: I've run out of port capacity on my 7206VXR and need to go to "the next router" or put in another 7206VXR side-by-side. Any recommendations on what to use if I were to replace my existing 7206VXR with another chassis? (it's limited to 5 GB interfaces, and we need 7 or 8) You've got to say more about what the router is doing and what you need from it. If it's routing for 8 1gb ethernets and doing full BGP routes, and nothing special, then a 6500 is an attractive option bang for your buck-wise. They're made for ethernet and comparitively cheap to keep adding ports to. Except when said 6500 sup CPU is asked to do BGP intensive stuff :) tv __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsp<https://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/ ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Next step-up from 7206VXR
On Tue, 19 Feb 2013, Eric A Louie wrote: I've run out of port capacity on my 7206VXR and need to go to "the next router" or put in another 7206VXR side-by-side. Any recommendations on what to use if I were to replace my existing 7206VXR with another chassis? (it's limited to 5 GB interfaces, and we need 7 or 8) You've got to say more about what the router is doing and what you need from it. If it's routing for 8 1gb ethernets and doing full BGP routes, and nothing special, then a 6500 is an attractive option bang for your buck-wise. They're made for ethernet and comparitively cheap to keep adding ports to. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Mixing sampled and non-sampled netflow on sup720
Is it a known/expected issue on the 6500 series with Sup720-3bxl that with a config in which some interfaces have "mls netflow sampling" and some do not, no netflow data is exported for the interfaces that do not have sampling enabled? I recently discovered this in 122-33.SXI. Adding mls netflow sampling to the interfaces where it was missing got the netflow data exporting as expected. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Migrating small distribution network to support IPv6
On Mon, 11 Feb 2013, Bill Jones wrote: It's a straightforward setup: two 7204s (NPE-G2) connected to two gigabit upstreams, with a collection of several 3550s doing a combination of layer 2 and 3 with a lot of tenants and ethernet customers having their upload speeds rate-limited depending on the negotiation...average tenant would get 10 mbps upload, but some are tech businesses who can push some decent bandwidth (enough to require gige). The routers are running 12.4(24)T. It's my understanding that to support the existing network configuration, I would need to replace the switch infrastructure to support IPv6 properly (hardware layer3 forwarding). AFAIK, the 3550s don't do IPv6 at all, so the only way they'd be useful in a dual-stack network would be as layer 2 switches trunking all L3 traffic back to the 7204s. Doing your rate-limiting/policing/shaping up at the routers is undesireable since it allows any one customer to flood the layer 2 network with up to their port speed of traffic. However, I remember reading that on the switches in the upgrade path from the 3550, you couldn't do rate-limiting, or at least do it as well as the 3550...I'm foggy on the details, I remember finding this out when The 3560 series does shaping in a totally different way than the 3550's policing, and you'll have to look at it and see if you can live with the lack of granularity its capable of providing. OTOH, if your network is entirely ethernet, I'd look at whether you actually need to be using 7204s and see if something like a 6500 can do all you need. Something like a 6500 with Sup32 might handle things and can do more flexible policing (similar to what you're used to on the 3550s). Depending on how many ports you need, a 6506 or 6509 with a few 6148A's might do. dozen different ports. Funding is limited (the connectivity is looked at as a loss leader, the money is in having low vacancy), primarily because there is no customer demand for IPv6 yet. I don't want to wait for some big potential tenant to require it, and then have to scramble to implement it, and potentially do it half-assed. What would what you do if this was your network? Thanks,Bill You could just keep going, business as usual, and for the first few IPv6 customers, trunk them back to the 7204s, and eventually upgrade to a better dual-stack capable network. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500/Sup720-3BXL FIB TCAM tuning
On Sat, 19 Jan 2013, Pete Templin wrote: I had a maintenance window this evening to upgrade a router and attempt to tune the FIB TCAM to be ready for continued IPv4 growth beyond the 512k default on this platform. I'd apply the commands to tune the FIB TCAM, reload, and upon reboot I'd have errors about a FIB Protocol Allocation mismatch. I'd tweak my numbers a bit (random guesses as to why I was tripping this error), and re-check status, where I'd see this: Has anyone successfully tuned this, and if so could you share the software version and tunings used? We're running advipservicesk9_wan-mz.122-33.SXJ2 if that matters. #sh mls cef maximum-routes FIB TCAM maximum routes : === Current :- --- IPv4- 600k MPLS- 8k (default) IPv6 + IP Multicast - 208k (default) That's just with "mls cef maximum-routes ip 600" on 122-33.SXI. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR-100x intro
On Sat, 5 Jan 2013, Charles Sprickman wrote: We're tentatively shopping around, and I'm looking for that sort of information on the ASR lineup. The 1002 and 1002-X look very interesting on paper, but I'm not finding much about what folks in a small service provider role have to say about them. We're at the point where everything is ethernet now, so our 7206 with an NPE-G2 is feeling pretty silly. Some of the ASR stuff seems to be in the used channel already, which is nice (I'd rather have two used than one new, FWIW). For an ethernet-only operation, the 6500/sup720-3bxl delivers considerable packet forwarding/$ (lots of parts in the used channel). Its biggest weaknesses would likely be netflow (having to do sampled if you're doing hundreds of mbit/s or more) and the question of what cisco chooses to do hardware-wise with tcam on future supervisors. The 3bxl is limited to 1M ipv4 routes or (N ipv4 + (1M-N)/2 ipv6) N<100 routes. Even the Sup2T-XL hasn't increased this limitation. If they choose not to address this in the next couple of years, the 6500 will become unsuitable for use where full BGP routing is necessary. They might choose to do this to force orgs using the 6500 as routers to buy ASRs (or Juniper gear)...or maybe the next Sup will support a few million FIB TCAM slots. L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 622592 434995 70% 144 bits (IP mcast, IPv6) 212992 11744 6% I may have to adjust the ipv4/ipv6 split [again] (which unfortunately requires a reboot), to squeeze a little more IPv4 capacity out of it assuming v6 growth continues slowly. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2651xm packet loss with 200 ft ethernet link
On Fri, 28 Dec 2012, Andy Dills wrote: However, we were seeing tremendous packet loss. After determining the errors were coming from this end, and testing and replacing everything in the path, we finally tried moving the router into the telco handoff room so we could try to eliminate a lot of variables. With a short patch cable, it worked fine, no packet loss. So, we made a 200 ft cable to simulate the issue, and hooked it up to the router while it sat next to the Level3 handoff...major packet loss again. We tried the other fastethernet interface on the 2651...same problem. However, if I take that same cable and terminate it into one of our 7200s, we get zero packet loss. You mentioned errors, but didn't say what type. Were you actually getting errors (crc/frame/collisions/etc.) or just packets vanishing on the wire? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco TAC successfully disappoints again
On Wed, 19 Dec 2012, Joe Maimon wrote: What exactly does Support mean? I just cannot believe the following fits the definition. Hello Joe, My name is J*** C and Im the manager of the Routing Protocols team within Cisco TAC. Im contacting you on behalf of J*** M* who is the owner of this SR. After reviewing the case notes, I understand that youre hitting a known bug and J*** was able to share with you some details of it as it is an internal bug. Due to this situation, we can not disclose any additional details as we cant go against our policies, what I would like to suggest is in case you have an account team, feel free to contact them directly so they can help you with this request. Feel free to contact me in case you have any other concerns, and also please let us know how to proceed with this SR. I'd say it sounds like you've run into a known bug serious enough that TAC's been told not to say anything about it other than "known bug, nothing to see here" until cisco gets around to doing an official security advisory and has gotten the fix out to all the larger customers they care about [more than you]. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] annoying vrrp code changes
I did a long overdue code upgrade on a pair of 6509s today and ran into a few unexpected hiccups. I guess cisco's VRRP implementation in 6500 122-18.SXD7b was non-RFC compliant. I had many VLANs with VRRP group 0 configured. Under 12.2 SXI (and according to the RFC), the VRID field (what I assume IOS calls the VRRP group number) is 1-255. That was obvious and easy to fix. All the vrrp 0's were rejected by the config parser at bootup. Neither obvious, nor quite as trivial to fix, in the older implementation, it was possible to migrate a customer from a single gateway to a VRRP gateway without using any more of their IPs by putting the two gateway router physical interfaces into a different subnet than the VRRP IP. i.e. router1: int vlan100 ip address 10.0.0.1/30 vrrp 1 ip 192.168.0.1 ... ip route 192.168.0.0 255.255.255.224 vlan100 router2: int vlan100 ip address 10.0.0.2/30 vrrp 1 ip 192.168.0.1 ... ip route 192.168.0.0 255.255.255.224 vlan100 In the SXI implementation, VRRP configured this way doesn't get past "State Init". Apparently, if you don't have a VRRP IP in the same subnet as the phys interface IP, VRRP won't work. If you do have a VRRP IP in the phys interface subnet, you can also have secondary VRRP IPs outside the phys interface subnet, using the above trick of routing the foriegn subnet to the interface. So, the workaround for the above situation is to renumber the physical interfaces into at least a /29, create an otherwise unnecessary VRRP IP in the /29, and then configure the customer's VRRP gateway as a secondary. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Spanning Tree help sought
On Thu, 15 Nov 2012, Christopher Gray wrote: On reading your response - and used the links you suggested - I note that I could just leave everything as default and let STP sort itself out. You could...but you really should dictate which switches are the root bridge and backup root bridge. Additionally, do not attempt to disable STP on any ports unless you really know what you're doing and can guarantee that nobody who doesn't will ever be able to plug anything into those ports. Bridge loops are a major PITA, and quickly overload things to the point that you may not be able to do anything to troubleshoot other than start physically unplugging things until you "make it stop". ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loose uRPF on Sup720/3B
On Wed, 14 Nov 2012, Pete Templin wrote:
On 11/14/12 3:45 AM, Gert Doering wrote:
ip verify unicast source reachable-via any allow-default
so what is a "suppressed verification drop"? And, much more important,
"will it still do that in hardware", or will loose-uRPF ("via any") punti
it into the software path for "some packets"?
Brian gave a decent response, but because I'm drinking my morning coffee I
feel the urge to add another reply for you (since it'll delay my departure
for work). A suppressed verification drop is a packet that would have
dropped with 'ip verify unicast source reachable-via [any|rx]', but didn't
drop because you added options (which can be allow-default, allow-self-ping,
and/or an ACL to punch some additional holes).
So that suggests that the suppressed drops were suppressed by
allow-default and that Gert doesn't have full routes on this device, which
is a given since it's a non-XL 3B.
--
Jon Lewis, MCP :) | I route
Senior Network Engineer | therefore you are
Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] custom fiber cables
On Sat, 10 Nov 2012, harbor235 wrote: Can anyone point me to a reputable custom fiber patch supplier, looking for an Internet based company with quick response times. By "custom", do you mean you get to specify the exact length rather than choose from the common meter increments? I've bought numerous times from fibercables.com, but I don't know if they'll do custom lengths. Their web site implies that they can/will. For that though, we've always just used bulk fiber and done the termination in-house. It's really not that hard to do...but I only just looked up and saw how expensive the tool kit is (Corning UniCam Pretium Tool Kit). ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2900 -> 2960 config question
On Fri, 21 Sep 2012, Joseph Mays wrote: interface FastEthernet0/22 description Trunk to sw2.dist.win.net duplex full speed 100 switchport access vlan 22 switchport trunk allowed vlan 1,201-224,1002-1005 switchport mode trunk no cdp enable The client on the remote switch, vlan 202, does not work through the new switch. On sw2 the uplink port is port 5, the client is on port 6. I don't know what might be causing this, unless something about the vlan database is not created by cutting and pasting the config from the 2900XL to the 2960. Did you create the vlans on the 2960? The vlans allowed on that port (other than 1) aren't going to work until/unless the 2960 knows those vlans exist. This info was probably hidden in the vlan database (not present in the running/startup config) on the 2900. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 6509 EOS/EOL
On Thu, 13 Sep 2012, Antonio Soares wrote: Hello group, The EOS/EOL announcement for the WS-C6509 says that the last Date of Support is November 30, 2012: You already can't buy a new support contract on a 6509 chassis. Cisco apparently expects us to junk those and replace them with 6509E chassis. But in the other hand, the Service Contract Center shows me the date of 31-Dec-2015. Here's an example: Maybe you can keep renewing an existing contract until 2015? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third-Party support providers for 650x switches ???
On Wed, 11 Jul 2012, Matthew Huff wrote: We have 4 x 6509 switches, each with 2 x Sup720 cards. In November, they non-E chassis go EOSL. At this time we can't justify upgrading them to the E chassis. Are there any providers that provide past EOSL support that anyone would recommend? What kind of "support" are you looking for? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Shutting down a switch port automatically after a specific time
If you have rancid, you could just use a cron job + clogin to schedule logging into the switch and shutting the port. On Sun, 24 Jun 2012, Arun Vijay wrote: Dear Alan Yes.That feature set is not available in 3550. If possible can u send a sample of the script which you are using to bring down the port after a certain time. Thanks Arun On Sun, Jun 24, 2012 at 8:07 PM, alan buxey wrote: Hi, I would like to shutdown certain switch ports in my cisco 3550 switch automatically after a specific time. I tried configuring Time range with access list.But that only denies the ip traffic to the port while the port remains UP. I need the port to be down and then get the intimation about the port gone down in my syslog server through traps,which is not possible through time range as the port remains in the UP state. very easy with energywisebut this is 3550 so doesnt have that featureset for timers we used to just use extrenal scripts which would use SNMP to UP/DOWN a port at certain times 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/ -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] channelized ds3 - make a point to point?
On Wed, 18 Apr 2012, Mike wrote: 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. I don't think the PA-MC-2T3 has any sort of built-in DACS functionality. If you have the PA-MC-2T3 though, you probably also have an M13 mux and DSX pannel (unless the telco is doing that part for you), so why not cross connect the circuits at the DSX rather than run them through the 7201? You lose the ability to monitor the circuits...they lose a point of failure. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Setting line encoding, no controller present
You didn't say what you've tried, but you might poke around in: conf t int s2/0 service-module t1 ? and I think you'll find everything you're looking for. On Thu, 12 Apr 2012, Joseph Mays wrote: I need to set the t1 controller for the serial interface below to be b8zs encoding and clock source internal, but the router does not even recognize the controller commands, and I can't find any relevant commands under the serial interface config. = gw1.office#show controller serial2/0 Interface Serial2/0 Hardware is Quicc 68360 with Integrated FT1 CSU/DSU module TX and RX clocks detected. idb at 0x6416E310, driver data structure at 0x64175A34 WIC interrupt reg = F SCC Registers: General [GSMR]=0x2:0x0030, Protocol-specific [PSMR]=0x8 Events [SCCE]=0x, Mask [SCCM]=0x001F, Status [SCCS]=0x0002 Transmit on Demand [TODR]=0x0, Data Sync [DSR]=0x7E7E Interrupt Registers: Config [CICR]=0x00C9CF00, Pending [CIPR]=0x Mask [CIMR]=0xC000C000, In-srv [CISR]=0x SDMA Registers: [SDSR]=0x00, [SDAR]=0x07A014E0, [SDCR]=0x0772 Command register [CR]=0x600 Port A [PADIR]=0x, [PAPAR]=0x [PAODR]=0x, [PADAT]=0xEEFD Port B [PBDIR]=0x0011FE, [PBPAR]=0x0E [PBODR]=0x00, [PBDAT]=0x03EE5C Port C [PCDIR]=0x000E, [PCPAR]=0x [PCSO]=0x0020, [PCDAT]=0x0FCF, [PCINT]=0x0001 BRGC1 = 0x , BRGC2 = 0x BRGC3 = 0x , BRGC4 = 0x Receive Ring rmd(3D010420): status 9000 length 2 address 7B99024 rmd(3D010428): status 9000 length F address 7B9B724 rmd(3D010430): status 9000 length 2 address 7B9C424 rmd(3D010438): status 9000 length 10 address 7B9AA24 rmd(3D010440): status 9000 length 12 address 7B996A4 rmd(3D010448): status 9000 length 11 address 7B99D24 rmd(3D010450): status B000 length F address 7B9A3A4 Transmit Ring tmd(3D010458): status 5C00 length E address 7A01894 tmd(3D010460): status 5C00 length E address 7C14B34 tmd(3D010468): status 5C00 length E address 7A014D4 tmd(3D010470): status 5C00 length E address 7C161B4 tmd(3D010478): status 5C00 length E address 7C15DF4 tmd(3D010480): status 5C00 length E address 7A00AD4 tmd(3D010488): status 7C00 length E address 7C14634 tx_limited=1(2) SCC GENERAL PARAMETER RAM (at 0x3D010C00) Rx BD Base [RBASE]=0x420, Fn Code [RFCR]=0x18 Tx BD Base [TBASE]=0x458, Fn Code [TFCR]=0x18 Max Rx Buff Len [MRBLR]=1548 Rx State [RSTATE]=0x18008240, BD Ptr [RBPTR]=0x440 Tx State [TSTATE]=0x18000348, BD Ptr [TBPTR]=0x458 SCC HDLC PARAMETER RAM (at 0x3D010C38) CRC Preset [C_PRES]=0x, Mask [C_MASK]=0xF0B8 Errors: CRC [CRCEC]=0, Aborts [ABTSC]=9, Discards [DISFC]=0 Nonmatch Addr Cntr [NMARC]=0 Retry Count [RETRC]=0 Max Frame Length [MFLR]=1608 Rx Int Threshold [RFTHR]=0, Frame Cnt [RFCNT]=65524 User-defined Address /// User-defined Address Mask 0x buffer size 1524 QUICC SCC specific errors: 131355 input aborts on receiving flag sequence 0 throttles, 0 enables 0 overruns 0 transmitter underruns 0 transmitter CTS losts 20703 aborted short frames ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASA IPSec VPN Problem
On Tue, 20 Mar 2012, Covalciuc Piotr wrote: We have the following problem with IPSec Site-to-Site VPN between Cisco ASA. The VPN establishes (IKE and IPSec phases are passed), but on my end I have only TX traffic, no RX. Who controls the other end? So you're sending traffic via the VPN, but not receiving any? And this problem is only with specific subnet: when we add another subnet in VPN config, it works. Can you elaborate on what you mean by "add another subnet"? Do you know what else we have to check? Probably the config at the other end...the one that's receiving your traffic but not sending any back. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Recommended IPv6 Resources
On Tue, 13 Mar 2012, Steve McCrory wrote: I'm dipping my toe into the world of IPv6 and I'm looking for recommendations on resources - books, design guides, white papers, tutorials etc. It's really not all that different from IPv4 other than much larger address space, conservative IP assignment gets flipped around 180*, and watch out for things like needing IPv6 ACLs on things like router/switch vty lines, and RA / SLAAC automatically enabling IPv6 on hosts before they've been configured for it (ACLs). ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 Owners, failure stats wanted
On Fri, 20 Jan 2012, Blake Dunlap wrote: Are they more likely to fail the other line cards? It doesn't seem very common practice to have to of every card in the chassis and provide customers with a port on two switching modules for example, so why dual RSPs? Are they *that* much more likely to fail? You had me until this line. Discrete dual ports is *very* common when people desire HA and it isn't a multihoming situation. We do this with single supervisors, and a full redundant identically configured chassis. Customer's who care get a link to each chassis. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Flow tools
On Wed, 18 Jan 2012, Dobbins, Roland wrote: On Jan 17, 2012, at 11:23 PM, John Brown wrote: 6506-E Sup720-3BXL. The NetFlow you get from this box won't be operationally useful - many caveats. Strongly suggest a move to Sup2T and DFC4 (where applicable), if you want good NetFlow from 6500s. That really depends on his definition of "operationally useful". At the traffic levels he mentioned, he'll likely have to do sampled netflow, but even that is useful for getting an idea of what's going on, identifying D?DoS targets/sources, verifying abusive traffic, etc. Sampled netflow is certainly more operationally useful than no netflow. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Flow tools
On Wed, 18 Jan 2012, John Brown wrote: Hi Oh Wise List :) If one was going to start up collecting netflow data for connectivity / peering / traffic engineering reasons, what tools work well these days. What shops using to look at top source or dest ASN's Track traffic anomalies (ddos, scans, other fun things) Oddly enough, the package I've been using for years to collect and work with flow data is called flow-tools. We are needing to track GigE and 10GigE interfaces. Packet rates are not high yet, but want to have something that reasonably scales. Are you sure whatever platforms you're using can handle and export that volume of netflow? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Loopback IP set to .255 - 6500 responds to ICMP echo-request from wrong interface
On Sun, 1 Jan 2012, Mikael Abrahamsson wrote: On Sun, 1 Jan 2012, Mohamed Touré wrote: For "security reasons" (Smurf attacks ...) IP packets with destination of classfull broadcast may be filtered by your upstream security devices if any. There were none of those involved in this. Having seen IOS versions that refused to forward traffic for .255 destinations, when the .255 was in the IGP as a /32 (even with ip classless in the config), I've since avoided using .0 or .255 addresses. It seems classful routing may be dead, but not entirely forgotten. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 650x sup2 / sup32 configuration - what makes sense?
On Fri, 9 Dec 2011, Jeff Meyers wrote: I've heard that now multiple times, but a # sh int cap says: Switch-1#sh int cap mod 5 | i ASIC Ports on ASIC: 1-24 Ports on ASIC: 1-24 [..] The ports on my WS-X6148A-GE-TX all say Ports on ASIC: 1-48 so, hopefully this doesn't mean what it appears to. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 650x sup2 / sup32 configuration - what makes sense?
On Thu, 8 Dec 2011, Seth Mattinen wrote: On 12/8/11 9:38 AM, Jon Lewis wrote: On Thu, 8 Dec 2011, Seth Mattinen wrote: And the 6148A supports jumbo frames, if that matters. But yeah, it has 2.6MB per port buffers instead of 1MB shared across 8 ports. It's supposed to have more than that. https://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper09186a0080131086.html Hmm, I normally look at this one: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html Either way it's still per-port. Interesting. I wonder which, if either, is correct? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 650x sup2 / sup32 configuration - what makes sense?
On Thu, 8 Dec 2011, Seth Mattinen wrote: And the 6148A supports jumbo frames, if that matters. But yeah, it has 2.6MB per port buffers instead of 1MB shared across 8 ports. It's supposed to have more than that. https://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper09186a0080131086.html ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 650x sup2 / sup32 configuration - what makes sense?
On Thu, 8 Dec 2011, Gert Doering wrote: The best choice? Don't use 6148-GE-TX modules. They are fundamentally broken (8 ports share one ASIC with a single-GE uplink, one port that's "full" will block out the other 7 ports, ...). It's even worse if you use them for 100M links, because a saturated 100M link will eat all the buffers from the other 7 ports on the same ASIC, causing RTT jumps on these other ports. Just to clarify, as I understand it, this (shared buffers) is an issue with the 6148-GE-TX, but not with the 6148A-GE-TX, which according to cisco documentation has much larger buffers and they're per port, not shared by the ports in each 8 port group. The 6148A-GE-TX is still 8:1 oversubscribed, so it's a poor choice if you have a need for lots of 1000baseT ports handling much traffic, but at least it has nice per-port buffers. I suspect if most of the ports are used as 100baseT, and you have the occasional 1000baseT port that might carry just a little more than 100mbit/s, it should do fine. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 SVI QoS
On Fri, 18 Nov 2011, Ghassan.khalil wrote: Interface vlan xx Ip address 10.10.10.1 255.255.255.248 service-policy in 1M-policy-IN service-policy out 1M-policy-OUT the result is that only the outbound policy is working and the traffic is being limited to the 1M speed which means I can only control the downlink traffic of my customers. I have another 7606 router in which I tested and the results were the same. How does the vlan traffic reach the 7600? If it's coming in on layer two switchports, you can do your ingress policing by applying a suitable input service-policy on those physical ports. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP neighbor with more specific prefixes
On Tue, 13 Sep 2011, Justin Krejci wrote: Cisco Folks, Internet Transit Providers Provider 1 Provider 2 Provider 3 Provider 4 We have aggregated prefixes (/19's, /18's etc) currently advertised to providers 1-3 on a single router. We are bringing on provider 4 but want to advertise only a few individual /24's within those aggregated prefixes to provider 4 and then tag them no-export. No other advertisements to provider 4. Tag them no-export where? Are you saying you don't want P4 to propagate those /24s outside their AS, or are you saying you want to announce those /24s only to P4 and not to P1-3? Either way, it should be trivial. You should have output route-maps for each provider. In those route-maps, you can do whatever selective process you want for controlling what's advertised to that provider. My recommendation would be use of community strings and "match community " in the route-maps. Can it just be done with the network command to include the more specific /24's and the filter out the more specific /24's with a prefix-list on our bgp sessions with providers 1-3 and filter out the aggregated /18's and /19's on our session with provider 4? That'd work too. Doing it with communities is just a whole lot more flexible and easier to manage down the road. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP IPv6 OIDs
On Sat, 10 Sep 2011, Ryan Rawdon wrote: By SNMPwalking our BGP speakers I found this OID which I use for graphing received v6 prefix counts since earlier this year (on a pair of 7206s running 12.4.22) .1.3.6.1.4.1.9.9.187.1.2.4.1.1.[32.1.5.80].2.1 where the part in [ ] somehow identifies the peer - I haven't quite figured out how yet. Here are some other examples but they are at the same OID aside from the presumed peer identifier (it is not the peer router ID, I can say that much for certain - for example none of the routers below are from 174 but the one above actually is): From what I've read, that [32.1.5.80] is the dotted-quad version of the first 32-bits of the 128-bit peer IP...and the kicker is that if you have multiple peers in the same /32, the stats for all of them get merged together. Are you peering with Cogent or a cogent customer in 2001:550::/32 (if I did the math correctly)? The odd thing is, that's more or less the same OID I use for v4 peer info, but on 12.2(33)SXI, all it shows me is the ipv4 peers. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP IPv6 OIDs
Is there an OID for SNMP polling the number of ipv6 unicast routes
received from an ipv6 BGP peer? i.e. I've been graphing the # of IPv4
routes received from our transit providers with
.1.3.6.1.4.1.9.9.187.1.2.4.1.1.${peerIP}.1.1
mostly as an indicator of transit provider health. i.e. if the number
suddenly goes up or down much, there's probably something wrong.
I'd like to do the same with IPv6 routes, but I haven't found the OID.
------
Jon Lewis, MCP :) | I route
Senior Network Engineer | therefore you are
Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] sup2T software & release notes have hit
On Mon, 5 Sep 2011, Phil Mayers wrote: If they haven't increased the max routes capability of the next generation Sup vs the 3BXL, then that's very disappointing. This is all quite well documented here: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SY/release/notes/ol_20679.html#wp2561330 I couldn't find that the last time I looked for Sup2T specs. So it seems they haven't increased the route capacity...just the traffic forwarding capacity. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] sup2T software & release notes have hit
On Mon, 5 Sep 2011, Alan Buxey wrote: VS-S2T-10G-XL 1024K (IPv4) 512K (IPv6) Right...but my point was, that's the same specs claim they make for the Sup720-3BXL, and it's misleading because at least with the 3BXL, it's 1M IPv4 routes [and 0 IPv6] OR 512K IPv6 routes [and 0 IPv4], or some compromise of smaller numbers of each, such as the 622592 IPv4 and 212992 IPv6 I posted. If they haven't increased the max routes capability of the next generation Sup vs the 3BXL, then that's very disappointing. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] sup2T software & release notes have hit
On Mon, 5 Sep 2011, Phil Mayers wrote: FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 262144 20 1% 144 bits (IP mcast, IPv6) 131072 8 1% 288 bits (IPv6 mcast) 65536 1 1% This is a non-XL sup2T. So, identical to a non-XL sup720 IIRC. Presumably the XLs have the same specs. That looks "bigger" than a non-XL sup720 though. i.e. here's a Sup32 L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 196608 590 1% 144 bits (IP mcast, IPv6) 32768 23 1% [no 288 bit IPv6 multicast...never seen that before] Your numbers suggest to me that if you had IPv6 totally disabled, that thing might handle 768k IPv4 routes. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] sup2T software & release notes have hit
On Mon, 5 Sep 2011, Phil Mayers wrote: To answer my own question; we just unboxed and loaded our first sup2T today. Boot time with no config was ~100 seconds, which is much faster than the sup720. IIRC, the specs for the Sup2T make the same max routes claim as the Sup720-3BXL (i.e. 100 IPv4 routes, 50 IPv6 routes, which for the 3BXL is misleading at best). Is the IPv4/IPv6 routing split still the same on the Sup2T, where you can have 1M IPv4 routes with IPv6 turned off, or some split such as: [from show platform hardware capacity] L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 622592 368412 59% 144 bits (IP mcast, IPv6) 2129927041 3% As IPv4 runs out, I suspect we're going to see continued, if not explosive, IPv4 routing table growth, and I'll be very disappointed if cisco didn't engineer the Sup2T to support more routes than all previous models. If not, hopefully there's some more capable PFC/DFC on the way, or maybe cisco just wants to eventually stop people from using the 6500 platform as a full BGP router and sell more ASRs or something. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface
On Mon, 29 Aug 2011, Simon Leinen wrote: In short: Never assume that two features work together until you tried it in the lab or got credible evidence from somewhere that they do. I'll add here that just because you configured it in the lab (and didn't get any errors from the CLI), don't assume it works until you've actually tested it and verified the functionality. When we first eval'd the 3550-48 switch, "ip verify unicast reverse-path" was accepted into the interface config for layer 3 interfaces...but it didn't actually do what you'd assume it would do [it didn't actually do anything]. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] OSPFv3 authentication
Am I missing something, or is OSPFv3 authentication (provided by ipsec, since auth was removed from the protocol) not supported in any release for any of cisco's switching platforms? i.e. 3560, 4900, 6500 Depending on how you search in feature navigator (the same feature appears to be there under two different names): IPv6 Security: IPv6 IPSec to Authenticate OSPFv3 IPv6 Routing: OSPF for IPv6 (OSPFv3) Authentication Support with IPsec you get different lists of supported platforms, but both are pretty small and lack any of the gear I'm interested in. Is everyone using/moving to ISIS?...or just doing OSPFv3 without authentication? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP question : What's the best way for filtering outgoing prefixes?
On Fri, 19 Aug 2011, Jay Nakamura wrote: While testing, I am wondering, is it standard practice to clear my community strings from routes before going to peer/transit? Yes. You never know what special meaning various community strings might have to someone else. You should set community none on routes you receive after you've looked at the community strings (if you were interested), and before sending routes to another AS unless you meant for them to go out with a certain community string. -- ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP question : What's the best way for filtering outgoingprefixes?
On Thu, 18 Aug 2011, Scott Granados wrote: Go with option A, community tags are your friend. It also removes the need for any network statements in your config thus reducing the work in the long term. You'll probably still need some network statements in your config at least for all your own routes. The best part about using community tags for BGP filtering are, you only have to setup an appropriate route-map/prefix-list on the router servicing the BGP customer. Once you receive/accept their route and tag it on that router, the rest of your network knows what to do with it based on the community tag. I was absolutely shocked the last time I helped a customer turn up BGP with a (primarily cable) transit provider, and was told that the turnup was being held up because it required updating prefix filters on their core routers, and they could only do that during a maintenance window and they weren't allowed to schedule any maintenance windows because a tropical storm was threatening to impact the SE US. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multihoming solution over two different ISP's
On Mon, 8 Aug 2011, Aftab Siddiqui wrote: Asking for the best solution: Yes its via BGP provided that you have you own Public IP space and ASN otherwise its not possible with 2 different ISPs. Adding HWIC-2FE would serve the physical requirement in your scenario. BGP is the best way to go, and you certainly can multihome with BGP using IP space assigned by one of the ISPs. Lots of AS's do that. More below... On Mon, Aug 8, 2011 at 2:28 PM, Martin T wrote: At the moment I have a following setup: http://img69.imageshack.us/img69/4227/252530.png a) Is it somehow possible to automatically switch over to another one connection in case the primary one fails. For example ping www.google.com over a period of time and in case it doesn't respond, automatically switch over to backup connection? b) Is it somehow possible to have one static IP address while using the services of two different IPSs? You can do "poor man's" multihoming using 2 ISPs (no BGP) by doing reachability testing of something or things out on the internet, and changing your default gateway when you think the primary connection has failed. You'll have to use NAT/PAT such that when you're going out through ISP-A, your outside NAT address is an ISP-A address, and when you're going out through ISP-B, your outside NAT address is an ISP-B address. With a bit of policy routing, you can even keep both the ISP-A and ISP-B connections up and usable simultaneously. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Dumb question
On Wed, 3 Aug 2011, Ziv Leyes wrote: Hi all, I have the following scenario (excuse my lousy ascii art...) ISP1 / / / RTR1 -iBGP- RTR2 \ \ \ ISP2 For the simplicity of the case, I have two prefixes, 1.1.1.1/24 and 2.2.2.2/24, I want to advertise prefix 1.1.1.1/24 to ISP1 as best, and 2.2.2.2/24 to ISP1 with prepends, and the opposite too, prefix 2.2.2.2/24 to ISP2 as best and prefix 1.1.1.1/24 to ISP1 with prepends. What I'm trying to do is to set up all in a way that the only place I set up my decision is on RTR1 only, and that will be reflected via the iBGP to RTR2 about how I want the prefixes to be advertised to my eBGP neighbors ISP1 and ISP2 I tried setting communities, but all I got is RTR2 to see and match the communities, but based on this, I couldn't get the prefixes advertised to the ISPs at all. What kind of manipulation I need to do in order for the RTR2 after matching the communities coming from RTR1, to advertise it to the ISPs according to the priorities I've mentioned before? This should be reasonably simple to do by setting communities on the prefixes on RTR1 (assuming RTR1 is exporting these prefixed into BGP...use a route-map there to set the communities). On RTR2, you'll need output route-maps for ISP1 and ISP2 that permit / permit and prepend based on community strings. i.e. on RTR1, you'd set multiple community strings on 1.1.1.1/24 and 2.2.2.2/24, first a string that indicates this is a route you want to advertise to the internet in general, then a second string that indicates you want some number of prepends when going out ISPx. In the output route-maps on RTR2, you'd check for these prepend community strings first, and the general "announce to internet" string last. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7206VXR 23-inch rack brackets?
On Wed, 13 Jul 2011, Jay Hennigan wrote: Does Cisco make a rack-mount kit for 7200 routers going into 23-inch telco racks? If so can someone provide a part number? If not, I can use aftermarket filler brackets but I would prefer the cleaner installation of stock brackets. Never seen them. We've always used the 19-23" spacers for the 7206's when going into 23" racks. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
On Wed, 29 Jun 2011 matthew.coleman-hamil...@servicebirmingham.co.uk wrote: Thanks. I had (perhaps foolishly) assumed that moving from an NPE-G1 to a Sup720-3BXL-based platform would represent an upgrade from the 7206VXR (as well as having the advantage of bringing our Internet BGP tier in-line with the rest of our core network from a hardware perspective). When comparing the NPE-G1 to a Sup720-3BXL for the purposes of being an internet-facing BGP router am I actually proposing a backwards step? It may not have as much CPU power as a G1, but it's a switch and was designed to switch packets at line rate...lots of them, lots more than a VXR can do. BGP convergence may go a little slower, but the platform will forward more traffic (PPS or Mbps) than the VXR. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Replacing a 7206VXR w/ NPE-G1 with Sup720-3BXL w/ WS-X6408A-GBIC
The "supervisor" is actually a split brain system...with the MSFC handling routing calculations/manipulation and the PFC handling packet switching. I expect your new setup will handle things just fine...and at least for the moment, a Sup720-3BXL can handle full tables. One annoyance, probably minor, is that none of cisco's GigE ports for the 6500 have a whole lot of output buffer, so if you're doing much traffic, you will likely see some output drops, but not enough to cause problems. On Wed, 29 Jun 2011, Chris Evans wrote: Its all forwarded by the supervisor. I wouldn't be worried about that too much. I'd be more worried about the full internet table being on the 6500. It will probably be okay but 6500s aren't great high scale routers. They don't have much CPU power. On Jun 29, 2011 11:17 AM, wrote: Hi, Our Internet BGP tier is currently provided by a pair of 7206VXR routers with NPE-G1s which are getting quite long in the tooth. We've recently been able to reclaim a pair of Sup720-3BXLs and the associated 6509 chassis'. Its our intention to retire the 7206s and replace them with the 6509s /w Sup720s but we require 6 GigE interfaces per box. We have a pair of WS-X6408A-GBIC 'classic bus' linecards on the shelf (no spare 65XX or 67XX modules unfortunately) but my question is whether using the WS-X6408A-GBIC to provide port capacity is a good or bad idea in this scenario? I appreciate that using a WS-X6408A-GBIC means that the classic 32Gbps shared bus will be used (with a max of 15Mpps per system) but in raw performance numbers this is a significant increase on the 7206VXR/NPE-G1s ~2Gbps backplane and ~1Mpps forwarding rate. My real concern is that I've found two different Cisco documents that describe the Forwarding-Engine Architecture differently for classic linecards. This link :- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html states that "the Supervisor engine CPU makes forwarding decision" and this link:- http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html states that "Centralized Cisco Express Forwarding engine located on supervisor policy feature card (PFC) makes forwarding decision" As the 6500 series is a hardware-based platform I'm keen to make use of hardware-supported features where available and not experience unexpected issues from high CPU utilisation. Can anyone confirm exactly how traffic will be forwarded by the Sup720-3BXL with a WS-X6408A-GBIC in the chassis? Thanks in advance, Matthew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] uRPF lacking on ME3600X?
On Tue, 14 Jun 2011, Jeff Kell wrote: On 6/14/2011 7:04 PM, Waris Sagheer (waris) wrote: uRPF is currently not supported and it is in the roadmap. (Slightly off the 3600 topic...) Does uRPF cut the FIB/TCAM in half on a 6500/Sup720 like it does a Sup2? No...but it has the annoying issue of only being able to do one flavor of uRPF on the whole box. Any ports configured for it will do whichever type is configured last. So it does reachable via rx or reachable via any...pick one. Don't try using the other. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP peer/customer routes
On Tue, 31 May 2011, vince anton wrote: 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 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). Maybe the customer doesn't realize you peer with AS11 (and see their more specifics via AS11). Maybe the customer is trying to reduce the amount of traffic on their transit connection to you and actually wants you (and everyone else) to deliver some of their traffic via AS11. If you decide to take any action, you should contact the customer first, explain why you're unhappy with their routing policy, see if it's intentional, and then decide what (if anything) to do about it. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst TCAM Question
They should be software switched. If you're moving much traffic through the box, that's not good. You might want to filter the BGP feeds so you're carrying less than the max supported number of routes...though even if you filtered on RIR minimums, I'm not sure you'd still be able to fit the resulting number of routes into your 196k limit. I know you could several years ago (i.e. 2007), but the global table was >100k routes smaller then. On Thu, 5 May 2011, Bill Blackford wrote: Platform: 7600/SUP720-B If a box that can only handle sub 200k IPV4 routes in TCAM receives two full feeds and as shown below is only 'using' 196305 of them, is the delta of that 350k dropped or is it then processed in software? Looking a 'sh route sum' it looks like a full table in the FIB. 'sh fm sum' shows nothing INACTIVE. L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 196608 196305100% 144 bits (IP mcast, IPv6) 32768 5 1% detail: ProtocolUsed %Used IPv4 196305100% MPLS 0 0% EoM0 0% IPv6 2 1% IPv4 mcast 3 1% IPv6 mcast 0 0% Adjacency usage: TotalUsed %Used 1048576 199 1% I see this in the logs which was my first clue for asking this question: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched thank you in advance for any input. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Safer DDOS drops
On Fri, 8 Apr 2011, Peter Kranz wrote: So today one of our customers was being hit with a DDOS attack with the following signature; basically a bunch of UDP junk of about 5 Gbps in volume.. At that traffic volume, you're probably better off with RTBH than trying to ACL it. That way the DDoS traffic isn't congesting your transit pipes. ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NetFlow for billing on 6500/SUP720-3B
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 don't have any experience telling a 6509 to only export certain flows, but unless traffic levels are pretty low, I suspect there will be switch processor load issues if you do more than some form of sampled netflow, and then you really can't bill based on it, because at most you'll be seeing like 1.5% of the traffic volume. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Old catalyst 6k 10/100 RJ45 cards.
On Wed, 30 Mar 2011, Lamar Owen wrote: Good afternoon list. I'm trying to find a document describing, concisely, the differences between the old 'classic' 6148-RJ45 10/100 48 port card and the 6248-RJ45 and 6348-RJ45. None of the usual information sources is being much help; looked through Cisco's docs on their ethernet linecards, on the Cisco Cluepon wiki, and others. I seem to remember something crossing this list way back in the past, but can't seem to locate in the archives. Yes, old, slow, bus, etc I know all that, and that that is generic to that era of EoL card; I'm just trying to determine what the exact differences are to deploy the few I have of each variety in an intelligent fashion. And if the answer is 'there isn't a substantial difference' that's ok; but I'm looking for any details, or a pointer to a page listing those details. Some of what you're looking for is probably here: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e.html There's no mention of the 6248 there though. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500/BGP/full route tables [even more] confusing...
On Sat, 26 Mar 2011, Jeff Kell wrote: I had a 6509/Sup2 (clearly can't do full tables) for some time, using various route-maps and filtering tricks to keep the IPv4 routes under 128K (which seems to be the magic number with uRPF enabled). If that is exceeded, it generates TCAM overflow errors and essentially the 6500 is bricked relative to passing traffic. Under 128K and it's fine. I intended to upgrade this to "something" suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to "PFC3A" mode: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3550, need some help ugrading software
On Mon, 21 Mar 2011, Renelson Panosky wrote: I've done a million of this with no problems, for some reasons today i am hitting a dead end please help. switch: boot Loading "flash:c3550-i9q3l2-mz.121-13.EA1a/c3550-i9q3l2-mz.121-13.EA1a.bin"...flash:c3550-i9q3l2-mz.121-13.EA1a/c3550-i9q3l2-mz.121-13.EA1a.bin: no such file or directory Seems pretty clear, that file's not there. Perhaps the path is invalid and the bin file is really in the root dir of the flash? switch: boot c3550-ipbasek9-tar.122-44.SE6.tar Loading "c3550-ipbasek9-tar.122-44.SE6.tar"...c3550-ipbasek9-tar.122-44.SE6.tar: permission denied Booting a tar file? Those are supposed to be unpacked by the switch using the archive download-sw ... command. ---------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Prevent DDoS
Even dedicated(expensive) devices aren't going to prevent a DDoS from impacting your network. The most common type of DDoS I've seen is packet flooding. These typically utilize compromised/botted systems on broadband or better internet connections or VPS/cloud computing resources with even more bandwidth and can be in the several hundred Mbit/s to several Gbit/s range. If you're hit with a DDoS that exceeds your internet capacity, then all the router security configs and dedicated "DDoS prevention" filtering devices aren't going to matter. All you can do for this type of attack is react and mitigate it with filtering by your internet provider(s). I recently did a little write-up on one method for this, BGP triggered real time blackhole routing. http://jonsblog.lewis.org/2011/02/05#blackhole On Mon, 14 Mar 2011, Ziv Leyes wrote: The only way to _prevent_ DDoS attacks is to get your hands on those that are planning to attack you and kick their arse before they run the DDoS. Once the attack is delivered, the only thing you can do is to mitigate it and wait till it's over... A mix of good configured control-plane policy on your core with uRPF towards the outside and a blackhole device is the most feasible way without having to buy a dedicated device to protect you Sorry for putting emphasis on semantics... :-) -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tseveendorj Sent: Monday, March 14, 2011 10:36 AM To: cisco-nsp Subject: [c-nsp] Prevent DDoS Hello, Is there anyway to prevent DDoS attack on Cisco Router? regards, Tseveen. ___ cisco-nsp 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/ ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 6500 output drops
This seems to come up every few years, so I figured I'd revive it and see if anyone has better answers now. :) I've got several 6509s with WS-X6408A-GBIC and WS-X6416-GBIC blades where I'm seeing output drops on GigE interfaces that (according to 30s avg) are typically doing just a few hundred mbit/s...i.e. anywhere from 20-50% line rate utilization and I'm seeing thousands of output drops per day. There are no interfaces larger than 1gbit, so it's not like there are very short lived microbursts coming from 10g ports swamping the 1gb port buffers. No amount of fiddling with output hold-queue size, wrr-queue bandwidth, or wrr-queue queue-limit has eliminated the drops. I realize these blades are bottom of the barrel as far as gigabit ethernet goes on the 6500. But even the newer cards don't have a whole lot more buffer space per port. Our cards have 512k per port. WS-X6516A has 1MB. The WS-X67xx cards have 1.17MB TX/166KB RX buffers. Would swapping out the WS-X64xx cards for WS-X6516A's (with or without DFC3BXL) likely make much difference? ------ Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
