rfc911.txt

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

routes  should  not  be updated. In the current implementation alternate routes
are not used.



2.1.1 Incoming Updates

EGP Updates are used to update  the  exterior  routing  table  if  one  of  the
following is satisfied:

   - No  routing  table  entry  exists for the destination network and the
     metric indicates the route is reachable (< 255).

   - The advised gateway is the same as the current route.

   - The advised distance metric is less than the current metric.

   - The current route is older (plus a  margin)  than  the  maximum  poll
     interval  for  all  acquired  EGP  neighbors.  That is, the route was
     omitted from the last Update.

If any exterior route entry, except the default route, is not  updated  by  EGP
within  4  minutes  or  3  times  the  maximum  poll interval, whichever is the
greater, it is deleted.

If there is more than one acquired EGP neighbor, the Update  messages  received
from each are treated the same way in the order they are received.

In  the worst case, when a route is changed to a longer route and the old route
is not first notified as unreachable, it  could  take  two  poll  intervals  to
update  a  route. With the current poll interval this could be 4 minutes. Under
Unix 4.2  BSD  TCP  connections  (Transmission  Control  Protocol)  are  closed
automatically  after  they  are idle for 6 minutes. So this worst case will not
result in the automatic closure of TCP connections.



2.1.2 Outgoing Updates

Outgoing Updates include the direct  and  static  networks  from  the  interior
routing table, except for the network shared with the EGP neighbor.

The  networks  that  are  allowed  to be advised in Updates may be specified at
initialization in EGPINITFILE. This allows particular  routes  to  be  excluded
from  exterior updates in cases where routing loops could be a problem. Another
case where this option is necessary, is when there  is  a  non-routing  gateway
belonging  to  a different AS which has not implemented EGP yet. Its routes may
need to be included in the kernel routing table but they are not allowed to  be
advised in outgoing updates.

If  the  interior routing table includes other interior gateways on the network
shared with the EGP neighbor they are include in  Updates  as  the  appropriate

RFC 911                                                                       6


first hop to their attached networks.

The  distance to networks is set as in the interior routing table except if the
route is marked down in which case the distance  is  set  to  255.  At  present
routes are only marked down if the outgoing interface is down. The state of all
interfaces  is  checked  prior  to  preparing  each  outgoing  Update using the
SIOCGIFFLAGS ioctl system call.

Unsolicited Updates are not sent.


2.2 Neighbor Acquisition

EGPINITFILE lists the addresses of trusted EGP  neighbor  gateways,  which  are
read  at  initialization.  These  will  usually  be  core gateways as only core
gateways provide full internet routing information.  At  the  time  of  writing
there  were  three  core  gateways  on  ARPANET which support EGP, CSS-GATEWAY,
ISI-GATEWAY and PURDUE-CS-GW, and two on MILNET, BBN-MINET-A-GW and AERONET-GW.

EGPINITFILE also includes the maximum number of these gateways that  should  be
acquired  at  any  one  time.  This is usually expected to be just one. If this
gateway is declared down another gateway on the  list  will  then  be  acquired
automatically  in  sufficient  time  to  ensure that the current routes are not
timed out.

The gateway will only accept acquisitions from neighbors on  the  trusted  list
and  will  not  accept  them if it already has acquired its maximum quota. This
prevents Updates being accepted from possibly unreliable sources.

The ability to acquire core gateways that are not on the trusted list but  have
been  learned of indirectly via Update messages is not included because not all
core gateways run EGP.

New acquisition Requests are sent to neighbors in  the  order  they  appear  in
EGPINITFILE.  No  more new Requests than the maximum number of neighbors yet to
be  acquired  are  sent  at  once.  Any  number  of  outstanding  Requests  are
retransmitted at 32 second intervals up to 5 retransmissions each at which time
the  acquisition  retransmission  interval  is increased to 4 minutes. Once the
maximum number of  neighbors  has  been  acquired,  unacquired  neighbors  with
outstanding  Requests  are  sent  Ceases.  This  approach provides a compromise
between fast response when neighbors do not initially respond and a  desire  to
minimize  the  chance that a neighbor may be Ceased after it has sent a Confirm
but before it has been received.  If the specified maximum number of  neighbors
cannot  be  acquired, Requests are retransmitted indefinitely to all unacquired
neighbors.


