- NANOG - lists.nanog.org

RADB based filters
by Justin Newton 08 Jan '98

08 Jan '98

Hi all, I was wondering what those of you who are doing RADB/MCI-RR/ANS RA filtering were doing about large networks which do not register their networks in the RADB. It would seem unwise to simply trust their announcements, and even more unwise to simply ignore their announcements, so... Whats the common parctice in this scenario?

3 2

RE: ATM --> HSSI
by Chad Skidmore 08 Jan '98

08 Jan '98

Try the ADSU from ADC Kentrox. Assuming that it is a DS-3 loop. --------------------------------------------------------- Chad Skidmore Director of Network Engineering Northwest Nexus, Inc. http://www.nwnexus.com 1-888-NWNEXUS -----Original Message----- From: andrew khoo [mailto:andrewk@aussie.net] Sent: Monday, January 05, 1998 9:15 AM To: nanog(a)merit.edu Subject: ATM --> HSSI what box can i use to convert PacBell ATM (for PacBell NAP) into HSSI? ============================================================== andrew khoo - rebel leader aus: +61-2-9223-2777 Ourworld Global Network, Australia usa: +1-415-902-8820 ============================================================== -- We Bite (tm) --

3 2

Newbie question.
by Jim Bachesta 08 Jan '98

08 Jan '98

I'm a network engineer coming up to speed on BGP. I'm currently not running BGP on my router. Are there any tools that will allow me to monitor BGP passively? Any pointers is appreciated. Jim Bachesta bachesta(a)photodisc.com Voice: 206-728-7781 Pager: 206-978-0336 Cell: 206-714-7330

4 3

Re: Things to do to make the network better
by Havard.Eidnes＠runit.sintef.no 08 Jan '98

08 Jan '98

> > Doing this on the customer border routers appears to me to be the > > obviously right place. > > Can you trust the customer border router? I personally don't. Hm, this is probably caused by terminology confusion. When I say "customer border router", I am referring to your router having the interface towards your customers, not a router owned by the customer. - Håvard

1 0

NANOG 12 INFO
by Pam Ciesla 08 Jan '98

08 Jan '98

The attendee list has been posted to the NANOG Webpage http://www.nanog.org. Please check this out. If you are not on the attendee list and should be please contact me. Please book your hotel reservations early the hotel block on rooms expires on 1/25. Hotel info available at http://www.ihighway.net/nanog/ Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Re: Things to do to make the network better
by Havard.Eidnes＠runit.sintef.no 08 Jan '98

08 Jan '98

> We have routers with ISDP PRI links, where the routing > information arrives from RADIUS via a CHAP login. There are 600 > routed objects in the RADIUS database, as well as 10k+ > non-routed (dynamic IP) objects. Every ISDN router therefore > has a potential 600 directly attached neighbors; although no > router has more than 60 links at any one time. Some common > equipment may handle this just barely; other is wholly > inadequate. It sounds to me like what you would really like was something akin to the "RPF check" as done on multicast traffic for unicast traffic on your customer routers, perhaps as a per-interface option. If this feature existed you would not accept a packet from a given source and incoming interface unless the box in question has a route for the source pointing back out the same interface. That way you would not get the administrative burden of maintaining access lists and ensuring they're always in synch with the local view of the routing system. Doing this on the customer border routers appears to me to be the obviously right place. Doing this in a place where asymmetrical routing is the norm (as appears to be the case in the current backbones) is obviously a non-starter. I think this has been mentioned several times to various providers in the past without this feature materializing, but one can still hope. (It's not unconceivable that the current access products have not been engineered with sufficient CPU resources to be able to even perform this task...) - Håvard

2 1

Re: route ingress
by Sean M. Doran 08 Jan '98

08 Jan '98

Vadim Antonov <avg(a)pluris.com> writes: > I quite agree with that (though i'm not convinced that "bottom->top" > allocation combined with recursive NATting is the best architecture). Randy Bush once made the comment that I live in a number of possible future Internets. These are two possibilities, not one. The variable-length bottom->top hierarchical network addressing scheme I prefer eliminates the need for translation of transport addresses. The hard work is in resolving endpoint name to transport address. NAT is only needed in the case where address uniqueness and routability is not inherently guaranteed by the transport addressing structure. Recursive NAT is only needed in the case where the size of a catenet is such that a number of intercommunicating NAT-using routing super domains in aggregate use more than the entire available address space. NAT buys us the time to investigate technologies considerably different from IP while retaining IP as the lingua franca. Recursive NAT buys time in the face of people who try to make the argument (since demolished by HWB's graphics, I think, yes?) that we really are under pressure to increase the number of potentially addressable things. > However, this does not preclude doing authentication with the current > routing system. Yes, I agree completely. However the current routing system sure doesn't make doing that easy. Sean.

1 0

Re: route ingress
by Sean M. Doran 08 Jan '98

08 Jan '98

