OSPF Media Types

‚  < ‚  Free Open Study ‚  > ‚  

OSPF runs on several media types. On some media, such as multiaccess and point-to-point media, the OSPF default network type is used. Therefore, there is no need to configure any network type on those media.

This section goes into detail on each medium type in OSPF and what network type to use for each medium. For OSPF, media can be divided into four categories:

  • Multiaccess media

  • Point-to-point media

  • Nonbroadcast multiaccess media

  • Demand circuits

Multiaccess Media

Multiaccess media includes Ethernet, Fast Ethernet, Gigabit Ethernet, FDDI, Token Ring, and similar multiaccess media. OSPF runs as a broadcast network type over these media. The OSPF network type of broadcast is on by default over these media.

In this network type, the DR and the BDR are elected to reduce the flooding on the segment. The multicast capabilities of OSPF are used to form adjacencies and to efficiently distribute the information to other routers on the segment. In broadcast network types, the interface subnet mask is checked in the Hello packet. If the masks of the two routers are different, an adjacency will not be formed .

Because this network type is on by default, no specific configuration is required for this media. Figure 8-25 shows an example of OSPF run over multiaccess media. Router A is elected as a DR because it has the highest priority. Router B is elected as the BDR. The priorities of both Routers B and C are equal; therefore, the BDR election is based on the highest router ID. All the routers will form an adjacency with the DR and the BDR. The DR and the BDR will listen specifically to the multicast address of 224.0.0.6 (all DR routers), while all other routers will listen to the multicast address of 224.0.0.5 (all SPF routers).

Figure 8-25. Multiaccess Media Example

graphics/08fig25.gif

Point-to-Point Media

Point-to-point media includes HDLC and PPP encapsulation links, Frame Relay/ATM point-to-point subinterfaces, and similar point-to-point interfaces.

The OSPF network type of point-to-point is on by default on these media. No DR or BDR election takes place on this medium type. All the OSPF packets are multicast-based. The reason for sending all OSPF packets as multicast is that, in some cases of unnumbered links, the destination address is not known. Figure 8-26 shows an example of point-to-point media. Router A is attached to three other routers through point-to-point links. Router A will form a full adjacency with Routers B, C, and D.

Figure 8-26. Point-to-Point Media Example

graphics/08fig26.gif

Nonbroadcast Multiaccess Media

Many media fall under this category of nonbroadcast multiaccess (NBMA), including Frame Relay, X.25, SMDS, and ATM. Additional configuration is required for this type of medium. The OSPF network type on these media is nonbroadcast, by default. Several network type options can be defined in this scenario. This medium can be run in several modes under OSPF:

  • Broadcast model

  • Point-to-point model

  • Point-to-multipoint model

Broadcast Model

In the broadcast model, the broadcast network is simulated. DRs and BDRs are elected. The broadcast model can be simulated in two ways:

  • Configure the network-type broadcast.

  • Configure the neighbor statement.

Figure 8-27 shows the NBMA network model. The medium is Frame Relay between routers. Router A has connectivity to all other routers; however, Routers B, C, D, and E are connected only to Router A, not to each other, through Frame Relay PVCs. The only time the broadcast model works here is when all routers are fully meshed. In a partially meshed situation, as shown in Figure 8-27, running a broadcast model is not recommended.

Figure 8-27. NBMA Media Example

graphics/08fig27.gif

Assuming that there is fully meshed Frame Relay connectivity, Example 8-20 shows the configuration that is required on all the routers. This configuration changes the network type of the router's Frame Relay interface to broadcast. One important thing to note here is that, in case of a static Frame Relay mapping, the keyword broadcast must be used at the end; otherwise , the OSPF multicast Hello will not go across the Frame Relay connection.

Example 8-20 Configure the Network Type as Broadcast
 RouterA#  interface serial 0   encapsualtion frame-relay    ip ospf network-type broadcast   

The command ip ospf network-type broadcast must be configured on all the routers' Frame Relay interfaces.

Another way to simulate the broadcast model is through the neighbor statement, as shown in Example 8-21. The neighbor statement must be configured manually in the hub router, which is Router A in this case. Router A must be configured with a higher priority so that it can always be the DR.

