- NANOG - lists.nanog.org

Re: Why doesn't BGP...
by Paul G. Donner 10 Nov '96

10 Nov '96

There's also an OSPF study guide available if anyone is interested. That takes care of two of the protocols. At 09:48 PM 11/9/96 GMT, Dean Gaudet wrote: >In article <hot.mailing-lists.nanog-Pine.ULT.3.95.961109093416.14900C-100000(a)halcyon.ha lcyon.com>, >Ed Morin <edm(a)halcyon.com> wrote: >>On Sat, 9 Nov 1996, Neil J. McRae wrote: >> >>> Try reading the manual. How is the router supposed to know what >> >>Well, until _somebody_ writes the definitive "Nutshell" book we >>all know just how useful the "FM" is to "RT". > >I personally have found the information on the website/cdrom to be very >complete. The case studies proved invaluable while I was learning various >things. The BGP case study is incredible -- if you read it after reading >a theoretical text on BGP then you'll be set for configuring networks with >a small number of borders. There's a draft somewhere too that talks about >common bgp configurations. > >Granted it probably takes several hours of using the manuals before >you get a feel for how they're laid out and where to go for things. >That layout changes between 11.0 and 11.1 which can be annoying. But >it's very complete. I've only ever dealt with ip, atalk and bridging >however, maybe the experience in the other protocols is different. > >Do you honestly believe that a book with "nutshell" in the title is >going to be more definitive than the CDROM documentation? It would >weight twenty pounds. And also on this nutshell thread -- I think that >people may be wishing for "IOS IP configuration in a nutshell". There's >no way a single book could do justice to all the protocols IOS deals with. > >Dean > >

1 0

Re: Why doesn't BGP...
by Chris A. Icide 10 Nov '96

10 Nov '96

At 09:33 AM 11/9/96 -0800, Ed Morin wrote: >Look, I can do a "show interface" on any interface and see what speed >it's running at and if it's dropping packets. If BGP hears a route >on an interface that isn't dropping packets shouldn't _that_ route >be considered "best" all other things being equal (hop counts and >all)? You can't tell me the router doesn't know this information >because _I_ get the information from the router itself!! > >I understand about route instabilities, etc. All I'm talking about >here is a better "tie breaker" than ordinate numbers of IP addresses. > Ed, One major problem that you have overlooked is what happens when this wonderful automagic route protocol does exactly what you suggest? You have two wonderful paths to a wonderful location in a wonderful world. However, some wonderful traffic has wonderfully overwhelmed one of your links, and you have (not so wonderful) packet loss. Immediately your routing protocol senses this, and begins to prefer the other route. But a strange thing happens, the packet loss disappears on the first route and appears on the second and all of the sudden you have packet loss on the second link. Now I was not involved in the designing of the BGP (any rev level) specification, so the next bit of text is MHO of some of the thought process that may have gone into the development. Making something "fool-proof" tends to induce ignorance of the process and sloppy (if not negligent) engineering. BGP is NOT designed as the end all be all solution for networking. This still requires the human brain. I think perhaps the folks who designed BGP might have had this in mind. The phrase, "When all you have is a hammer, everything looks like a nail" comes to mind. Don't think of BGP as your hammer, it's a tool in a bag of tools. Of course there are always two necessary things one should know before using a tool: 1. What was the tool designed for? 2. What are all the features of the tool, that allows one to use it to it's fullest capability. And finally, I'm going to throw in my personal humble opinion... If you are having packet loss constantly on your network, and it's within your control, you need to re-engineer your network. If it's out of your control, you need to re-engineer your network to bring it within your control. <hops off soapbox> Chris A. Icide Nap.Net, L.L.C.

1 0

Re: Why doesn't BGP...
by Tony Li 10 Nov '96

10 Nov '96

I don't think the people who came up with BGP4 ever expected to see what some people do with their router configs. Don't bet on that. ;-) Tony

1 0

Re: spamspamspam (fwd)
by dgaudet＠plebe.com 09 Nov '96

09 Nov '96

