Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
To form OSPF neighbor relationships on LANs and point-to-point WAN interfaces, OSPF
simply needs to be enabled on the interface, and the neighboring routers must agree to a
set of parameters (as summarized in Chapter 5, Table 5-5.) However, when using Frame Relay
in certain configurations, engineers must do more implementation planning and use
additional configuration commands to make OSPF work. Additionally, the people monitoring
and operating the network must also understand several differences in how OSPF
works in such cases and be ready to interpret the output of show commands.
The issues described in this section of the chapter arise when the IP subnetting and Frame
Relay design places more than two WAN routers into a single subnet. Such a design requires
multipoint logic, either configured on the physical serial interface or on a multipoint
subinterface.
This section begins by reviewing the IP subnetting design issues that can lead to the
broader OSPF issues over Frame Relay. Next, this section examines the issues of running
OSPF over Frame Relay, concentrating on the concepts. This final part of this section ends
with several OSPF configuration examples using multipoint Frame Relay.
IP Subnetting Design over Frame Relay
When planning the subnets to use over a Frame Relay WAN, the design engineer has several
options. The simplest and most obvious choice uses a single subnet for every PVC (as
seen throughout the examples in Chapters 5, 6, and 7), with all routers using point-topoint
subinterfaces associated with each single PVC. Most companies who still use Frame
Relay today still use such a subnetting design.
In some cases, a shortage of IP addresses may make a design engineer choose to use fewer
WAN subnets, with less waste. Many companies use private IP addresses inside their Enterprise
internetwork–often times specifically class A network 10.0.0.0–and most companies
do not have a shortage of IP addresses and subnets available. However, using one
subnet per PVC does consume more IP addresses than the alternative–to put more than
two routers into a Frame Relay WAN subnet. You get the advantage of fewer IP addresses
consumed in the WAN but the penalty of more configuration and complexity with the
OSPF implementation.
For example, consider the two internetworks shown in Figure 8-3. On the left, four routers
connect in a full mesh of PVCs, whereas on the right, the four routers use a partial mesh.
In each case, assume each router uses their s0/0/0 interface to connect to the cloud.
First, consider the differences in IP addressing for the one-subnet-per-PVC choice and the
single-subnet choice. The single-subnet design could use just one subnet–for instance,
subnet 10.1.1.0/29, with usable address 10.1.1.1–10.1.1.6 (subnet broadcast 10.1.1.7). With
four routers, the subnet contains enough IP addresses for each router, plus two additional
addresses. Conversely, with a single-subnet-per-PVC, the design would require six subnets,
This brief configuration works in part because of many default settings. IOS enables
Frame Relay Inverse ARP (InARP) by default, so all four routers learn of the other routers’
IP address/DLCI mappings dynamically. All PVCs learned on the interface will be associated
with the physical interface.
As a result, after creating this configuration, with a working Frame Relay network, the
four routers can ping each other in every case for which a PVC exists between the two
routers. In other words, in the full mesh case, all four routers should ping the other three
routers’ IP addresses in the 10.1.1.0/29 subnet. In the partial mesh case, the R1/R3 pair
cannot ping each other.
The ping problem between R1 and R3 demonstrates some key concepts related to how
Frame Relay mapping works. InARP allows the routers to learn the IP address of any
router on the other end of a PVC, but R1/R3 do not have a PVC connecting them in the
partial mesh side of Figure 8-3, so InARP does not learn the mapping. Then, when R1
(10.2.123.1) wants to send a packet to 10.2.123.3 (R3), R1 looks at its Frame Relay mapping
information and does not find 10.2.123.3. As a result, R1 discards the packet because it
does not know what DLCI to use to forward the packet.
Sample Configuration Using Multipoint Subinterfaces
The same effects occur with a valid alternate configuration using a multipoint subinterface,
both in the full and partial mesh cases. When using subinterfaces, IOS needs a command
under a Frame Relay subinterface that associates each PVC with that subinterface:
either a frame-relay interface-dlci command or frame-relay map command. The framerelay
interface-dlci command just associates the DLCI with the subinterface, relying on
Frame Relay InARP to discover mappings. The second command (frame-relay map) statically
configures that mapping, while also associating the DLCI with the subinterface.
Example 8-5 shows an alternative configuration on Router R1, using a multipoint subinterface.
All four routers could mimic the same configuration, but that configuration is not
shown in the example.
Example 8-5 OSPF over Multipoint Frame Relay Subinterfaces
! Router R1
interface S0/0/0
encapsulation frame-relay
!
interface S0/0/0.1 multipoint
ip address 10.1.123.1 255.255.255.248
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay interface-dlci 104
This configuration on R1, with similar configuration on the other three routers, has the
same results as those with Example 8-4. When a full mesh exists, all routers should be
pingable. With a partial mesh, all routers should be pingable, except those with no PVC
between the two routers (R1/R3 in this case).
www.CareerCert.info
270 CCNP ROUTE 642-902 Official Certification Guide
With those background details in mind, the chapter now examines the challenges that
arise when trying to use multipoint.
OSPF Challenges When Using Multipoint
Next, consider OSPF over both the full and partial meshes as described in the last few
pages. As it turns out, if you enabled OSPF on the interfaces, but do not add OSPF configuration,
OSPF does not form neighborships in either case.
Note: Rather than repeat the long phrase “on physical interfaces or on multipoint interfaces”
many times in the coming pages, the rest of this chapter simply refers to both as
“multipoint interfaces,” because more than one destination may be reachable through
these types ofinterfaces.
The default OSPF network type on multipoint interfaces–the nonbroadcast network
type–prevents OSPF from working without further configuration. Additionally, depending
on the configuration you add to make OSPF work, the network may appear to be
working in that the correct routes are learned, but packets cannot be forwarded. Worse
yet, packet forwarding could work when testing, but later, when the DR in that subnet
failed, packet forwarding could fail, even though paths exist over different PVCs.
To avoid such pitfalls, this section examines the issues. To understand the issues, an engineer
needs to know the answer to three questions related to OSPF over Frame Relay multipoint
interfaces:
■ Do the routers attempt to discover neighbors by sending and receiving multicast
OSPF Hello messages, or do the neighbors require static definition?
■ Do the routers attempt to elect a DR/BDR?
■ Does a partial mesh exist or full mesh?
The next few pages examine these topics one at a time.
Neighbor Discovery or Static Neighbor Definition
The OSPF network type–a per-interface setting–defines whether a router attempts to discover
OSPF neighbors on an interface. When the router attempts discovery, it sends multicast
(224.0.0.5) OSPF Hello messages out the interface.
The first potential problem occurs when a Frame Relay configuration oversight causes the
dynamic OSPF neighbor discovery process to fail. When a router needs to send a broadcast
or multicast over Frame Relay, the router must actually send a copy of the packet over
each PVC instead, because the Frame Relay network does not have the ability to replicate
the broadcast or multicast packet. Routers do send the multicast OSPF Hellos for any
PVCs listed in frame-relay interface-dlci commands, and for any DLCIs listed in framerelay
map commands if the broadcast keyword was included. However, if the frame-relay
map command omits the broadcast keyword, that router will not replicate the OSPF multicasts,
or any other broadcast or multicast frames for that DLCI.
www.CareerCert.info
Chapter 8: OSPF Virtual Links and Frame Relay Operations 271
Key
Topic
Alternatively, some OSPF network types tell a router to not attempt automatic discovery
of neighbors. In such a case, the router should be configured with the neighbor ip-address
OSPF router subcommand. This command overcomes the issue with neighbor discovery.
The actions to take for the issues related to neighbor discover are somewhat straightforward:
■ If the configured network type allows for neighbor discovery using Hellos, and you
use InARP, the neighbors should be discovered.
■ If the configured network type allows for neighbor discovery, and you use frame-relay
map, ensure that the broadcast keyword is included.
■ If the configured network type does not allow for neighbor discovery, statically configure
neighbors.
The upcoming samples show cases of using network types that dynamically discover
neighbors and cases that show static definition of neighbors.
To Use a Designated Router, or Not
IOS has several available OSPF network types for Frame Relay, some of which tell the
router to try to elect a DR/BDR. The reasoning is that when choosing a subnet design like
those shown in Figure 8-3, with a single subnet that includes more than two Frame Relay
routers, the design looks like a LAN from a Layer 3 perspective. Other options for OSPF
network types tell the routers to not elect a DR/BDR.
A potential issue exists when using a DR over Frame Relay. The issue relates to whether
the Frame Relay partial mesh includes the right PVCs to support the OSPF messages that
flow in the presence of a DR/BDR. As you may recall from Chapter 6, “OSPF Topology,
Routes, and Convergence,” when a DR exists, all OSPF routers must send and receive
OSPF messages with the DR, with messages to the DR being sent to the 224.0.0.6 all-DR’s
multicast address. Additionally, the DR sends messages to the 224.0.0.5 all-SPF router’s
multicast address, with these messages intended for all OSPF routers in the subnet. For the
same reason, all routers should send and receive messages with the BDR, in case it takes
over for the DR. However, two DROther routers do not need to send each other OSPF
messages.
For a Frame Relay partial mesh to work when also using an OSPF DR, a PVC must exist
between any two routers that need to perform database exchange directly with each
other. In short, the following PVCs must exist:
■ Between the DR and every other router in the subnet
■ Between the BDR and every other router in the subnet
For example, consider the partial mesh shown in Figure 8-4, which mirrors the partial
mesh seen on the right side of Figure 8-3. In this case, R1 acts as DR, and R2 as BDR.
OSPF actually works fine in this design, until the fated day when R1’s serial link fails.
When it fails, R2 takes over as DR, but R3 has no way to send and receive OSPF messages
with R2. As a result, R3 will no longer learn routes that pass over the WAN.
www.CareerCert.info
272 CCNP ROUTE 642-902 Official Certification Guide
DR
BDR
R2 R4
R3
R1
Figure 8-4 Poor Choices of BDR in a Partial Mesh
To deal with this particular issue with a partial mesh, either avoid using a DR at all by
changing the OSPF network type on all routers in the subnet, or restrict the role of
DR/BDR to routers with PVCs connected to all other routers in a subnet. For example, R1
and R4 in Figure 8-4 have three PVCs, one each to the other three routers. By configuring
the routers so that R2 and R3 refuse to become DR or BDR, you can avoid the case of a
poor choice of DR/BDR.
Summarizing the key points about the issues in this section:
■ If using a network type that requires a DR/BDR, restrict the role of DR and BDR to
routers that have a PVC connecting to all other routers.
■ Configure the OSPF network type to avoid using a DR/BDR.
Mapping Issues with a Partial Mesh
The last issue with OSPF over multipoint Frame Relay topologies relates to the Layer 2
mapping, either created by InARP or statically configured with frame-relay map commands.
This mapping on a router lists each neighbor’s IP address, and that router’s DLCI
used to reach that router. InARP learns this mapping for each router on the other end of a
PVC, but not for other routers where no PVC exists. For example, in Figure 8-4, R2 and
R3 would not learn mapping for each other with InARP. Similarly, when configuring the
frame-relay map command, many engineers think only of statically creating mappings for
neighboring routers on the other end of each PVC. In short, the mapping in both cases
matches the partial mesh.
OSPFmultipoint interfaces have problems when the Frame Relay mapping matches the
partial mesh but does not include mapping to every other router in the subnet–even those
routers where no PVC exists. The best way to describe the problem is to start with an example,
as seen in Figure 8-5. The figure shows the same old partial mesh, with some IP addresses
and DLCIs shown.
Configuring and Verifying OSPF Operations on Frame Relay
The concepts related to the issues of running OSPF over Frame Relay can require a bit of
thought about things that many of us can ignore when working with a typical OSPF network.
Thankfully, the implementation choices are a little more straightforward. When the
design dictates more than two routers per subnet over Frame Relay, you need to configure
Frame Relay to use either physical interfaces or multipoint subinterfaces. In those cases,
only four OSPF network types exist. Then, the choice of OSPF network type answers two
big questions: Will the routers try and elect a DR, and will they try to discover neighbors?
From there, the rest of the implementation plan flows from the issues already discussed in
this chapter.
For reference, Table 8-3 summarizes the four OSPF network types available on serial interfaces
that use Frame Relay, either the physical interface or a multipoint subinterface. Note
that the setting is per interface and can be set with the ip ospf network type interface
subcommand; the first column in the table lists the exact keyword according to this command.
All the upcoming examples use the same network diagram as shown in Figure 8-6. After
the figure, the text moves on to the examples showing this internetwork configured with
three options for network type on Frame Relay serial and multipoint subinterfaces: nonbroadcast,
point-to-multipoint, and point-to-multipoint nonbroadcast. (This chapter does
not include a sample of using network type broadcast, because the LAN-based examples
in Chapter 5 all use a default of network type broadcast.)
Note: The following samples all use multipoint subinterfaces. Also, for each example, all
four routers use the same OSPF network type. However, note that IOS has no mechanism
to prevent routers from using different interface types or different OSPF network types,
but such inconsistency can cause problems and be very difficult to operate. Configurations
that mix OSPF network types in the same subnet are outside the scope of this book.
would prevent any further communication on the WAN anyway, so the lack of a BDR
does not make the problem worse.)
The OSPF priority defines the priority when choosing a DR and BDR. Configured with
the ip ospf priority value interface subcommand, the higher number (ranges from 0–255)
wins. Also, a priority of 0 has special meaning: it prevents that router from becoming the
DR or BDR. By configuring OSPF priority of 0 on routers that do not have a PVC connected
to each other router (such as R2, R3, and R4 in this case), the other routers (R1 in
this case) will be the only routers eligible to become the DR.
Example 8-6 begins by showing the required configuration, defining neighbors and setting
the OSPF priority on R2, R3, and R4 to 0. The example shows just R1 and R2; R3’s
and R4’s configuration mirror R2’s, other than the IP address settings.
Example 8-6 OSPF over Multipoint Frame Relay Subinterfaces–Default Configuration
! First, R1’s configuration
R1#show running-config int s0/0/0.1
Building configuration...
Current configuration : 169 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.1 255.255.255.248
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay interface-dlci 104
end
R1#show running-config | begin router ospf
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
router-id 1.1.1.1
neighbor 10.2.123.2
neighbor 10.2.123.3
neighbor 10.2.123.4
! Next, R2’s configuration
R2#show running-config interface s0/0/0.1
Building configuration...
Current configuration : 113 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.2 255.255.255.248
frame-relay interface-dlci 101
ip ospf priority 0
end
www.CareerCert.info
Chapter 8: OSPF Virtual Links and Frame Relay Operations 277
R2#show running-config | begin router ospf
router ospf 2
network 10.0.0.0 0.255.255.255 area 0
router-id 2.2.2.2
neighbor 10.2.123.1
R2#show ip ospf interface s0/0/0.1
Serial0/0/0.1 is up, line protocol is up
Internet Address 10.2.123.2/29, Area 0
Process ID 2, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER, Priority 0
Designated Router (ID) 1.1.1.1, Interface address 10.2.123.1
No backup designated router on this network
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Example 8-6 shows the configuration of three neighbors on router R1 (R2, R3, and R4),
plus one neighbor on R2 (R1). It does not show the explicit configuration of the OSPF
network type because each router uses the default for multipoint subinterfaces of nonbroadcast.
However, the show ip ospf interface command at the end of the output confirms
the network type on the multipoint subinterface of R2.
The priority configuration results in R1 becoming DR, and none of the other routers being
willing to even become BDR. R1 omits an ip ospf priority command, defaulting to 1,
while R2 shows an ip ospf priority 0 command, removing itself from consideration as DR
or BDR. The output at the bottom of the page again confirms the result on R2, with its
own priority of 0, the result of RID 1.1.1.1 (R1) as DR, but with no BDR elected.
Note: You can also attempt to configure a neighboring router’s OSPF priority with the
neighbor address priority priority-value command.
Although the configuration shown in Example 8-6 takes care of the particulars of defining
neighbors and of influencing the choice of DR/BDR, it does not, however, include the
configuration for the Frame Relay mapping issue with a partial mesh. All four routers need
mapping to the other three router’s IP addresses in their common Frame Relay subnet. In
this particular case, R1 learns all the mappings with InARP, because it has a PVC connected
to all the other routers. However, R2, R3, and R4 have learned all OSPF routes but
cannot forward traffic to each other because they have not learned the mappings.
Example 8-7 shows the background regarding this issue, along with an example solution
on R2 using frame-relay map commands. Note that comments inside the example show
the progression of proof and changes to solve the problem.
www.CareerCert.info
278 CCNP ROUTE 642-902 Official Certification Guide
Example 8-7 The Need for frame-relay map Commands
! First, R2 has routes for the LAN subnets off R1, R3, and R4, each referring
! to their respective routers as the next-hop IP address
R2#show ip route ospf
10.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
O 10.4.4.0/27 [110/65] via 10.2.123.4, 00:03:52, Serial0/0/0.1
O 10.3.3.0/26 [110/65] via 10.2.123.3, 00:06:02, Serial0/0/0.1
O 10.1.1.0/24 [110/65] via 10.2.123.1, 00:06:12, Serial0/0/0.1
! Next, R2 successfully pings R1’s LAN IP address
R2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
! Next, R2 fails when pinging R3’s LAN IP address
R2#ping 10.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
! R2 has mapping only for 10.2.123.1 in the Frame Relay subnet
R2#show frame-relay map
Serial0/0/0.1 (up): ip 10.2.123.1 dlci 101(0x65,0x1850), dynamic,
broadcast,
CISCO, status defined, active
! Next, the engineer adds the mapping for R3 and R4, with DLCI 101 as the
! PVC, which connects to R1
R2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0/0.1
R2(config-subif)#frame-relay map ip 10.2.123.3 101 broadcast
R2(config-subif)#frame-relay map ip 10.2.123.4 101 broadcast
R2(config-subif)#^Z
!
! Not shown, similar mapping configured on R3 and R4
www.CareerCert.info
Chapter 8: OSPF Virtual Links and Frame Relay Operations 279
! R2 now has the necessary mappings
R2#show frame-relay map
Serial0/0/0.1 (up): ip 10.2.123.4 dlci 101(0x65,0x1850), static,
broadcast,
CISCO, status defined, active
Serial0/0/0.1 (up): ip 10.2.123.3 dlci 101(0x65,0x1850), static,
broadcast,
CISCO, status defined, active
Serial0/0/0.1 (up): ip 10.2.123.1 dlci 101(0x65,0x1850), dynamic,
broadcast,
CISCO, status defined, active
! Same ping now works
R2#ping 10.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
Although the example demonstrates the original problem and then the solution, it does
also demonstrate a particularly difficult challenge for a verification plan. Before adding
the mapping, OSPF appeared to be working on R2, because R2 had learned all the routes
it should have learned. However, packet forwarding failed due to the lack of the correct
Frame Relay mappings. When reviewing verification plans for the exam, take extra care
when using Frame Relay, and do not rely solely on seeing OSPF routes as proof that connectivity
exists between two routers.
Using Network Type Point-to-Multipoint
Network type point-to-multipoint tells routers to act oppositely compared to the nonbroadcast
type: to not elect a DR/BDR and to dynamically discover neighbors. Both options
allow the routers to simply not configure additional commands. As a result, the only
configuration requirement, beyond enabling OSPF on the multipoint subinterface or physical
serial interface, is to configure any static Frame Relay mappings if a partial mesh exists.
Example 8-8 shows a completed OSPF configuration on Routers R1 and R2 in Figure 8-6.
All the routers change their network type using the ip ospf network point-to-multipoint
interface subcommand. The other big change as compared to using the nonbroadcast network
type (as seen in Examples 8-6 and 8-7) is the absence of configuration. (Example 8-8
does show all OSPF-related configuration on R1 and R2.) As with Example 8-6, the example
omits the R3 and R4 configuration, but the configuration follows the same conventions
as on R2. Also, note that the routers without PVCs to each other router still require
the frame-relay map commands (included in the example) for the same reasons as shown
in Example 8-7.
www.CareerCert.info
280 CCNP ROUTE 642-902 Official Certification Guide
Example 8-8 Configuring Multipoint OSPF Using Network Type Point-to-Multipoint
! First, R1’s configuration
R1#show run int s0/0/0.1
Building configuration...
Current configuration : 169 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.1 255.255.255.248
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay interface-dlci 104
ip ospf network point-to-multipoint
end
R1#show run | begin router ospf
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
router-id 1.1.1.1
! Next, on R2:
R2#show run int s0/0/0.1
Building configuration...
Current configuration : 169 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.2 255.255.255.248
frame-relay interface-dlci 101
frame-relay map ip 10.2.123.3 101 broadcast
frame-relay map ip 10.2.123.4 101 broadcast
ip ospf network point-to-multipoint
end
R2#show run | begin router ospf
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
router-id 2.2.2.2
Example 8-9 confirms a few details about the operation with the point-to-multipoint network
type. Taken from R1, the show ip ospf interfaces S0/0/0.1 command confirms the
network type, and it also confirms full adjacency with the other three routers. Also, compared
to the same command on Router R2 near the end of Example 8-6, note that this
command does not even mention the concept of a DR nor BDR, because this network
type does not expect to use a DR/BDR.
www.CareerCert.info
Chapter 8: OSPF Virtual Links and Frame Relay Operations 281
Example 8-9 Confirming the Operation of Network Type Point-to-Multipoint
! First, R1’s configuration
R1#show ip ospf interface s0/0/0.1
Serial0/0/0.1 is up, line protocol is up
Internet Address 10.2.123.1/29, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:23
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 4/4, 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 3, Adjacent neighbor count is 3
Adjacent with neighbor 2.2.2.2
Adjacent with neighbor 4.4.4.4
Adjacent with neighbor 3.3.3.3
Suppress hello for 0 neighbor(s)
Using Network Type Point-to-Multipoint Nonbroadcast
OSPF network type point-to-multipoint nonbroadcast tells routers to act like the similarly
named point-to-multipoint type by not electing a DR/BDR. However, the difference
lies in neighbor discovery–the keyword “nonbroadcast” implies that the routers cannot
broadcast (or multicast) to discover neighbors.
The configuration uses a mix of the commands seen for the nonbroadcast and point-tomultipoint
network types. Essentially, the configuration of priority for the purpose of influencing
the DR/BDR election can be ignored, because no DR/BDR will be elected.
However, the routers need neighbor commands to predefine neighbors. Also, regardless of
network type, for those routers without direct PVCs, Frame Relay mapping must be added.
This particular OSPF network type does have some design advantages if the design also
uses multipoint subinterfaces. The required neighbor commands also have an optional
cost parameter so that the cost associated with each neighbor can be different. With
point-to-multipoint, the router considers the dynamically discovered neighbors to be
reachable with a cost equal to the cost of the associated multipoint subinterface, so the
cost cannot be set per neighbor.
Example 8-10 shows the configurations on R1 and R2 for this case, with the configuration
of R3 and R4 mirroring R2s.
www.CareerCert.info
282 CCNP ROUTE 642-902 Official Certification Guide
Example 8-10 Configuring Multipoint OSPF Using Network Type Point-to-Multipoint
Nonbroadcast
! First, R1’s configuration
R1#show run int s0/0/0.1
Building configuration...
Current configuration : 169 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.1 255.255.255.248
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay interface-dlci 104
ip ospf network point-to-multipoint non-broadcast
end
R1#show run | begin router ospf
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
router-id 1.1.1.1
neighbor 10.2.123.2
neighbor 10.2.123.3
neighbor 10.2.123.4
! Next, on R2:
R2#show run int s0/0/0.1
Building configuration...
Current configuration : 169 bytes
!
interface Serial0/0/0.1 multipoint
ip address 10.2.123.2 255.255.255.248
frame-relay interface-dlci 101
frame-relay map ip 10.2.123.3 101 broadcast
frame-relay map ip 10.2.123.4 101 broadcast
ip ospf network point-to-multipoint non-broadcast
end
R2#show run | begin router ospf
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
router-id 2.2.2.2
neighbor 10.2.123.1
No comments:
Post a Comment