August 1998 - Test - lists.nanog.org

Re: MAE-East - Operational question
by Richard Irving 20 Aug '98

20 Aug '98

Communism, *NOT* marxism. Lets see: router> conf t router> int nanog 0 router> no ip directed-communism router> access-group 66 IN router>^z router> router> access-list 66 deny MARXISM router> access-list 66 deny _POLITICS_ router> access-list 66 deny POLITICAL_PARTIES router> access-list 66 permit PHILOSOPHY router> access-list 66 permit IDEAOLOGY router> And now I leave the remainder of this discussion to OFF NANOG. (and your local Poli-SCI PHD) This config doesn't seem to be helping my routing much.... But, in your defense, I am actually saying the opposite of what you *think*. (I am saying it *doesn't* work , but making a distinction between the ideology, and "supposed" implementations going by that name, that *fine grained* distinction *is* the point :( The depths of greed that *some* of humanity exhibit, being the fatal flaw for both plans. (FDDI&COMMUNISM) .) (Darn lasers!) foo wrote: > > Richard Irving wrote: > > *Pure* communism was a great ideaology! However, > > its failure, for the most part, was cited > > as "not accounting for human nature" > > as if. > > that's the most often heard, and most false statement > one can make about communism. > > try actually reading communist literature, and see if > you think marxism is such a great idealogy. > > -foo

1 0

Re: NANOG 14 & wbn Transition
by Sean Donelan 20 Aug '98

20 Aug '98

>wbn Transition >-------------- >I am leaving Merit at the end of the month. After 4 years of evening >classes while working full-time at Merit, I'm planning on taking a few >months off for a much needed vacation, and then move on to something else. Congrats. Welcome to the land of MBA's. May you go forth and earn lots of money :-) And maybe even have some fun. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

NANOG 14 & wbn Transition
by William B. Norton 20 Aug '98

20 Aug '98

Hi all - NANOG 14 will be held November 9-10 (with tutorials on the 8th) at the Atlanta Marriott Marquis 265 Peachtree Center Avenue Atlanta, Georgia 30303 (404) 521-0000 (Voice) (404) 586-6098 (Fax) Be sure to mention the NANOG group when you register at the hotel; the group rate is $149/night. The NANOG 14 registration page is scheduled to go up Friday. wbn Transition -------------- I am leaving Merit at the end of the month. After 4 years of evening classes while working full-time at Merit, I'm planning on taking a few months off for a much needed vacation, and then move on to something else. Craig Labovitz has agreed to join Pam and Susan and run NANOG 14. (With respect to my other responsibilities, Sue Hares will be taking over Directorship of the RSNG Project, and Craig will be leading the community RADB/IRRD project.) All of us will be at IETF next week if you have any questions or concerns; I'll probably see you all there as I troll one last time for NANOG topics. As we enter September: Agenda proposals should be sent to labovit(a)merit.edu and srh(a)merit.edu, Logistics/Vendor Sponsorship questions should be sent to pam(a)merit.edu, Joke submissions (will still be greatly appreciated BTW) should still be sent to wbn(a)umich.edu ;-) You guys have made chairing NANOG the most fun part of my job at Merit. I want to thank you all and wish you the best! Cheers - Bill --------------------------------------------------------------------- William B. Norton <wbn(a)umich.edu> 734.936.2656 (W) 734.662.0748 (H)

1 0

Re: intranet
by Vince Fuller 20 Aug '98

20 Aug '98

> At 05:43 PM 8/18/98 +0800, william(a)pacific.net.ph wrote: ... > >Proposed Solution: > > > >The 7010 router will be connected to the 2 ISPs. The 7010 will be upgraded > >to an IOS that supports NAT; all IP address behind the 7010 will be treated > >as internal IP addresses (to reduce reconfiguration). IP address subnets > >from both ISPs will be NAT-mapped to internal IP addresses over the 7010, > >including the DNS server and the mail server. > > > >The DNS will be configured to use their DNS as the primary name server. > >The 2 ISPs' name servers will be used as secondary name servers. > > > >The mail server will be configured to have 2 IP address, one actual and one > >virtual IP address using the network card. The DNS will have an MX 10 and > >an MX 20, each pointing to one IP addresses for the network card. > > > > > >Is this solution possible? Will it work? Did I forget anything? Any tips? > > That is one way to do it .. another and I think a BETTER way would be to > only use 1 set of ip's ( a set that is "portable" ) and talk bgp with both > providers. This way you can move the traffic in the most efficient way . If > you take routes from both of em you may get a better path to site X from > provider a and a better path to site Y from provider B . > > This way if provider a goes down the BGP will move trafic of the link that > is still "GOOD" The NAT approach has the obvious advantage of being more "CIDR-friendly" to the "global Internet". It is probably somewhat more complicated, but if implemented correctly, it should provide reasonable redundancy and load- sharing just like a "portable" address space solution. --Vince

