Ccna 4 Case Study Ospf And Frame-Relay

Implementing Your Design

Last Updated on Wed, 13 Dec 2017 | Ospf Network

This section discusses some of the design topics to consider within this case study and how to implement them in the network given the preceding discussion. These can be both OSPF-specific topics and other all-encompassing network issues, such as IP addressing.

IP Addressing

You are able to obtain a contiguous block of 32 Class C (/24 or 255.255.255.0 mask) subnets for this network from the IP address manager. The address block is 172.17.64.0/19, which allows clean summarization into the backbone area after the corporate network converts to OSPF. This occurs because all the Frame Relay network LAN and WAN addresses are to be summarized as one route (172.17.64.0/19) after the backbone routers are converted to OSPF, as shown in Figure 4-39.

246 Chapter 4: Design Fundamentals

Figure 4-39 IP Addressing Scheme

Hub Router Runs IGRP on Ethernet Port

Figure 4-39 IP Addressing Scheme

Hub Router Runs IGRP on Ethernet Port

Hub router serial WAN port subinterfaces all in OSPF area 64.

Sales Office LAN Addressing

Given the host requirements of 50-150 nodes per remote LAN and the existing subnetting scheme of /24 (Class C mask) on the corporate network, you should assign /24 subnets of the 172.17.64.0/19 space to each of the 25 spoke LANs. Every LAN is to have addressing space for up to 254 nodes with this subnetting scheme to facilitate future growth requirements at each site. This fulfills the earlier requirement concerning network growth and planning. This masking scheme will be easily understood by the desktop support staff and will work with existing routers running IGRP, which does not carry subnet information in routing updates. Routers require a uniform masking scheme enterprise-wide.

The spoke router LAN subnets on this network are assigned the range 172.17.65.0 to 172.17.90.255.

The hub router attaches to an existing corporate backbone Ethernet segment. The router is assigned an IP address from that subnet, which does not fall within the 172.17.64.0/19 range. You are given 172.17.10.240/24 for the hub router Ethernet IP address.

WAN Addressing

Before the WAN IP address plan can be devised for the routers on this network, you must decide whether to treat the Frame Relay PVCs as a single multipoint subnet or a collection of point-to-point links on the Cisco routers. Remember, multipoint makes the Frame Relay cloud behave as a large LAN subnet, whereas the point-to-point mode models each PVC as a separate WAN point-to-point link in terms of addressing and routing.

Given the additional requirements to support the IPX protocol in an any-to-any fashion, the point-to-point model is the only option. IPX RIP is a distance-vector routing protocol. The protocol has the split-horizon behavior limitation of not sending routing updates out an interface on which they were received. The multipoint model would not facilitate IPX any-to-any because the router would not send IPX routing updates out to any of the remote routers.

To support the point-to-point model, you must define individual router serial port logical interfaces or subinterfaces, each of which represent a discrete IP subnet and IPX network. TCP/IP addressing can accommodate this model most efficiently by assigning each of the subinterfaces with a /30 subnet. IP address space for these WAN links is derived from further subnetting of a single /24 bit subnet (172.17.95.0). The hub router configuration in Example 4-16 provides more details.

Example 4-16 Hub Router Configuration

RTP_HQ#

interface serial 0 encapsulation frame-relay ietf frame-relay lmi-type ansi no ip address interface serial 0.1 point-to-point description PVC to Cumberland router ip address 172.17.95.1 255.255.255.252 ipx network 179500

frame-relay interface-dlci 401 broadcast interface serial 0.2 point-to-point description PVC to west LA router ip address 172.17.95.5 255.255.255.252 ipx network 179504

frame-relay interface-dlci 402 broadcast

OSPF Area Organization

Given the relatively small size of this network (less than 50 routers), it is practical to include all routers into one OSPF area. This creates a "portable" OSPF network that can be easily integrated into the enterprise corporate OSPF network after it is converted from IGRP. Because you do not know the future location of the OSPF backbone, you decide to be safe and put all routers in this network into a nonzero area. Putting this network into a nonzero area allows you to avoid a future mass router reconfiguration after the corporate network is converted to OSPF. You assign this nonzero OSPF area an identifier of 64 because this is the base number of the /19 CIDR block, which is a logical representation of the addressing. You decide to use the company's registered BGP AS number of 5775 as the OSPF process ID number for this network, as follows:

