On this page
|
| SUMMARY | |
| Protocol |
: |
Exterior Gateway Protocol |
| Protocol suite |
: |
TCP/IP |
| Layer |
: |
Network Layer |
| Type |
: |
Exterior routing protocol |
| SNMP MIBs |
: |
iso.org.dod.internet.mgmt.mib-2.egp (1.3.6.1.2.1.8) |
| Related protocols |
: |
IP,
IPv4,
TCP,
BGP,
IGP |
|
| DESCRIPTION |
The Exterior Gateway Protocol (EGP) is an exterior routing protocol used for exchanging routing information with gateways in other autonomous systems. Unlike interior protocols, EGP propagates only reachability indications, not true metrics. EGP updates contain metrics, called distances which range from 0 to 255. GateD will only compare EGP distances learned from the same AS.
EGP is responsible for communication of network reachability information between neighboring routers, which may or may not be in different autonomous systems. The operation of EGP is somewhat similar to that of BGP. Each EGP router maintains a database of information regarding what networks it can reach and how to reach them. It sends this information out on a regular basis to each router to which it is directly connected. Routers receive these messages and update their routing tables, and then use this new information to update other routers. Information about how to reach each network propagates across the entire internetwork.
An exterior gateway using EGP passes along information to its EGP neighbors but does not advertise reachability information about its EGP neighbors (gateways are neighbors if they exchange routing information) outside the autonomous system. It has three main features:
- It supports a neighbor acquisition protocol. Two gateways may be regarded as neighbors if they are connected by an internet which is transparent to them. EGP does not specify the way in which one gateway initially decides that it wants to become a neighbor of another. To become a neighbor it must send an Acquisition confirm message as a response to an Acquisition Request message. This step is necessary to obtain routing information from another gateway.
- It supports a neighbor reachability protocol. It is used by a gateway to keep real-time information as to the reachability of its neighbors. The EGP protocol provides two message types for that purpose: a Hello message and an I Hear You message (response to Hello).
- It supports update messages (also called network reachability (NR) messages) that carry routing information. No gateway is required to send NR.
Neighbor Acquisition
Before it is possible to obtain routing information from an exterior gateway, it is necessary to acquire that gateway as a direct neighbor. (The distinction between direct and indirect neighbors will be made in a later section.) In order for two gateways to become direct neighbors, they must be neighbors, in the sense defined above, and they must execute the NEIGHBOR ACQUISITION PROTOCOL, which is simply a standard three-way handshake.
A gateway that wishes to initiate neighbor acquisition with another sends it a Neighbor Acquisition Request. This message should be repeatedly transmitted (at a reasonable rate, perhaps once every 30 seconds or so) until a Neighbor Acquisition Reply is received. The Request will contain an identification number which is copied into the reply so that request and reply can be matched up.
A gateway receiving a Neighbor Acquisition Request must determine whether it wishes to become a direct neighbor of the source of the Request. If not, it may, at its option, respond with a Neighbor Acquisition Refusal message, optionally specifying the reason for refusal. Otherwise, it should send a Neighbor Acquisition Reply message. It must also send a Neighbor Acquisition Request message, unless it has done so already.
Two gateways become direct neighbors when each has sent a Neighbor Acquisition Message to, and received the corresponding Neighbor Acquisition Reply from, the other.
Neighbor Reachability
The purpose of the neighbor-reachability algorithm is to confirm that the neighbor can safely be considered operational and capable of providing reliable net-reachability information. An equally important purpose is to filter noisy reachability information before sending it on to the remainder of the Internet gateway system, thus avoiding unnecessary reachability changes.
As described above, a gateway operating in the active mode sends periodic Hello commands and listens for I-H-U responses in order to determine neighbor-reachability indications. A gateway operating in the passive mode determines reachability indications by means of the Status field in received Hello commands. Poll commands and Update responses can be used in lieu of Hello commands and I-H-U responses respectively, since they contain the same Status-field information.
The neighbor-reachability algorithm runs continuously while the gateway is in the Down and Up states and operates as follows. Define a moving window in time starting at the present and extending backwards for t seconds. Then count the number n of neighbor-reachability indications which have occurred in that window. If n increases to j, then declare a Up event. If n decreases to k, then declare a Down event. The number n is set to zero upon entering the Down state from any state other than the Up state.
Network Reachability
Network reachability information is encoded into Update messages in the form of lists of nets and gateways. The IP Source Address field of the Poll command is used to specify a network common to the autonomous systems of each of the neighbors, which is usually, but not necessarily, the one common to the neighbors themselves. The Update response includes a list of gateways on the common net. Associated with each gateway is a list of the networks reachable via that gateway together with corresponding hop counts.
Two types of gateway lists can be included in the Update response, the format of which is described in Appendix A. Both lists include only those gateways directly connected to the net specified in the IP Source Network field of the last-received Poll command. The internal list includes some or all of the gateways in the same autonomous system as the sender, together with the nets which are reachable via these gateways, with the sending gateway listed first. A net is reachable in this context if a path exists to that net including only gateways in the system. The external list includes those gateways in other autonomous systems known to the sender. It is important to realize that the hop counts do not represent a routing metric and are comparable between different gateways only if those gateways belong to the same autonomous system; that is, are in the internal list.
Header format
8 | 16 | 24 | 32 | Version | Type | Code | Status | Checksum | Autonomous System | Sequence | Data |
- Version
8 bits. The version number. This version is version 2.
- Type
8 bits. The type identifies the message type.
- Code
8 bits. The code identifies the message code (subtype).
- Status
8 bits. The status contains message-dependent status information.
- Checksum
16 bits. The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message starting with the EGP version number field. When computing the checksum the checksum field itself should be zero.
- Autonomous System
16 bits. The assigned number identifying the particular autonomous system.
- Sequence
16 bits. The sequence number is for the send state variable (commands) or receive state variable (responses and indications).
- Data
Variable length.
EGP message types
Name | Function | Request | Request acquisition of neighbor and/or initialize polling variables | Confirm | Confirm acquisition of neighbor and/or initialize polling variables | Refuse | Refuse acquisition of neighbor | Cease | Request de-acquisition of neighbor | Cease-ack | Confirm de-acquisition of neighbor | Hello | Request neigbor reachability | I-H-U | Confirm neigbor reachability | Poll | Request net-reachability update | Update | Net-reachability update | Error | Error message |
State Machine
The state-machine model includes a number of state variables which establish the state of the protocol between the gateway and each of its neighbors. Thus, a gateway maintaining EGP with a number of neighbors must maintain a separate set of these state variables for each neighbor. The current state, events and actions of the state machine apply to each neighbor separately.
The model assumes that system resources, including the set of state variables, are allocated when the state machine leaves the Idle state, either because of the arrival of a Request specifying a new neighbor address, or because of a Start event specifying a new neighbor address. When either of these events occur the values of the state variables are initialized as indicated below. Upon return to the Idle state all resources, including the set of state variables, are deal located and returned to the system. Implementators may, of course, elect to dedicate resources and state variables permanently.
Following is a list of time-interval parameters which control retransmissions and other time-dependent functions.
Name | Value | Description | | P1 | 30 sec | minimum interval acceptable between successive Hello commands received | | P2 | 2 min | minimum interval acceptable between successive Poll commands received | | P3 | 30 sec | interval between Request or Cease command retransmissions | | P4 | 1 hr | interval during which state variables are maintained in the absence of commands or responses in the Down and Up states. | | P5 | 2 min | interval during which state variables are maintained in the absence of responses in the Acquisition and Cease states |
Managing the State Variables
This section describes the detailed management of these variables, including sequence numbers, polling intervals and timers.
- Sequence Numbers
All EGP commands and replies carry a sequence number. The state variable R records the last sequence number received in a command from that neighbor. The current value of R is used as the sequence number for all replies and indications sent to the neighbor until a command with a different sequence number is received from that neighbor.
Implementors are free to manage the sequence numbers of the commands sent; however, it is suggested that a separate send state variable S be maintained for each EGP neighbor and that its value be incremented just before the time an Poll command is sent and at no other times. The actions upon receipt of a response or indication with sequence number not equal to S is not specified; however, it is recommended these be discarded.
- Polling Intervals
As part of the Request/Confirm exchange a set of polling intervals are established including T1, which establishes the interval between Hello command retransmissions, and T2, which establishes the interval between Poll retransmissions.
Each gateway configuration is characterized by a set of fixed parameters, including P1, which specifies the minimum polling interval at which it will respond to Hello commands, and P2, which specifies the minimum polling interval at which it will respond to Poll commands. P1 and P2 are inserted in the Hello Interval (S1) and Poll Interval (S2) fields, respectively, of Request commands and Confirm responses.
- Hello Polling Mode
The neighbor-reachability algorithm can be used in either the active or passive mode. In the active mode Hello commands are sent periodically along with Poll commands, with reachability determined by the corresponding I-H-U and Update responses. In the passive mode Hello commands are not sent and I-H-U responses are not expected. Reachability is then determined from the Status field of received Hello or Poll commands or Update responses.
- Timers
There are three timers defined in the state machine: t1, used to control retransmission of Request, Hello and Cease messages, t2, used to control retransmission of Poll commands, and t3, which serves as an abort-timer mechanism should the protocol hang indefinitely. The timers are set to specified values upon entry to each state and count down to zero.
Starting and Stopping the Protocol
The Start and Stop events are intrinsic to the system environment of the gateway. They can be declared as the result of the gateway process being started and stopped by the operator, for example. A Start event has meaning only in some states; however, a Stop event has meaning in all states.
In all except the Idle state the abort timer t3 is presumed running. This timer is initialized at P5 seconds upon entry to any state and at P4 seconds upon receipt of a neighbor-reachability indication in the Down and Up states. If it expires a Stop event is declared. A Stop event can also be declared by an intrinsic system action such as a resource problem or operator command.
Determining Neighbor Reachability
The purpose of the neighbor-reachability algorithm is to confirm that the neighbor can safely be considered operational and capable of providing reliable net-reachability information. An equally important purpose is to filter noisy reachability information before sending it on to the remainder of the Internet gateway system, thus avoiding unnecessary reachability changes.
As described above, a gateway operating in the active mode sends periodic Hello commands and listens for I-H-U responses in order to determine neighbor-reachability indications. A gateway operating in the passive mode determines reachability indications by means of the Status field in received Hello commands. Poll commands and Update responses can be used in lieu of Hello commands and I-H-U responses respectively, since they contain the same Status-field information.
|
 Top of Page
