Section 4.3. Adjacencies


4.3. Adjacencies

As you progress through this book, you will learn that IS-IS and OSPF have quite a few optional capabilitiesparticularly OSPF. Before two neighbors that have discovered each other can begin exchanging routing information, they must ensure that they understand each other's capabilities. Otherwise, some of the information exchanged might be misunderstood, or interpreted differently between the two neighbors, resulting in inaccurate or broken routing. Additionally, the neighbors must ensure that they agree on some basic parameters such as that they are on the same IP subnet, that their interface MTUs are the same, how often each neighbor should expect a Hello message from the other, and so on.

To ensure that two IS-IS or OSPF neighbors can reliably exchange routing information, they form an adjacency. An adjacency can be thought of as a negotiated agreement between neighbors that essential subnet parameters match and that the information they exchange will be correctly interpreted. If the two neighbors cannot agree on a defined set of parameters and options, they do not become adjacent and they do not consider each other as valid next hops toward other routers.

4.3.1. OSPF Adjacencies

After discovering a neighbor, an OSPF router must verify that bidirectional communication is possible with the neighbor, through a mechanism called three-way handshaking. Figure 4.20 expands on the basic example of three-way handshaking you saw in Chapter 2. RB has just become active on the subnet shared with RA, and is not yet aware of RA. So, in its first Hello, the neighbor list is empty. RA, having received that first Hello from RB, sends a Hello of its own. Notice that it includes RB's RID in its neighbor list. RB, when it receives the Hello, not only has discovered RA but sees its RID in the neighbor list and knows that there is two-way communication with RA. In the third Hello shown, RB has added RA's RID to the neighbor list. When RA receives this Hello, it likewise knows that two-way communication with RB is established.

Figure 4.20. Three-way handshaking verifies two-way communication.


After two-way communication is established, and if the network type connecting the two neighbors is broadcast or nonbroadcast multi-access (NBMA), a designated router and backup designated router election is performed. Section 4.4 covers the mechanics of DR and BDR election.

Next, the neighbors decide whether an adjacency should be formed between them. If the network type connecting them is point to point, point to multipoint, or a virtual link (discussed in Section 4.2.3), the routers should form an adjacency. If the network type is broadcast or NBMA, an additional consideration is made: An adjacency is formed only if one of the neighbors is a DR or BDR.

If the two neighbors decide that an adjacency should be formed, they begin synchronizing their link state databases. Only after the databases are synchronized are OSPF neighbors fully adjacent. In OSPF, both the neighbor relationships and the database synchronization are driven by state machines. The neighbor state machine and database synchronization are detailed in Chapter 6.

Throughout the OSPF adjacency formation process, from neighbor discovery to database synchronization, certain parameters must be verified as matching. If any of them do not, the adjacency is not established. Most of these parameters are in the Hello messages, and are checked when a neighbor's Hello is received. First, the IP header and OSPF headers of the Hello packet are checked for validity. Next, the values in the Hello Interval and Router Dead Interval fields are checked. If these values do not match the values of the receiving interface, no adjacency is formed. On all network types except point-to-point and virtual links, the Network Mask is also checked and must match the mask configured on the interface. On point-to-point networks and virtual links, the Network Mask field is ignored.

In addition to such standard parameters that must match between any two OSPF neighbors, certain optional capabilities, if supported by one neighbor, must be supported by the other neighbor. A router indicates which optional capabilities it supports in the Options field, which was shown in Figure 4.9. The Options field appears not only in the Hello message header, but also in the headers of Database Description packets and all LSAs. As this varied appearance might indicate, flags in this field are examined at various points during the database synchronization and adjacency process. Some options must match for a neighbor's Hello packets to be accepted at all, whereas other mismatched options can be ignored or negotiated between the neighbors. Full use of the Options field is explained in Chapter 6, but for now it is sufficient to say that some of the options flags in the Hello header are examined during the initial neighbor discovery.[3]

[3] If you simply cannot wait until Chapter 6 to find out, the E (External Routing Capability) in the Hello's Options field must match. This flag is used to enforce the rules of stub areas (see Chapter 7), and if the flags do not match between neighbors the Hello messages are rejected.

After examining the parameters carried in the Hello message, a decision is made whether to continue attempting to form an adjacency. If the decision is positive, the Hello messages provide input events to the OSPF neighbor state machine and the adjacency process continues.

So, When Are OSPF Neighbors Adjacent?

