- Test - lists.nanog.org

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

RE: BBN Peering issues
by Martin, Christian 19 Aug '98

19 Aug '98

>You play engineering and revenue as a dichotomy when in fact >it is a duality. In the "real world" that you like to refer >to, it is more of a symbiotic relationship. Though it would >be nice to be aloof in a lab and be lavishly compensated, I would >venture to say that such a situation is not the norm. >Let us get one point understood. You deserve nothing more than >you pay for. You were not, by merit of your diction, infrastructure, >prowess, or mandate from heaven, conferred a right to the >resources of another individual or conglomeration of individuals. >If you abhor these paper-pushers so, you are more than able to >find the capitalisation to finance a global altruistic >network where anyone can peer with anyone and we will all get along. >It will be akin to the communes of the 60s. We can just >hallucinate until the reality evaporates. > >BR "Well said, well spoken." -Irwin Fletcher (AKA Fletch (AKA Chevy Chase))

1 0

Cisco CC images and SMTP access-lists
by Martin, Christian 19 Aug '98

19 Aug '98

Has anyone noticed problems with NetFlow enabled interfaces having difficulty handling SMTP access-lists? ICMP works fine, as well as as-path lists, but we are seeing SMTP traffic passing lists as if they don't exist. --Chris

1 0

RE: Smurf Attack Reporting?
by Martin, Christian 19 Aug '98

19 Aug '98

http://www.powertech.no Regards, Chris -----Original Message----- From: Jason Weisberger [mailto:jweis@softaware.com] Sent: Tuesday, August 18, 1998 3:13 PM To: nanog(a)merit.edu Subject: Smurf Attack Reporting? Where is the central repository these days for reporting a fairly large Smurf attack? Who is running the blackhole list? -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275 "Trust in God and fear nothing." --Gen. Lewis A. Armistead

1 0