2.3 Hello and Poll Intervals

The Request and Confirm messages include minimum  values  for  Hello  and  Poll
intervals.  The advised minimums by this and the core gateways are currently 30
and 120 seconds respectively.

RFC 911                                                                       7


The  received  intervals  are  checked  against  upper  bounds to guard against
nonsense values. The upper bounds are currently set  at  120  and  480  seconds
respectively.  If,  they are exceeded the particular neighbor is considered bad
and not sent further Requests for one hour. This allows  the  situation  to  be
corrected  at  the  other  gateway and normal operation to automatically resume
from this gateway without an excess of unnecessary network traffic.

The actual Hello and Poll intervals are chosen by first selecting  the  maximum
of  the  intervals  advised  by this gateway and its peer. A 2 second margin is
then added to the Hello interval to take  account  of  possible  network  delay
variations  and the Poll interval is increased to the next integer ratio of the
Hello interval. This results in 32 second Hello and 128 second Poll intervals.

If an Update is not received in response to a Poll, at most  one  repoll  (same
sequence number) is sent instead of the next scheduled Hello.


2.4 Neighbor Cease

If  the EGP process is sent a SIGTERM signal via the Kill command, all acquired
neighbors are sent Cease(going down) commands.  Ceases are retransmitted at the
hello interval at most 3 times.  Once all have either responded with Cease-acks
or been sent three retransmitted Ceases the process is terminated.


2.5 Neighbor Reachability

Only  active  reachability  determination  is  implemented.  It  is   done   as
recommended in [Mills 84a] with a minor variation noted below.

A  shift  register  of responses is maintained.  For each Poll or Hello command
sent a zero is shifted into the shift register.  If a response  (I-H-U,  Update
or  Error) is received with the correct sequence number the zero is replaced by
a one.  Before each new command is  sent  the  reachability  is  determined  by
examining  the  last  four  entries  of  the shift register. If the neighbor is
reachable  and  <=  1  response  was  received  the  neighbor   is   considered
unreachable.  If the neighbor is considered unreachable and >= 3 responses were
received it is now considered reachable.

A neighbor is considered reachable immediately after acquisition  so  that  the
first  poll  received  from  a  core  gateway  (once  it considers this gateway
reachable) will be responded to with an Update. Polls are  not  sent  unless  a
neighbor  is considered reachable and it has not advised that it considers this
gateway unreachable in its last Hello, I-H-U or Poll message.    This  prevents
the first Poll being discarded after a down/up transition. This is important as
the  Polls  are  used  for reachability determination. Following acquisition at
least one message must be received before the first Poll is sent.  This  is  to
determine  that  the  peer  does  not  consider this gateway down. This usually
requires at least one Hello to be sent prior to the first poll. The  discussion
of  this  paragraph  differs  from  [Mills 84a] which recommends that a peer be
considered down following acquisition and Polls may be sent as soon as the peer
is  considered  up.  This  is  the  only   significant   departure   from   the

RFC 911                                                                       8


recommendations in [Mills 84a].

Polls  received  by  peers  that  are  considered unreachable are sent an Error
response which allows their reachability determination to  progress  correctly.
This action is an option within [Mills 84a].

When  a  neighbor  becomes  unreachable  all  routes  using it as a gateway are
deleted from the routing table. If there are  known  unacquired  neighbors  the
unreachable gateway is ceased and an attempt is made to acquire a new neighbor.
If all known neighbors are acquired the reachability determination is continued
for  30  minutes  ([Mills  84a]  suggests  60  minutes)  after  which  time the
unreachable neighbor is ceased and reacquisition  attempted  every  4  minutes.
This is aimed at reducing unnecessary network traffic.

If  valid  Update  responses  are  not  received for three successive polls the
neighbor is ceased and an alternative acquired or reacquisition is attempted in
4 minutes. This provision is provided in case erroneous Update data formats are
being sent by the neighbor. This situation did occur  on  one  occasion  during
testing.


2.6 Sequence Numbers