In article <hot.mailing-lists.nanog-v02140b00aeaab407998a(a)[207.135.64.133]>, Chris Russo <crusso(a)alink.net> wrote: >Sure, if the Spam-Hating software is buggy, then it will generate >unnecessary garbage. If it works, however, the only fear you'll have is if >your users are spamming. That should be taken care of by dealing with the >spammer(s), rather than by taking the ostrich approach. In the past I was targetted by an anti-spam attack against "eros net" (I forget their real domain) because I'm listed in one of the nameserver records for EROS.COM which is not at all related to "eros net". I suppose this sort of human screw up may not happen depending on how the tool is written. In any event, sometimes people who receive email they asked for (i.e. entering their email address on a web form which explicitly said they would be receiving said mail) initiate anti-spam attacks because they forgot they asked for the mail. Dean

1 0

Re: spamspamspam (fwd)
by crusso＠alink.net 09 Nov '96

09 Nov '96

>And yet again the usefulness of whois contacts is eroded. I don't know >about the rest of you, but I'm beginning to indirect all my whois >information through idiot filters -- indirect email addresses, alternate >phone numbers. I don't even run anything large. Sure, if the Spam-Hating software is buggy, then it will generate unnecessary garbage. If it works, however, the only fear you'll have is if your users are spamming. That should be taken care of by dealing with the spammer(s), rather than by taking the ostrich approach. Chris Russo ------------------------------------------------------------------ A-Link Network Services (408) 720-6161 http://www.alink.net This space for rent. ------------------------------------------------------------------

1 0

Canadian ISP Code of Conduct
by Paul Ferguson 09 Nov '96

09 Nov '96

Noticed a press release this morning which stated the CAIP (Canadian Association of Internet Providers) had defined a 'voluntary' code of conduct for Canadian ISP's. FYI. http://www.caip.ca/caipcode.htm - paul

4 3

Re: Why doesn't BGP...
by dgaudet＠plebe.com 09 Nov '96

09 Nov '96

In article <hot.mailing-lists.nanog-Pine.ULT.3.95.961109093416.14900C-100000(a)halcyon.halcyon.com>, Ed Morin <edm(a)halcyon.com> wrote: >On Sat, 9 Nov 1996, Neil J. McRae wrote: > >> Try reading the manual. How is the router supposed to know what > >Well, until _somebody_ writes the definitive "Nutshell" book we >all know just how useful the "FM" is to "RT". I personally have found the information on the website/cdrom to be very complete. The case studies proved invaluable while I was learning various things. The BGP case study is incredible -- if you read it after reading a theoretical text on BGP then you'll be set for configuring networks with a small number of borders. There's a draft somewhere too that talks about common bgp configurations. Granted it probably takes several hours of using the manuals before you get a feel for how they're laid out and where to go for things. That layout changes between 11.0 and 11.1 which can be annoying. But it's very complete. I've only ever dealt with ip, atalk and bridging however, maybe the experience in the other protocols is different. Do you honestly believe that a book with "nutshell" in the title is going to be more definitive than the CDROM documentation? It would weight twenty pounds. And also on this nutshell thread -- I think that people may be wishing for "IOS IP configuration in a nutshell". There's no way a single book could do justice to all the protocols IOS deals with. Dean

1 0

Re: Why doesn't BGP...
by Vadim Antonov 09 Nov '96

09 Nov '96

