Changing the Network Type on an Interface

Problem

You want to change the default OSPF network type on an interface.

Solution

OSPF supports several different types of logical networks on interfaces. The default values are often exactly what you want, but it is sometimes useful to change them:

Router9#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router9(config)#interface FastEthernet0/0
Router9(config-if)#ip ospf network ?
 broadcast Specify OSPF broadcast multi-access network
 non-broadcast Specify OSPF NBMA network
 point-to-multipoint Specify OSPF point-to-multipoint network
 point-to-point Specify OSPF point-to-point network

Router9(config-if)#

 

Discussion

Before altering the OSPF network type on an interface, it is useful to understand the differences between the different network types and what the defaults are. Table 8-3 shows the default OSPF network types for a variety of common media.

Table 8-3. OSPF default network types for several common media

Media type Type or layer 2 encapsulation Default OSPF network
Serial, ISDN, Async, Dialer HDLC Point-to-point
  PPP Point-to-point
  LAPB Point-to-point
  Frame Relay Nonbroadcast
  ATM-DXI Nonbroadcast
  X.25 Nonbroadcast
  SMDS Nonbroadcast
ATM N/A Nonbroadcast
Point-to-point subinterface Frame Relay, ATM, etc. Point-to-point
Multipoint subinterface Frame Relay, ATM, etc. Nonbroadcast
Ethernet, FastEthernet, GigabitEthernet N/A Broadcast
Ethernet VLAN, Subinterface ISL, dot1Q Broadcast
Loopback N/A Loopback
Tunnel N/A Point-to-point

The configuration example in the Solutions section above shows the different available options that you can set on an interface:

Router9(config)#interface FastEthernet0/0
Router9(config-if)#ip ospf network ?
 broadcast Specify OSPF broadcast multi-access network
 non-broadcast Specify OSPF NBMA network
 point-to-multipoint Specify OSPF point-to-multipoint network
 point-to-point Specify OSPF point-to-point network

These four keywords control two main factors: whether or not the medium is capable of supporting broadcast or multicast packets, and whether it is necessary to elect a Designated Router (DR) for the network.

The broadcast keyword means that the network does support broadcasts, and that it requires a DR. In this case, because the routers can communicate by means of broadcasts (and implicitly also multicasts), they can make use of the well-known reserved OSPF multicast addresses 224.0.0.5 and 224.0.0.6. traffic addressed to the first of these addresses is received by every OSPF router on the network segment. Traffic addressed to the latter address is received only by the DR and BDR.

Although the broadcast network type requires that all of the OSPF routers on the segment establish adjacencies with one another and that they elect a DR and BDR, they are able to do both of these actions automatically without further configuration.

The nonbroadcast keyword specifies that this network is Nonbroadcast Multiple Access (NBMA). This means that there could be several OSPF devices on the network, but that they cannot use the standard multicast addresses to communicate with one another. Because there are potentially several OSPF devices on the network, they must have a DR and a BDR for scalability reasons, but all OSPF packets between the routers must be unicast. As a result, with this network type, you will need to manually configure OSPF neighbors with the neighbor command.

To demonstrate the options, we will use a series of Frame Relay examples. For more information on Frame Relay, please refer to Chapter 10:

Router9#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router9(config)#interface Serial0/0
Router9(config-if)#ip address 192.168.10.9 255.255.255.0
Router9(config-if)#encapsulation frame-relay
Router9(config-if)#frame-relay map ip 192.168.10.2 123 broadcast
Router9(config-if)#exit
Router9(config)#router ospf 1
Router9(config-router)#network 192.168.10.0 0.0.0.255 area 0
Router9(config-router)#neighbor 192.168.10.2
Router9(config-router)#exit
Router9(config)#end
Router9#

We also need to configure a corresponding neighbor command on the other router:

Router2(config)#router ospf 1
Router2(config-router)#network 192.168.10.0 0.0.0.255 area 0
Router2(config-router)#neighbor 192.168.10.9

Then these two routers are able to establish an OSPF adjacency:

Router9#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.15.3 1 FULL/BDR 00:01:43 192.168.10.2 Serial0/0
Router9#

In this case, because we have left the default OSPF network type for a Frame Relay interface, it is assumed to be nonbroadcast:

Router9#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
 Internet Address 192.168.10.9/24, Area 0
 Process ID 1, Router ID 172.19.2.1, Network Type NON_BROADCAST, Cost: 64
 Transmit Delay is 1 sec, State DR, Priority 1
 Designated Router (ID) 172.19.2.1, Interface address 192.168.10.9
 Backup Designated router (ID) 192.168.15.3, Interface address 192.168.10.2
 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
 oob-resync timeout 120
 Hello due in 00:00:29
 Index 1/2, flood queue length 0
 Next 0x0(0)/0x0(0)
 Last flood scan length is 1, maximum is 1
 Last flood scan time is 0 msec, maximum is 0 msec
 Neighbor Count is 1, Adjacent neighbor count is 1
 Adjacent with neighbor 192.168.15.3 (Backup Designated Router)
 Suppress hello for 0 neighbor(s)
