Operation of EGP

Version 1 of EGP was proposed in RFC 827. Version 2, slightly modified from version 1, was proposed in RFC 888[2], and the formal specification of EGPv2 is given in RFC 904[3].

EGP Topology Issues

EGP messages are exchanged between EGP neighbors, or peers. If the neighbors are in the same AS, they are interior neighbors. If they are in different autonomous systems, they are exterior neighbors. EGP has no function that automatically discovers its neighbors; the addresses of the neighbors are manually configured, and the messages they exchange are unicast to the configured addresses.

RFC 888 suggests that the time-to-live (TTL) of EGP messages be set to a low number, because an EGP message should never travel farther than to a single neighbor. However, nothing in the EGP functionality requires EGP neighbors to share a common data link. For example, Figure 1-1 shows two EGP neighbors separated by a router that speaks only RIP. Because EGP messages are unicast to neighbors, they can cross router boundaries. Therefore, Cisco routers set the TTL of EGP packets to 255.

Figure 1-1. EGP Neighbors Do Not Have to Be Connected to the Same Network

EGP gateways are either core gateways or stub gateways. Both gateway types can accept information about networks in other autonomous systems, but a stub gateway can send only information about networks in its own AS. Only core gateways can send information they have learned about networks in autonomous systems other than their own.

To understand why EGP defines core and stub gateways, it is necessary to understand the architectural limitations of EGP. As previously mentioned, EGP is not a routing protocol. Its updates list only reachable networks, without including enough information to determine shortest paths or to prevent routing loops. Therefore, the EGP topology must be built with no loops .

Figure 1-2 shows an EGP topology. There is a single core AS to which all other autonomous systems (stub autonomous systems) must attach. This two-level tree topology is very similar to the two-level topology requirements of OSPF, and its purpose is the same. Recall from Routing TCP/IP, Volume I that interarea OSPF routing is essentially distance vector, and therefore vulnerable to routing loops. Requiring all traffic between nonbackbone OSPF areas to traverse the backbone area reduces the potential for routing loops by forcing a loop-free interarea topology. Likewise, requiring all EGP reachability information between stub autonomous systems to traverse the core AS reduces the potential for routing loops in the EGP topology.

Figure 1-2. To Prevent Routing Loops, Only Core Gateways Can Send Information Learned from One AS to Another AS

EGP Functions

EGP consists of the following three mechanisms:

• Neighbor Acquisition Protocol

• Neighbor Reachability Protocol

• Network Reachability Protocol

These three mechanisms use ten message types to establish a neighbor relationship, maintain the neighbor relationship, exchange network reachability information with the neighbor, and notify the neighbor of procedural or formatting errors. Table 1-1 lists all of the EGP message types and the mechanism that uses each message type.

Table 1-1. EGP Message Types

Message Type	Mechanism
Neighbor Acquisition Request	Neighbor Acquisition
Neighbor Acquisition Confirm	Neighbor Acquisition
Neighbor Acquisition Refuse	Neighbor Acquisition
Neighbor Cease	Neighbor Acquisition
Neighbor Cease Acknowledgment	Neighbor Acquisition
Hello	Neighbor Reachability
I-Heard-You	Neighbor Reachability
Poll	Network Reachability
Update	Network Reachability
Error	All functions

The following sections discuss the details of each of the three EGP mechanisms; the section "EGP Message Formats" in this chapter covers the specific details of the messages.

Neighbor Acquisition Protocol

Before EGP neighbors can exchange reachability information, they must establish that they are compatible. This function is performed by a simple two-way handshake in which one neighbor sends a Neighbor Acquisition Request message, and the other neighbor responds with a Neighbor Acquisition Confirm message.

None of the RFCs specify how two EGP neighbors initially discover each other. In practice, an EGP gateway learns of its neighbor by manual configuration of the neighbor's IP address. The gateway then unicasts an Acquisition Request message to the configured neighbor. The message states a Hello interval, the minimum interval between Hello messages that the gateway is willing to accept from the neighbor, and a Poll interval, the minimum interval that the gateway is willing to be polled by the neighbor for routing updates. The neighbor's responding Acquisition Confirm message will contain its own values for the same two intervals. If the neighbors agree on the values, they are ready to exchange network reachability information.

