- Test - lists.nanog.org

Load sharing on BGP on C75xx
by Pascal Petit - SYNET 12 Nov '97

12 Nov '97

Has anyone experienced load balancing on C75xx using BGP. I have noticed that 11.2 introduce multipath support, however I was wondering about performances ... Is it done at Optimal Switching level ? Thanks for sharing any type of experiences as multipath BGP, asymetric traffic on two links, .... ------------------------------------------------------------------------ Pascal Petit SYNET tel: 33 1 4696 0040 74, rue Roque de Fillol fax: 33 1 4696 0041 92800 Puteaux email: ppetit(a)synet.fr FRANCE http://www.synet.fr

1 0

Re: I don't want to crash the 'net
by gary flynn 12 Nov '97

12 Nov '97

> From: Sheryl Chapin <schapin(a)ctel.net> > > So if anyone has any advice, caveats, pointers to docs, > things I absolutely should do or things I absolutely > shouldn't do, I would be EXTREMELY grateful. Sheryl, I recently went through the same learning experience and found the following document very helpful when combined with the references you already listed: Internet Routing Architectures Bassam Halabi Cisco Press/New Riders Publishing Besides applied theory, it contains practical approaches to solving various realistic problems including the whys, the alternate solutions, and related Cisco IOS commands. My copy doesn't have an ISBN number. I think I got it from www.amazon.com (but it may have been Borders). It helped me a lot in making our previous T1 link a backup to our new primary DS3 link. Its worked twice although I think there are still some problems because the BGP table revision keeps incrementing. Nobody's complained of any flaps though. (anyone can take this as an open invitation to complain or suggest fixes <GRIN>) AS 10357 Gary Flynn Network Analyst James Madison University

1 0

I don't want to crash the 'net
by Sheryl Chapin 12 Nov '97

12 Nov '97