Example 8-21 Configuring the neighbor Statement on the Hub Router
 RouterA#  interface serial 0   encapsulation frame-relay   ip address 141.108.1.1 255.255.255.0    ip ospf priority 10    !   router ospf 1    neighbor 141.108.1.2     neighbor 141.108.1.3     neighbor 141.108.1.4     neighbor 141.108.1.5   
Point-to-Point Model

If the point-to-point model is used, each PVC must be defined as a separate point-to-point subinterface; therefore, a separate subnet for each point-to-point subinterface is needed. Example 8-22 shows the configuration required at the hub Router A to create point-to-point subinterfaces. No network type is needed under the subinterface because, by default, all subinterfaces have a point-to-point network type. The physical topology remains the same as that shown in Figure 8-27.

The advantage of this model is that virtual circuit (VC) cost can be configured on a per-interface basis. The disadvantage is that a lot of address space is wasted on every point-to-point subinterface. In addition, the size of the router LSA created by Router A will be fairly large because it must include a Type 3 stub link for every point-to-point link.

Example 8-22 Configuring Point-to-Point Subinterfaces
 RouterA#  Interface Serial 0.1 point-to-point  ip address 141.108.1.1 255.255.255.252 !  Interface Serial 0.2 point-to-point  ip address 141.108.1.5 255.255.255.252 

Similarly, other subinterfaces can be created.

Point-to-Multipoint Model

In a point-to-multipoint model, each router that has connectivity with another router forms an adjacency with that router. No DR or BDR is elected in this network type. Muticast Hellos are sent to discover neighbors, so it is essential that Layer 2 must support multicast/broadcast capability. Also, only one subnet is required for the whole NBMA cloud, as shown in Figure 8-27.

Example 8-23 shows the configuration required for the point-to-multipoint network type. Router A's Serial 0 is configured for point-to-multipoint network type. This net-work type must be configured on all the remote Routers B, C, D, and E.

Example 8-23 Configuration for Point-to-Multipoint Network Type
 RouterA#  interface serial 0   encapsulation frame-relay   ip address 141.108.1.1 255.255.255.0    ip ospf network-type point-to-multipoint   

This is the recommended network type to use in non ‚ fully meshed NBMA networks. Sometimes, a medium is NBMA but is not capable of supporting multicast, so point-to-multipoint network type cannot be used. For this kind of medium, another network type has been introduced, called point-to-multipoint nonbroadcast. Assuming in Figure 8-27 that the NBMA network does not support multicast capabilities, this new type can be used. Example 8-24 shows the configuration required for this network type. This network type is configured only on Serial 0 on Router A, but it must be configured on all the remote router's serial interfaces. The neighbor statement is required for this network type, but a DR and BDR will not be elected.

Example 8-24 Configuring Point-to-Multipoint Nonbroadcast Network Type
 RouterA#  interface serial 0   encapsulation frame-relay   ip address 141.108.1.1 255.255.255.0    ip ospf network-type point-to-multipoint non-broadcast    !   router ospf 1    neighbor 141.108.1.2     neighbor 141.108.1.3     neighbor 141.108.1.4     neighbor 141.108.1.5   

Demand Circuits

The demand circuit option was introduced as of Cisco IOS Software Release 11.2. With demand circuits, an adjacency is formed and all the databases are exchanged at the beginning. Then after the dead timer kicks in, the adjacency remains up even after the Layer 2 goes down. This is useful when you have to pay unnecessary toll charges to keep the link in use. ISDN is a prime example of a situation in which a demand circuit can be used. As long as the ISDN link is up, you must pay for the link.

The main characteristics of a demand circuit that make it different from a normal circuit are as follows :

  • Periodic Hellos are suppressed.

  • Periodic LSAs refreshes are suppressed.

Periodic Hellos are suppressed only on point-to-point and point-to-multipoint network types. All other network type Hellos still are sent over the interface.

The periodic LSA refresh that takes place every 30 minutes will not happen with a demand circuit because when the demand circuit link is established, a unique option bit, the DC bit or Do Not Age (DNA) bit (discussed earlier in the "Hello Packets" section), is sent across. If two routers negotiate the DC bit successfully, they make a note of it and set a specific bit in the LSA Age field that is the most significant bit. By setting this bit, the LSA stops aging over the demand circuit, so no periodic updates are sent.

