Re: Has PSI been assigned network 1?
Karl, you obviously do not understand what global networking and policy routing mean. Right today we nearly killed all Internet by _not_ doing paranoid filtering on ANS route announcements (well we couldn't do it because of certain contractual obligations). ANS had trouble with generating configuration for ENSS 147, so they simply dropped all routes at our MAE-East+ box without filtering they usually do, which would be fine if we didn't do some upgrades at ICM, which involved changing preferences in ICM-SL routing, to the effect that SL started preferring AS 690 as path to many European networks. It resulted in SprintLink -> Europe traffic being moved from SL->ICM FDDI connection to SL->ENSS(147)->ANS core->Dante path; which at the daytime grew and turned out be enough to overload ENSSes along the path. This resulted in ENSS 147 delaying BGP keealives for so long that MAE-E peers (including SprintLink) were dropping their BGP sessions, only to reset them later. Since that causes route caches being flushed all _other_ ciscos were falling back to switching by CPU, became overloaded and started dropping their BGP sessions. Which resulted in snowball of real massive routing flap. I imagine how Internet would work if everybody listened to the enlightened advice of our esteemed sage:
Fascistic filtering breaks connectivity.
So you trade a *risk* of broken connectivity for KNOWN broken connectivity?
Sounds like a poor trade to me, and one which, undertaken consciously and with knowledge of the repercussions, leaves you with being less than a full Internet connectivity provider.
After all, if you're filtering perfectly valid announcements then you are, by definition, not providing connectivity to the "whole Internet" to the best of your ability, are you?
Sorry, Karl. Internet is lucky that people who run most big networks know better than to wait for shit to happen. In the system as large as Internet shit happens permanently. Somewhere, in the most unxpected places. If you persist in your dislike of filtering i guess i'll purely accidentally misconfigure a static route, so it will be the the same as your backbone address. RS won't save you. This is a joke, of course. --vadim
Karl, you obviously do not understand what global networking and policy routing mean.
Nonsense. You obviously do not understand what providing robust connectivity means.
Right today we nearly killed all Internet by _not_ doing paranoid filtering on ANS route announcements (well we couldn't do it because of certain contractual obligations).
ANS had trouble with generating configuration for ENSS 147, so they simply dropped all routes at our MAE-East+ box without filtering they usually do, which would be fine if we didn't do some upgrades at ICM, which involved changing preferences in ICM-SL routing, to the effect that SL started preferring AS 690 as path to many European networks. It resulted in SprintLink -> Europe traffic being moved from SL->ICM FDDI connection to SL->ENSS(147)->ANS core->Dante path; which at the daytime grew and turned out be enough to overload ENSSes along the path.
Sorry, no. You broke this by doing your own "upgrades" as well. Fact is, if someone starts flapping badly at you, and they announce many paths (ie: a significant CPU load is presented by this) you're screwed no matter HOW MUCH you filter. The equipment available today is designed foolishly -- route update processing and actual packet processing should NEVER be done by the same CPU -- but it is -- and as such you're dead when this happens. That cannot be avoided by being a fascist. However, what you can do is make sure that backup paths don't work at all when things break, and in some cases you can make sure that you can't reach certain prefixes at all, when there is a perfectly valid path being announced to you. In some of these cases of "backhoe fade" and even software failure connectivity has been impacted when it SHOULD NOT HAVE BEEN by this policy of yours. Filtering only serves to violate the premise of BGP4 and routing in general - that the metrics and route weights will guide a packet to the most expeditious path. When you remove some of those choices, you second-guess the physical realities of the time. What you're doing here is *removing* choices. This is bad. Making certain choices <less desirable> is good, and is how you should get packet loads and traffic shares to go where you want. But removing some paths from consideration entirely by pretending they don't exist when in fact they do serves to violate the integrity of the net as a whole.
Sorry, Karl. Internet is lucky that people who run most big networks know better than to wait for shit to happen. In the system as large as Internet shit happens permanently. Somewhere, in the most unxpected places.
Yep. So? You wish to argue with the fact that people do silly, stupid, inept and sometimes even malicious things? No argument. Your solution is to lock everyone up BEFORE they do something bad? This has to tie in with a political philosophy somewhere....
If you persist in your dislike of filtering i guess i'll purely accidentally misconfigure a static route, so it will be the the same as your backbone address. RS won't save you.
This is a joke, of course.
--vadim
-- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
From: "Karl Denninger, MCSNet" <karl@mcs.com> To: avg@sprint.net (Vadim Antonov)
Karl, you obviously do not understand what global networking and policy routing mean. Nonsense. You obviously do not understand what providing robust connectivity means.
ROFL!!!!! Thanks. Made my day.
Filtering only serves to violate the premise of BGP4 and routing in general - that the metrics and route weights will guide a packet to the most expeditious path. When you remove some of those choices, you second-guess the physical realities of the time.
Filtering does not violate any premise in BGP4. BGP4 was designed to allow the assignment of administrative weights. That is to say, POLICY. And I happen to believe not accepting a route for 204.68.252/24 from someone who is not authorized to route the associated ASes is a good policy. If someone announced a route to NET99 that was not authorized then ANS would ignore that route, and you would still have connectivity through us. Only the customers of the ISP who misconfigured his equipment, and anyone uniformed enough to accept routes from him, would lose out. Yes, as Vadim points out, there is an administrative cost to filing NACRs. Yes, you need bigger, faster routers with a LOT more memory. Yes, I see outages every day because someone did not file a NACR, filed it incorrectly, or it was not processed on time. But the resulting connectivity is, IMHO, more robust than, to borrow a metaphor, having promiscuous sessions with all your peers and praying you don't get the 'black hole', Larry Plato ANS Network Operations
Filtering only serves to violate the premise of BGP4 and routing in general - that the metrics and route weights will guide a packet to the most expeditious path. When you remove some of those choices, you second-guess the physical realities of the time.
Filtering does not violate any premise in BGP4. BGP4 was designed to allow the assignment of administrative weights. That is to say, POLICY. And I happen to believe not accepting a route for 204.68.252/24 from someone who is not authorized to route the associated ASes is a good policy. If someone announced a route to NET99 that was not authorized then ANS would ignore that route, and you would still have connectivity through us. Only the customers of the ISP who misconfigured his equipment, and anyone uniformed enough to accept routes from him, would lose out.
Ok, Larry, let me ask the $10,000 question: If I announce 204.137.64/20 to you, how do you know if I am authorized to do so or not? The answer is, absent something LIKE a NACR (ie: RR, RA, etc) you don't. So now, if you *don't know*, do you take it or don't you? I'm not arguing against NACRs and RAs. In fact, just the opposite. If you're going to filter, and I understand that it can serve a purpose, then you *MUST* trust some authoritative source, and that source must have the information to make the decision. Saying "I'll accept anything from the netblocks I gave this ISP, and nothing more" is baloney. A transit provider has NO IDEA what routes you, as an ISP, are authorized to route or who your customers are. My business arrangements and their details are none of anyone else's business, just like I have no business knowing what kind of deal ANS cut with some other provider. Yet if ANS announces to me a prefix at some public peering point, there should be some way for me to determine if it is or is not a legit announcement. All that transit provider needs to know is what you register as announcable via your AS, and that the delegate(s) of those address prefixes agree that you can reach them. That's a function that both NACRs and RAs serve. Filtering *without* that information is time-consuming and serves to break connectivity. Vadim has argued *vehemently* against trusting any neutral, exterior source of this information, like a route server.
But the resulting connectivity is, IMHO, more robust than, to borrow a metaphor, having promiscuous sessions with all your peers and praying you don't get the 'black hole',
Larry Plato ANS Network Operations
You and I aren't disagreeing here. What I disagree with is filtering *without* using something that serves as a table of authorities on who can reach what. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
Ok, Larry, let me ask the $10,000 question:
If I announce 204.137.64/20 to you, how do you know if I am authorized to do so or not?
The answer is, absent something LIKE a NACR (ie: RR, RA, etc) you don't.
So now, if you *don't know*, do you take it or don't you?
I'm not arguing against NACRs and RAs. In fact, just the opposite. If you're going to filter, and I understand that it can serve a purpose, then you *MUST* trust some authoritative source, and that source must have the information to make the decision.
Even with a route registry, you have no way of knowing, apriora, that the registration is correct. There have already been "helpful" attempts to register information for others w/o their consent. Eric C. & I came up with this idea about the same time. I call it "Chain of Custody" and Eric has other names for it. In general, it depends on religious registration in whois and/or rwhois, the distributed IRR and PGP. Here is a brief summary: Basically, I have made a proposal to have the Internic set an example by registering all delegations in whois/RWhois and signing the delegation. All down-stream ISPs should do the same (register delegations in RWhois and sign any downstream delegations) When a custodian wishes to register a delegation for routing, they sign the request. That way, registry operators can follow a "chain of custody" to give priority when duplicate registration requests are entered into one or more registries. --bill
The equipment available today is designed foolishly -- route update processing and actual packet processing should NEVER be done by the same CPU -- but it is -- and as such you're dead when this happens. Lest anyone believe this, it's bullshit. Karl just buys low end gear and then complains because it's not high end gear. Tony
The equipment available today is designed foolishly -- route update processing and actual packet processing should NEVER be done by the same CPU -- but it is -- and as such you're dead when this happens.
Lest anyone believe this, it's bullshit.
Karl just buys low end gear and then complains because it's not high end gear.
Tony
I suppose that a 7000 with a SSP is considered "low end" gear then? It was *Vadim* who was complaining about CPU usage on your boxes, not me. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
I agree that one cpu does all is outdated monolithic design. Even hub vendors have two: one for hubbing, one for snmp and rmon. Mike On Fri, 28 Apr 1995, Tony Li wrote:
The equipment available today is designed foolishly -- route update processing and actual packet processing should NEVER be done by the same CPU -- but it is -- and as such you're dead when this happens.
Lest anyone believe this, it's bullshit.
Karl just buys low end gear and then complains because it's not high end gear.
Tony
-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------
We have been working on breaking up the monolithic routing model on Unix workstations. I will be speaking more about this at NANOG, but see http://www.ra.net/routing.arbiter/RT/mrt.html The code and documentation are early alpha. There will probably be a public alpha release sometime around the next NANOG. - Craig -- Craig Labovitz labovit@merit.edu Merit Network, Inc. (313) 764-0252 (office) 1071 Beal Ave, Ann Arbor, MI (313) 747-3745 (fax) Michael F. Nittmann writes:
To: Tony Li <tli@cisco.com> Cc: karl@mcs.com, avg@sprint.net, avg@sprint.net, nanog@merit.edu, rps@ISI.EDU, salo@msc.edu Subject: Re: Has PSI been assigned network 1? In-Reply-To: <199504280712.AAA00290@greatdane.cisco.com> Message-Id: <Pine.BSD.3.91.950428114053.28003D-100000@muffin.wis.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII
I agree that one cpu does all is outdated monolithic design. Even hub vendors have two: one for hubbing, one for snmp and rmon.
Mike
On Fri, 28 Apr 1995, Tony Li wrote:
The equipment available today is designed foolishly -- route update processing and actual packet processing should NEVER be done by the same CPU -- but it is -- and as such you're dead when this happens.
Lest anyone believe this, it's bullshit.
Karl just buys low end gear and then complains because it's not high end gear.
Tony
-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------
I agree that one cpu does all is outdated monolithic design. Even hub vendors have two: one for hubbing, one for snmp and rmon.
Mike
The existing route servers do this now... One CPU to compute routes and then we forward the tables to ISP peers. --bill
I agree that one cpu does all is outdated monolithic design. Even hub vendors have two: one for hubbing, one for snmp and rmon.
Mike
The existing route servers do this now... One CPU to compute routes and then we forward the tables to ISP peers.
--bill
Only if NSPs and ISPs are willing to use them. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
well, I meant of course calculating routes and routing (user, payload, actual usage) traffic, not announcing tables. how about: one cpu for doing topology( including receiving and sending data related to that task), and (while <value of one> smaller than enough) one++ for doing traffic over that topology (where again traffic is 'user' traffic, not only and not excluding route announcements). .... sorry that ny phrase cited below was not mathematically, logically, or legally a one-one expression. ( anyways, the inverse would be then no outdated monolithic design is not one cpu does nothing, right?) ... yes, <value of enough> is probably time limited approximated but never reached Mike (enjoying the fact that it is FRIDAY) .............still like the thread header! since someone complained (was that on this list here?), nobody dares transiting this discussion to a new thread. ;-) On Fri, 28 Apr 1995 bmanning@ISI.EDU wrote:
I agree that one cpu does all is outdated monolithic design. Even hub vendors have two: one for hubbing, one for snmp and rmon.
Mike
The existing route servers do this now... One CPU to compute routes and then we forward the tables to ISP peers.
--bill
-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------
participants (9)
-
ATM_Feel_the_Power -
bmanning＠ISI.EDU -
Craig Labovitz -
Karl Denninger, MCSNet -
Larry J. Plato -
Michael F. Nittmann -
randy＠psg.com -
Tony Li -
Vadim Antonov