rfc911.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,136 行 · 第 1/4 页

Network Working Group
Request for Comments: 911






                      EGP GATEWAY UNDER BERKELEY UNIX 4.2



                                  PAUL KIRTON


       University of Southern California, Information Sciences Institute
     Visiting Research Fellow from Telecom Australia Research Laboratories

                                22 August 1984











                                   ABSTRACT

This  report  describes an implementation of the Exterior Gateway Protocol that
runs under the Unix 4.2 BSD operating system.  Some  issues  related  to  local
network configurations are also discussed.



Status of this Memo:

This  memo describes  an implementation of the Exterior Gateway Protocol  (EGP)
(in that sense it is a status report).  The memo also discusses  some  possible
extentions  and  some  design  issues   (in that sense it is an invitation  for
further discussion).  Distribution of this memo is unlimited.



    Funding for this research was provided by DARPA and Telecom Australia.

RFC 911                                                                       i


                               Table of Contents

1. INTRODUCTION                                                               1

1.1 Motivation for Development                                                1
1.2 Overview of EGP                                                           2

2. GATEWAY DESIGN                                                             4

2.1 Routing Tables                                                            4
     2.1.1 Incoming Updates                                                   5
     2.1.2 Outgoing Updates                                                   5
2.2 Neighbor Acquisition                                                      6
2.3 Hello and Poll Intervals                                                  6
2.4 Neighbor Cease                                                            7
2.5 Neighbor Reachability                                                     7
2.6 Sequence Numbers                                                          8
2.7 Treatment of Excess Commands                                              8
2.8 Inappropriate Messages                                                    8
2.9 Default Gateway                                                           9

3. TESTING                                                                   10

4. FUTURE ENHANCEMENTS                                                       11

4.1 Multiple Autonomous Systems                                              11
4.2 Interface Monitoring                                                     11
4.3 Network Level Status Information                                         11
4.4 Interior Gateway Protocol Interface                                      12

5. TOPOLOGY ISSUES                                                           13

5.1 Topology Restrictions and Routing Loops                                  13
     5.1.1 Background                                                        13
     5.1.2 Current Policy                                                    14
5.2 Present ISI Configuration                                                15
     5.2.1 EGP Across ARPANET                                                17
     5.2.2 EGP Across ISI-NET                                                17
     5.2.3 Potential Routing Loop                                            18
5.3 Possible Future Configuration                                            18
     5.3.1 Gateway to UCI-ICS                                                18
     5.3.2 Dynamic Switch to Backup Gateway                                  19
          5.3.2.1 Usual Operation                                            19
          5.3.2.2 Host Initialization                                        19
          5.3.2.3 When Both the Primary and Backup are Down                  20
          5.3.2.4 Unix 4.2 BSD                                               20

6. ACKNOWLEDGEMENT                                                           21

7. REFERENCES                                                                22

RFC 911                                                                       1


1. INTRODUCTION

The Exterior Gateway Protocol (EGP) [Rosen 82; Seamonson & Rosen 84; Mills 84a]
has been specified to allow autonomous development of different gateway systems
while  still  maintaining  global distribution of internet routing information.
EGP provides a means for  different  autonomous  gateway  systems  to  exchange
information about the networks that are reachable via them.

This  report  mainly  describes  an  implementation  of EGP that runs as a user
                               *                                  **
process under the Berkeley Unix  4.2 operating system run on a VAX    computer.
Some  related issues concerning local autonomous system configurations are also
discussed.

The EGP implementation is experimental and is not a part of Unix 4.2 BSD. It is
anticipated that Berkeley will incorporate a version of EGP in the future.

The program is written in C. The EGP  part  is  based  on  the  C-Gateway  code
written  by  Liza  Martin at MIT and the route management part is based on Unix
4.2 BSD route management daemon, "routed".

The EGP functions are consistent with the specification of [Mills  84a]  except
where noted.

A  knowledge  of  EGP  as  described  in  [Seamonson  & Rosen 84; Mills 84a] is
assumed.

This chapter discusses the motivation for the project, Chapter 2 describes  the
gateway  design,  Chapter 3 is on testing, Chapter 4 suggests some enhancements
and Chapter 5 discusses topology issues.

Further information about running the EGP program and describing  the  software
is being published in an ISI Research Report ISI/RR-84-145 [Kirton 84].

Requests  for  documentation  and  copies  of the EGP program should be sent to
Joyce Reynolds ([e-mail]). Software support is not provided.


1.1 Motivation for Development

With the introduction of EGP, the internet gateways  will  be  divided  into  a
"core"  autonomous  system  (AS)  of  gateways  maintained by Bolt, Beranek and
Newman  (BBN)  and  many  "stub"  AS's  that  are   maintained   by   different
organizations  and  have at least one network in common with a core AS gateway.
The core AS will act as a  hub  for  passing  on  routing  information  between

_______________

  *
   Unix is a trade mark of AT&T
  **
    VAX is a trade mark of Digital Equipment Corporation

RFC 911                                                                       2


different  stub AS's so that it will only be necessary for stub AS's to conduct
EGP with a core gateway. Further detail is given in [Rosen 82].