Sequence  numbers  are  managed  as recommended in [Mills 84a]. Single send and
receive sequence numbers are maintained for each neighbor.  The  send  sequence
number  is  initialized  to  zero  and is incremented before each new Poll (not
repoll) is sent and at no other time. The send sequence number is used  in  all
commands.  The  receive  sequence  number is maintained by copying the sequence
number of the last Request, Hello, or Poll command received  from  a  neighbor.
This  sequence  number  is  used  in outgoing Updates. All responses (including
Error responses) return the sequence number of the message just received.


2.7 Treatment of Excess Commands

If more than 20 commands are received from a neighbor in any  8  minute  period
the  neighbor  is  considered  bad,  Ceased and reacquisition prevented for one
hour.

At most one repoll (same sequence number) received before the poll interval has
expired (less a 4 second margin for network delay variability) is responded  to
with  an  Update,  others are sent an Error response. When an Update is sent in
response to a repoll the unsolicited bit is not set,  which  differs  from  the
recommendation in [Mills 84a].


2.8 Inappropriate Messages

If  a Confirm, Hello, I-H-U, Poll or Update is received from any gateway (known
or unknown) that is in the unacquired state, synchronization has probably  been
lost  for  some  reason. A Cease(protocol violation) message is sent to try and
reduce unnecessary network traffic. This action is an option in [Mills 84a].

RFC 911                                                                       9




2.9 Default Gateway

A  default gateway may be specified in EGPINITFILE. The default route (net 0 in
Unix 4.2 BSD) is used by the kernel packet forwarder if there  is  no  specific
route for the destination network. This provides a final level of backup if all
known EGP neighbors are unreachable. This is especially useful if there is only
one available EGP neighbor, as in the ISI case, Section 5.2.2.

The  default route is installed at initialization and deleted after a valid EGP
Update message is received. It  is  reinstalled  if  all  known  neighbors  are
acquired  but  none  are  reachable,  if routes time out while there are no EGP
neighbors that are acquired and reachable, and prior to process termination.

It is deleted after a valid EGP Update message is received because the  default
gateway will not know any more routing information than learned via EGP.  If it
were  not deleted, all traffic to unreachable nets would be sent to the default
gateway under Unix 4.2 forwarding strategy.

The default gateway should normally be set to a full-routing core gateway other
than the known EGP neighbor gateways to give another backup in case all of  the
EGP gateways are down simultaneously.

RFC 911                                                                      10


3. TESTING

A few interesting cases that occurred during testing are briefly described.

The   use   of  sequence  numbers  was  interpreted  differently  by  different
implementers. Consequently some implementations  rejected  messages  as  having
incorrect  sequence numbers, resulting in the peer gateway being declared down.
The main problem was that the specification was solely in narrative form  which
is  prone  to  inconsistencies, ambiguities and incompleteness. The more formal
specification of [Mills 84a] has eliminated these ambiguities.

When testing  the  response  to  packets  addressed  to  a  neighbor  gateway's
interface  that  was  not  on  the  shared net a loop resulted as both gateways
repeatedly exchanged  error  messages  indicating  an  invalid  interface.  The
problem  was that both gateways were sending Error responses after checking the
addresses but before the EGP message type was checked.  This was  rectified  by
not  sending  an  Error response unless it was certain that the message was not
itself an Error response.

On one occasion a core gateway had some  form  of  data  error  in  the  Update
messages  which  caused  them to be rejected even though reachability was being
satisfactorily conducted. This resulted in all routes being  timed  out.    The
solution  was  to  count  the  number of successive Polls that do not result in
valid Updates being received and if this number reaches  3  to  Cease  EGP  and
attempt to acquire an alternative gateway.

Another  interesting idiosyncrasy, reported by Mike Karels at Berkeley, results
from having multiple gateways between MILNET and ARPANET. Each ARPANET host has
an assigned gateway to use for access to MILNET. In cases where the EGP gateway
is a host as well as  a  gateway,  the  EGP  Update  messages  may  indicate  a
different  MILNET/ARPANET  gateway from the assigned one. When the host/gateway
originates a packet that is routed  via  the  EGP  reported  gateway,  it  will
receive  a  redirect to its assigned gateway.  Thus the MILNET gateway can keep