Hi all, First, an apology if this is off topic. A (brief) intro/explanation. My name is Sheryl Chapin. I am the network administrator for a startup ISP in Maine. I would say that I am the sr. network admin, except I am the *only* network admin. I have 18 years expierience in computers, 10 years with Unix and 3 with Cisco routers. I am not a programmer, I am a system and network administrator. My topology: I have two 7513's in two different cities in Maine: Portland and Winthrop. They are connected via a T3. I have a T3 connection to UU Net from Portland and in a week I will have a T3 connection to AGIS from Winthrop. I have a *very* basic BGP configuration running on the Portland router right now. What I need is some practical help/advice on how to configure my routers once AGIS is also connected. I want to be able to load balance and I would like to do it without crashing a major portion of the internet. I have been reading everything I can find on BGP, Avi Freedman's columns and web pages have been extremely helpfull, but the Cisco documentation just gives me a headache. I am not a stupid person, but I am willing to admit that I have never done this level of configuration before. I figure I can either ask for some help and look stupid or crash the internet, and quite frankly, I would rather look stupid then do something stupid. (Mr. Freedman's columns do a really good job of putting the fear of God into someone just starting out with BGP :-) Part of my problem is the documenation does a good job of giving me syntax, but not of explaining WHY I should or should not do something. For example, UU Net gave me configuration commands for turning on BGP which included a "redistribute connected" command. Someone else from another ISP here in Maine (that we are co-locating with) told me not to use it. Now I know what the redistribute command does, I just haven't found anything anywhere to explain what the pros and cons are for using it. How does it affect the routing? I really work better when I understand how things work. So if anyone has any advice, caveats, pointers to docs, things I absolutely should do or things I absolutely shouldn't do, I would be EXTREMELY grateful. If this is just totally off topic, again, my apologies. Thanks for your time. Sheryl Chapin CommTel Internet 207.377.3508 schapin(a)ctel.net

3 2

Re: Potentially dangerous Pentium bug disc
by sob＠academ.com 12 Nov '97

12 Nov '97

I tested the test program (using both signed and unsigned char) on Pentium Pros running BSD/OS 3.0 and got "illegal instruction, core dumped" and no hang. On regular Pentiums running the same OS, I got the hang. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Announcing new route (What besides BGP?)
by Joe Provo - Network Architect 12 Nov '97

12 Nov '97

[snip] > > use. Or, if it has been replaced/supplemented with something else. Is > > there a FAQ I should have bookmarked which contains this information? Or, > > if there isn't could someone point me in the right direction? > > Half of the information in the raddb is outdated and erroneous. That's a bogus statement. The ANS stats show a very good picture, albeit from their perspective, of how much/little error there is. If you look at many MLPAs, newer Bi-lats, BGP requirements for downstreams to be turned up, etc, you'll see people requiring IRR registration. Joe Provo -- Joe Provo, Network Architect 508.229.8400 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

2 1

Re: Inbound prefix filters
by Bradley Reynolds 12 Nov '97

12 Nov '97

On Tue, 11 Nov 1997, John A. Tamplin wrote: > Actually, I view it the other way. If someone is announcing routes for one > of our prefixes, connectivity is at least partially broken for that prefix, I think the whole point of filtering is that you will not send packets to that newly announced route. You can access-list it and if you suddenly see matching on some deny, then you can investigate at somewhere like nitrous and figure out who is announcing what. In general, I would not be willing to sacrifice the performance of the people who are paying me m0ney just to be able to quickly? ascertain who is causing the problem. > BTW, this has happened to us twice, and both times the offender was a > direct competitor in one of our local markets. Does anybody have any > feel for how often these "accidents" are not accidents? > Time to slap the kiddies for playing with daddy's router. brad reynolds ber(a)cwru.edu "Faith: not wanting to know what is true." -- Friedrich Nietzsche

1 0

IPv8 < IPv6
by Jim Fleming 12 Nov '97

12 Nov '97

Thanks for the responses to my IPv8 note. In case people missed the point, IPv8 addresses are smaller than IPv6. Here are the sizes. IPv4 - 32 bits IPv6 - 128 bits IPv8 - 43 bits (3+8+32) There is a natural routing hierarchy with IPv8 addressing....8 regions, 256 distribution centers in each region and full 32 bit Internets from there. IPv8 addresses can fit inside the IPv6 address fields. ==== Now...back to the point...NANOG people have the opportunity to help the Internet Community with Address Management and Governance. The specific protocol header is not nearly as critical as a coherent addressing plan that takes routing into consideration and quality of service. I suggest that people learn to manage 43 bit addresses before they try to deal with 128 bit addresses. It does little good to have huge addresses if people can not route packets from A to B because the Address Management is chaotic. NANOG people can help to bring order to the chaos that larger addresses can bring. Jim Fleming Unir Corporation IBC, Tortola, BVI

6 15

Hello? This one is wierd.
by Alex Rubenstein 12 Nov '97

12 Nov '97

Is this legal? traceroute to www.japan.net (204.68.24.180), 30 hops max, 40 byte packets 1 nac-nyc1-fa0-100Mb (207.99.0.201) 1.648 ms 1.063 ms 0.765 ms 2 e9-0.border1.nyc1.genuity.net (207.240.48.49) 1.569 ms 1.922 ms 4.960 ms 3 f6.core1.nyc1.genuity.net (207.240.1.81) 1.606 ms 1.737 ms 2.747 ms 4 core1.wdc1.genuity.net (207.240.0.25) 6.691 ms 8.987 ms 10.889 ms 5 h1.peer1.wdc1.genuity.net (207.240.1.246) 8.311 ms 10.539 ms 9.257 ms 6 maeeast.acsi.net (192.41.177.108) 8.230 ms 8.514 ms 8.878 ms 7 columb-sc-1-a12-0.acsi.net (206.222.97.1) 20.543 ms 22.417 ms 18.487 ms 8 greenv-sc-1-a12-0.acsi.net (206.222.97.5) 27.777 ms 27.418 ms28.025 ms 9 little-ar-1-a12-0-1.acsi.net (206.222.97.2) 60.061 ms 54.746 ms 55.946 ms 10 fortwo-tx-1-a12-0.acsi.net (206.222.97.6) 55.008 ms 61.942 ms 63.695 ms 11 904.Hssi4-0.GW1.HOU1.ALTER.NET (157.130.128.25) 60.870 ms 58.826 ms 61.469 ms 12 321.atm1-0-0.cr1.hou1.alter.net (137.39.21.109) 63.880 ms 57.682 ms 62.116 ms 13 112.ATM8-0-0.CR1.ATL1.Alter.Net (137.39.31.5) 201.734 ms * 72.052 ms 14 311.ATM6-0-0.SR1.ATL1.Alter.Net (137.39.21.73) 69.777 ms 71.955 ms 72.176 ms 15 h14-1.t104-0.Atlanta.t3.ans.net (140.223.65.18) 100.501 ms * 102.249 ms 16 h13-1.t64-0.Houston.t3.ans.net (140.223.65.13) 107.077 ms 99.397 ms 109.687 ms 17 h13-1.t80-1.St-Louis.t3.ans.net (140.223.25.14) 98.975 ms 99.187 ms 101.531 ms 18 h11-1.t24-0.Chicago.t3.ans.net (140.223.25.21) 115.362 ms 103.821 ms 93.777 ms 19 * h13-1.t96-0.Denver.t3.ans.net (140.223.25.18) 125.611 ms 125.056 ms 20 f1-0.c96-10.Denver.t3.ans.net (140.222.96.197) 123.094 ms 130.940 ms 124.054 ms 21 enss3336.t3.ans.net (207.25.224.18) 127.490 ms 123.043 ms * 22 * * * 23 * * *

5 4

IP Forwarding
by Tom Hubina 12 Nov '97

12 Nov '97

Hi all... I've been lurking here for a while, and realize that I really don't know much about the innards of networking, but I do have a question I was wondering if you could answer. If I'm in the wrong place, flame me, kick me, do whatever :) We have customers in Europe who need to download large (10 Meg+) files from us on an almost daily basis. They are all on ISDN or other low bandwidth dial-up so it takes them quite some time, if they are even succesful at all. At first glance a mirror site doesn't appeal to us since we have very frequent updates and need to provide security with frequent new user adds and changes. For now we've been living with the slow speeds and dropped transfers, but here's what I was wondering: Could a domain name be set up in Europe to point to a machine in Europe on a global service providers net (PSINet for instance). All this machine does is forward packets to a machine at our location on the same network (PSINet). The whole point of this would be to avoid overcrowded peer points where a lot of our current packetloss appears to be coming from. Does this idea have any merit, or would I simply be exchanging one problem for another? Would it even work at all? Is there a better solution that would increase our connection quality to Europe while keeping the server at our location? Thanks for your time. ---------------------------- Tom Hubina tomh(a)gibbsnc.com Gibbs and Associates 805-523-0004 ----------------------------

1 0

Re: Geographic v. topological address allocation
by Sean Donelan 11 Nov '97

11 Nov '97

Either geographic or topological address assignment will work. What works 'better' (I won't say 'best') depends on so-called externalities. In today's Internet the sender's provider keeps all the money. The sending provider wants the traffic off the sender's network as quickly as possible and onto the destination's provider network. In this case the goal is to minimize usage of the sending provider's network, so you want address assignment based on the destination provider, so you can find the nearest destination provider gateway from the source. On the other hand, lets assume a different economic model. If instead the sending provider had to pay the destination provider based on the mileage (e.g. V&H coordinates) between where the sending provider gives the traffic to the destination's provider and the final destination, the sender would want to carry the traffic as close to the destination as possible, assuming that its less expensive for the sender to use its facilities than to pay to use someone else's facilities, and hand the traffic to the destination's provider at the last possible gateway. In this case, the goal is to minimize mileage charges on the other provider's network, so you want the address assignment based on geography, so you can find the closest sending provider gateway to the final destination. The clunker in most models is traffic flows in both directions, and money also exists at both ends. Neither model is very good at global optimization of traffic or the money. Even having a single payer and single provider, such as was used in the NSFNET, resulted in sub-optimal use in some cases due to yet other externalities. What's interesting is as a provider's network reaches different sizes, different types of optimization become more desirable. And, yes, both styles of addressing can be used to make it difficult for competitors to enter the market.

2 1