When a gateway first learns of a neighbor, it considers the neighbor to be in the Idle state. Before sending the first Acquisition Request, the gateway transitions the neighbor to the Acquire state; when the gateway receives an Acquisition Confirm, it transitions the neighbor to the Down state.

NOTE

See RFC 904 for a complete explanation of the EGP finite state machine.

A gateway can refuse to accept a neighbor by responding with a Neighbor Acquisition Refuse message rather than an Acquisition Confirm message. The Refuse message can include a reason for the refusal, such as a lack of table space, or it can refuse for an unspecified reason.

A gateway can also break an established neighbor relationship by sending a Neighbor Cease message. As with the Refuse message, the originating gateway has the option of including a reason for the Cease or leaving the reason unspecified. A neighbor receiving a Neighbor Cease message responds with a Neighbor Cease Acknowledgment.

The last case of a Neighbor Acquisition procedure is a case in which a gateway sends an Acquisition Request but the neighbor does not respond. RFC 888 suggests retransmitting the Acquisition message "at a reasonable rate, perhaps every 30 seconds or so." Cisco's EGP implementation does not just repeat unacknowledged messages over a constant period. Rather, it retransmits an unacknowledged Acquisition message 30 seconds after the original transmission. It then waits 60 seconds before the next transmission. If no response is received within 30 seconds of the third transmission, the gateway transitions the neighbor state from Acquire to Idle (see Example 1-1). The gateway remains in the Idle state for 300 seconds (5 minutes) and then transitions to Acquire and starts the process all over.

Notice in Example 1-1 that each EGP message has a sequence number. The sequence number allows EGP message pairs (such as Neighbor Acquisition Request/Confirm, Request/Refusal, and Cease/Cease-Ack pairs) to be identified. The next section, "Network Reachability Protocol," details how the sequence numbers are used.

When two EGP gateways become neighbors, one is the active neighbor and one is the passive neighbor. Active gateways always initiate the neighbor relationship by sending Neighbor Acquisition Requests. Passive gateways do not send Acquisition Requests; they only respond to them. The same is true for Hello/I-Heard-You message pairs, described in the following section: The active neighbor sends the Hello, and the passive neighbor responds with an I-Heard-You (I-H-U). A passive gateway can initiate a Neighbor Cease message, however, to which the active gateway must reply with a Cease Acknowledgement message.

Example 1-1 debug ip egp transactions Command Output Displays EGP State Transitions

 Shemp#  debug ip egp transactions  EGP debugging is on Shemp#  EGP: 192.168.16.2 going from IDLE to ACQUIRE  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180 EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180 EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180  EGP: 192.168.16.2 going from ACQUIRE to IDLE   EGP: 192.168.16.2 going from IDLE to ACQUIRE  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180 EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180 EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0      Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180  EGP: 192.168.16.2 going from ACQUIRE to IDLE  

A core gateway, which can be a neighbor of routers in several other autonomous systems, might be the active gateway of one neighbor adjacency and the passive gateway of another neighbor adjacency . Cisco's EGP implementation uses the AS numbers as the determining factor: The neighbor whose AS number is lower will be the active neighbor.

Neighbor Reachability Protocol

After a gateway has acquired a neighbor, it maintains the neighbor relationship by sending periodic Hello messages. The neighbor responds to each Hello with an I-H-U message. RFC 904 does not specify a standard period between Hellos; Cisco uses a default period of 60 seconds, which can be changed with the command t imers egp.

When three Hello/I-H-U message pairs have been exchanged, the neighbor state changes from Down to Up (see Example 1-2). The neighbors can then exchange network reachability information, as described in the next section.