The use of the term adjacent can be confusing in OSPF documentation. In some places, neighbors are called adjacent as soon as they discover each other. In others, you are told that successful database synchronization is prerequisite to an adjacency. Which is right?

Neighbors are adjacent when they discover each other, but are not fully adjacent until they complete the database synchronization process as described in Chapter 6. It is a subtle difference in terminology for what is in practice a big difference in the state of the neighboring routers, but that is what we are given.


4.3.2. IS-IS Adjacencies

Defining IS-IS adjacencies can be a bit confusing if you try to glean the definition from the documentation. ISO 10589 defines an adjacency as "The subset of the local routing information base pertinent to a single neighbor." And it defines the routing information base as the combination of the link state database and the forwarding database. This implies that two IS-IS neighbors are adjacent only after their databases have been synchronized, just as with OSPF. However, when you read further in the spec, it becomes apparent that operationally, IS-IS neighbors consider themselves adjacent when two-way communication has been established and before database synchronization has taken place. But ISO 10589 is not self-contradictory in its definitions. As you will see in Chapter 6, OSPF uses a complex, state-machine-driven process to synchronize its databases, whereas IS-IS database synchronization is a much simpler process. There is an assumption that if two neighbors have two-way communication, they can synchronize their databases. Much of this assumption has to do with the fact that the rules for accepting IS-IS LSPs are more flexible and forgiving than those for accepting OSPF LSAs.

Therefore, it is proper to say that IS-IS neighbors are adjacent after they establish bidirectional communication.

Two kinds of adjacency can be formed by IS-IS: L1 adjacencies, between two neighbors whose area IDs are the same, and L2 adjacencies, between two neighbors that have the same or different AIDs. Recall from the discussion accompanying Table 4.1 earlier in this chapter that the Circuit Type field on the IS-IS Hello can be one of three values:

  • 1 means the originator accepts only L1 adjacencies.

  • 2 means the originator accepts only L2 adjacencies.

  • 3 means the originator accepts both L1 and L2 adjacencies.

Recall also that IS-IS uses two types of Hello messages: LAN Hellos and Point-to-Point Hellos. Routers treat these two types somewhat differently, so we will examine adjacencies on broadcast networks first, and then look at adjacencies on point-to-point networks.

4.3.2.1. IS-IS Adjacencies on Broadcast Networks

A LAN Hello, as you read earlier, can be either an L1 or L2 Hello. A router's IS-IS interface can be configured as L1 only, L2 only, or both. This determines what kind of Hello the router originates, and whether the router listens for messages whose destination LAN address is AllL1ISs (0180.c200.0014), AllL2ISs (0180.c200.0015), or both.

Two TLVs included in LAN Hellos are essential for forming adjacencies: the IS Neighbors TLV (Figure 4.14) and the Area Addresses TLV (Figure 4.13). The IS Neighbors TLV is used for three-way handshaking, and the Area Addresses TLV is used along with the Circuit Type field to determine the type of adjacency to form.

IS-IS routers keep track of adjacencies in an adjacency database, and reference them by SysID. The initial state of an adjacency is "Down." In this state, the router is sending LAN Hellos on the interface but has not heard any Hellos from neighbors. When a LAN Hello is received, the source MAC address of the LAN Hello is recorded in the adjacency database as the SNPA, and the adjacency state is changed to "Initializing." This state signifies that the neighbor is known, but that bidirectional communication has not yet been verified. The router then includes the neighbor's SNPA in the IS Neighbors TLV in its own LAN Hellos. When the router sees its own interface MAC address in the IS Neighbors TLV of the neighbor's Hellos, it knows that bidirectional communication has been verified. It can then change the state of the adjacency to "Up." But before that can happen, the two neighbors must agree on the type of adjacency to establish.

When an L1 LAN Hello is received, the router checks the AIDs listed in the Area Addresses TLV against its own configured AIDs. If one or more AIDs match, the router accepts an L1 adjacency to the originating neighbor. If no AIDs match, the adjacency is rejected. When an L2 LAN Hello is received, the router does not check the AID list; it just accepts an L2 adjacency to the originating neighbor.

These variables open up several possible results, based on the interface configurations of the originator and receiver of the Hellos and the configured AIDs of the originator and receiver. To demonstrate the possible results, suppose two routers R1 and R2 are connected over an Ethernet link. In the first example, the routers are both configured as L1-only and with the same AIDs. The result is an L1 adjacency:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Up            19               0:90:27:5b:88:51 

If one of the AIDs is changed so that they no longer match, the L1 adjacency is no longer valid:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Rejected      22               0:90:27:5b:88:51 