At the time of this  project  there  were  28  "non-routing"  gateways  in  the
internet.  Non-routing  gateways  did  not  exchange  routing  information  but
required static entries in the core gateway routing tables.   Since  August  1,
1984  these  static  entries  have  been  eliminated and previously non-routing
gateways are required to communicate this  information  to  the  core  gateways
dynamically via EGP [Postel 84].

At the USC Information Sciences Institute (ISI) there was a non-routing gateway
to  the  University  of  California  at  Irvine  network  (UCI-ICS).  With  the
elimination of  non-routing  gateways  from  the  core  gateway  tables  it  is
necessary to inform the core ISI gateway of the route to UCI-ICS using EGP.

Also,  we  would  like a backup gateway between ISI-NET and the ARPANET in case
the core ISI gateway is down. Such, a gateway  would  need  to  convey  routing
information  via EGP. Details of the ISI network configuration are discussed in
Section 5.2.

Of the 28 non-routing gateways 23 were implemented by Unix  systems,  including
ISI's.  Also, ISI's proposed backup gateway was a Unix system. Thus there was a
local and general need for an EGP implementation to run under Unix. The current
version  of  Unix  that  included  Department  of  Defense  (DoD) protocols was
Berkeley Unix 4.2 so this was selected.


1.2 Overview of EGP

This report assumes a knowledge of EGP, however a brief overview is given  here
for completeness. For further details refer to [Rosen 82] for the background to
EGP,  [Seamonson & Rosen 84] for an informal description, and [Mills 84a] for a
more formal specification and implementation details.

EGP is generally conducted between gateways in  different  AS's  that  share  a
common network, that is, neighbor gateways.

EGP  consists  of three procedures, neighbor acquisition, neighbor reachability
and network reachability.

Neighbor acquisition is a two way handshake in which gateways agree to  conduct
EGP  by exchanging Request and Confirm messages which include the minimum Hello
and Poll  intervals.    Acquisition  is  terminated  by  exchanging  Cease  and
Cease-ack messages.

Neighbor  reachability  is  a  periodic exchange of Hello commands and I-H-U (I
heard you) responses to ensure that each gateway is up. Currently a  30  second
minimum interval is used across ARPANET. Only one gateway need send commands as
the   other   can  use  them  to  determine  reachability.  A  gateway  sending
reachability commands is said to be in the active mode, while  a  gateway  that
just responds is in the passive mode.

RFC 911                                                                       3


Network  reachability  is  determined by periodically sending Poll commands and
receiving Update responses which indicate the networks  reachable  via  one  or
more  gateways  on  the  shared network. Currently 2 minute minimum interval is
used across ARPANET.

RFC 911                                                                       4


2. GATEWAY DESIGN

EGP  is a polling protocol with loose timing constraints. Thus the only gateway
function requiring good performance is packet forwarding.  Unix 4.2 already has
packet forwarding built into the kernel where best performance can be achieved.
At the time of writing Unix 4.2 did not send  ICMP  (Internet  Control  Message
Protocol)  redirect  messages  for  misrouted packets. This is a requirement of
internet gateways and will later be added by Berkeley.

The EGP and route update functions are implemented as a  user  process.    This
facilitates  development and distribution as only minor changes need to be made
to the Unix kernel.  This is a similar approach to the Unix route  distribution
program  "routed"  [Berkeley  83]  which  is  based  on  the  Xerox  NS Routing
Information Protocol [Xerox 81].


2.1 Routing Tables

A route consists of a destination network  number,  the  address  of  the  next
gateway  to  use  on  a  directly  connected  network,  and a metric giving the
distance in gateway hops to the destination network.

There are two sets of routing  tables,  the  kernel  tables  (used  for  packet
forwarding) and the EGP process tables. The kernel has separate tables for host
and  network  destinations.  The EGP process only maintains the network routing
tables. The EGP tables are updated when EGP Update messages are received.  When
a  route is changed the kernel network tables are updated via the SIOCADDRT and
SIOCDELRT ioctl system calls. At  initialization  the  kernel  network  routing
tables  are  read  via the kernel memory image file, /dev/kmem, and copied into
the EGP tables for consistency.

This EGP implementation is designed to run on a gateway that is  also  a  host.
Because  of  the relatively slow polling to obtain route updates it is possible
that the host may receive notification of routing changes  via  ICMP  redirects
before  the EGP process is notified via EGP. Redirects update the kernel tables
directly. The EGP process listens for redirect messages on  a  raw  socket  and
updates its routing tables to keep them consistent with the kernel.

The  EGP  process routing tables are maintained as two separate tables, one for
exterior routes (via different AS gateways) and one for  interior  routes  (via
the  gateways of this AS).  The exterior routing table is updated by EGP Update
messages. The interior  routing  table  is  currently  static  and  is  set  at
initialization  time. It includes all directly attached nets, determined by the
SIOCGIFCONF ioctl system call and any interior non-routing gateways  read  from
the  EGP  initialization file, EGPINITFILE. The interior routing table could in
future be updated dynamically by an Interior Gateway Protocol (IGP).

Maintaining separate tables for exterior and interior routing  facilitates  the
preparation  of  outgoing  Update  messages which only contain interior routing
information [Mills 84b].  It also permits alternative external  routes  to  the
internal  routes  to  be  saved  as  a  backup in case an interior route fails.
Alternate routes are flagged,  RTS_NOTINSTALL,  to  indicate  that  the  kernel

RFC 911                                                                       5