If an active neighbor sends three sequential messages without receiving a response, the neighbor state transitions to Down. The gateway sends three more Hellos at the normal Hello interval; if there is still no response, the state changes to Cease. The gateway sends three Neighbor Cease messages at 60-second intervals. If the neighbor responds to any of the messages with a Cease Acknowledgment, or does not respond at all, the gateway transitions the neighbor state to Idle and waits 5 minutes before transitioning back to Acquire and attempting to reacquire the neighbor. Example 1-3 shows this sequence of events.

Example 1-2 debug ip egp transactions Command Output Displays Two-Way Handshake Success and EGP State Transitions

  EGP: 192.168.16.2 going from IDLE to ACQUIRE  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=ACQUIRE, Code=REQUEST, Status=1 (ACTIVE-MODE), Hello=60, Poll=180 EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=ACQUIRE, Code=CONFIRM, Status=2 (PASSIVE-MODE), Hello=60, Poll=180  EGP: 192.168.16.2 going from ACQUIRE to DOWN  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=REACH, Code=HELLO, Status=2 (DOWN) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=REACH, Code=HELLO, Status=2 (DOWN) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=REACH, Code=HELLO, Status=2 (DOWN) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN)  EGP: 192.168.16.2 going from DOWN to UP  

Example 1-3 The Neighbor at 192.168.16.2 Has Stopped Responding. The Interval Between Each of the Unacknowledged EGP Messages Is 60 Seconds

 Shemp# EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=REACH, Code=HELLO, Status=1 (UP) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=REACH, Code=I-HEARD-YOU, Status=1 (UP) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=REACH, Code=HELLO, Status=1 (UP) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2      Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0 EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=REACH, Code=HELLO, Status=1 (UP)  EGP: 192.168.16.2 going from UP to DOWN  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=REACH, Code=HELLO, Status=2 (DOWN) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=REACH, Code=HELLO, Status=2 (DOWN) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=REACH, Code=HELLO, Status=2 (DOWN)  EGP: 192.168.16.2 going from DOWN to CEASE  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=ACQUIRE, Code=CEASE, Status=5 (HALTING) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=ACQUIRE, Code=CEASE, Status=1 (ACTIVE-MODE) EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3      Type=ACQUIRE, Code=CEASE, Status=1 (ACTIVE-MODE)  EGP: 192.168.16.2 going from CEASE to IDLE  

Example 1-4 shows another example of a dead neighbor, except this time a core gateway (192.168.16.2) in the passive mode is discovering the dead neighbor (192.168.16.1).

Example 1-4 Neighbor 192.168.16.1 Has Stopped Responding. The debug Messages Are Taken from 192.168.16.2, a Gateway in Passive Mode

 Moe# EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=1      Type=REACH, Code=HELLO, Status=1 (UP) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=1      Type=REACH, Code=I-HEARD-YOU, Status=1 (UP) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=1      Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0 EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2      Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0 EGP: 192.168.16.1 going from UP to DOWN  EGP: 192.168.16.1 going from DOWN to CEASE   EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3  Type=ACQUIRE, Code=CEASE, Status=5 (HALTING) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3      Type=ACQUIRE, Code=CEASE, Status=2 (PASSIVE-MODE) EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3      Type=ACQUIRE, Code=CEASE, Status=2 (PASSIVE-MODE)  EGP: 192.168.16.1 going from CEASE to IDLE  

