MRC%PANDA@SUMEX-AIM.STANFORD.EDU (Mark Crispin) (11/13/86)
Some of you may be interested in the following EGP topology, which I got back from my favorite gateway, 10.1.0.15. Note that 10.2.0.80 thinks that network 127 is 3 hops away. What the hell is network 127??? -- Mark -- [Network topology for network 10 12 interior gateway(s), 0 exterior gateway(s) Gateway at 1.0.15: Network(s) 0 hop(s) away: 128.43 Network(s) 1 hop(s) away: 192.12.215, 192.5.144, 192.12.62 Gateway at 2.0.80: Network(s) 1 hop(s) away: 26 Network(s) 2 hop(s) away: 128.47, 192.5.9, 128.44, 6, 192.12.33, 192.12.128, 128.26, 192.5.38, 192.12.131, 128.25, 192.5.92, 128.21 Network(s) 3 hop(s) away: 192.12.29, 192.12.30, 128.29, 192.5.26, 192.5.21, 128.20, 128.3, 128.60, 192.5.23, 192.5.22, 192.5.25, 192.12.139, 192.12.119, 128.8, 128.115, 192.12.124, 192.5.52, 192.12.196, 128.63, 128.102, 192.5.16, 192.12.184, 128.122, 128.38, 192.12.120, 192.12.64, 127, 192.12.15, 128.49 Network(s) 4 hop(s) away: 128.155, 192.16.14, 192.12.65, 192.12.31, 192.5.47, 192.5.218, 192.5.65, 192.16.7, 192.12.125, 192.12.13, 192.16.16, 128.54 Network(s) 5 hop(s) away: 128.165 Gateway at 5.0.5: Network(s) 2 hop(s) away: 192.12.172 Gateway at 2.0.5: Network(s) 1 hop(s) away: 8, 128.11, 128.89 Gateway at 2.0.25: Network(s) 1 hop(s) away: 4 Gateway at 3.0.27: Network(s) 1 hop(s) away: 128.9 Network(s) 2 hop(s) away: 7, 128.4, 35, 192.5.39, 28, 128.6, 18, 128.2, 192.12.19, 192.12.18, 192.5.7, 192.5.11, 192.12.141, 192.5.14, 128.31, 128.170 Network(s) 3 hop(s) away: 192.5.28, 192.5.29, 128.39, 128.16, 128.98, 128.124, 128.149, 192.12.9, 128.97, 192.5.55, 128.121, 192.5.165, 192.5.56 Network(s) 4 hop(s) away: 192.10.41, 192.5.57, 192.5.148 Network(s) 6 hop(s) away: 128.117, 192.17.5, 128.5, 192.5.146, 192.12.207, 128.135 Gateway at 1.0.28: Network(s) 1 hop(s) away: 192.5.18 Gateway at 2.0.37: Network(s) 1 hop(s) away: 192.5.48 Network(s) 2 hop(s) away: 128.10, 128.83, 192.5.104, 128.32, 128.104, 192.12.220, 192.12.12, 192.5.2, 128.136, 192.5.10, 192.5.37, 192.5.53, 192.12.5, 192.5.58, 192.5.69, 128.101, 128.91, 128.125, 128.110, 128.95, 128.52 Network(s) 3 hop(s) away: 128.105, 192.12.44, 128.42, 192.16.72, 192.5.49, 192.12.221, 192.5.40, 192.5.19, 128.140, 192.12.63, 192.16.73, 128.81, 192.10.42, 192.12.56, 128.139, 128.99 Network(s) 4 hop(s) away: 192.12.185, 192.12.69, 128.112, 192.5.101, 128.96 Network(s) 5 hop(s) away: 128.46 Gateway at 5.0.51: Network(s) 1 hop(s) away: 128.18 Gateway at 5.0.63: Network(s) 1 hop(s) away: 14 Gateway at 7.0.63: Network(s) 1 hop(s) away: 192.1.9 Network(s) 2 hop(s) away: 192.1.2, 128.30, 36, 128.84 Network(s) 3 hop(s) away: 192.1.4 Network(s) 4 hop(s) away: 192.12.91 Gateway at 2.0.9: Network(s) 1 hop(s) away: 128.36 Network(s) 2 hop(s) away: 192.5.88 Network(s) 4 hop(s) away: 192.12.81, 192.16.167 ] -------
brescia@CCV.BBN.COM (Mike Brescia) (11/14/86)
> Some of you may be interested in the following EGP topology, which I got > back from my favorite gateway, 10.1.0.15. Note that 10.2.0.80 thinks that > network 127 is 3 hops away. What the hell is network 127??? Net 127, an unregistered net number, is used by Berkeley in the 4.xBSD unix to indicate the 'loopback interface' internal to the host. It has in the past been advertised by some hosts which run EGP and accidently have the loopback address listed first in the configuration of the net interfaces in the unix. It is happening again at NLM-MCS. The 'core' system, while providing some protection to itself, does not censor any information, but passes this on to the other gateways, and thus to the other EGP sites. It probably causes a bit of confusion on any vaxes which run EGP and are trying to use their own loopback interface. (I've deliberately tried to eschew any biased statements above, but had to get this self-referent, biased sentence in.) Mike Brescia Gateway Censor.
rick@seismo.CSS.GOV (Rick Adams) (11/14/86)
Network 127 is everyones favorite bogus network! It's used as a loopback network by many BSD UNIX systems. It should never be exported, but sometimes leaks occur. ---rick
JJW@SAIL.STANFORD.EDU (Joe Weening) (11/14/86)
Page 6 of the new "Assigned Numbers" (RFC 990) explains that
The class A network number 127 is assigned the "loopback"
function, that is, a datagram sent by a higher level protocol
to a network 127 address should loop back inside the host. No
datagram "sent" to a network 127 address should ever appear on
any network anywhere.
I hadn't seen this announced before, but apparently the de facto
standard use of this number has become official, and someone is
therefore violating the standard. Time for the protocol police
to start an investigation ...
Joekarels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) (11/14/86)
The error that causes net 127 to be advertised (other than not using a better address for loopback "interfaces") is a confguration error for Kirton's EGP. The egp configuration file should always list the "egpnetsreachable", and the list should not include 127. Otherwise, the EGP process looks up everything it can find on the local machine. Any address (even an officially assigned one) can be used for the loopback with 4.3; it's set just like any other address. (But now I note in jjw's reply that 127 is official; I guess everyone is required to implement it.) Mike
GOWER@A.ISI.EDU (Neil E. Gower) (11/14/86)
In Mark's message about the toplology as seen from the point of view of 10.1.0.15, the following entry appeared. Gateway at 5.0.5: Network(s) 2 hop(s) away: 192.12.172 I am really confused because our network (192.12.172) is attached directly to the ARPAnet (10) via a GW at 10.1.0.46. Does the fact that the table shows that we are 2 hops (whatever that means) behind the BBN MIL-ARPA GW explain why we (in Texas) have a hard time getting to the West coast? Are we going through the East coast to get there? Or is this just a mirage which is necessary for the EGP/GGP stuff to work? Or a result of the shortage of table space in the GWs? Neil Gower -------
braden@ISI.EDU (Bob Braden) (11/14/86)
The error that causes net 127 to be advertised (other than not using a better address for loopback "interfaces") is a confguration error for Kirton's EGP. The egp configuration file should always list the "egpnetsreachable", and the list should not include 127. Otherwise, the EGP process looks up everything it can find on the local machine. Mike, It would seem that a program that allows a configuration error to cause public mischief has a bug. Since "Kirton's EGP" is effectively part of the BSD distribution, can we hope that this bug will be fixed? Bob Braden
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (11/15/86)
Hi. This is a canned message. My apologies for not sending a personalized reply, but this question gets asked once a month and I got tired of typing the same message. (An MIT hacker defined 'Hell' as 'answering the same bug report over and over again'.) It was answered most recently on: Fri 3 Oct 86 01:48:28-EDT Fri 31 Oct 86 16:03:42-EST You have asked a question about the infamous 'extra hop problem'. The problem is not caused by EGP, which is telling you exactly what the gateway you are a neighbour with is doing itself with packets to given destinations, but the routing protocol (GGP) which is used by the core gateways among themselves. It predates EGP, was not designed with the pattern of information flows that you see in EGP in mind, and is the cause of the problem. As a brief example of the problem, if MIT has core gateway A as an EGP peer, and Berkeley has a peer core gateway B, then there is no way (using GGP) for A to inform B that to get to MIT it can go direct; both B and all its clients (e.g. Berkeley) think they have to go through A. This is the cause of the funny routes to places you ought to be able to get to directly, etc. Your gateway is just fine, and it's not EGP's fault either. The extra hop problem will only be solved when GGP is retired; i.e. when the PDP11 core gateways are replaced by Butterflys, probably. When GGP is replaced the problem will magically disappear without any changes to EGP. For a more detailed explanation of the problem, look in the TCP-IP archive for a message I sent out at Thu 6 Mar 86 18:16:01-EST which goes into great detail. (No, I do not know how to access the TCP-IP archives, so don't send me mail asking for it; I'll ignore your message. If someone from the NIC sends me the appropriate info, I'll happily insert it here.) Just out of interest, were you on TCP-IP then? Noel -------
SRA@XX.LCS.MIT.EDU (Rob Austein) (11/16/86)
Date: Thursday, 13 November 1986 23:20-EST
From: karels%okeeffe@BERKELEY.EDU (Mike Karels)
Any address (even an officially assigned one) can be used for the loopback
with 4.3; it's set just like any other address. (But now I note in jjw's
reply that 127 is official; I guess everyone is required to implement it.)
I got the impression that this was a more along the lines of
allocating the network number so that nobody would try to use it for
anything else (because there will probably always be broken machines
that leak this address). I certainly didn't read it as an imperative
that all TCP/IP implementations go out and implement loopback on this
address.
If anybody else read this the way Mike did I guess we need a
clarification from the Number Czar.
--RobMILLS@A.ISI.EDU (11/17/86)
In response to the message sent 13 Nov 86 16:20:28 EST (Thu) from brescia@ccv.bbn.com Marc, Well, what we have here is the famous Martian, which would be even more famous if some gateways (not the core gateways) didn't censor them. While I don't fault the Gateway Censor for not coming down on X-rated packets (I think it's ugly to have to do that), we get a lot more flotsam way up here on the NSFnet bayous. Dave -------
karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) (11/18/86)
Well, yes, as a matter of fact I've already fixed this bug locally. The bug and a fix were also reported on egp-people some time back. I fixed it somewhat differently, in a way which doesn't depend on the loopback network of 127. I'm updating the copy on ucbarpa for anonymous ftp. The notes and an example configuration file have also been updated. The three modified files are in pub/4.3/egp-update.tar on ucbarpa.berkeley.edu. Mike