- Test - lists.nanog.org

Re: Provider credibility - does it matter? was Re: Inter-provider relations
by Vadim Antonov 11 Nov '96

11 Nov '96

Roger Bohn <Rbohn(a)UCSD.edu> wrote: At 8:36 PM -0700 10/24/96, Vadim Antonov wrote: >Note that i didn't even talk about less measurabe, but way too >more important things like hosting of information suppliers. >Say, Big Provider connects 1000 web sites; Small Provider hosts >1 site -- benefit from peering in terms of Web site diversity to >the Big Provider's customers is 0.1%. To Small Provider's >customers the benefit of peering is 99.9%. >Oops, this has an arithmetic fallacy. Assuming that Big Provider also has >1000x more customers than Small Provider, and that all 1001 web sites are >equally attractive, then there are 1000 BP customers each with a .001 >chance of wanting to surf the SP web site. Compare this with 1 SP customer >with a .999 chance of wanting to surf a BP web site, and a .001 chance of >surfing the SP web site. No, this is not about mutual traffic -- this is about benefit to _a_ customer. Your computation is correct but is completely irrelevant from the point of view of a customer. They're interested in reacheability, not traffic at some exchange point. I.e. each small ISP's customer derives 99.9% of benefit from the peering, while large ISP's customer derives only 0.01%. Hence, the large ISP can force small ISP to pay up -- without connectivity to a large ISP the small ISP will be dead pretty soon. This is exactly like grocery chains which can (and do) force consumers to pay up for food -- although you can grow your own tomatoes in your backyard and probably sell them to those grocery chains. Good chances are, they're not interested. --vadim

10 21

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

10 Nov '96

William Allen Simpson <wsimpson(a)greendragon.com> wrote: >Wasn't there a draft somewhere along the way on a global guidelines on >how to set the metrics? I remeber seeing something like that. However i went further by explicitly separating per-hop metrics into static (administrative) and dynamic (injected from IGP) parts, with an explicit visibility scope for the dynamic part. > If there's any interest i can dig the draft out and place it on my www > server. > >Sure. Ok, it is in http://www.pluris.com/avg/draft-bgpmetric.ps and .txt. --vadim

1 0

RE: Why doesn't BGP thread...
by ALAN DORN HETZEL JR 10 Nov '96

10 Nov '96

It's not a perfect solution, but you might consider applying a weight to the routes received over each link based on the speed (or some arbitrary quality factor) of the link. This will sort of get you what you are describing. -Dorn

1 0

Why doesn't BGP thread...
by Deepak Jain 10 Nov '96

10 Nov '96

Maybe I missed something in the original BGP question, but it sounded much like this. A single router has at least two connections to upstream providers [for arguement sake, different ones]. BGP is used to negotiate the transfer of routing information from their core routers (as opposed to border) into this single router. [There can be multiple single routers in this description, but the idea is that this single router is a border, and the only communications it really passes are internal routing information, not external routing information. This router is not a transit router between any two upstream providers] If there are two paths with the same number of hops, across two different size/speed/congestion level links, BGP makes a somewhat arbitrary decision based on IP address of the interface. I don't think this decision is passed on to other routers in the original question's model. I picture a guy with a T-1 or two, or a 10Mbit FNS connection and a few T1s. If I am wrong, don't waste your time correcting me, just ignore this as I am just looking for clarification of the question; I just want to know whether anything interesting will come out of this thread or not. In this model, this decision is not passed onto other routers [in the sense that this single router will in many cases advertise the same set of routes to both providers] it is just trying to decide which path to send the data down. OSPF [like someone else mentioned] keeps in mind link speed issues and automatically adjusts metrics according to some text book method. [which can be overriden. I think ether is 1000, and FDDI is 100] If this router were to look at the BW setting on each interface, and look at packet loss on each interface, AOTE, I don't see the problem it would cause (either in CPU load, or flapping). Again, in this model, this is not a border router at a NAP, this is a router nicely buried in two or three bigger networks. I don't think we are dealing with an NP complete (Traveling Salesman) type problem either because we are not trying to look very "deep" into the upstream network, just 1 link. And again this is not being propagated to any other routers. Any problems with this model? Of course, if this single router flaps, AND the upstream network provider's customer-connection routers do not have half decent access lists/filter paths on them, lots of problems could arise, but a lot of that is easy to fix. For example, a network A was receiving network B advertisements from one of its customers who also has a connection to network B, network A started using the customer's connection for transit to network B because of this. Filtering customer route announcements is pretty important for security, and flap dampening is essentially just another kind if filtering. Did I miss any issues? -Deepak.

1 0

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

10 Nov '96

It's on CCO. If you can't find it with a search let me know and I'll get you a copy. Donner P.S. Look for the OSPF Design Guide at http://www.cisco.com/warp/customer/104/2.html At 03:59 PM 11/9/96 -0800, you wrote: >Is it on the site? I'd be interested in seeing an OSPF study guide -- >I have a nead to switch from eigrp to ospf. > >Dean > >In message <2.2.32.19961110021917.009a2d88(a)lint.cisco.com>, "Paul G. Donner" writes: >>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 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