In two normal scenarios the periodic refresh of the LSA will be sent:

  • If there is a change in network topology

  • If there is a router in OSPF domain that cannot understand demand circuits

In the first case, not much can be done because the router must send the new LSA infor-mation to update the neighbor about the topology change. In the second case, however, there is a special way to handle this situation.

The ABR, which is the router between A and C in Figure 8-28, knows that Router C is incapable of understanding DNA LSAs because it sees the options in the LSA originated by Router C and because the DC bit is clear in the Option field. When this situation occurs, the ABR indicates to the demand circuit ‚ capable routers not to originate the LSA with the DNA bit set because there is a router that does not understand the DNA bit. The ABR originates an indication LSA in the backbone, telling everyone in the backbone not to originate any DNA LSAs. This indication LSA is shown in Example 8-25. This is a Type 4 summary LSA in which the link-state ID is the ABR itself instead of the ASBR.

Figure 8-28. Scenario in Which the Periodic LSA Refresh Will Be Sent Across a Demand Circuit

graphics/08fig28.gif

Example 8-25 Indication LSA Example
 RouterA#  show ip ospf database asbr-summary  Adv Router is not-reachable   LS age: 971   Options: (No TOS-capability, No DC)   LS Type: Summary Links(AS Boundary Router)  Link State ID: 141.108.1.129 (AS Boundary Router address)   Advertising Router: 141.108.1.129  LS Seq Number: 80000004   Checksum: 0xA287   Length: 28   Network Mask: /0  TOS: 0  Metric: 16777215  

The metric of indication LSA is set to infinity, and the link-state ID is always the router ID of the ABR originating the indication LSA. In Figure 8-28, the link between Routers A and B is configured as a demand circuit, but because there is a router in Area 1 that is incapable of understanding the DNA LSA, no DNA LSA will be originated by Area 2. As a result, the periodic refresh of the LSAs will be sent across the demand circuit.

As a solution, configure Area 1 as a stub or NSSA area. This is because of section 2.5.1 of the Demand Circuit RFC 1793 that states: "LSAs in regular OSPF areas are allowed to have DoNotAge set if and only if every router in the OSPF domain (excepting those in stub areas and NSSAs) is capable of DoNotAge processing." So, if Area 1 is defined as stub or NSSA, LSA in Area 2 will be allowed to have LSA with DNA bit set.

Another recommendation is to always include a demand circuit in a nonbackbone area. If a situation arises similar to the one shown in Figure 8-28 and the demand circuit is also a part of the backbone, there is no solution for this because the backbone area cannot be configured as a stub or NSSA area. The advantage of configuring demand-circuit in a stub area is that if there are any routers in a remote OSPF area that cannot understand the DNA LSA, the indication LSA that will be generated by the ABR can never enter into the stub area. Therefore, the demand-circuit capable routers can still generate the LSA with DNA bit set within the area. Example 8-26 shows the configuration necessary to make a circuit a demand circuit. Only one side is required to have the demand circuit command under the interface because, if the other side is capable of understanding demand circuits, it auto-matically negotiates this capability in the Hello packet; otherwise, it simply ignores this option.

Example 8-26 Configuring a Demand Circuit
 RouterA# interface serial 0  encapsulation frame-relay  ip address 141.108.1.1 255.255.255.0  ip ospf network-type point-to-multipoint   ip ospf demand-circuit  

A demand circuit can be run on any network type. The difference is that, without a point-to-point or point-to-multipoint network type, the Hellos will not be suppressed; however, these media types can still use the flooding robustness of demand circuit, and the LSA will not age out over that demand circuit links.

OSPF Media Type Summary

Table 8-4 explains the default value for each type of medium and gives the recommended network type.

Table 8-5. Media Type with Possible OSPF Network Types
Media Types Default OSPF Network Type Recommended OSPF Network Type
Multiaccess Broadcast Broadcast
Point-to-point Point-to-point Point-to-point
Nonbroadcast multiaccess (NBMA) Nonbroadcast Nonbroadcast, point-to-multipoint, point-to-multipoint nonbroadcast, point-to-point
Demand circuits Point-to-point, point-to-multipoint
‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

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