gateway
Click on the red underlined text to get to the source
... Seamonson&Rosen84; Mills84a]
has been specified to allow autonomous development of different gateway systems
while still maintaining global distribution of internet routing information ...
... routing information.
EGP provides a means for different autonomous gateway systems to exchange
information about the networks that are reachable via them.
...
...
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 ...
... 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.
...
... With the introduction of EGP, the internet gateways will be divided into a
"core" autonomous system (AS ...
... "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 ...
... 's so that it will only be necessary for stub AS's to conduct
EGP with a core gateway. Further detail is given in [Rosen82].
...
...
At the time of this project there were 28 "non-routing" gateways in the
internet. Non-routing ...
... in the
internet. Non-routing gateways did not exchange routing information but
required static entries in the core gateway ...
... 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 ...
... . 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 ...
... 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 [Postel84 ...
...
At the USC Information Sciences Institute (ISI) there was a non-routing gateway
to the University of California at Irvine network (UCI-ICS ...
... ICS). With the
elimination of non-routing gateways from the core gateway tables it is
necessary to inform the core ISI gateway ...
... elimination of non-routing gateways from the core gateway tables it is
necessary to inform the core ISI gateway of the route ...
... gateways from the core gateway tables it is
necessary to inform the core ISI gateway of the route to UCI-ICS using EGP ...
... EGP.
Also, we would like a backup gateway between ISI-NET and the ARPANET in case
the core ISI gateway ...
... 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 ...
... 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 ...
...
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
...
... 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 ...
... more formal specification and implementation details.
EGP is generally conducted between gateways in different AS's that share a
common network ...
...
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
...
... 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 ...
... 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 ...
... 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 ...
... sending
reachability commands is said to be in the active mode, while a gateway that
just responds is in the passive mode.
...
... 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 ...
... 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
...
... for misrouted packets. This is a requirement of
internet gateways and will later be added by Berkeley.
The EGP ...
... network number, the address of the next
gateway to use on a directly connected network, and a metric giving the
distance in gateway ...
... gateway to use on a directly connected network, and a metric giving the
distance in gateway hops to the destination network.
...
...
This EGP implementation is designed to run on a gateway that is also a host.
Because of the relatively slow polling to obtain route ...
... 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 ...
... AS gateways) and one for interior routes (via
the gateways of this AS). The exterior routing table is updated by EGP ...
... 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 ...
... initialization file, EGPINITFILE. The interior routing table could in
future be updated dynamically by an Interior Gateway Protocol (IGP).
...
... 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 ...
...
If the interior routing table includes other interior gateways on the network
shared with the EGP ...
... addresses of trusted EGP neighbor gateways, which are
read at initialization. These will usually be core gateways ...
... gateways, which are
read at initialization. These will usually be core gateways as only core
gateways provide full internet ...
... read at initialization. These will usually be core gateways as only core
gateways provide full internet routing information. At the time of writing
...
... internet routing information. At the time of writing
there were three core gateways on ARPANET which support EGP, CSS ...
... CSS-GATEWAY,
ISI-GATEWAY and PURDUE-CS-GW, and two on MILNET, BBN-MINET-A-GW and AERONET-GW.
...
... 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 ...
... 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
...
... 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.
...
... 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
...
... been learned of indirectly via Update messages is not included because not all
core gateways run EGP.
...
...
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.
...
... 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 ...
... 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
...
... 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 ...
... 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
...
... 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 ...
... 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
...
...
When a neighbor becomes unreachable all routes using it as a gateway are
deleted from the routing table. If there are known unacquired ...
... 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 ...
...
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 ...
... 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 ...
... 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 ...
... default
gateway under Unix 4.2 forwarding strategy.
The default gateway should normally be set to a full-routing core gateway other
...
... The default gateway should normally be set to a full-routing core gateway other
than the known EGP neighbor ...
... than the known EGP neighbor gateways to give another backup in case all of the
EGP gateways are down simultaneously.
...
... 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
...
...
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
...
... gateway's
interface that was not on the shared net a loop resulted as both gateways
repeatedly exchanged error messages indicating an invalid interface ...
... error messages indicating an invalid interface. The
problem was that both gateways were sending Error responses after checking the
addresses but before the ...
... 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 ...
... 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
...
...
Another interesting idiosyncrasy, reported by Mike Karels at Berkeley, results
from having multiple gateways between MILNET and ARPANET. Each ARPANET host ...
... ARPANET host has
an assigned gateway to use for access to MILNET. In cases where the EGP gateway
...
... an assigned gateway to use for access to MILNET. In cases where the EGP gateway
is a host as well as a gateway ...
... Update messages may indicate a
different MILNET/ARPANET gateway from the assigned one. When the host/gateway
...
... ARPANET gateway from the assigned one. When the host/gateway
originates a packet that is routed via the EGP reported gateway ...
... 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 ...
... EGP reported gateway, it will
receive a redirect to its assigned gateway. Thus the MILNET gateway can keep
being switched between the gateway ...
... gateway, it will
receive a redirect to its assigned gateway. Thus the MILNET gateway can keep
being switched between the gateway reported by EGP ...
... gateway. Thus the MILNET gateway can keep
being switched between the gateway reported by EGP and the assigned gateway. A
...
... being switched between the gateway reported by EGP and the assigned gateway. A
similar thing occurs when using routes to other nets reached via MILNET/ARPANET
...
... . A
similar thing occurs when using routes to other nets reached via MILNET/ARPANET
gateways.
...
... AS, all
neighbors on the list would need to be acquired in order to ensure that
gateways from both AS's were always acquired. This results in an unnecessary
excess of EGP ...
... reliability. A
more desirable approach would be to have separate lists of trusted EGP gateways
and the maximum number to be acquire, for each AS. Routing ...
... EGP. This is one case where the unsolicited Update message would help, but
there is still the delay for other non-core gateways to poll core EGP gateways
...
... there is still the delay for other non-core gateways to poll core EGP gateways
for the new routing information.
...
... neighbors
or other neighbor gateways. This information should be used to improve the
response time to changes.
...
... Interior Gateway Protocol Interface ...
... ].
Routing loops can occur when two gateways think there are alternate routes to
reach a third gateway via each other. When the third gateway ...
... Routing loops can occur when two gateways think there are alternate routes to
reach a third gateway via each other. When the third gateway goes down they end
up pointing to each other forming a routing loop ...
... gateways think there are alternate routes to
reach a third gateway via each other. When the third gateway goes down they end
up pointing to each other forming a routing loop. Within the present core
...
... system, loops are broken by counting to "infinity" (the internet diameter in
gateway hops). This (usually) works satisfactorily because GGP propagates
changes fairly quickly as routing updates are sent as soon as changes occur.
...
... , changes are propagated slowly. Although a single unsolicited NR
message can be sent, it won't necessarily be passed straight on to other
gateways who must hear about it indirectly. Also, the distance metrics of
different AS's are quite independent and hence can't be used to count to
...
... routing packet could be sent over the route that
instructs each gateway to delete the route after forwarding the packet on. The
...
... gateways connected by
networks. Each gateway in the system must be reachable from every
other gateway in its system by paths including only gateways ...
... networks. Each gateway in the system must be reachable from every
other gateway in its system by paths including only gateways in that
system.
...
... gateway in the system must be reachable from every
other gateway in its system by paths including only gateways in that
system.
...
... - A gateway in a system may run EGP with a gateway in any other system
as long as the path over which EGP itself is run does not include a
...
... as long as the path over which EGP itself is run does not include a
gateway in a third system.
- The "core system" is distinguished from the others by the fact that
...
... systems other than itself.
- At least one gateway in every system must have a net in common with a
gateway in the core system.
...
... - At least one gateway in every system must have a net in common with a
gateway in the core system.
- There are no topological or connectivity restrictions other than
...
... those implied above.
A gateway will use information derived from its configuration (directly
connected nets), the IGP of its system, called S in the following, (interior
...
... will be resolved as follows:
- If N is directly connected to the gateway, all IGP and EGP reports
...
... another, the interior report takes precedence.
- If N is reported as interior by two or more gateways of the same
system using EGP, the reports specifying the smallest hop count ...
... version of the ISI network configuration is shown in Figure 5-1.
ISI-Hobgoblin can provide a backup gateway function to the core ISI-Gateway
between ARPANET ...
... network configuration is shown in Figure 5-1.
ISI-Hobgoblin can provide a backup gateway function to the core ISI-Gateway
between ARPANET and ISI-NET. ISI-Hobgoblin is a VAX 11/750 which runs Berkeley
...
... ISI-Hobgoblin.
ISI-Troll is part of a split gateway to the University of California at Irvine
network (UCI-ICS). The complete logical ...
... to the University of California at Irvine
network (UCI-ICS). The complete logical gateway consists of ISI-Troll, the 9600
baud link and UCI-750A [Rose84 ...
... cannot run the EGP program. It is therefore a non-routing gateway. The
existence of UCI-ICS net must be advised to the core AS ...
... Hosts on ISI-NET, including ISI-Troll, have static route entries indicating
ISI-Gateway as the first hop for all networks other than UCI-ICS and ISI-NET.
...
... +-------------+ +-------------+ +---------------+
| ISI-PNG11 | | | | |
| Arpanet | | ISI-GATEWAY | | ISI-HOBGOBLIN |
| Address | | | | Vax 11/750 |
...
...
ISI-Hobgoblin will advise ISI-Gateway across ARPANET, and hence the core
system, that it can reach ISI-NET and UCI-ICS ...
... AS's exterior to ISI and destined for UCI-ICS will be routed via
ISI-Gateway, ISI-Hobgoblin and ISI-Troll. The extra hop via ISI-Gateway (or
other core EGP ...
... ICS will be routed via
ISI-Gateway, ISI-Hobgoblin and ISI-Troll. The extra hop via ISI-Gateway (or
other core EGP gateway ...
... Gateway (or
other core EGP gateway) is because the core gateways do not currently pass on
indirect-neighbor ...
... other core EGP gateway) is because the core gateways do not currently pass on
indirect-neighbor exterior gateway ...
... gateways do not currently pass on
indirect-neighbor exterior gateway addresses in their IGP messages
...
... addresses in their IGP messages
(Gateway-to-Gateway Protocol). Packets originating from UCI-ICS destined for
...
... IGP messages
(Gateway-to-Gateway Protocol). Packets originating from UCI-ICS destined for
exterior AS ...
... ICS destined for
exterior AS's will be routed via ISI-Troll and ISI-Gateway. Thus the incoming
and out going packet routes are different.
...
... ICS can only communicate with exterior AS's if ISI-Troll, ISI-Hobgoblin and
ISI-Gateway are all up. The dependence on ISI-Gateway could be eliminated if
ISI-Troll routed packets via ISI-Hobgoblin rather than ISI-Gateway ...
... AS's if ISI-Troll, ISI-Hobgoblin and
ISI-Gateway are all up. The dependence on ISI-Gateway could be eliminated if
ISI-Troll routed packets via ISI-Hobgoblin rather than ISI-Gateway. However,
...
... Gateway are all up. The dependence on ISI-Gateway could be eliminated if
ISI-Troll routed packets via ISI-Hobgoblin rather than ISI-Gateway. However,
as ISI-Hobgoblin is primarily a host and not a gateway ...
... Gateway. However,
as ISI-Hobgoblin is primarily a host and not a gateway it is preferable that
ISI-Gateway route ...
... route packets when possible.
ISI-Hobgoblin can provide a back-up gateway function to ISI-Gateway as it can
automatically switch ...
...
ISI-Hobgoblin can provide a back-up gateway function to ISI-Gateway as it can
automatically switch to an alternative core EGP ...
... automatically switch to an alternative core EGP peer if ISI-Gateway goes down.
Even though ISI-Hobgoblin normally advises the core system that it can reach
ISI-NET the core uses its own internal route ...
... Even though ISI-Hobgoblin normally advises the core system that it can reach
ISI-NET the core uses its own internal route via ISI-Gateway in preference.
For hosts on ISI-NET to correctly route ...
... For hosts on ISI-NET to correctly route outgoing packets they need their static
gateway entries changed from ISI-Gateway to ISI-Hobgoblin. At present this
would have to be done manually. This would only be appropriate if ISI-Gateway ...
... on ISI-NET to correctly route outgoing packets they need their static
gateway entries changed from ISI-Gateway to ISI-Hobgoblin. At present this
would have to be done manually. This would only be appropriate if ISI-Gateway
...
... gateway entries changed from ISI-Gateway to ISI-Hobgoblin. At present this
would have to be done manually. This would only be appropriate if ISI-Gateway
was going to be down for an extended period.
...
...
ISI-Hobgoblin will advise ISI-Gateway across ISI-NET that its indirect
neighbor, ISI-Troll, can reach UCI-ICS net.
...
... All exterior packet routing for UCI-ICS will be via ISI-Gateway in both
directions with no hops via ISI-Hobgoblin. Packets originating from
ISI-Hobgoblin as a host ...
... host and destined for exterior AS's will be routed via
ISI-Gateway, rather than the ARPANET interface, in both directions, thus taking
...
... UCI-ICS can only communicate with exterior AS's if ISI-Troll and ISI-Gateway
are up and ISI-Hobgoblin has advised ISI-Gateway of the UCI-ICS ...
... AS's if ISI-Troll and ISI-Gateway
are up and ISI-Hobgoblin has advised ISI-Gateway of the UCI-ICS route. If
...
... route. If
ISI-Hobgoblin goes down, communication will still be possible because
ISI-gateway (and other core gateways) do not time out routes to indirect
neighbors. If ISI- ...
... ISI-Hobgoblin goes down, communication will still be possible because
ISI-gateway (and other core gateways) do not time out routes to indirect
neighbors. If ISI-Gateway then goes down, it will need to be readvised by
...
... (and other core gateways) do not time out routes to indirect
neighbors. If ISI-Gateway then goes down, it will need to be readvised by
ISI-Hobgoblin of the UCI-ICS route ...
... should provide more reliable
service for UCI-ICS for the following reasons: ISI-Gateway is specifically
designed as a gateway, it is expected to be up more than ISI-Hobgoblin, it is
...
... ICS for the following reasons: ISI-Gateway is specifically
designed as a gateway, it is expected to be up more than ISI-Hobgoblin, it is
desirable to eliminate extra routing hops where possible and, the exterior
...
... ISI-Hobgoblin is to be used in its back-up mode, EGP could be restarted across
ARPANET after the new gateway routes are manually installed in the hosts.
Therefore, EGP ...
...
Because both ISI-Gateway and ISI-Hobgoblin provide routes between ARPANET and
ISI-NET there is a potential routing loop ...
... original tree structure restriction. Provided ISI-Hobgoblin does not conduct
EGP simultaneously with ISI-Gateway over ISI-NET and ARPANET, the gateways will
...
... EGP simultaneously with ISI-Gateway over ISI-NET and ARPANET, the gateways will
only ever know about the alternative route from the shared EGP ...
... network. Thus a loop cannot occur. For instance, if EGP is
conducted over ISI-NET, both ISI-Gateway and ISI-Hobgoblin will know about the
alternative routes via each other to ARPANET from ISI-NET, but they will not
...
... alternative routes via each other to ARPANET from ISI-NET, but they will not
know about the gateway addresses on ARPANET to be able to access ISI-NET from
...
... interface to be up and performance will
improve because the extra gateway hop will be eliminated.
This will also allow EGP ...
... EGP to be conducted across ARPANET giving access to the
alternative core gateways running EGP. This will increase the chances of being
able to reliably acquire an EGP ...
... EGP neighbor at all times. It will also eliminate
the extra hop via ISI-Gateway for packets originating from ISI-Hobgoblin, as a
host, and destined for exterior networks.
...
...
It was noted in Section 5.2.1 that ISI-Hobgoblin can provide a backup gateway
function to ISI-Gateway between ARPANET ...
... It was noted in Section 5.2.1 that ISI-Hobgoblin can provide a backup gateway
function to ISI-Gateway between ARPANET and ISI-NET. Such backup gateways could
...
... function to ISI-Gateway between ARPANET and ISI-NET. Such backup gateways could
become a common approach to providing increased reliability.
...
... reliability.
At present the change over to the backup gateway requires the new gateway route
...
...
At present the change over to the backup gateway requires the new gateway route
to be manually entered for hosts ...
... to be manually entered for hosts on ISI-NET. This section describes a possible
method for achieving this changeover dynamically when the primary gateway goes
down.
...
... down.
The aim is to be able to detect when the primary gateway is down and have all
hosts on the local network change to the backup ...
... is down and have all
hosts on the local network change to the backup gateway with a minimum amount
of additional network traffic. The hosts ...
... of additional network traffic. The hosts should revert back to the primary
gateway when it comes up again.
The proposed method ...
...
The proposed method is for only the backup gateway to monitor the primary
gateway status and for it to notify all hosts of the new ...
... The proposed method is for only the backup gateway to monitor the primary
gateway status and for it to notify all hosts of the new gateway address ...
... to monitor the primary
gateway status and for it to notify all hosts of the new gateway address when
there is a change.
...
... probe messages, such
as ICMP echoes, to the primary gateway every 30 seconds and uses the responses
to determine reachability as for EGP ...
... EGP. If the primary gateway goes down a
"gateway-address message" indicating the backup gateway address ...
... (or preferably multicast) to all hosts. When the primary gateway comes up
another gateway message indicating the primary gateway ...
... hosts. When the primary gateway comes up
another gateway message indicating the primary gateway address is broadcast ...
... gateway comes up
another gateway message indicating the primary gateway address is broadcast.
...
...
Each host would run a process that listens for gateway-address messages. If a
different gateway ...
... gateway-address messages. If a
different gateway is advised it changes the default gateway entry to the new
address.
...
... address messages. If a
different gateway is advised it changes the default gateway entry to the new
address.
...
...
When a host comes up the primary gateway could be down so it needs to be able
to determine that it should use the backup gateway. The host ...
... host comes up the primary gateway could be down so it needs to be able
to determine that it should use the backup gateway. The host could read the
address of the primary and backup ...
... . The host could read the
address of the primary and backup gateways from a static initialization file.
It would then set its default gateway ...
... gateways from a static initialization file.
It would then set its default gateway as the primary gateway and send a
"gateway ...
... static initialization file.
It would then set its default gateway as the primary gateway and send a
"gateway-request message ...
... default gateway as the primary gateway and send a
"gateway-request message" to the backup gateway requesting the current gateway ...
... "gateway-request message" to the backup gateway requesting the current gateway
address. The backup ...
... gateway-request message" to the backup gateway requesting the current gateway
address. The backup gateway would respond with a ...
... requesting the current gateway
address. The backup gateway would respond with a gateway-address message. If
...
...
address. The backup gateway would respond with a gateway-address message. If
no response is received the gateway ...
... gateway-address message. If
no response is received the gateway-request should be retransmitted three times
at 30 second intervals. If no response is received the backup gateway can be
...
... no response is received the gateway-request should be retransmitted three times
at 30 second intervals. If no response is received the backup gateway can be
assumed down and the primary gateway retained as the default.
...
... at 30 second intervals. If no response is received the backup gateway can be
assumed down and the primary gateway retained as the default.
Whenever the backup gateway ...
... gateway retained as the default.
Whenever the backup gateway comes up it broadcasts a gateway-address ...
... Alternatively, a broadcast (or multicast) gateway-request message could be
defined to which only gateways ...
... gateway-request message could be
defined to which only gateways would respond. The backup gateway-address
...
... request message could be
defined to which only gateways would respond. The backup gateway-address
message needs to indicate that it is the backup gateway ...
... gateway-address
message needs to indicate that it is the backup gateway so that future requests
need not be broadcast. Again, three retransmissions ...
... broadcast. Again, three retransmissions should be used. But the
primary gateway also needs to broadcast its address whenever it comes up.
...
...
If the primary gateway is down and the backup knows it is going down, it should
broadcast gateway- ...
... If the primary gateway is down and the backup knows it is going down, it should
broadcast gateway-address messages indicating the primary gateway in case the
...
... broadcast gateway-address messages indicating the primary gateway in case the
primary gateway comes up first.
...
... address messages indicating the primary gateway in case the
primary gateway comes up first.
But the backup could go down without warning and the primary come up before it.
...
...
But the backup could go down without warning and the primary come up before it.
If the primary gateway broadcasts a gateway-address ...
... If the primary gateway broadcasts a gateway-address message when it comes up
there is no problem. Otherwise, while hosts ...
... address message when it comes up
there is no problem. Otherwise, while hosts are using the backup gateway they
should send a gateway-request message ...
... hosts are using the backup gateway they
should send a gateway-request message every 10 minutes. If no response is
received it should be retransmitted 3 times at 30 second intervals and if still
...
... request message every 10 minutes. If no response is
received it should be retransmitted 3 times at 30 second intervals and if still
no response the backup assumed down and the primary gateway reverted to.
Thus the only time hosts ...
...
Thus the only time hosts need to send messages periodically is when the primary
gateway does not send gateway-address messages on coming up and the backup
...
... Thus the only time hosts need to send messages periodically is when the primary
gateway does not send gateway-address messages on coming up and the backup
gateway is being used. In some cases, such as at ISI, the primary ...
... does not send gateway-address messages on coming up and the backup
gateway is being used. In some cases, such as at ISI, the primary gateway is
managed by a different organization and experimental ...
... -address messages on coming up and the backup
gateway is being used. In some cases, such as at ISI, the primary gateway is
managed by a different organization and experimental features cannot be
...
... broadcast function.
On Unix 4.2 BSD systems, both the gateway and host processes could be run at
the user level so that kernel modifications are not required.
...
... Kirton, P.A., "EGP Gateway Under Berkeley Unix 4.2", University of Southern California, Information Sciences Institute, Research Report ISI/RR-84-145, to be published. ...
... Mills, D.L., "Exterior Gateway Protocol Formal Specification", Network Information Center RFC 904hist, April 1984. ...
... Postel, J., "Exterior Gateway Protocol Implementation Schedule" Network Information Center RFC 890, Feb. 1984. ...
... Connection into the ARPA-Internet: The Raw-Packet Split Gateway", Department of Information and Computer Science, University of California, Irvine, Technical Report 216, Feb. 1984. ...
... Seamonson, L.J. and Rosen, E.C., "Stub Exterior Gateway Protocol", Network Information Center RFC 888, Jan. 84. ...