But, if the routers are changed to L2 only, and the conflicting AIDs remain, an L2 adjacency is established:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              2 Up            19               0:90:27:5b:88:51 

If the AIDs are changed so that they again match, and the routers remain L2 only, an L2 adjacency remains:

jeff@R1> show isis adjacency brief Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              2 Up            20               0:90:27:5b:88:51 

If one router is L1 only while the other is L2 only, an adjacency is not established, whether the AIDs match or not:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              2 Down          23               0:90:27:5b:88:51 

Next, the routers are given the same AIDs, but R1 is L1 only whereas R2 is configured to accept both L1 and L2 adjacencies. R2 receives only an L1 LAN Hello from R1, and so accepts just an L1 adjacency:

jeff@R2> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R1              1 Up            8                0:90:27:9d:f1:38 

But because R2 is configured for both L1 and L2, it sends both L1 and L2 LAN Hellos. R1, which is configured as L1 only, reflects this in its adjacency database by accepting the L1 adjacency and rejecting the L2 adjacency:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Up            23               0:90:27:5b:88:51 fe-0/0/2.0      R2              2 Rejected      18               0:90:27:5b:88:51 

Using the same configuration as before but with mismatched AIDs, no adjacencies are accepted. R1 cannot accept an L1 adjacency because the AIDs are different, and cannot accept an L2 adjacency because it is configured as L1 only:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Rejected      8                0:90:27:5b:88:51 fe-0/0/2.0      R2              2 Rejected      9                0:90:27:5b:88:51 

The next example is similar to the previous two, except that R1 is now configured as L2 only. Again, R2 is sending out both L1 and L2 LAN Hellos. R1 rejects the L1 adjacency, whether the AIDs are mismatched or not, but accepts the L2 adjacency in both cases:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Rejected      12               0:90:27:5b:88:51 fe-0/0/2.0      R2              2 Up            22               0:90:27:5b:88:51 

If R1 and R2 are both configured to accept both L1 and L2 adjacencies, and the AIDs match, both L1 and L2 adjacencies are accepted:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Up            21               0:90:27:5b:88:51 fe-0/0/2.0      R2              2 Up            21               0:90:27:5b:88:51 

However, if the AIDs do not match, the L1 adjacency is again rejected:

jeff@R1> show isis adjacency Interface       System          L State         Hold (secs)      SNPA fe-0/0/2.0      R2              1 Rejected      10               0:90:27:5b:88:51 fe-0/0/2.0      R2              2 Up            25               0:90:27:5b:88:51 

Table 4.2 summarizes the results of all these examples.

Table 4.2. Summary of Different L1/L2 and Area ID Combinations

R1 Type

R1 AID

R2 Type

R2 AID

Adjacency

L1-only

47.0001

L1-only

47.0001

L1

L1-only

47.0001

L1-only

47.0002

None

L2-only

47.0001

L2-only

47.0002

L2

L2-only

47.0001

L2-only

47.0002

L2

L1-only

47.0001

L2-only

47.0002

None

L1-only

47.0001

L2-only

47.0001

None

L1-only

47.0001

Both

47.0001

L1

L1-only

47.0001

Both

47.0002

None

L2-only

47.0001

Both

47.0001

L2

L2-only

47.0001

Both

47.0002

L2

Both

47.0001

Both

47.0001

L1 and L2

Both

47.0001

Both

47.0002

L2


All of the examples you have seen here concern the relationship between just two routers. But an Ethernet network, or other type of LAN network, can have many routers attached to the same broadcast medium. It is possible for a set of routers sharing a common link to be configured with a variety of Circuit Type values and AIDs, resulting in several different adjacency relationships on the same link. A very diverse set of IS-IS configurations on a single link is unusual in practice, but it could happen. To understand such a network, it is necessary to understand how each router sees its adjacencies in relation to every other router in the link.

4.3.2.2. IS-IS Adjacencies on Point-to-Point Networks

The rules for forming adjacencies between two neighbors across point-to-point links are almost identical to the rules between any two neighbors on a LAN link, with one difference: Unlike LAN Hellos, Point-to-Point Hellos do not have an IS Neighbors TLV for verifying bidirectional communication. The original IS-IS specification in ISO 10589 simply forgoes the three-way handshake and requires that the underlying point-to-point medium be reliable. This is hardly a safe bet, so an extension that allows IS-IS three-way handshaking on point-to-point links has been specified in RFC 3373. This extension uses a Point-to-Point Three-Way Adjacency TLV, shown in Figure 4.21.