Router(config)#router ospf 5775 The hub router at Terrapin corporate headquarters in RTP, NC is to be the sole ASBR in this network because it must run OSPF and IGRP to support mutual redistribution of routes between the campus and WAN networks.

248 Chapter 4: Design Fundamentals

Because all routers in the Frame Relay network are to be in area 64, no backbone area (area 0) is created; and subsequently, no routers are configured as ABRs or backbone routers at this point. Figure 4-40 shows the OSPF area architecture established for Terrapin.

Figure 4-40 New OSPF Network Design

DMZ Segment

OSPF Redistributed into IGRP 1 (Internal Only)

Internet

Internet Proxy/ Firewall

Campus Router Providing IGRP "Gateway of Last Resort" (0.0.0.0) to Entire Network EthernetO Interface in OSPF Area 0

Corporate IGRP Network Process #1

OSPF Area 64

' All 30 Spoke Routers and Hub Routerx Serial Interface in Area 64

Future OSPF Network

172.17.0.0/16 (172.17.65.0-172.17.90.254 Deployed on Campus)

' All 30 Spoke Routers and Hub Routerx Serial Interface in Area 64

Frame Relay Hub Router OSPF ABR/ASBR

Frame Relay Hub Router OSPF ABR/ASBR

Specifying the OSPF Network Type

Use the default OSPF network type of point-to-point because you are modeling the router Frame Relay cloud as individual point-to-point subinterfaces. The initial step of DR/BDR election is not required because only two routers exist on point-to-point networks, resulting in quick adjacency formation upon startup.

Implementing Authentication

The IS security manager insists that you use OSPF authentication to provide a level of security on this network. You implement simple password authentication by assigning a key of WhatIsTheMatrix to your OSPF area 64. All OSPF routers added to this Frame Relay network need this key configured to form an OSPF adjacency with the hub router. This authentication must be entered under the OSPF process ID and on each serial interface, as shown in Example 4-17.

Example 4-17 Configuring OSPF Authentication interface serial 0.1 point-to-point description PVC to Cumberland router ip address 172.17.95.1 255.255.255.252 ip ospf authentication-key WhatlsTheMatrix ipx network 179500

frame-relay interface-dlci 401 broadcast !

router ospf 5775 area 64 authentication

NOTE If you are planning on implementing OSPF authentication, you should also enable the

Cisco password encryption option through the use of the service password-encryption command.

Configuring Link Cost

Because all spoke routers have only one PVC provisioned to the hub router, there is no need to configure specific OSPF costs to links in order to engineer traffic patterns in a particular matter. Use the defaults by not assigning costs in router configurations.

Tuning OSPF Timers

Because all routers are Cisco routers and all run the same version of code, you do not need to tune individual Hello, dead, or retransmit timers. Cisco's default WAN values of 10, 40, and 120, respectively, provide fast convergence times and ensure consistency across all routers (see Example 4-18).

Example 4-18 Relevant Configuration of the Terrapin Headquarters Router

RTP_HQ#

interface Ethernet 0

description LAN connection to campus backbone ip address 172.17.10.240 255.255.255.0 !

interface serial 0.1 point-to-point description PVC to Cumberland router ip address 172.17.95.1 255.255.255.252 ip ospf authentication-key WhatlsTheMatrix ipx network 179500

frame-relay interface-dlci 401 broadcast !

interface serial 0.2 point-to-point description PVC to west LA router ip address 172.17.95.5 255.255.255.252 ip ospf authentication-key WhatlsTheMatrix continues

250 Chapter 4: Design Fundamentals

Example 4-18 Relevant Configuration of the Terrapin Headquarters Router (Continued)

ipx network 179504

frame-relay interface-dlci 401 broadcast !

router ospf 5775

network 172.17.95.0 0.0.0.255 area 64 area 64 authentication

Strategizing Route Redistribution

Redistribution of routes between the OSPF and IGRP domains are to be done at the Frame Relay hub router (ASBR) at RTP, NC. To learn of routes from both domains, the hub router must run both an OSPF and an IGRP routing process. Redistribution of routes must address all the issues detailed in the sections that follow.