When the gateway does not receive a Hello within the 60-second Hello interval, it tries to "wake up" its neighbor. Because a gateway in passive mode cannot send Hellos, it sends a Poll message. The gateway then waits for one Poll interval. (Cisco's default Poll interval is 180 seconds, or 3 minutes.) If no response is received, it sends another Poll and waits another Poll interval. If there still is no response, the gateway changes the neighbor state to Down and then immediately to Cease. As in Example 1-3, three Cease messages are sent and the neighbor state is changed to Idle.

Network Reachability Protocol

When the neighbor state is Up, the EGP neighbors can begin exchanging reachability information. Each gateway periodically sends a Poll message to its neighbor, containing some sequence number. The neighbor responds with an Update message that contains the same sequence number and a list of reachable networks. Example 1-5 shows how Cisco's IOS Software uses the sequence numbers.

Example 1-5 EGP Neighbors Poll Each Other Periodically for Network Reachability Updates

  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120  Type=REACH, Code=HELLO, Status=1 (UP)  EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120  Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120  Type=REACH, Code=HELLO, Status=1 (UP)  EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120  Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120  Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0 EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120      Type=UPDATE, Code=0, Status=1 (UP), IntGW=2, ExtGW=1, Net=192.168.16.0      Network 172.17.0.0 via 192.168.16.2 in 0 hops      Network 192.168.17.0 via 192.168.16.2 in 0 hops      Network 10.0.0.0 via 192.168.16.2 in 3 hops      Network 172.20.0.0 via 192.168.16.4 in 0 hops      Network 192.168.18.0 via 192.168.16.3(e) in 3 hops      Network 172.16.0.0 via 192.168.16.3(e) in 3 hops      Network 172.18.0.0 via 192.168.16.3(e) in 3 hops EGP: 192.168.16.2 updated 7 routes  EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3  Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3  Type=UPDATE, Code=0, Status=1 (UP), IntGW=1, ExtGW=0, Net=192.168.16.0      Network 172.19.0.0 via 192.168.16.1 in 0 hops  EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=121  Type=REACH, Code=HELLO, Status=1 (UP)  EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=121  Type=REACH, Code=I-HEARD-YOU, Status=1 (UP) 

Every Hello/I-H-U pair exchanged between neighbors contains the same sequence number until a Poll is sent. The Poll/Update pair also uses the same sequence number. After the Update has been received, the active neighbor increments the sequence number. In Example 1-5, the sequence number is 120 through the Poll/Update, and it then is incremented to 121. Notice that both neighbors send a Poll; in this example, the Poll from the passive neighbor (192.168.16.2) has an entirely different sequence number (3). A neighbor always responds with an Update containing the same sequence number as the Poll.

The default polling interval used by Cisco's IOS Software is 180 seconds and can be changed with the command timers egp. Normally, a gateway sends an Update only when it is polled; however, this means a topology change might go unannounced for up to 3 minutes. EGP provides for this eventuality by allowing a gateway to send one unsolicited Update ”that is, an Update that is not in response to a Poll ”each Poll interval. Cisco, however, does not support unsolicited Updates.

NOTE

The t imers egp command is also used to change the Hello interval. The format of the command is timers egp hello polltime.

Both the Poll and the Update messages include the address of a source network. For example, the Poll and Update messages in Example 1-5 show a source network of 192.168.16.0. The source network is the network from which all reachability information is measured ”that is, all networks requested or advertised can be reached via a router attached to the source network. Although this network is usually the network to which the two neighbors are both attached, it is more accurately the network about which the Poll is requesting information, and the network about which the Update is supplying information. EGP is a purely classful protocol, and the source network ”as well as the network addresses listed in the Updates ”are always major class network addresses, and never subnets.

Following the source network address is a list of one or more routers and the networks that can be reached via those routers. The common characteristic of the routers on the list is that they are all attached to the source network. If a router on the list is not the EGP gateway that originated the Update, the router is an indirect or third-party neighbor.

Figure 1-3 illustrates the concept of indirect EGP neighbors. One router, Moe, is a core gateway and is peered with three other gateways.

Figure 1-3. Indirect EGP Neighbors

The debug messages in Example 1-5 are taken from Shemp, the router in AS1. Notice in the Update originated by Moe (192.168.16.2) that three networks are listed as reachable via Moe, but also, four networks are listed as reachable via Larry (192.168.16.4) and Curly (192.168.16.3). These two routers are Shemp's indirect neighbors, via Moe. Joe, in AS3, is not an indirect neighbor, because it is not attached to the source network. Its networks are merely advertised as being reachable via Moe.

The advertisement of indirect neighbors saves bandwidth on a common link, but more importantly, indirect neighbors increase efficiency by eliminating an unnecessary router hop. In Figure 1-3, for example, Shemp is not peered with any router other than Moe. In fact, Larry is not even speaking EGP, but is advertising its networks to Moe via RIP. Moe is performing a sort of "preemptive redirect" by informing Shemp of better next-hop routers than itself.

In fact, it is possible for an EGP Update to contain indirect neighbors only ”that is, the originator might not include itself as a next hop to any network. In this scenario, the originator is a route server. It has learned reachability information from an IGP or from static routes, and it advertises this information to EGP neighbors without itself performing any packet-forwarding functions.

From the perspective of an EGP gateway, a neighbor is either an interior gateway or an exterior gateway. A neighbor is an interior gateway if it is in the same AS, and it is an exterior gateway if it is in a different AS. In Figure 1-3, all the EGP gateways see all their neighbors as external gateways. If Larry were speaking EGP and peered with Moe, those two routers would see each other as interior gateways.

An EGP Update message includes two fields for describing whether the routers in its list are interior or exterior gateways (see the following section, "EGP Message Formats"). Looking at the first Update message in Example 1-5, you can see these fields just before the source network: IntGW=2 and ExtGW=1. The sum of these two fields tells how many routers are listed in the Update. All the interior gateways specified are listed first; therefore, if IntGW=2 and ExtGW=1, the first two routers listed are interior gateways and the last router listed is an exterior gateway. If you compare the Update message from 192.168.16.2 in Example 1-5 with Figure 1-3, you will see that the three networks reachable via Curly are listed last in the Update and are marked as exterior ”that is, they are reachable via a gateway exterior to Moe. Because stub gateways cannot advertise networks outside of their own AS, only Updates from core gateways can include exterior gateways.

The EGP Update message associates a distance with each network it lists. The distance field is 8 bits, so the distance can range from 0 to 255. RFC 904 does not specify how the distance is to be interpreted, however, other than that 255 is used to indicate unreachable networks. Nor does the RFC define an algorithm for using the distance to calculate shortest inter-AS paths. Cisco chooses to interpret the distance as hops, as shown in Example 1-5. The default rules are very basic:

• A gateway advertises all networks within its own AS as having a distance of 0.

• A gateway advertises all networks within an AS other than its own as having a distance of 3.

• A gateway indicates that a network has become unreachable by giving it a distance of 255.

For example, you can see in Example 1-5 and Figure 1-3 that although network 172.20.0.0 is one router hop away from Moe, Moe is advertising the network with a distance of 0 ”the same distance as network 172.17.0.0, which is directly attached. Network 10.0.0.0 is also one router hop away, and network 172.18.0.0 is two hops away, but both are in different autonomous systems and are therefore advertised with a distance of 3. The point is that the distance used by EGP is virtually useless for determining the best path to a network.

Example 1-6 shows the routing table of Shemp and the route entries resulting from the Update in Example 1-5.

Example 1-6 Shemp's Routing Table

 Shemp#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set  E    10.0.0.0 [140/4] via 192.168.16.2, 00:00:52, Ethernet0  C    192.168.16.0 is directly connected, Ethernet0  E    192.168.17.0 [140/1] via 192.168.16.2, 00:00:52, Ethernet0   E    192.168.18.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0   E    172.20.0.0 [140/1] via 192.168.16.4, 00:00:52, Ethernet0   E    172.16.0.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0   E    172.17.0.0 [140/1] via 192.168.16.2, 00:00:52, Ethernet0   E    172.18.0.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0  172.19.0.0 255.255.255.0 is subnetted, 1 subnets C       172.19.1.0 is directly connected, Loopback0 Shemp# 

There are two points of interest in the routing table. First, notice that the EGP entries have an administrative distance of 140. This is higher than the administrative distance of any IGP (with the exception of External EIGRP), so a router will always choose an IGP route over an EGP advertisement of the same network.

Second, notice that the distances to each of the EGP-advertised networks are one higher than the distances shown in the Update of Example 1-5. Cisco's EGP process increments the distance by one, just as a RIP routing algorithm does.

EGP Message Formats

EGP uses five different formats to encode the ten message types shown in Table 1-1. All the messages have a common header, as shown in Figure 1-4.

Figure 1-4. EGP Message Header

The fields in the EGP message header are defined as follows :

• Version ” Specifies the current EGP version number. If this number in a received message does not agree with the receiver's version number, the message is rejected. The version number of all current EGP implementations is 2.

• Type ” Specifies which of the five message formats follows the header. Table 1-2 (which appears after this list) shows the ten EGP message types and the type number used by each.

• Code ” Specifies the subtype. For example, if type = 5, the code specifies whether the message is a Hello or an I-Heard-You.

• Status ” Varies according to the message type (as with the Code field). For example, a Neighbor Acquisition message can use the status to indicate whether it is active or passive, whereas a Neighbor Reachability message can use the Status field to indicate an Up or Down state.

• Checksum ” The one's complement of the one's complement sum of the EGP message. This is the same error-checking algorithm used by IP, TCP, and UDP.

• Autonomous System Number ” Specifies the AS of the message's originator.

• Sequence Number ” Synchronizes message pairs (as described previously in this chapter). For example, an Update should always contain the same sequence number as the Poll to which it is responding.

Table 1-2. EGP Message Types

Type	Message
3	Neighbor Acquisition Request
3	Neighbor Acquisition Confirm
3	Neighbor Acquisition Refuse
3	Neighbor Cease
3	Neighbor Cease Acknowledgment
5	Hello
5	I-Heard-You
2	Poll
1	Update
8	Error

The Neighbor Acquisition Message (EGP Message Type 3)

Neighbor Acquisition messages are EGP message type 3. Table 1-3 shows the codes used to indicate the EGP message. Table 1.4, taken from RFC 904, shows the possible values of the Status field and the reasons a particular status might be used.

Table 1-3. Codes Used with Message Type 3

Code	Message
	Neighbor Acquisition Request
1	Neighbor Acquisition Confirm
2	Neighbor Acquisition Refuse
3	Neighbor Cease
4	Neighbor Cease Acknowledgment

Figure 1-5 shows the format of the Neighbor Acquisition message. The Hello Interval and Poll Interval fields are present only in the Neighbor Acquisition Request (code 0) and Neighbor Acquisition Confirm (code 1) messages. All other Neighbor Acquisition messages are identical to the message header, with no other fields included.

Figure 1-5. The Neighbor Acquisition Message

Table 1-4. Status Numbers Used with Message Type 3

Status	Description	Use
	Unspecified	When nothing else fits
1	Active mode	Request/Confirm only
2	Passive mode	Request/Confirm only
3	Insufficient resources	Out of table space Out of system resources
4	Administratively prohibited	Unknown autonomous system Use another gateway
5	Going down	Operator initiated stop Abort timeout
6	Perimeter problem	Nonsense polling parameters Unable to assume compatible mode
7	Protocol violation	Invalid command or response received in this state

• Hello interval ” The minimum interval, in seconds, between Hellos that the originator is willing to accept. The Cisco default Hello interval is 60 seconds and can be changed with the command timers egp.

• Poll interval ” The minimum interval, in seconds, between Polls that the originator is willing to accept. The Cisco default Poll interval is 180 seconds and can be changed with the command timers egp.

The Neighbor Reachability Message (EGP Message Type 5)

The Neighbor Reachability message (see Figure 1-6) is the EGP header, with Type = 5. No additional fields are included, because all necessary information is carried in the Code (see Table 1-5) and Status (see Table 1-6) fields.

Figure 1-6. The Neighbor Reachability Message

Table 1-5. Codes Used with Message Type 5

Code	Message
	Hello
1	I-Heard-You

Table 1-6. Status Numbers Used with Message Types 5 and 2

Status	Description
	Indeterminate
1	Up state
2	Down state

The Poll Message (EGP Message Type 2)

The only field that is added to the EGP header to create the Poll message (see Figure 1-7) is the IP Source Network, the network about which reachability information is being requested. The IP address encoded in this field is always a major Class A, B, or C network. The Code field is always 0, and the Status numbers used are the same as those described in Table 1-6. (RFC 888 shows the Status field as unused in the Poll and Error messages.)

Figure 1-7. The Poll Message

The Update Message (EGP Message Type 1)

As with the Poll message, the Code field of the Update is always 0. Table 1-7 shows the possible values of the Status field, which is the same as the values of Table 1-6 with the exception of the Unsolicited value.

Table 1-7. Status Numbers Used with Message Type 1

Status	Description
	Indeterminate
1	Up state
2	Down state
128	Unsolicited

The most significant bit of the Status field is the Unsolicited bit; if the bit is set (giving the field a value of 128), the Update is unsolicited. The Unsolicited bit can be used in combination with any of the other Status values.

The Update message includes a four-level hierarchy of lists. Figure 1-8 shows the format of the Update message and how the hierarchy of lists is organized.

Figure 1-8. The Update Message

At the highest level of the hierarchy is a list of all the routers that are directly attached to the source network. The number of gateways on the list is specified by the sum of the # of Interior Gateways and the # of Exterior Gateways fields.

At the next level, interior gateways are distinguished from exterior gateways. All interior gateways, including the originator, are listed first. If there are any exterior gateways, they are listed after the interior gateways.

At the third layer of the hierarchy, each listed gateway has a list of distances. As with the interior and exterior gateways, a field specifies the number of distances on the list.

Finally, for each listed distance there is a list of networks that can be reached at that distance and via that gateway. A field is included to specify the number of networks on the list.

The complete descriptions for the fields of the Update message format are as follows:

• # of Interior Gateways ” Specifies the number of interior gateways on the list.

• # of Exterior Gateways ” Specifies the number of exterior gateways following the list of interior gateways. The sum of this field and the # of Interior Gateways, shown as N in Figure 1-8, is the total number of gateways listed in the Update.

• IP Source Network ” Specifies the network about which reachability information is being supplied. That is, all networks listed in the Update are reachable via a gateway attached to this network. The IP address encoded in this field is always a major Class A, B, or C network.

• Gateway IP Address ” Specifies the address of a gateway attached to the source network. Only the host portion of the major Class A, B, or C address is listed; as a result, the length of the field is variable from 1 octet for a Class C address to 3 octets for a Class A address. The network portion of the address is already known from the IP Source Network field.

• # of Distances ” Specifies the total number of distances being advertised under the listed gateway.

• Distance ” Specifies a particular distance advertised under the listed gateway.

• # of Networks ” Specifies the total number of networks advertised under the listed distance of the listed gateway.

• Network ” Specifies the IP address of the network being advertised. In Figure 1-8, each network is shown as belonging to a particular gateway, a particular distance, and a particular order in the network list. Like the Gateway IP Address field, the Network field is variable. Unlike the Gateway IP Address field, the Network field lists the network portion rather than the host portion of a major Class A, B, or C address.

The Error Message (EGP Message Type 8)

A gateway can send an Error message (see Figure 1-9) at any time to notify a sender of a bad EGP message or an invalid field value. The Code field of the error message is always 0, and the Status is one of the values described in Table 1-7.

Figure 1-9. The Error Message

NOTE

RFC 888 shows the Status field in the Error message (like in the Poll message) as unused. RFC 904 specifies the uses shown in Table 1-7.

The originator of the Error message can use an arbitrary value as the sequence number. Table 1-8, which is taken from RFC 904, describes the possible values of the Reason field. The Error message header is the first 12 octets of the EGP message that prompted the Error message.

Table 1-8. Values of the Reason Field of the Error Message

Reason Field Value	Description	Use
	Unspecified	When nothing else fits.
1	Bad EGP header format	Bad message length. Invalid Type, Code, or Status field.
2	Bad EGP Data field format	Nonsense polling rates (Request/Confirm). Invalid Update message format. Response IP Network Address field does not match command (Update).
3	Reachability info unavailable	No information available on the network specified in the IP Network Address field (Poll).
4	Excessive polling rate	Two or more Hello messages received within the Hello interval. Two or more Poll messages received within the Poll interval. Two or more Request messages received within some (reasonably short) interval.
5	No response	No Update received for the Poll within some (reasonably long) interval.