|
| EXAMPLES |
|
|
Top of Page
|
| PROTOCOL RELATIONS |
■ Parent layer
■ Child layer
IP
| | EGP | |
Top of Page
|
| GLOSSARY |
|
BGP
Border Gateway Protocol (BGP) is an exterior gateway routing protocol that enables groups of routers (called autonomous systems) to share routing information so that efficient, loop-free routes can be established. BGP is commonly used within and between Internet Service Providers (ISPs).
Gateway
A network device used to translate between two different protocols. Used to interconnect two networks that use incompatible protocols. It is a node on a network that serves as an entrance to another network. In enterprises, the gateway is the computer that routes the traffic from a workstation to the outside network that is serving the Web pages. In homes, the gateway is the ISP that connects the user to the internet.
In enterprises, the gateway node often acts as a proxy server and a firewall. The gateway is also associated with both a router, which use headers and forwarding tables to determine where packets are sent, and a switch, which provides the actual path for the packet in and out of the gateway.
It is also a computer system located on earth that switches data signals and voice signals between satellites and terrestrial networks and an earlier term for router, though now obsolete in this sense as router is commonly used.
Router
A device that forwards data packets along networks. A router is connected to at least two networks, commonly two LANs or WANs or a LAN and its ISP network. Routers are located at gateways, the places where two or more networks connect.
Routers use headers and forwarding tables to determine the best path for forwarding the packets, and they use protocols such as ICMP to communicate with each other and configure the best route between any two hosts.
|
Top of Page
|
| REFERENCES |
RFCs:
[ RFC 827] EXTERIOR GATEWAY PROTOCOL (EGP).
Updated by: RFC 904.
[ RFC 888] STUB EXTERIOR GATEWAY PROTOCOL.
Updated by: RFC 904.
[ RFC 890] Exterior Gateway Protocol Implementation Schedule.
[ RFC 904] Exterior Gateway Protocol Formal Specification.
STD: 18.
Updates: RFC 827, RFC 888.
[ RFC 911] EGP GATEWAY UNDER BERKELEY UNIX 4.2.
[ RFC 975] Autonomous Confederations.
[ RFC 1004] A Distributed-Protocol Authentication Scheme.
[ RFC 1092] EGP and Policy Based Routing in the New NSFNET Backbone.
[ RFC 1156] Management Information Base for Network Management of TCP/IP-based internets.
Obsoletes: RFC 1066.
[ RFC 1158] Management Information Base for Network Management of TCP/IP-based internets: MIB-II.
Obsolete RFCs:
[ RFC 1066] Management Information Base for Network Management of TCP/IP-based internets.
Obsoleted by: RFC 1156
|
Top of Page
|
| OTHER PROTOCOLS OF TCP/IP SUITE |
|
|
|
|
|