Campus Routing to Frame Relay WAN

This section discusses how the existing campus routers dynamically learn about the new Frame Relay networks, specifically examining the following issues:

• OSPF route redistribution into IGRP

• Static route aggregation and redistribution into IGRP

• OSPF route aggregation and redistribution into IGRP

• Testing of OSPF route redistribution into IGRP

Redistribution of OSPF routes into the IGRP process causes the hub router to send IGRP advertisements of all /24 subnets known to OSPF. This allows all spoke router LAN subnets to be learned by IGRP routers. This topic is covered in Chapter 6.

Use the internal keyword when performing this redistribution on the hub Cisco router to allow only OSPF internal routes to be redistributed into IGRP. This prevents a possible router loop in the future if more routers are installed and are running two-way OSPF/IGRP redistribution. (All the Frame Relay LAN or WAN networks are known as OSPF internal routes because the networks originated from this same domain.)

However, the WAN subnets cannot be redistributed into IGRP this easily because of the classless IP subnetting scheme of /30. IGRP supports only classful subnetting, and routers would ignore all /30 subnets when redistributing. Although this would not affect host-to-host IP connectivity, it might potentially cause a problem with network management tools, subsequently causing routing holes when accessing the router's WAN IP address directly to or from Frame Relay.

Two possible strategies for handling the WAN link advertisements into IGRP are as follows:

• Static route aggregation redistribution into IGRP

• OSPF route aggregation and redistribution into IGRP

With static route aggregation and redistribution into IGRP, you must represent all /30 WAN subnets into an aggregate 24-bit summary and then redistribute them because only /24 prefixed routes are announced into IGRP. Configure a static route on the hub router for 172.17.95.0255.255.255.0, with the next hop as the Null 0 interface (aka the hub router). Now, redistribute static routes into IGRP, and all IGRP routers can route traffic to these WAN links. Control redistribution of routes to just the 172.17.95.0/24 network by defining an access list that allows only redistribution of this route. Defining an access list can prevent future routing problems if additional static routes are added to the hub router, which the campus need not know about through IGRP. The configuration in Example 4-19 demonstrates how to control redistribution of routes.

Example 4-19 Configuring Route Redistribution

RTP_HQ#

router igrp 10 network 172.17.0.0 passive-interface serial0.1:0.30 default-metric 10000 100 255 1 1500 redistribute ospf 5774 match internal redistribute static distribute-list 3 out static ip route 172.17.95.0 255.255.255.0 null0 access-list 3 permit 172.17.95.0

The passive-interface command stops IGRP updates from being broadcasted unnecessarily across all WAN PVCs.

The default-metric command assigns IGRP metrics to routes known from all other route sources (in this case, static routes) that need redistribution into IGRP.

NOTE IGRP uses bandwidth, delay, reliability, load, and MTU components to calculate route metrics across specific interfaces. The values 1000010025511500 are defaults for 10-MB Ethernet.

An alternative to static route aggregation of the WAN subnets would be to use OSPF route aggregation and redistribution into IGRP to accomplish this task. This is the preferred solution and the one chosen for this case study because OSPF is already currently being redistributed into the IGRP process to propagate the LAN subnets.

To accomplish OSPF route summarization, the hub router must be configured as an ABR or ASBR because OSPF inter-area summarization can occur only at area boundaries toward the backbone. You can accomplish this by adding the Ethernet interface into OSPF area 0. Now that the hub router (RTP_HQ) is an ABR, you can summarize the WAN subnets as one

252 Chapter 4: Design Fundamentals

/24 network (172.17.95.0/24). This network falls on the established 24-bit boundary and is redistributed into IGRP, understood by all interior IGRP-speaking routers, as shown in Example 4-20.

Example 4-20 Configuring OSPF Route Summarization

RTP_HQ# router igrp 10 network 172.17.0.0 passive-interface serial0.1:0.30 default-metric 10000 100 255 1 1500 redistribute ospf 5775 match internal router ospf 5775

network 172.17.64.0 0.0.0.255 area 64 network 172.17.10.240 0.0.0.0 area 0 area 64 range 172.17.64.0 255.255.255.0 area 64 authentication