Avi Freedman <freedman(a)netaxs.com> wrote: >Anyway, sorry to be snide - any suggestions you have about algorithms >for exchanging routing data between (or inside of) providers that also >takes into account link size and perhaps hop-count, as opposed to >just AS-PATH, are welcome at the next IETF meeting. The problem with physical metrics is that they're pretty much useless in the real world, where network administrators often want to have traffic to go along suboptimal ways to balance the load. Obviously, any "automagic" load-sensitive system must have a global knowledge, and long-term statistics on traffic patterns to be able to simulate the behaviour of "gut feeling" of the engineers. Regarding BGP metrics -- there's a problem with a single "universal" metric in an exterior routing protocol, namely the absense of a single authority to assign those metrics. Different networks may have very much confiliciting interests in how to assign BGP metrics. Some time ago i wrote a draft (which didn't get any support and quietly expired) regarding BGP metrics -- the idea was to have a vector of metrics (one per AS hop) instead of a single scalar metric; and allow network operators to calculate weighted sums to obtain the locally significant scalar metrics. I.e. a network operator may decide for himself how to interpret BGP metrics coming from different AS-es (or by different paths). The draft also describes a mechanism for scaling IGP metrics to generate BGP metrics (thus replacing MEDs with a generic mechanism). It also allows "fudging" the weighted sum with an exit-specific constant, thus superceding local prefs. In other words, the proposed metric system is generic enough to make MEDs, LOCAL_PREFs, and many cases of use of communities, a mere particular cases; so they can be obsoleted. The default metric for an AS-hop is 1.0, and the default weight vector is all-ones, so the default behaviour is identical to that of the current BGP. If there's any interest i can dig the draft out and place it on my www server. --vadim

1 0

CIX routing service (was Re: AGIS/DIGEX)
by Eric Ziegast 09 Nov '96

09 Nov '96

> > > [...] Since Digex is at too few NAPs to peer with AGIS, and they > > > are not at the CIX, we see no routes from them. > > CIX is taking new connections, either T1, PB-SMDS, or DEC-PAIX (FDDI or > Ether). Just a side thought about CIX's role in the Internet... With peering requirements becoming too strict for new players, I see two alternatives for getting good peering connectivity: - RA servers - semi-reliable registration-based database for routing updates - lacks media sensing - CIX - on-the-fly trust-the-providers routing updates - media sensing through BGP peering sessions - router could overload CIX started up long ago to "create a level playing field" (commercial providers vs. ANS/NSFNET/AUP). When everyone willingly peered with everyone else at MAE's and NAPs, CIX was becoming a moot point (why use CIX over a slow link when I can go direct via DS3/Router/Giga/- Router/DS3?). Now that the playing field isn't level anymore (big fish refusing to peer with little fish), perhaps CIX has a new use - simple peering at major exchange points. Instead of having people all try to peer with each other, a lengthy process and complex to manage), why not have CIX put a router in any exchange point and say, "Here CIX members, peer with this router and you'll get routing to every other CIX member at the exchange point." The "big ISPs" will still peer with each other directly, even privately, but they have enough traffic in between them to make it worthwhile. New or small ISPs would be the primary benefactors. So you ask, "What about RA?" I have nothing against it. For new providers, it's an excellent solution that gets them off the ground peering. I suspect though that some providers just don't like the fact that the routing is decoupled from the L2 switching making exchange point connectivity outages hard to detect/correct quickly. Some would say that CIX gets saturated. Yes, CIX-West was at one time fatally saturated on incoming bit pipes (not necessarily CIX's fault), but saturation can be reduced or eliminated by: - having multiple CIX routers - one set at every major exchange point (no, there's no bacbone in between). - rate-limiting peers to a maximum of XX Mbps (ATM, yes; possible on GigaSwitchs or FDDIs?). - detecting then encouraging peers with more than X Mbps of traffic (on average) to offload traffic to direct peering or other exchange points. - Using multiple iBGP routers at an exchange point. Then again, it doesn't have to be CIX; it just seems natural since they've been running CIX-West for oh-so-long. A bunch of smart BGP people can go out, get some money, buy the equipment, install it, and have ISPs pay them for the service. Would such a peering entity compete with ISPs? I don't think so. Routing at a peering point isn't their business - transiting customers to "the Internet" reliably and quickly is. ISPs would be the customers of the "enhanced peering service". I don't think this is really a new idea, nor really my concern, but I see two of my service providers struggling to get new peering and think, "There's got to be a better way." ... just something to think about. -- Eric Ziegast Looking in from the edge

3 2

Re: Cisco for dummies?
by Paul J. Zawada 09 Nov '96

09 Nov '96

Actually, to cover everything the various flavors of IOS does, you would probably need different nutshell books targeted at different audiences, perhaps one for each flavor of IOS. (Enterprise, IBM, Desktop, ISP...) I don't think too many people on this list would care about the SNA $%#^ that Cisco-Blue does. --zawada At 05:33 PM 11/8/96 -0500, Deepak Jain wrote: > >Actually the Nutshell books are great. "Cisco IOS in a Nutshell" I can go >for that. Aren't they the ones that also do *the* Sendmail book? > Paul J. Zawada, RCDD | Senior Network Engineer zawada(a)ncsa.uiuc.edu | National Center for Supercomputing Applications +1 217 244 4728 | http://www.ncsa.uiuc.edu/People/zawada

3 2