1 0

ISP Route Filter Policies - please update http://www.nanog.org/fi lter.html
by Kummer, Joerg {PYN~Basel} 20 Aug '98

20 Aug '98

Please contribute to the list on http://www.nanog.org/filter.html by sending mail to mailto:www@www.merit.edu and this mailing list mailto:nanog@merit.edu I'd say the list should not only include hard facts like URLs to ISP publications, but also information like your personal experiences, known issues caused by publicly unconfirmed route filtering etc... Pointers to better sources of such information are also appreciated... thanks joerg P.S. Yes, I have (also) selfish reasons to ask for that...

1 0

BBN peering, a technical issue
by Jerry Scharf 20 Aug '98

20 Aug '98

Having waded through discussions of policy and definitions of transit, I thought I would try to make something more personally interesting out of this thread. Let's say I have coloA, a colo company who wants to go out of it's way to not screw the big carrier B. In fact, I want to move all the packets destined for B on my network as far as I can and then dump it an the peering point closest to B's final destination. They will do hot potato to me, but I want to do the opposite with them. Since we assume A and B are talking BGP, and B is doing it's job of not polluting the internet routing tables, there is most likely not going to be enough prefixes to make this work stock, MEDs or no. How does B send his POP level routing to A? (I make the assumption that the POP level is the closest correspondence to exchange connections.) Does this change if B is using BGP confederations or not? In this case, leaking is not a problem because A is a transit provider for no one and the filters eat all the routes, more specific or less. Are there any downsides to B giving this information to A? sorry, I'll try to keep the technical/operational issues to a minimum, jerry

2 1

Re: intranet
by Dean Anderson 19 Aug '98

19 Aug '98

Another thing you can do is work with a provider in your area that has 2 pops. In Boston, for example, BBN has a Cambridge Pop and a Boston Pop. Their highest service level brings a T1 to each. Presumably, only one Pop would suffer a catastophe that wouldn't be suffered by other providers as well. Of course, the lines run side by side through the customers building and into the street, so we are still subject to the limitation that our construction workers carry saws and don't know how to splice fiber. ;-) --Dean At 10:28 PM 8/18/98 -0400, Chris Gibiault wrote: >That is one way to do it .. another and I think a BETTER way would be to >only use 1 set of ip's ( a set that is "portable" ) and talk bgp with both >providers. This way you can move the traffic in the most efficient way . If >you take routes from both of em you may get a better path to site X from >provider a and a better path to site Y from provider B . ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

More on BBN
by dlr＠bungi.com 19 Aug '98

19 Aug '98

We are planning on additional action to inform the customers and shareholders of BBN about the proposed changes in peering. If your organization(s) would like to participate, please email privately or call me. Dave Rand +1 408 254-7111 -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: The Cidr Report
by Sean M. Doran 19 Aug '98

19 Aug '98

| > B/ When we can easily do: | > | > "router bgp N | > proxy-aggregate route-map Lazy-Types | | I may be misunderstanding, but does this (proposed) config statement | automaticly suppress (aggregate) any prefixes that are exactly the | same as another prefix except in the length? For example given | | 128.8.0.0/16 | 128.8.0.0/24 | 128.8.1.0/24 | | the last two would not be propogated? That would be cool! Right, essentially. This is particularly easy if all the attributes are the same, notably the AS_Path. In IOS there is already a pretty good set of tools to choose what one proxy-aggregates -- and how -- that were developed several years ago; a tool to choose when to apply a set of these would also be useful. One policy that I think would be useful would be: "Does the origin AS announce more than N prefixes? If so, aggregate/drop more specifics as follows..." Sean.

1 0

Dupes and Dates
by Tim Wolfe 19 Aug '98

19 Aug '98

Anyone else seeing messages from Friday the 14th and Saturday the 15th a second time today? Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

9 8