To test the OSPF route redistribution into IGRP, you can display the routing table of any IGRP internal router, which indicates the success or failure of the redistribution of OSPF routes into IGRP. If problems arise, debugging IGRP transactions on the ASBR (hub) router can provide the necessary troubleshooting information.

CAMPUS-to-WAN Routing

Now that all WAN routes are available on the campus IGRP backbone, it is necessary to advertise routing information to the WAN routers so that all campus subnets can be reached. This can be accomplished in the following ways:

• Redistributing IGRP routes into OSPF

• Generating a default route into OSPF

All known IGRP subnets can be redistributed into OSPF at the hub router with the configuration shown in Example 4-21.

The keyword metric 100 is an arbitrary default metric that is attached to IGRP routes redistributed into OSPF.

The keyword metric-type 1 makes redistributed IGRP routes external Type 1. This allows the OSPF spoke routers to add individual link costs to calculate OSPF metrics.

0323FMf.book Page 253 Wednesday, March 12, 2003 9:41 AM

Case Study: Designing an OSPF Network 253

The subnets keyword is necessary to allow subnets of natural Class B address 172.17.0.0 to be redistributed into OSPF.

When generating a default route into OSPF, because all spoke routers have only a single path (one PVC) out to the WAN, all destinations that are not locally connected would need to traverse that path. A default route (0.0.0.0 0.0.0.0) can be sent from the ASBR hub router in lieu of specific subnet routes. This is the preferred method in this case because the routing tables on remote routers become smaller, and potential routing loops that can result from two-way redistribution can be avoided. Example 4-22 demonstrates this procedure.

RTP_HQ#

router ospf 5775

default information originate metric 100 metric-type 1

Refer to Figure 4-40 to see the implementation of the techniques covered in this section for campus-to-WAN routing. Although the Terrapin OSPF network design was fairly straightforward in terms of IP addressing and OSPF architecture, the integration into the existing IGRP network presented a number of challenges. Adding OSPF into existing networks running other routing protocols is often a difficult task and must be carefully planned out; otherwise, suboptimal routing or even loops can occur.

Example 4-22 Changing the Metric

Chapter

Hello,

I know i read something about this in the Official Certification Guide for CCNP Route but I can't find it anymore, and it just bugs me.

Why does the configuration bellow works if I do a frame-relay map to the ip that is configured on interface ?

if you use for example on R1 frame-relay map ip 10.0.0.2 102 broadcast and on R2 frame-relay map ip 10.0.0.1 201 broadcast ,neighbors are formed, without broadcast keyword neighbors don't come up of course, but how does it work with this config ?

 

Below are the configurations

 

 

R1

interface Serial0/0

ip address 10.0.0.1 255.255.255.0

encapsulation frame-relay

ip ospf network point-to-point

clock rate 2000000

frame-relay map ip 10.0.0.1 102 broadcast

frame-relay map ip 10.0.0.2 102

frame-relay interface-dlci 102

no frame-relay inverse-arp

router ospf 1

network 10.0.0.0 0.0.0.255 area 0

 

R2

interface Serial0/1

ip address 10.0.0.2 255.255.255.0

encapsulation frame-relay

ip ospf network point-to-point

clock rate 2000000

frame-relay map ip 10.0.0.1 201

frame-relay map ip 10.0.0.2 201 broadcast

frame-relay interface-dlci 201

no frame-relay inverse-arp

router ospf 1

network 10.0.0.0 0.0.0.255 area 0

 

FR

frame-relay switching

interface Serial0/0

no ip address

encapsulation frame-relay

logging event subif-link-status

logging event dlci-status-change

clockrate 56000

no frame-relay inverse-arp

frame-relay intf-type dce

frame-relay route 102 interface Serial0/1 201

interface Serial0/1

no ip address

encapsulation frame-relay

logging event subif-link-status

logging event dlci-status-change

clockrate 56000

no frame-relay inverse-arp

frame-relay intf-type dce

frame-relay route 201 interface Serial0/0 102

 

 

R1#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.0.0.2          0   FULL/  -        00:00:33    10.0.0.2        Serial0/0

 

 

R2#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.0.0.1          0   FULL/  -        00:00:35    10.0.0.1        Serial0/1

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *