Re: IPv6 network boundaries vs. IPv4
OT: He probably meant MOP and LAT are not routable, man that brings back memories. Kevin Oberman wrote: Date: Sat, 25 Aug 2007 23:56:29 -0600 From: John Osmon [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is anyone out there setting up routing boundaries differently for IPv4 and IPv6? I'm setting up a network where it seems to make sense to route IPv4, while bridging IPv6 -- but I can be talked out of it rather easily. Years ago, I worked on a academic network where we had a mix of IPX, DECnet, Appletalk, and IP(v4). Not all of the routers actually routed each protocol -- DECnet wasn't routable, and I recall some routers that routed IPX, while bridging IP... DECnet not routable? Not even close to true. At one time DECnet was technically well ahead of IP networking and far more commonly used. It was not until about 1993 that IP traffic passed DECnet as the dominate protocol and ESnet continued to route DECnet, mostly to support the High Energy Physics community. When the Hinsdale fire segmented tie IP Internet in 1988, the global DECnet Internet survived, albeit with limits bandwidth between the coasts. DECnet was far from perfect and, over time, IP surpassed it in terms of both performance and robustness, but it was not only routable, but globally routed long ago. This all made sense at the time -- there were IPX networks that needed to be split, while IP didn't need to be. DECnet was... DECnet -- and Appletalk was chatty, but useful. AppleTalk was a royal pain! Gator boxes and FastPaths would go insane and saturate the network with broadcasts. But AppleTalk did have some really neat features. I keep hearing the mantra in my head of: I want my routers to route, and my switches to switch. I agree wholeheartedly if there is only one protocol -- but with the mix of IPv4 and IPv6, are there any folks doing things differently? With a new protocol in the mix are the lessons of the last 10 (or so) years not as clear-cut? Most routers are a blend of router and switch. The Cisco 6500 and 7600 boxes are probably the most popular large router in the world, but the heart of each is a Catalyst switch. So, the switch switches and the router routes, but they are both the same box. At a major networking show we would switch the IPv6 back to the core routers because of bugs in the IPv6 implementations on many systems. You do what works best for your network. If it means switching IPv6, so be it. This is probably especially true when the router is from a company that charges substantially extra for IPv6 software licenses. If the is only limited IPv6 traffic, switching to a central router might not only be technically the best solution, but the most reasonable fiscal approach.
Re: 2M today, 10M with no change in technology? An informal survey.
Heya, My understanding is that there are no known algorithms for fast updates (and particularly withdrawals) on aggregated FIBs, especially if those FIBs are stored in CIDR form. This is the prime reason why all those Cisco 65xx/76xx with MSFC2/PFC2 will be worthless junk in a couple of months. Do we have a real date for when this occurs? If you aren't doing uRPF, I thought they ran up to 256,000 routes. (I may not recall correctly) We ran into this hiccup a few months ago on a Sup720-3B (well, a 3BXL which mistakenly had a 3B card in the chassis, causing the SUP to clock down and act like a 3B), but I think the Sup2's are in a similar situtation. Though the box can handle up to 224k routes, they are set by default to only handle 192k IPv4 + MPLS routes plus 32k IPv6 + IP multicast routes. You can retune this so that you can get up to 224k IPv4 routes, but I've recently seen our Internet table bumping against this. My understanding is that this is a hardware limit, so upgrading is your only option. Eric :)
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Eric Gauthier wrote: Do we have a real date for when this occurs? If you aren't doing uRPF, I thought they ran up to 256,000 routes. (I may not recall correctly) We ran into this hiccup a few months ago on a Sup720-3B (well, a 3BXL which mistakenly had a 3B card in the chassis, causing the SUP to clock down and act like a 3B), but I think the Sup2's are in a similar situtation. Though the box can handle up to 224k routes, they are set by default to only handle 192k IPv4 + MPLS routes plus 32k IPv6 + IP multicast routes. You can retune this so that you can get up to 224k IPv4 routes, but I've recently seen our Internet table bumping against this. My understanding is that this is a hardware limit, so upgrading is your only option. The sup2 can actually handle a bit more ipv4 routes than the Sup720(non-3bxl). I don't know if it can go all the way to 256k routes. I can't seem to find any cisco data sheets that specify max ipv4 routes on the sup2. The output from show mls cef hardware suggests 256k is the limit. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IPv6 network boundaries vs. IPv4
On 26-aug-2007, at 7:56, John Osmon wrote: Is anyone out there setting up routing boundaries differently for IPv4 and IPv6? I'm setting up a network where it seems to make sense to route IPv4, while bridging IPv6 -- but I can be talked out of it rather easily. Why would you want to do that? I've been tempted to do it the other way around, though. In a hosting environment, you can end up with a bunch of /24s dumped on a broadcast domain with a number of different customers but the addresses so intermingled that you can't give each customer their own VLAN. With IPv6, there is enough address space to give each customer a VLAN and and address block to go along with that, which is a lot cleaner.
Re: IPv6 network boundaries vs. IPv4
On Sat, 25 Aug 2007 23:56:29 MDT, John Osmon said: Is anyone out there setting up routing boundaries differently for IPv4 and IPv6? I'm setting up a network where it seems to make sense to route IPv4, while bridging IPv6 -- but I can be talked out of it rather easily. We decided to map our IPv6 subnets one-to-one to our IPv4, so each of our routed /22 to /27 subnets gets a /64 IPv6 prefix. This however was just due to the fact that our topology permitted that - your mileage may vary. pgpKnL9djt2I6.pgp Description: PGP signature
ICMP being dropped between Global Crossings and Onvoy
I have a network (AS33234) I am trying to support that is downstream from Onvoy on one of their connections. Our monitoring equipment is located in AS4452. Our monitoring system is not able to ping their network through Onvoy. The block seems to be happening at either Global Crossings or Onvoy. We are able to reach them using any protocol other than an ICMP ping (We are able to traceroute). Does anyone else know about or see a similar block going on. I have attached part of a traceroute. 2 suwC6.gig3-1-4.qualitytech.com (216.154.207.145) [AS 20141] 0 msec 0 msec 4 msec 3 suw04-gig1-0-0.qualitytech.com (216.154.207.173) [AS 20141] 0 msec 0 msec 0 msec 4 gig6-2.suwangaeq01w.cr.deltacom.net (66.35.174.165) [AS 6983] 4 msec 0 msec 0 msec 5 * * * 6 pos5-0.atlngapk22w.cr.deltacom.net (66.35.174.101) [AS 6983] 0 msec 4 msec 0 msec 7 so-0-0-0.ar3.DAL1.gblx.net (64.208.169.141) [AS 3549] 4 msec 4 msec 4 msec 8 so1-0-0-622M.ar2.MIN1.gblx.net (67.17.71.34) [AS 3549] 44 msec 44 msec 44 msec 9 WBS-CONNECT-LLC-Minneapolis.ge-2-3-0.409.ar2.MIN1.gblx.net (64.215.81.82) [AS 3549] 44 msec 44 msec 44 msec 10 * * * 11 * * * 12 WikstromTel-7003.onvoy.net (137.192.32.30) [AS 5006] 52 msec 52 msec 56 msec -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: Market for diversity
On 8/26/07, Jason LeBlanc [EMAIL PROTECTED] wrote: More on point for this thread, I always have new vendors bring in fiber maps and show me their paths. Images of the intended path specified on the map are part of the contract, including verbage regarding failover paths. Once I know where their fiber is, I can look for another vendor that takes a different path. This often won't get you the most cost-effective connections, and sometimes it'll be bad for performance as well, and doesn't always take advantage of available technology. For instance, if Carrier 1 and Carrier 2 both use the same route for their primary connection, and you buy from Carrier 1 because they're 5% cheaper, you may find that Carrier 2's second-best route is a lot more expensive that Carrier 1's. If you're buying from two carriers to get equipment diversity as well as route diversity, you've lost. Another kind of problem I've run into in the past - here in California, to get from SF to LA, you can either go down the coast or down the Central Valley, depending on which railroads or highways you like. But there's another route that takes a railroad connection from SLO (middle of the coast) to Bakersfield (south/middle of the valley), and if your primary connection uses that route, the options for diverse routes go through Salt Lake City or Denver. Given the history of what fiber got built when, you'll find that for some speeds many of the carriers use that crossover route, while for lower speeds there's a lot more choice. From a technology standpoint, a lot of carriers are starting to use intelligent optical switches that give them automated provisioning, automatic reroutes, etc., so while they can show you where their cable routes are, and where the most likely provisioning and reroutes go, in general you can't get a precise guaranteed route, because that's not what the switches do. What I find hard to combat are MA changing operations over time, In general, it's hard for one carrier to keep track of diversity (though some can), and much much harder for two carriers to keep diverse from each other. And the tracking problems scale differently for large connections, where you may build custom access rings, than for small connections where most providers are reselling telco last-mile copper. There's also the problem of diversity philosophy - it's not uncommon for large East-Coast companies to view equipment diversity as the critical problem, and concentrate their switches into a smaller number of larger sites where they can do cost-effective sparing, and have their fiber spread out across many different physical routes, not remembering that customers in the West Coast expect that buildings just fall down sometimes, so they care about building diversity, and geographical and demographic considerations mean that there are only a few good routes across the Rockies and along the coasts. (Of course, sometimes this means that the West Coast customers buy from multiple carriers to get building diversity and _still_ get caught when a telco DACS fails :-) Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Operational Feedback Requested on Pending Standard
All, Below is an email sent to the IETF OPS Area mailing list soliciting feedback from operators regarding firewalls. We would also appreciate feedback from the Operators Mailing Lists. Please respond to the OPS Area mailing list if you have a position on the item below. You can subscribe to the Operations and Management Area mailing list at the URL below if you are not already subscribed. https://www.ietf.org/mailman/listinfo/ops-area On behalf of the OPS Area Directors and myself, thank you. Ted - With OPS Area WG Hat On -- During the final review phases of the review of http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-09.txt the issue described below surfaced. It is actually not completely new, it was discussed in the past in a form or another, and it is not necessarily specific to this document and MIB module only, but also to other MIB modules. We believe that input from network operators can help, and we solicit this input. The MIDCOM-MIB defines tables containing firewall rules, indexed by ifIndex. ifIndex values can change when interfaces are swapped or devices reboot, and this could lead to rules being applied to the wrong interface. How do you, network operators, prefer interfaces be identified? - Is ifIndex the preferred choice even though the indices can change on reboot? - Is ifName a better choice for identifying interfaces in rules, since it is set by the device and remains fairly stable across reboots and is guaranteed to be unique? - is ifAlias a better choice, since it can be set by operators, although it is not guaranteed to be unique? We would appreciate inputs and thank you for your cooperation.
Re: IPv6 network boundaries vs. IPv4
On Mon, Aug 27, 2007 at 07:12:54AM -0400, Jason LeBlanc wrote: OT: He probably meant MOP and LAT are not routable, man that brings back memories. Yeah, I realy did, but my fingers typed 'decnet isn't routable' because that how the folks I worked with at the time described the issue. I was young at the time, and didn't understand the nuances (as opposed to being older and missing nuances now). My old nuerons took over when I composed the message, sorry for the confusion. Thanks to all the folks that have replied off-list. The (on topic) answers are coming where I expected them: - keep routing boundaries congruent - at local edges / stubs do whatever you want, but do it in private, and wash your hands afterwards (with appologies to R.A. Heinlein)
Re: Operational Feedback Requested on Pending Standard
Hi Ted, develloping IASON I did run into that problem. Among other things IASON was meant to read the configuration of a device and the things connected to it. When e.g. a switch port was bad, a device was unplugged and plugged into another port, then IASON was meant to reconfigure the switch, vpn and parameters, so that the device could run as if nothing had changed. Most dramatically IASON would allow you to replace a CISCO by an HP ProCurve switch and automatically configure everything as soon as the device was switched on (DHCP and bootp). IASON would discover any device that was asking for DHCP and bootp to query an initial configuration then it would look through its ports and MAC lists to see where it was connected and what devices where connected Of course IASON would work with ifIndex not with ifName as these are different from manufacturer to manufacturer - and definitely not ifAlias because IASON would configure the device before an operator could see it. I might teach IASON to use ifName and keep tables for the different hardware but definitely not ifAlias. Well, neither Global Crossing nor Exodus cared for IASON so the snmp part was never finished and IASON only used snmpwalk to scan devices. I remember the faces of two operators at a new installation when they plugged in three new switches and IASON immediately moved them to a vpn where the operators could not find them. As soon as they plugged in a service laptop it would connect that laptop to the NOC vpn but they would never see the management port. Of course IASON had already issued new passwords, so rs232 would not help them either :) Cheers Peter and Karin Ted Seely wrote: All, Below is an email sent to the IETF OPS Area mailing list soliciting feedback from operators regarding firewalls. We would also appreciate feedback from the Operators Mailing Lists. Please respond to the OPS Area mailing list if you have a position on the item below. You can subscribe to the Operations and Management Area mailing list at the URL below if you are not already subscribed. https://www.ietf.org/mailman/listinfo/ops-area On behalf of the OPS Area Directors and myself, thank you. Ted - With OPS Area WG Hat On -- During the final review phases of the review of http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-09.txt the issue described below surfaced. It is actually not completely new, it was discussed in the past in a form or another, and it is not necessarily specific to this document and MIB module only, but also to other MIB modules. We believe that input from network operators can help, and we solicit this input. The MIDCOM-MIB defines tables containing firewall rules, indexed by ifIndex. ifIndex values can change when interfaces are swapped or devices reboot, and this could lead to rules being applied to the wrong interface. How do you, network operators, prefer interfaces be identified? - Is ifIndex the preferred choice even though the indices can change on reboot? - Is ifName a better choice for identifying interfaces in rules, since it is set by the device and remains fairly stable across reboots and is guaranteed to be unique? - is ifAlias a better choice, since it can be set by operators, although it is not guaranteed to be unique? We would appreciate inputs and thank you for your cooperation. -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
RE: IPv6 network boundaries vs. IPv4
We did the same thing... It seems easiest from a management perspective to copy the ipv4 logical layer with v6. The only change on our side was the fixed prefix length which if anything was a nice change. We did run into a few devices (old layer 3 switches) that don't support ipv6 and on those we either did not deploy IPv6 or moved the routing off for both v4 and v6 to the nearest core router that could handle v6 for any vlans that required the v6 capability. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) http://spectrumnetworks.us -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 27, 2007 10:25 AM To: John Osmon Cc: nanog@merit.edu Subject: Re: IPv6 network boundaries vs. IPv4 On Sat, 25 Aug 2007 23:56:29 MDT, John Osmon said: Is anyone out there setting up routing boundaries differently for IPv4 and IPv6? I'm setting up a network where it seems to make sense to route IPv4, while bridging IPv6 -- but I can be talked out of it rather easily. We decided to map our IPv6 subnets one-to-one to our IPv4, so each of our routed /22 to /27 subnets gets a /64 IPv6 prefix. This however was just due to the fact that our topology permitted that - your mileage may vary.
Any MSN/Live Mail Admin Contacts?
Hello, I'm experiencing a lot of problems with about 8 of our outbound mail gateways to the MSN/Live mail servers throughout the day. Are there any mail/sysadmins on this list, or anyone that can get me in contact with someone there, as the general postmaster support is less then fourth coming with information. Anything would be greatly appreciated. Thanks, Raymond Corbin Support Analyst HostMySite.com
Re: 2M today, 10M with no change in technology? An informal survey.
According to this link, which alleges to be from cisco-nsp, an MSFC2 can hold 256,000 entries in its FIB of which 12,000 are reserved for Multicast. I do not know if the 12,000 can be set to serve the general purpose. The MSFC2 therefore can server 244,000 routes without uRPF turned on. Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? http://osdir.com/ml/network.nsp.cisco/2002-08/msg00283.html Deepak
Re: Any MSN/Live Mail Admin Contacts?
On 8/27/07, Raymond L. Corbin [EMAIL PROTECTED] wrote: Hello, I'm experiencing a lot of problems with about 8 of our outbound mail gateways to the MSN/Live mail servers throughout the day. Are there any mail/sysadmins on this list, or anyone that can get me in contact with someone there, as the general postmaster support is less then fourth coming with information. Anything would be greatly appreciated. Ray: Im not sure what you mean by less than forthcoming, but we have success here: http://postmaster.msn.com/Guidelines.aspx And here: http://postmaster.msn.com/Default.aspx Best, Marty
Re: 2M today, 10M with no change in technology? An informal survey.
On Aug 27, 2007, at 2:49 PM, Deepak Jain wrote: According to this link, which alleges to be from cisco-nsp, an MSFC2 can hold 256,000 entries in its FIB of which 12,000 are reserved for Multicast. I do not know if the 12,000 can be set to serve the general purpose. The MSFC2 therefore can server 244,000 routes without uRPF turned on. Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? Um? Real Soon Now? According to http://www.cidr-report.org/as2.0/ we're at 233,000 routes (as seen from AS 2.0 now) and the rate of growth as seen from http://bgp.potaroo.net/ seems pretty steep. I must be missing something obvious (or should I be dusting off my unused Y2K survival gear?) Thanks, -drc
Re: 2M today, 10M with no change in technology? An informal survey.
David Conrad wrote: On Aug 27, 2007, at 2:49 PM, Deepak Jain wrote: According to this link, which alleges to be from cisco-nsp, an MSFC2 can hold 256,000 entries in its FIB of which 12,000 are reserved for Multicast. I do not know if the 12,000 can be set to serve the general purpose. The MSFC2 therefore can server 244,000 routes without uRPF turned on. Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? Um? Real Soon Now? According to http://www.cidr-report.org/as2.0/ we're at 233,000 routes (as seen from AS 2.0 now) and the rate of growth as seen from http://bgp.potaroo.net/ seems pretty steep. I must be missing something obvious (or should I be dusting off my unused Y2K survival gear?) I found that, eventually. I'm only seeing about 227K routes, but customer routes from wherever the CIDR report is getting data could be part of the difference. Where do the FIBs break on older 12000 series and M-series routers? (or pick the *next* most popular piece of network equipment that is used in full-routes scenarios). Maybe I should take a whack at my aggregation idea on an MSFC2 to see how it does. Hmmm.. Deepak
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, David Conrad wrote: Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? Um? Real Soon Now? ... I must be missing something obvious (or should I be dusting off my unused Y2K survival gear?) Unlike Y2K, the end of the useful service life up the Sup2 can easily be pushed further away in time. ASnum NetsNow NetsAggrNetGain % GainDescription Table 233651151129 82522 35.3% All ASes AS4134 1337 339 998 74.6% CHINANET-BACKBONE No.31,Jin-rong Street AS18566 1020 101 919 90.1% COVAD - Covad Communications Co. AS4323 1315 437 878 66.8% TWTC - Time Warner Telecom, Inc. AS4755 1331 507 824 61.9% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System There's really only 151129 routes you need to have full routes. Forcing just these top 4 slobs to aggregate reduces your global table by 3619 routes. Forcing the top 30 to aggregate frees up 15809 routes. Of course there are other reasons to upgrade (better CPU, MPLS, IPv6, etc.), but if you can't upgrade, there are alternatives to stretch the old hardware. It's not like it hasn't been done before. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 2M today, 10M with no change in technology? An informal survey.
Jon, On Aug 27, 2007, at 5:50 PM, Jon Lewis wrote: Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? Real Soon Now? According to Geoff, the BGP table is growing at around 3500 routes per month, so we're looking at blowing out MSFC2s in about 3 months if nothing changes. And here I was, wondering about 2M routes... Unlike Y2K, the end of the useful service life up the Sup2 can easily be pushed further away in time. Easy is, I suspect, in the mind of the route injector. There's really only 151129 routes you need to have full routes. Forcing just these top 4 slobs to aggregate reduces your global table by 3619 routes. ~1 more month. Forcing the top 30 to aggregate frees up 15809 routes. ~3 more months. Of course there are other reasons to upgrade (better CPU, MPLS, IPv6, etc.), but if you can't upgrade, there are alternatives to stretch the old hardware. For a few more months. What are upgrade cycles like again? How common are the MSFC2s? It's not like it hasn't been done before. Yep. The nice thing about repeating history is you have a good idea of the whinage that you're in store for. CIDR Wars 2.0: This Time It's For Real! No, really. We mean it this time. :-) Regards, -drc I used to be disgusted, now I try to be amused ... -- Elvis Costello
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Jon Lewis wrote: Of course there are other reasons to upgrade (better CPU, MPLS, IPv6, etc.), Now if this was a dust old MSFC2 that was like 5 years old I'd say ok. The problem is twofold: 1. Cisco is still selling the 7600 with the Sup32 bundle (which is what we bought) and saying you can take a full route table on it. I could already do MPLS and IPv6 on this box. This is pretty new hardware. 2. The only thing I could buy is the top of the line Sup720 3BXL. Ok, fine, but I don't need mega-super-d00per backplane speed. I just need more TCAM like Christoper Walken needs more cowbell. Cisco needs to have a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. If I end up upgrading because of this it will probably be a forklift upgrade to another platform. And there's no guarantee that it would be a Cisco one. -- John A. Kilpatrick [EMAIL PROTECTED]Email| http://www.hypergeek.net/ [EMAIL PROTECTED] Text pages| ICQ: 19147504 remember: no obstacles/only challenges
Re: 2M today, 10M with no change in technology? An informal survey.
At 8:50 PM -0400 8/27/07, Jon Lewis wrote: Unlike Y2K, the end of the useful service life up the Sup2 can easily be pushed further away in time. ASnum NetsNow NetsAggrNetGain % GainDescription There's really only 151129 routes you need to have full routes. Forcing just these top 4 slobs to aggregate reduces your global table by 3619 routes. Forcing the top 30 to aggregate frees up 15809 routes. That's an additional ~5 months at the current rate of new routes (and current ratio of customers per new routed block.) There's a lot more than 3500 new customers per month globally and if we get to the point where they are not coming out of hierarchical PA space, the new monthly routing growth will increase dramatically. /John
Re: 2M today, 10M with no change in technology? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch... And the 7600 is a router? :) -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch...
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, John A. Kilpatrick wrote: 1. Cisco is still selling the 7600 with the Sup32 bundle (which is what we bought) and saying you can take a full route table on it. I could already do MPLS and IPv6 on this box. This is pretty new hardware. Where are they saying that? The Sup32 sounded great until it became clear that it came with PFC3B (not 3BXL), and that there was no upgrade path to 3BXL. If it was/is being sold as a BGP routing solution, it was awfully short sighted. 2. The only thing I could buy is the top of the line Sup720 3BXL. Ok, fine, but I don't need mega-super-d00per backplane speed. I just need more TCAM like Christoper Walken needs more cowbell. Cisco needs to have a We're in the same boat. According to show catalyst6000, our Sup2's are doing just fine. If there were a Sup32-3BXL, it'd be more than sufficient for our needs. If I end up upgrading because of this it will probably be a forklift upgrade to another platform. And there's no guarantee that it would be a Cisco one. I guess cisco wants to play chicken with us and Juniper. Will you really do the forklift, or just bite the bullet and go Sup720-3BXL? I think they're better on the latter and counting on a bunch of hardware sales in the coming months. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 2M today, 10M with no change in technology? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch... And the 7600 is a router? :) I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... And tagged with some white paint. Though if you've kept up with the latest IOS developments, cisco is finally differentiating the platforms we've assumed for years were only different in angle and paint. 6500's won't get to run the newest 7600 code. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Jon Lewis wrote: On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch... And the 7600 is a router? :) I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow...
Re: 2M today, 10M with no change in technology? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: And the 7600 is a router? :) I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... I still needle my Cisco rep about that from time to time. IMHO, the 6500/7600 split was one of the dumbest, most poorly thought-out decisions Cisco ever made. That and they still haven't given me the warm-and-fuzzy about the plans for IOS licensing. Where I work, we're heavily invested in 6500s in the core and I don't see that changing any time soon. The borders are Junipers because they 'just plain work' :) jms
Re: 2M today, 10M with no change in technology? An informal survey.
On 8/27/07, Justin M. Streiner [EMAIL PROTECTED] wrote: I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... http://farm.tucows.com/images/2006/07/cow_tipping.jpg :D
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Jon Lewis wrote: On Tue, 28 Aug 2007, Chris L. Morrow wrote: I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... And tagged with some white paint. Though if you've kept up with the latest IOS developments, cisco is finally differentiating the platforms we've assumed for years were only different in angle and paint. 6500's won't get to run the newest 7600 code. Oh poor cow :( In all seriousness though, most routing platforms have their costs and benefits. The 7600/6500 do some things nicely, apparently large FIB's aren't their strength though (in most deployed configs atleast). -Chris
Re: 2M today, 10M with no change in technology? An informal survey.
1. Cisco is still selling the 7600 with the Sup32 bundle (which is what we bought) and saying you can take a full route table on it. I could already do MPLS and IPv6 on this box. This is pretty new hardware. Where are they saying that? The Sup32 sounded great until it became clear that it came with PFC3B (not 3BXL), and that there was no upgrade path to 3BXL. If it was/is being sold as a BGP routing solution, it was awfully short sighted. Their reps do it all the time. I worked with my rep to buy a couple of new routers. I specifically said I would be taking a full routing table on these boxes- Cisco's rep said the Sup-32 would be fine for my needs. Now I definitely didn't do as much checking as I should have but I was busy and that's why you have rep's in the first place. (I kept thinking the Sup32 was based on the 3BXL- I have no idea why). Thankfully I don't need to take a full table on these routers and their forwarding speed among the few ports I have is more important than the FIB size. That said- if I did need the full table I would be royally ticked off at Cisco right now. If I end up upgrading because of this it will probably be a forklift upgrade to another platform. And there's no guarantee that it would be a Cisco one. I guess cisco wants to play chicken with us and Juniper. Will you really do the forklift, or just bite the bullet and go Sup720-3BXL? I think they're better on the latter and counting on a bunch of hardware sales in the coming months. Given how many people are tired of being screwed over by Cisco I wouldn't make that bet if I were Cisco. -Don
NANOG Humour (Re: 2M today, 10M with no change in technology? An informal survey.)
On Mon, 27 Aug 2007, Hex Star wrote: On 8/27/07, Justin M. Streiner [EMAIL PROTECTED] wrote: I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... http://farm.tucows.com/images/2006/07/cow_tipping.jpg :D While its occasionally amusing, can we please keep the humour to the minimum, while sticking to the operational content? -alex (mlc chair)
Re: 2M today, 10M with no change in technology? An informal survey.
On 8/27/07 7:36 PM, Chris L. Morrow [EMAIL PROTECTED] wrote: and here I always looked at the 6500 as a switch... It switches, it routes, it makes julienne fries... -- John A. Kilpatrick [EMAIL PROTECTED]Email| http://www.hypergeek.net/ [EMAIL PROTECTED] Text pages| ICQ: 19147504 remember: no obstacles/only challenges
SNMP Trap Alarm?
Ok, I could have picked a better title. I'm looking for a pointer to a box (pref. an embedded platform of some kind) that will receive/accept SNMP traps and sound a real world alarm/siren/klaxon. It can do fancy things like logging and such, but not strictly required. I could build one, but I'd rather have something OTS. Thanks in advance, Deepak
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Jon Lewis wrote: Though if you've kept up with the latest IOS developments, cisco is finally differentiating the platforms we've assumed for years were only different in angle and paint. 6500's won't get to run the newest 7600 code. I think Cisco is coming to their senses. SXH has *most* of SRB features, while (hopefully) more stable. At this point, imho, the rsp720 is getting the short end of the stick, because it is only limited to SRB+, while you have a choice of SX* and SRB on the sup720. But I think, imho, this discussion belongs to cisco-nsp more than to nanog-l. -alex [not speaking as mlc blah blah]
Re: 2M today, 10M with no change in technology? An informal survey.
On 8/27/07 9:39 PM, Donald Stahl [EMAIL PROTECTED] wrote: Thankfully I don't need to take a full table on these routers and their forwarding speed among the few ports I have is more important than the FIB size. That said- if I did need the full table I would be royally ticked off at Cisco right now. Well the way I'm putting it to my Cisco rep is Why should I invest in 3BXLs instead of another vendor's solution? I'm saying this repeatedly. Maybe they'll get the hint. I won't throw away the 7604s...I could totally redeploy them in my corporate infrastructure. At this point they really are Cat 6500s. I don't mind if they make a 7600-only train as long as the 7600s can still run 6500 code then at least it makes them useful. Just not as edge routers. I bet Juniper is lulzing this hardcore. -- John A. Kilpatrick [EMAIL PROTECTED]Email| http://www.hypergeek.net/ [EMAIL PROTECTED] Text pages| ICQ: 19147504 remember: no obstacles/only challenges
Re: 2M today, 10M with no change in technology? An informal survey.
On Mon, 27 Aug 2007, Deepak Jain wrote: Where do the FIBs break on older 12000 series and M-series routers? (or pick the *next* most popular piece of network equipment that is used in full-routes scenarios). On the 12000, I'd give the following observations on the state of the older linecards for DFZ routing: GRP that can't handle 512 meg memory has been useless for quite some time. GRP-B with 512 megs of ram seems ok for at least 6-12 more months. PRP needs 1 gig of ram. All LCs need at least 256 megs of route memory. 4GE engine3 LC needs 512 megs of route memory. 10x1GE Engine 4 LC needs 512 megs of route memory. Engine2 LCs are starting to run out of forwarding resources, cisco states 200k routes, but obviously they still work, but for how long? Otoh the SIP-601 comes with 2 gigs of route memory, which is really nice. The 12000 with recent hardware will most likely last quite some time, but the hardware designed in the late 90ties is (not strangely) running out of steam. So if you have old hardware, you need to monitor your memory and table utilization on a monthly basis. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