Figure 4.21. The Point-to-Point Three-Way Adjacency TLV.


When an IS-IS router supports the three-way option, it looks for the Three-Way Adjacency TLV in the Hellos of its neighbors. The absence of this TLV means that the neighbor does not support the option; in this case, the router reverts to the standard ISO two-way handshake. Normal behavior for IS-IS is to ignore TLVs it does not understand. So, if an ISIS router that does not support the three-way option receives a Point-to-Point Hello from a router that does, the Three-Way Adjacency TLV is just ignored.

If a router that supports the option has not received a Point-to-Point Hello containing a valid Three-Way Adjacency TLV on a particular interface, the three-way adjacency state of the interface is "Down." In its Hellos transmitted on that interface it indicates the three-way state of "Down" with a value of 2 in the Adjacency Three-Way State field, and includes its circuit ID for the connected circuit in the Extended Local Circuit ID field.

When the router receives a Hello that includes a valid Three-Way Adjacency TLV, but the router does not see its System ID in the Neighbor System ID field and its local circuit ID in the Neighbor Extended Local Circuit ID field, it changes the three-way state for that interface to "Initializing." The router makes note of the neighbor's SysID from the Source ID field in the Hello, and the neighbor's local circuit ID from the relevant field in the Hello or the Extended Local Circuit ID in the TLV. These values are then included in the Neighbor System ID and Neighbor Extended Local Circuit ID fields of its own subsequent Hellos, and the value of the Adjacency Three-Way State field is changed to 1, indicating the Initializing state.

When the router receives a Hello with its own SysID in the Neighbor System ID field and its local circuit ID in the Neighbor Extended Local Circuit ID field, it changes the three-way adjacency state to Up. The Up state is also signaled in subsequent Hellos with a value of 0 in the Adjacency Three-Way State field.

You surely noticed that the three possible states of the three-way adjacency, Down, Initializing, and Up, seem to be the same three states in the standard ISO-prescribed adjacency. They are not the same states. An IS-IS router can have both an adjacency state and a three-way state, to be backward compatible with neighbors that do not support the three-way option. So, a router that receives a Point-to-Point Hello with no Three-Way Adjacency TLV will transition its adjacency state to Up, while its three-way adjacency remains Down.

You probably are wondering about the word extended that is associated with the Local Circuit ID fields in the TLV. Notice that the fields in the TLV are 4 bytes long. This is a byproduct of the new TLV that overcomes a limitation of the original IS-IS specification, in which a router could only support 256 interfaces, because of the 1-byte Local Circuit ID field in the point-to-point Hello (Figure 4.12). Chapter 8 discusses this extended capability in more detail.

And, one last detail you might be puzzling over: Why is it necessary for the two neighbors to advertise their local circuit IDs in the TLV, when an exchange of SysIDs should suffice for three-way handshaking? Consider a case where the point-to-point link is moved to another interface, either on the same router or on a different router, and the move happens in such a way that no link-down condition is reported by the link's physical layer. Suppose further that the new interface has the same Circuit ID as the previous interface, or the new router has the same SysID as the previous router. Such a circumstance is highly unlikely, but if you have worked with large networks for any time, you know that "unlikely" does not mean "impossible." By including both the SysID and the local Circuit ID in the TLV, such changes are more likely to be detected and cause a proper break in the existing adjacency.

When an adjacency is established, the local router sets the holding time for the adjacency to the value of the holding time in the neighbor's Hello. On broadcast networks the neighbor priority also is set according to the value of the Priority field in the LAN Hello. And, the area addresses in the Area Addresses TLV are associated with the neighbor in the adjacency database. If any of these three variables changes in subsequent Hellos received from the neighbor, the adjacency database is updated to reflect the changes. This is a significant difference from OSPF: Two IS-IS neighbors can have different advertised holding times, priorities, and lists of area addresses.

In OSPF, the hello times and router priorities must match for the adjacency to be accepted. Perhaps more important, with IS-IS these values can change from one Hello to the next. Because of this variability, the IS-IS values can be changed "on-the-fly," whereas OSPF adjacencies fail until the changes are made on both sides of the adjacencies, requiring scheduled downtime to make such changes.




OSPF and IS-IS(c) Choosing an IGP for Large-Scale Networks
OSPF and IS-IS: Choosing an IGP for Large-Scale Networks: Choosing an IGP for Large-Scale Networks
ISBN: 0321168798
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Jeff Doyle

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net