Router9#

If we change the OSPF network type to point-to-multipoint, the router will start to treat each Frame Relay PVC on the interface as a separate point-to-point link. In this case, there is no need for a DR or BDR, and we also don't need to manually configure the neighbors:

Router9(config)#interface Serial0/0
Router9(config-if)#ip address 192.168.10.9 255.255.255.0
Router9(config-if)#encapsulation frame-relay
Router9(config-if)#frame-relay map ip 192.168.10.2 123 broadcast
Router9(config-if)#ip ospf network point-to-multipoint
Router9(config-if)#exit
Router9(config)#router ospf 1
Router9(config-router)#network 192.168.10.0 0.0.0.255 area 0
Router9(config-router)#exit

Now the router is able to able to automatically find its neighbor:

Router9#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.15.3 0 FULL/ - 00:01:47 192.168.10.2 Serial0/0
Router9#

There is another option available for the point-to-multipoint network type. You will notice that we have deliberately configured the broadcast keyword on our frame-relay map command. This keyword tells the router to forward broadcast and multicast traffic across this PVC. This is necessary because the point-to-multipoint network type works like a collection of separate point-to-point networks, for which OSPF still uses the well known multicast address 224.0.0.5. If the individual PVCs were not capable of handling this multicast traffic, we would have to specify the additional nonbroadcast keyword on the ip ospf network point-to-multipoint command. If we do this, then we once again require the neighbor command because the neighboring routers are not able to discover one another without the multicast capability:

Router9(config)#interface Serial0/0
Router9(config-if)#ip address 192.168.10.9 255.255.255.0
Router9(config-if)#encapsulation frame-relay
Router9(config-if)#frame-relay map ip 192.168.10.2 123 
Router9(config-if)#ip ospf network point-to-multipoint non-broadcast
Router9(config-if)#exit
Router9(config)#router ospf 1
Router9(config-router)#network 192.168.10.0 0.0.0.255 area 0
Router9(config-router)#neighbor 192.168.10.2
Router9(config-router)#exit

The only network type that we haven't yet discussed is the point-to-point option. This type of network doesn't require a DR or BDR, but it does require multicast packets to establish neighbor relationships. So, once again, if you have a medium that supports multicasts, the neighbors should find one another automatically; otherwise, you must manually configure OSPF neighbor commands on both routers.

Of the OSPF network types listed in Table 8-3, the Loopback interface stands out because it doesn't fit into any of the categories mentioned up until now. Cisco routers treat Loopback interfaces differently. By default, OSPF will advertise addresses on Loopback interfaces as /32 networks.

Naturally, there is never another OSPF device on the other end of a Loopback interface, so it doesn't matter whether or not it supports multicasts. And there will never be a requirement for a DR or BDR on this type of interface. But sometimes you want to use Loopback interfaces to advertise networks with longer prefixes. In this case, you can configure a point-to-point OSPF network type on the Loopback interface to force OSPF to advertise the network with the correct mask:

Router9(config)#interface Loopback0
Router9(config-if)#ip address 10.2.5.2 255.255.255.0
Router9(config-if)#ip ospf network point-to-point
Router9(config-if)#exit
Router9(config)#interface Loopback1
Router9(config-if)#ip address 10.2.6.2 255.255.255.0
Router9(config-if)#exit

Here you can see that the only difference between these two interfaces is that one of them has been configured with a point-to-point network type. And on another router, you can see the result:

Router3#show ip route ospf
 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O 10.2.6.2/32 [110/65] via 192.168.10.9, 00:00:02, Serial0/0.10
O 10.2.5.0/24 [110/65] via 192.168.10.9, 00:00:02, Serial0/0.10
Router3#

 

See Also

Chapter 10

Router Configuration and File Management

Router Management

User Access and Privilege Levels

TACACS+

IP Routing

RIP

EIGRP

OSPF

BGP

Frame Relay

Handling Queuing and Congestion

Tunnels and VPNs

Dial Backup

NTP and Time

DLSw

Router Interfaces and Media

Simple Network Management Protocol

Logging

Access-Lists

DHCP

NAT

First Hop Redundancy Protocols

IP Multicast

IP Mobility

IPv6

MPLS

Security

Appendix 1. External Software Packages

Appendix 2. IP Precedence, TOS, and DSCP Classifications

Index



Cisco IOS Cookbook
Cisco IOS Cookbook (Cookbooks (OReilly))
ISBN: 0596527225
EAN: 2147483647
Year: 2004
Pages: 505

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