hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (09/28/86)
I have been looking at our EGP routings. I checked a few sites that I know we talk to a lot. Our current EGP peers are yale-gw and css-ring-gw. (We keep a list of possible peers, and the gateway picks 2. It will change if one of them becomes inaccessible. This particular pair seems to be fairly stable.) Here I what I found: CMU: As far as I can see, the only way into CMU is cmu-gateway, 10.2.0.14. The EGP table showed 10.3.0.27, which is gateway.isi.edu. We will hope that ISI would be smart enough to give us a redirect if we actually used this route, but it seems odd none the less. We tried to establish a direct EGP connection with cmu-gateway, but we were unable to acquire them. (In addition to the list of potential peers, our gateway also has a list of secondary gateways, all of which it will acquire. The intent is that these are gateways that are so important to us that we don't want to depend upon the core for information about them.) We have ended up adding a static routing to them. MIT: They seem to have 4 different networks. The ones with direct Arpanet gateways are 18 (using 10.0.0.77) and 128.52 (using 10.3.0.6). EGP was telling us to use 10.3.0.27 (isi) and 10.2.0.37 (purdue) respectively. Fortunately, we were able to acquire both of MIT's gateways, so I am simply going to list them as secondary gateways. Stanford: It appears that the only reasonable route to network 18 is stanford-gateway, 10.1.0.11. Our EGP table was telling us to use 10.2.0.37 (purdue-cs-gateway). We were able to acquire the stanford gateway, and have also added them to our list of secondary gateways. Am I doing something wrong? Here is the relevant portion of our current configuration file. I confess that I do not know where the list of primary neighbors came from. It seems to have been developed by one of our systems staff after numerous dealings with the Network Operations Center trying to diagnose problems. Note that the gateway itself is Cisco Systems' commerical version of the Stanford Arpanet gateway. It is based on a 68000, with an ACC 1822 card. This code has probably not been used many places outside of Stanford, so it is certainly possible that there are problems left with it. But it gives every appearance of doing the right thing. primary-neighbors 2 egp-neighbor 10.7.0.63 46 primary ! bbn-net2-gateway egp-neighbor 10.2.0.37 46 primary ! purdue-cs-gw egp-neighbor 10.0.0.94 46 primary ! wisc-gateway egp-neighbor 10.3.0.27 46 primary ! isi-gateway egp-neighbor 10.0.0.25 46 primary ! css-ring-gw (seismo) egp-neighbor 10.0.0.9 46 primary ! harvard-gw egp-neighbor 10.1.0.51 46 primary ! sri-prm-gw egp-neighbor 10.1.0.54 46 primary ! cit-cs-gw egp-neighbor 10.2.0.9 46 primary ! yale-gw # talk directly to our friends, since these tend to have bogus routes egp-neighbor 10.0.0.77 46 ! mit-gw, for net 18 egp-neighbor 10.3.0.6 46 ! mit-ai-gw, for net 128.52 egp-neighbor 10.1.0.11 46 ! stanford-gw, for net 36 # I can't get cmu-gateway to respond to EGP, so do it statically route 128.2.254.36 10.2.0.14 ! cmu-gateway, for net 128.2
MRC@SIMTEL20.ARPA (Mark Crispin) (09/29/86)
The funny EGP stuff isn't in cisco's gateway; my TOPS-20 EGP gets the same sort of garbage. Fortunately, *most* of the gateways *will* redirect. I think the mailbridges are the principle culprit. Dave Mills can probably give you a complete description of what is wrong and why. -------