I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
Jon Green writes:
Hi folks-
I have a problem that I need some advice on, and figured this was a good place to turn. We are attempting to connect a T1 to Sprint in order to multi-home our network. Currently we are connected to multiple points on MCI's backbone, and have just installed a T1 to UUnet. We heard back from Sprint today.. they are rejecting us as a customer because we do not use Cisco routers. Apparently they feel that Bay Networks routers are not capable of routing Internet traffic, ignoring the fact that they already peer with ANS and several other providers using Bay routers.
You are actually getting some misinformation. You can use any router you want, we just can't help you configure things other than Cisco routers. If you want us to manage your router, then it must be a Cisco, otherwise use whatever you want.
Any suggestions welcome. Anyone from Sprint who'd like to comment, please do so.
Tell your Sprint sales folks that I said it was fine and approve the SCA. If they have any questions, have them call me.
-Hank Kilmer Mgr Sprint IP OPS Engineering
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
I suspect two problems. Some [potential] cvustomers are not hearing clearly, or Sprint has some internal communication problem that is leaking out to customers. Probably more of the latter then the former, but likely a bit of both. But the tough question is what to do when a customer wants to attach something 'strange'. We're a few decades past the Carterphone decision, so we probably should let the customer do it. But how much are we obliged to debug it for them? And how are we compensated for our efforts beyond those to which we are used? randy
On Wed, 25 Sep 1996, Rob Liebschutz wrote:
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
I had a sprint T1 a long time ago and we just had a P133 with Emerging Tech T1 cards. We were doing BGP4 with them and MCI and had to go with the P133 PC router because we ran out of RAM on the 4500s and did not have the cash then for a 7000. We did have that same problem, sprint said that if we changed to a PC router they would terminate our connection. So I had to setup peering on the cisco then at night swap in my PC. It was able to do cisco HDLC so it worked out and I setup the router so that when you telneted to it it looked like a cisco. I think that most of this is a sales person problem, because not many tech people cared if I was using a cisco or a toaster, as long as I managed it. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
On Wed, 25 Sep 1996, Rob Liebschutz wrote:
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
I had a sprint T1 a long time ago and we just had a P133 with Emerging Tech T1 cards. We were doing BGP4 with them and MCI and had to go with the P133 PC router because we ran out of RAM on the 4500s and did not have the
You ran out of RAM on the 4500??? With just two full BGP sessions?
cash then for a 7000. We did have that same problem, sprint said that if we changed to a PC router they would terminate our connection. So I had to setup peering on the cisco then at night swap in my PC. It was able to do cisco HDLC so it worked out and I setup the router so that when you telneted to it it looked like a cisco.
I think that most of this is a sales person problem, because not many tech people cared if I was using a cisco or a toaster, as long as I managed it.
Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
Avi
Avi Freedman writes:
You ran out of RAM on the 4500??? With just two full BGP sessions?
I could see it happening. The useful lifespan of 32MB cisco routers for full routing is pretty close to being over. (Depends on what else is going on for that router, of course. YMMV, etc.)
Avi Freedman writes:
You ran out of RAM on the 4500??? With just two full BGP sessions?
I could see it happening. The useful lifespan of 32MB cisco routers for full routing is pretty close to being over.
(Depends on what else is going on for that router, of course. YMMV, etc.)
Hmm... Do you have any of these boxes? My impression is that a 4500 w/ 3 or 4 full views still takes well under 24mb, and doesn't impact the performance of the box at all. Avi
Avi Freedman writes:
Hmm... Do you have any of these boxes?
I do speak from some personal experience, yes.
My impression is that a 4500 w/ 3 or 4 full views still takes well under 24mb, and doesn't impact the performance of the box at all.
There are many unaccounted for variables here. You certainly don't have as many unadvertised more specifics as we do, as much stuff in the IGP, etc., etc. Those doing less will get some more breathing room, but unless many more people get more more serious about reducing global routing tables it won't be too long before 32MB will not be enough for anyone.
Avi Freedman writes:
Hmm... Do you have any of these boxes?
I do speak from some personal experience, yes.
My impression is that a 4500 w/ 3 or 4 full views still takes well under 24mb, and doesn't impact the performance of the box at all.
There are many unaccounted for variables here. You certainly don't have as many unadvertised more specifics as we do, as much stuff in the IGP, etc., etc. Those doing less will get some more breathing
Yes, a huge IGP (thousands of routes) is an issue that most people choosing 4500s vs. 7010s don't have to face :)
room, but unless many more people get more more serious about reducing global routing tables it won't be too long before 32MB will not be enough for anyone.
Yup... Thanks, Avi
Avi Freedman writes:
Yes, a huge IGP (thousands of routes) is an issue that most people choosing 4500s vs. 7010s don't have to face :)
Hey, we have less than a thousand routes in our IGP. :-) More seriously, they don't have to face that issue, but 8 MB of headroom is not very much. Once you get to much less than 3 or 4 MB things can get interesting due to transients. (For those buying 32MB routers, just make sure they can be upgraded to 64MB. The day of reckoning for 64MB routers is still a while off.)
Avi Freedman writes:
Yes, a huge IGP (thousands of routes) is an issue that most people choosing 4500s vs. 7010s don't have to face :)
Hey, we have less than a thousand routes in our IGP. :-)
More seriously, they don't have to face that issue, but 8 MB of headroom is not very much. Once you get to much less than 3 or 4 MB things can get interesting due to transients.
If you're very paranoid it can help some (don't accept any routes from any of your peers from any other, and none of your peers will send you huge numbers of routes unless they're REALLY misconfigured and are seriously mungeing AS-PATHs. But yes, I'd agree - and buffer space can be a transient additional memory requirement also.
(For those buying 32MB routers, just make sure they can be upgraded to 64MB. The day of reckoning for 64MB routers is still a while off.)
Sigh, you can always hostile-aggegate, but one doesn't like to do that... Avi
Joseph Malcolm writes:
There are many unaccounted for variables here. You certainly don't have as many unadvertised more specifics as we do, as much stuff in the IGP, etc., etc. Those doing less will get some more breathing room, but unless many more people get more more serious about reducing global routing tables it won't be too long before 32MB will not be enough for anyone.
Not, you understand, that I think the global routing table should be kept in control, but I find it to be extraordinarily annoying that in a world where cheap PCs have been able to take 128meg on their motherboards for years (indeed, many can take far more!) and in which workstations frequently have 64M of memory in them, there are routers (many still sold!) which lack the slots to take more than 32M of memory. Perry
"Perry E. Metzger" writes:
Not, you understand, that I think the global routing table should be kept in control,
Obviously that was a typo -- I think everyone agrees that the global routing table *must* be kept in control...
but I find it to be extraordinarily annoying that in a world where cheap PCs have been able to take 128meg on their motherboards for years (indeed, many can take far more!) and in which workstations frequently have 64M of memory in them, there are routers (many still sold!) which lack the slots to take more than 32M of memory.
Perry
"Perry E. Metzger" writes:
Not, you understand, that I think the global routing table should be kept in control,
Obviously that was a typo -- I think everyone agrees that the global routing table *must* be kept in control...
Do they? There is a rather large contingency of folks who feel the current paradigms of global routing necessitate a table growth explosion. Moving away from a BFR to a distributed switching system does have merits. The assumption for this model is that the routing engine for the switching systems grows exponentially. I don't really buy into this point of view, but it is there... -alan -- alan@mindvision.com
On Thu, 26 Sep 1996 13:37:00 -0400 "Perry E. Metzger" <perry@piermont.com> alleged:
Not, you understand, that I think the global routing table should be kept in control, but I find it to be extraordinarily annoying that in a world where cheap PCs have been able to take 128meg on their motherboards for years (indeed, many can take far more!) and in which workstations frequently have 64M of memory in them, there are routers (many still sold!) which lack the slots to take more than 32M of memory.
Its insane, I use BSD based routers and have little problems, I can take up to 1 gig of memory in my routers... I'm about to install 2 NetBSD routers to peer on the LINX, and I'm hoping for the same uptimes for my NetBSD core routers: NetBSD defender.router.EASYNET.NET 1.2_BETA NetBSD 1.2_BETA (ROUTER) #2: Sat Jul 13 03:25:14 BST 1996 neil@defender.router.easynet.co.uk:/usr/src/sys/arch/i386/compile/ROUTER i386 6:55PM up 73 days, 6:17, 2 users, load averages: 0.06, 0.08, 0.08 GateD-defender.router.EASYNET.NET> show ip route 100 IP radix tree: 81032 nodes, 41812 routes This router handles our internal BGP4 to our 3 border routers, and carries a full routeing table, and will handle updates for the LINX. "It works." If only more people would try it. :( Regards, Neil. -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
Perry E. Metzger writes:
Not, you understand, that I think the global routing table should be kept in control, but I find it to be extraordinarily annoying that in a world where cheap PCs have been able to take 128meg on their motherboards for years (indeed, many can take far more!) and in which workstations frequently have 64M of memory in them, there are routers (many still sold!) which lack the slots to take more than 32M of memory.
Cisco has been repeatedly abused for this. They have learned, a bit, over the years. The non-M 45xx/47xx boxes are I think no longer being sold, and the "M" replacements are upgradeable to 64MB. (of course, I suspect you'll never be able to get more than 64 MB of memory for a 7000. Someday they will get abused for that, too.)
On Thu, 26 Sep 1996, Avi Freedman wrote:
You ran out of RAM on the 4500??? With just two full BGP sessions?
Sorry wrong router, they were 4000s, and had almost 3 full sessions. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
As Hank commented eqarlier, I think you've got a salesperson feeding misinformation. I've personally configured and successfully had a full BGP routing session between a cisco 7000 and a Bay Networks router. Would you care for numbered or unnumbered BGP4 with that? Steve Mansfield smm@uunet.uu.net AlterNet Senior Network Engineer ...uunet!smm 703-206-5758
Steve - I think he means Sprint told him they would not BGP4 peer with him if he didn't have a Cisco 7000 series router. Not that it wasn't possible. :) -Deepak. On Thu, 26 Sep 1996, Steve Mansfield wrote:
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
As Hank commented eqarlier, I think you've got a salesperson feeding misinformation. I've personally configured and successfully had a full BGP routing session between a cisco 7000 and a Bay Networks router. Would you care for numbered or unnumbered BGP4 with that?
Steve Mansfield smm@uunet.uu.net AlterNet Senior Network Engineer ...uunet!smm 703-206-5758
On Thu, 26 Sep 1996 10:36:56 -0400 (EDT) Deepak Jain <deepak@jain.com> alleged:
Steve -
I think he means Sprint told him they would not BGP4 peer with him if he didn't have a Cisco 7000 series router. Not that it wasn't possible. :)
You have to vote with your feet on this and take your money elsewhere. Regards, Neil. -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A> BTnet support reply regarding 45 minutes of no service: "BGP FNF, BGP A OK, BT ISP A OK, MFI NO GO!!" -- Bill.Peters@bt.net
I spoke to a sprint salesperson about 2 weeks ago and was told that I could not get any kind of BGP4 peering with Sprint unless I had a Cisco 7000 series router.
As Hank commented eqarlier, I think you've got a salesperson feeding misinformation. I've personally configured and successfully had a full BGP routing session between a cisco 7000 and a Bay Networks router. Would you care for numbered or unnumbered BGP4 with that?
As a reference point, this restriction is also in their customer handbook (dated October 1995, the latest one I could find) available on their web page. If it's just a salesperson feeding misinformation, it's probably also being fed to the salespeople and the customers via the handbook. --quote-- 2.4.2 Customer Provided Routers Customers may provide their own SprintLink router only if the router: * is a Cisco router running Cisco revision level 10.2 or greater * has at least 4MB flash memory for customers with static routing, or 8MB flash memory for customers with dynamic routing * is configured, maintained, and managed by the customer Customer provided routers can be single-homed or multi-homed. Single-homed customers have one path to the Internet from a single customer IP address. Multi-homed customers have multiple paths to the Internet from a single customer IP address. Multi-homed customer routers must also meet the following requirements: * are Cisco 7000 or 7010 models * run BGP-4 When providing the router, the customer will also be responsible for furnishing the necessary ancillary equipment (cables, routing software, etc.) to insure interoperability with the SprintLink network router. Sprint is not obligated to accept trouble calls related to the customer provided router. In the event a customer requests assistance from Sprint to correct a trouble relating to the customer provided router, Sprint will inform the customer that a "dispatch charge" will be applied to the customer's next bill for the services provided by the Sprint CPE Technician. --end quote-- etc. It goes on to say that they are in the process of certifying other routers. It's been a year: perhaps the online handbook and the salespeople should be updated.. -mm-
participants (11)
-
Alan Hannan -
Avi Freedman -
Deepak Jain -
Joseph Malcolm -
Mark E. Mallett -
Nathan Stratton -
Neil J. McRae -
Perry E. Metzger -
randy＠psg.com -
Rob Liebschutz -
Steve Mansfield