"John A. Tamplin" <jat(a)Traveller.COM> writes: > I don't understand how the current top-down allocation affects how that > would be done. This is a very broad issue so i will oversimplify. Right now, in order to verify that a particular prefix is being announced properly, one has to be able to associate the prefix with the announcer in two directions. Firstly, one has to walk a tree of registries from the root towards the announcement to make sure the address has been allocated correctly. This means that registries from the root down have to keep some sort of credential scheme for each entity to which it has allocated addresses, and moreover, that those credentials are carried in routing announcements, which is interesting when you consider aggregation. Secondly, one needs a routing registry which indicates that the route has been announced following the proper policy. Then, when you hear an announcement you have to walk back through the policy tree to ensure that not only the policy as registered was followed but also you need to check processing credentials to make sure people aren't faking up a remote AS-to-AS adjacency, for example. With a bottom up allocation scheme, assuming something like IS-IS on steroids as the Internet-wide routing protocol, where there is a flat-routed (or locally-interpreted) part on the extreme right and the address grows leftwards away from the originating area, one does not have to go to a registry to check whether a particular network should be originating a particular address. Moreover, routing will be hierarchical in nature, in verifying policy one will generally make use of a tree of trust in verifying the processing signatures, although one can ask each area recursively if it had intended the announcement to its adjacent (parent or child) area. Policy in a hierarchical network where addressing strictly follows topology will be simpler to describe even in the presence of unusual constraints, and therefore the verification work will be simpler. Moreover, at a distance, all you want to do is verify the presence or absence of an area to area adjacency rather than the presence or abence of a large number of global prefixes. Finally, all you need is a database of unique area-id to credentials, rather than a hierarchical database of prefix-to-entity/entity-to-credential scheme. > As I see it (and I haven't spent any significant time > working on it, but it seems straightforward): > 1) ARIN/whoever signs an address allocation to an entity To make it clearer, try working on defining "whoever". > 2) that entity signs route announcements to peers/upstreams, incuding > who they are announced to What do you do about aggregation, both atomic and proxy? What do you do about pieces of an aggregate when they appear, or more importantly, when they do not appear? > 3) readvertisements are signed by the advertiser What do you do if there is a transient change in topology such that the chain of announcers differs substantially? For instance, suppose you see an AS path of A B C D E for a particular prefix, and later you see F G H I E? How do you know this announcement is correct and should be believed? > Any recipient of a route can verify that the address space was properly > allocated by inspecting the address allocation certificate and verifying > the signature of the registry, and they can verify the path that > advertisement has taken to get to where it is. Thus no one can interject > a route to a network prefix that is not properly allocated, and someone > cannot steal a route advertisement for someone else's prefix. The biggest > problem with something like this is the size of the routing table in > memory (since you have to keep certificates around for readvertisements) > and in the bandwidth required for the updates. Ok, so suppose someone somewhere announces 128.100.251/24. Walk the decision tree of a number of routers, notably ones at big exchange points, or ones at smaller multihomed networks a couple of ASes away from some of the big networks, and tell me what you think needs to happen. Then make it more fun: deaggregate 9/8 at the /24 (or the /30) level and announce it around, or try announcing huge swaths of address space programattically with a modified gated (for example). Where is the huge wave of announcements caught and dealt with, and what has to cope with such a flood of announcements? > I am not familiar with NIMROD, do you have a pointer to it? It's in the usual place for IETF working groups, and specifically http://www.ietf.org/html.charters/nimrod-charter.html is what you want. The likliest evolutionary direction of the Internet now is something like NIMROD married to MPLS (another IETF WG) with translation between the new stuff and old IPv4 hosts (and to-be-considered-old IPv6 hosts) close to the edges of the Internet. Sean.

1 0

exodus?
by Alex "Mr. Worf" Yuriev 08 Jan '98

08 Jan '98

Hi, For about 10 hours we have been having trouble reaching someone at Exodus through the NOC who can properly re-configure their sessions (we're seeing no-next-hop garbage, and our routes are not being preferred). Can someone from Exodus please contact us? Thanks, Alex Net Access NOC 215 864-2360

1 0

mci-rr
by jamie＠intuition.iagnet.net 08 Jan '98

08 Jan '98

Anyone getting similar problems? Message 83/84 Mail Delivery Subsystem Jan 7, 98 04:06:04 pm -0500 Postmaster notify: Cannot send message within 5 days Return-Path: <> Date: Wed, 7 Jan 1998 16:06:04 -0500 (EST) Auto-Submitted: auto-generated (postmaster-notification) [Attach #1: ""] [Type: text/plain, Encoding: 7bit, Size: 370] The original message was received at Fri, 2 Jan 1998 15:45:24 -0500 (EST) from localhost ----- The following addresses had permanent fatal errors ----- <mci-rr(a)RR.mci.net> ----- Transcript of session follows ----- <mci-rr(a)RR.mci.net>... Deferred: Connection timed out with rr.mci.net. Message could not be delivered for 5 days Message will be deleted from queue -- james g.k. rishaw dal/efnet:gavroche __ IAGnet/CIC/netILLINOIS Backoffice DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 "The man who doesn't read good books has no advantage over the man who can't read them." - Mark Twain

2 2