05-Layer 3—IP Routing Configuration Guide

HomeSupportResource CenterSwitchesS12500X-AF SeriesS12500X-AF SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C S12500X-AF Switch Series Configuration Guides(R26xx)-6W10205-Layer 3—IP Routing Configuration Guide
Table of Contents
Related Documents

01-Text

Download Book  (5.21 MB)

Contents

Configuring basic IP routing· 1

Routing table· 1

Dynamic routing protocols· 2

Route preference· 2

Load sharing· 3

Route backup· 3

Route recursion·· 3

Route redistribution·· 3

Extension attribute redistribution·· 3

Setting the maximum lifetime for routes and labels in the RIB·· 4

Setting the maximum lifetime for routes in the FIB·· 4

Configuring RIB NSR·· 5

Configuring IPv4 RIB NSR·· 5

Configuring IPv6 RIB NSR·· 5

Configuring inter-protocol FRR·· 6

Configuring IPv4 RIB inter-protocol FRR·· 6

Configuring IPv6 RIB inter-protocol FRR·· 6

Enabling the IPv4 enhanced ECMP mode· 7

Displaying and maintaining a routing table· 7

Configuring static routing· 9

Configuring a static route· 9

Configuring BFD for static routes· 10

Bidirectional control mode· 10

Single-hop echo mode· 11

Configuring static route FRR·· 12

Configuration guidelines· 12

Configuring static route FRR by specifying a backup next hop· 12

Configuring static route FRR to automatically select a backup next hop· 13

Enabling BFD echo packet mode for static route FRR·· 13

Displaying and maintaining static routes· 13

Static route configuration examples· 14

Basic static route configuration example· 14

BFD for static routes configuration example (direct next hop) 15

BFD for static routes configuration example (indirect next hop) 18

Static route FRR configuration example· 20

Configuring a default route· 23

Configuring RIP·· 24

Overview·· 24

RIP route entries· 24

Routing loop prevention·· 24

RIP operation·· 24

RIP versions· 25

Protocols and standards· 25

RIP configuration task list 25

Configuring basic RIP·· 26

Enabling RIP·· 26

Controlling RIP reception and advertisement on interfaces· 27

Configuring a RIP version·· 27

Configuring RIP route control 28

Configuring an additional routing metric· 28

Configuring RIPv2 route summarization·· 29

Disabling host route reception·· 30

Advertising a default route· 30

Configuring received/redistributed route filtering· 30

Setting a preference for RIP·· 31

Configuring RIP route redistribution·· 31

Tuning and optimizing RIP networks· 32

Configuration prerequisites· 32

Setting RIP timers· 32

Enabling split horizon and poison reverse· 33

Setting the maximum number of RIP ECMP routes· 33

Enabling zero field check on incoming RIPv1 messages· 34

Enabling source IP address check on incoming RIP updates· 34

Configuring RIPv2 message authentication·· 34

Setting the RIP triggered update interval 35

Specifying a RIP neighbor 35

Configuring RIP network management 36

Configuring the RIP packet sending rate· 36

Setting the maximum length of RIP packets· 37

Setting the DSCP value for outgoing RIP packets· 37

Configuring RIP GR·· 37

Enabling RIP NSR·· 38

Configuring BFD for RIP·· 38

Configuring single-hop echo detection (for a directly connected RIP neighbor) 39

Configuring single-hop echo detection (for a specific destination) 39

Configuring bidirectional control detection·· 40

Configuring RIP FRR·· 40

Configuration restrictions and guidelines· 40

Configuration prerequisites· 41

Configuring RIP FRR·· 41

Enabling BFD for RIP FRR·· 41

Displaying and maintaining RIP·· 41

RIP configuration examples· 42

Configuring basic RIP·· 42

Configuring RIP route redistribution·· 45

Configuring an additional metric for a RIP interface· 47

Configuring RIP to advertise a summary route· 48

Configuring RIP GR·· 51

Configuring RIP NSR·· 52

Configuring BFD for RIP (single-hop echo detection for a directly connected neighbor) 53

Configuring BFD for RIP (single hop echo detection for a specific destination) 56

Configuring BFD for RIP (bidirectional detection in BFD control packet mode) 58

Configuring RIP FRR·· 61

Configuring OSPF· 64

Overview·· 64

OSPF packets· 64

LSA types· 64

OSPF areas· 65

Router types· 67

Route types· 68

Route calculation·· 68

OSPF network types· 69

DR and BDR·· 69

Protocols and standards· 70

OSPF configuration task list 70

Enabling OSPF·· 72

Configuration prerequisites· 72

Configuration guidelines· 73

Enabling OSPF on a network· 73

Enabling OSPF on an interface· 74

Configuring OSPF areas· 74

Configuring a stub area· 74

Configuring an NSSA area· 75

Configuring a virtual link· 75

Configuring OSPF network types· 76

Configuration prerequisites· 76

Configuring the broadcast network type for an interface· 76

Configuring the NBMA network type for an interface· 76

Configuring the P2MP network type for an interface· 77

Configuring the P2P network type for an interface· 78

Configuring OSPF route control 78

Configuration prerequisites· 78

Configuring OSPF route summarization·· 78

Configuring received OSPF route filtering· 79

Configuring Type-3 LSA filtering· 80

Setting an OSPF cost for an interface· 80

Setting the maximum number of ECMP routes· 81

Setting OSPF preference· 81

Configuring discard routes for summary networks· 81

Configuring OSPF route redistribution·· 82

Advertising a host route· 83

Excluding interfaces in an OSPF area from the base topology· 83

Tuning and optimizing OSPF networks· 84

Configuration prerequisites· 84

Setting OSPF timers· 84

Setting LSA transmission delay· 85

Setting SPF calculation interval 85

Setting the LSA arrival interval 86

Setting the LSA generation interval 86

Disabling interfaces from receiving and sending OSPF packets· 87

Configuring stub routers· 87

Configuring OSPF authentication·· 88

Adding the interface MTU into DD packets· 89

Setting the DSCP value for outgoing OSPF packets· 89

Setting the maximum number of external LSAs in LSDB·· 89

Setting OSPF exit overflow interval 89

Enabling compatibility with RFC 1583· 90

Logging neighbor state changes· 90

Configuring OSPF network management 91

Setting the LSU transmit rate· 91

Setting the maximum length of OSPF packets that can be sent by an interface· 92

Enabling OSPF ISPF·· 92

Configuring prefix suppression·· 92

Configuring prefix prioritization·· 93

Configuring OSPF PIC·· 94

Setting the number of OSPF logs· 95

Filtering outbound LSAs on an interface· 95

Filtering LSAs for the specified neighbor 95

Configuring GTSM for OSPF·· 96

Configuring OSPF GR·· 97

Configuring OSPF GR restarter 97

Configuring OSPF GR helper 98

Triggering OSPF GR·· 98

Configuring OSPF NSR·· 99

Configuring BFD for OSPF·· 99

Configuring bidirectional control detection·· 99

Configuring single-hop echo detection·· 100

Configuring OSPF FRR·· 100

Configuration prerequisites· 100

Configuration guidelines· 101

Configuration procedure· 101

Advertising OSPF link state information to BGP·· 102

Displaying and maintaining OSPF·· 102

OSPF configuration examples· 104

Basic OSPF configuration example· 104

OSPF route redistribution configuration example· 106

OSPF route summarization configuration example· 108

OSPF stub area configuration example· 111

OSPF NSSA area configuration example· 113

OSPF DR election configuration example· 115

OSPF virtual link configuration example· 119

OSPF GR configuration example· 121

OSPF NSR configuration example· 124

BFD for OSPF configuration example· 126

OSPF FRR configuration example· 129

Troubleshooting OSPF configuration·· 131

No OSPF neighbor relationship established· 131

Incorrect routing information·· 132

Configuring IS-IS·· 133

Overview·· 133

Terminology· 133

IS-IS address format 133

NET· 134

IS-IS area· 135

IS-IS network types· 136

IS-IS PDUs· 137

Protocols and standards· 139

IS-IS configuration task list 139

Configuring basic IS-IS·· 140

Configuration prerequisites· 140

Enabling IS-IS·· 141

Setting the IS level and circuit level 141

Configuring P2P network type for an interface· 141

Configuring IS-IS route control 142

Configuration prerequisites· 142

Configuring IS-IS link cost 142

Specifying a preference for IS-IS·· 143

Configuring the maximum number of ECMP routes· 144

Configuring IS-IS route summarization·· 144

Advertising a default route· 145

Configuring IS-IS route redistribution·· 145

Configuring IS-IS route filtering· 145

Configuring IS-IS route leaking· 146

Tuning and optimizing IS-IS networks· 147

Configuration prerequisites· 147

Specifying the interval for sending IS-IS hello packets· 147

Specifying the IS-IS hello multiplier 147

Specifying the interval for sending IS-IS CSNP packets· 148

Configuring a DIS priority for an interface· 148

Disabling an interface from sending/receiving IS-IS packets· 148

Enabling an interface to send small hello packets· 149

Configuring LSP parameters· 149

Controlling SPF calculation interval 151

Configuring convergence priorities for specific routes· 152

Setting the LSDB overload bit 152

Configuring the ATT bit 153

Configuring the tag value for an interface· 153

Configuring system ID to host name mappings· 154

Enabling the logging of neighbor state changes· 155

Enabling IS-IS ISPF·· 155

Enabling prefix suppression·· 155

Configuring IS-IS network management 156

Configuring IS-IS PIC·· 157

Enhancing IS-IS network security· 158

Configuration prerequisites· 158

Configuring neighbor relationship authentication·· 158

Configuring area authentication·· 158

Configuring routing domain authentication·· 159

Configuring IS-IS GR·· 159

Configuring IS-IS NSR·· 160

Configuring BFD for IS-IS·· 161

Configuring IS-IS FRR·· 161

Configuration prerequisites· 162

Configuration guidelines· 162

Configuration procedure· 162

Displaying and maintaining IS-IS·· 163

IS-IS configuration examples· 165

Basic IS-IS configuration example· 165

DIS election configuration example· 169

IS-IS route redistribution configuration example· 173

IS-IS authentication configuration example· 177

IS-IS GR configuration example· 180

IS-IS NSR configuration example· 181

BFD for IS-IS configuration example· 184

IS-IS FRR configuration example· 187

Configuring BGP·· 191

Overview·· 191

BGP speaker and BGP peer 191

BGP message types· 191

BGP path attributes· 191

BGP route selection·· 195

BGP route advertisement rules· 195

BGP load balancing· 196

Settlements for problems in large-scale BGP networks· 197

MP-BGP·· 200

BGP multi-instance· 201

BGP configuration views· 201

Protocols and standards· 203

BGP configuration task list 203

Configuring basic BGP·· 206

Enabling BGP·· 206

Configuring a BGP peer 207

Configuring dynamic BGP peers· 209

Configuring a BGP peer group· 211

Specifying the source address of TCP connections· 220

Generating BGP routes· 221

Injecting a local network· 221

Redistributing IGP routes· 223

Controlling route distribution and reception·· 224

Configuring BGP route summarization·· 224

Advertising optimal routes in the IP routing table· 227

Advertising a default route to a peer or peer group· 228

Limiting routes received from a peer or peer group· 230

Configuring BGP route filtering policies· 231

Configuring BGP route update delay· 237

Configuring BGP route dampening· 238

Controlling BGP path selection·· 239

Setting a preferred value for routes received· 239

Configuring preferences for BGP routes· 241

Configuring the default local preference· 242

Configuring the MED attribute· 244

Configuring the NEXT_HOP attribute· 248

Configuring the AS_PATH attribute· 250

Ignoring IGP metrics during optimal route selection·· 255

Configuring the SoO attribute· 256

Tuning and optimizing BGP networks· 258

Configuring the keepalive interval and hold time· 258

Configuring the interval for sending updates for the same route· 259

Enabling BGP to establish an EBGP session over multiple hops· 260

Enabling immediate re-establishment of direct EBGP connections upon link failure· 261

Enabling 4-byte AS number suppression·· 262

Enabling MD5 authentication for BGP peers· 263

Enabling keychain authentication for BGP peers· 264

Configuring BGP load balancing· 265

Disabling BGP to establish a session to a peer or peer group· 266

Configuring GTSM for BGP·· 267

Configuring BGP soft-reset 268

Protecting an EBGP peer when memory usage reaches level 2 threshold· 274

Configuring an update delay for local MPLS labels· 275

Flushing the suboptimal BGP route to the RIB·· 276

Setting a DSCP value for outgoing BGP packets· 276

Enabling per-prefix label allocation·· 277

Disabling optimal route selection for labeled routes without tunnel information·· 277

Configuring a large-scale BGP network· 278

Configuring BGP community· 278

Configuring BGP route reflection·· 280

Configuring a BGP confederation·· 282

Configuring BGP GR·· 283

Configuring BGP NSR·· 284

Enabling SNMP notifications for BGP·· 285

Enabling logging for session state changes· 285

Enabling logging for BGP route flapping· 286

Configuring BFD for BGP·· 288

Configuring BGP FRR·· 289

Configuring 6PE·· 292

Configuring basic 6PE·· 292

Configuring optional 6PE capabilities· 293

Configuring BGP LS·· 295

Configuring basic BGP LS·· 295

Configuring BGP LS route reflection·· 295

Specifying an AS number and a router ID for BGP LS messages· 296

Displaying and maintaining BGP·· 296

Displaying BGP·· 296

Resetting BGP sessions· 299

Clearing BGP information·· 299

IPv4 BGP configuration examples· 300

Basic BGP configuration example· 300

BGP and IGP route redistribution configuration example· 304

BGP route summarization configuration example· 307

BGP load balancing configuration example· 310

BGP community configuration example· 313

BGP route reflector configuration example· 316

BGP confederation configuration example· 318

BGP path selection configuration example· 322

BGP GR configuration example· 325

BFD for BGP configuration example· 326

BGP FRR configuration example· 330

Multicast BGP configuration example· 334

Dynamic BGP peer configuration example· 337

BGP LS configuration example· 339

IPv6 BGP configuration examples· 341

IPv6 BGP basic configuration example· 341

IPv6 BGP route reflector configuration example· 344

6PE configuration example· 347

BFD for IPv6 BGP configuration example· 350

IPv6 BGP FRR configuration example· 353

Troubleshooting BGP·· 357

Symptom·· 357

Analysis· 357

Solution·· 357

Configuring PBR·· 358

Overview·· 358

Policy· 358

PBR and Track· 359

Restrictions and guidelines: PBR configuration·· 359

PBR configuration task list 360

Configuring a policy· 360

Creating a node· 360

Setting match criteria for a node· 360

Configuring actions for a node· 361

Specifying a policy for PBR·· 362

Specifying a policy for local PBR·· 362

Specifying a policy for interface PBR·· 362

Specifying a policy for outbound PBR on a VXLAN tunnel interface· 363

Displaying and maintaining PBR·· 363

PBR configuration examples· 364

Packet type-based local PBR configuration example· 364

Packet type-based interface PBR configuration example· 365

Configuring IPv6 static routing· 368

Configuring an IPv6 static route· 368

Configuring BFD for IPv6 static routes· 368

Bidirectional control mode· 369

Single-hop echo mode· 369

Displaying and maintaining IPv6 static routes· 370

IPv6 static routing configuration examples· 370

Basic IPv6 static route configuration example· 370

BFD for IPv6 static routes configuration example (direct next hop) 372

BFD for IPv6 static routes configuration example (indirect next hop) 375

Configuring an IPv6 default route· 378

Configuring RIPng· 379

Overview·· 379

RIPng route entries· 379

RIPng packets· 379

Protocols and standards· 380

RIPng configuration task list 380

Configuring basic RIPng· 380

Configuring RIPng route control 381

Configuring an additional routing metric· 381

Configuring RIPng route summarization·· 381

Advertising a default route· 382

Configuring received/redistributed route filtering· 382

Setting a preference for RIPng· 382

Configuring RIPng route redistribution·· 383

Tuning and optimizing the RIPng network· 383

Setting RIPng timers· 383

Configuring split horizon and poison reverse· 384

Configuring zero field check on RIPng packets· 384

Setting the maximum number of ECMP routes· 385

Configuring the RIPng packet sending rate· 385

Setting the interval for sending triggered updates· 386

Configuring RIPng GR·· 386

Configuring RIPng NSR·· 387

Configuring RIPng FRR·· 387

Configuration restrictions and guidelines· 388

Configuration prerequisites· 388

Configuring RIPng FRR·· 388

Enabling BFD for RIPng FRR·· 388

Displaying and maintaining RIPng· 389

RIPng configuration examples· 389

Basic RIPng configuration example· 389

RIPng route redistribution configuration example· 392

RIPng GR configuration example· 394

RIPng NSR configuration example· 395

Configuring RIPng FRR·· 397

Configuring OSPFv3· 400

Overview·· 400

OSPFv3 packets· 400

OSPFv3 LSA types· 400

Protocols and standards· 401

OSPFv3 configuration task list 401

Enabling OSPFv3· 402

Configuring OSPFv3 area parameters· 403

Configuration prerequisites· 403

Configuring a stub area· 403

Configuring an NSSA area· 403

Configuring an OSPFv3 virtual link· 404

Configuring OSPFv3 network types· 404

Configuration prerequisites· 405

Configuring the OSPFv3 network type for an interface· 405

Configuring an NBMA or P2MP neighbor 405

Configuring OSPFv3 route control 406

Configuration prerequisites· 406

Configuring OSPFv3 route summarization·· 406

Configuring OSPFv3 received route filtering· 407

Configuring Inter-Area-Prefix LSA filtering· 407

Setting an OSPFv3 cost for an interface· 407

Setting the maximum number of OSPFv3 ECMP routes· 408

Setting a preference for OSPFv3· 408

Configuring OSPFv3 route redistribution·· 409

Tuning and optimizing OSPFv3 networks· 410

Configuration prerequisites· 410

Setting OSPFv3 timers· 410

Setting LSA transmission delay· 411

Setting SPF calculation interval 411

Setting the LSA generation interval 411

Setting a DR priority for an interface· 412

Ignoring MTU check for DD packets· 412

Disabling interfaces from receiving and sending OSPFv3 packets· 412

Enabling logging for neighbor state changes· 413

Configuring OSPFv3 network management 413

Setting the LSU transmit rate· 414

Configuring stub routers· 414

Configuring prefix suppression·· 415

Setting the maximum number of OSPFv3 logs· 416

Configuring OSPFv3 authentication·· 416

Configuring OSPFv3 GR·· 417

Configuring GR restarter 417

Configuring GR helper 418

Triggering OSPFv3 GR·· 418

Configuring OSPFv3 NSR·· 418

Configuring BFD for OSPFv3· 419

Configuring OSPFv3 FRR·· 419

Configuration prerequisites· 420

Configuration guidelines· 420

Configuration procedure· 420

Displaying and maintaining OSPFv3· 422

OSPFv3 configuration examples· 423

OSPFv3 stub area configuration example· 423

OSPFv3 NSSA area configuration example· 427

OSPFv3 DR election configuration example· 429

OSPFv3 route redistribution configuration example· 432

OSPFv3 route summarization configuration example· 435

OSPFv3 GR configuration example· 439

OSPFv3 NSR configuration example· 440

BFD for OSPFv3 configuration example· 441

OSPFv3 FRR configuration example· 444

Configuring IPv6 IS-IS·· 447

Overview·· 447

Configuring basic IPv6 IS-IS·· 447

Configuring IPv6 IS-IS route control 448

Configuring IPv6 IS-IS link cost 449

Tuning and optimizing IPv6 IS-IS networks· 450

Configuration prerequisites· 450

Assigning a convergence priority to IPv6 IS-IS routes· 450

Setting the LSDB overload bit 451

Configuring a tag value on an interface· 451

Controlling SPF calculation interval 451

Enabling IPv6 IS-IS ISPF·· 452

Enabling prefix suppression·· 452

Configuring BFD for IPv6 IS-IS·· 452

Configuring IPv6 IS-IS FRR·· 453

Configuration prerequisites· 453

Configuration procedure· 454

Enabling IPv6 IS-IS MTR·· 455

Displaying and maintaining IPv6 IS-IS·· 456

IPv6 IS-IS configuration examples· 456

IPv6 IS-IS basic configuration example· 456

BFD for IPv6 IS-IS configuration example· 461

IPv6 IS-IS FRR configuration example· 463

Configuring IPv6 PBR·· 467

Overview·· 467

Policy· 467

IPv6 PBR and Track· 468

Restrictions and guidelines: IPv6 PBR configuration·· 468

IPv6 PBR configuration task list 468

Configuring an IPv6 policy· 469

Creating an IPv6 node· 469

Setting match criteria for an IPv6 node· 469

Configuring actions for an IPv6 node· 469

Configuring IPv6 PBR·· 470

Configuring IPv6 local PBR·· 470

Configuring IPv6 interface PBR·· 470

Displaying and maintaining IPv6 PBR·· 471

IPv6 PBR configuration examples· 471

Packet type-based IPv6 local PBR configuration example· 471

Packet type-based IPv6 interface PBR configuration example· 473

Configuring routing policies· 476

Overview·· 476

Filters· 476

Routing policy· 476

Configuring filters· 477

Configuration prerequisites· 477

Configuring an IP prefix list 477

Configuring an AS path list 478

Configuring a community list 478

Configuring an extended community list 478

Configuring a routing policy· 479

Configuration prerequisites· 479

Creating a routing policy· 479

Configuring if-match clauses· 479

Configuring apply clauses· 481

Configuring the continue clause· 482

Displaying and maintaining the routing policy· 483

Routing policy configuration examples· 483

Routing policy configuration example for IPv4 route redistribution·· 483

Routing policy configuration example for IPv6 route redistribution·· 486

Index· 489

 


Configuring basic IP routing

IP routing directs IP packet forwarding on routers based on a routing table. This chapter focuses on unicast routing protocols. For more information about multicast routing protocols, see IP Multicast Configuration Guide.

Routing table

A RIB contains the global routing information and related information, including route recursion, route redistribution, and route extension information. The router selects optimal routes from the routing table and puts them into the FIB table. It uses the FIB table to forward packets. For more information about the FIB table, see Layer 3—IP Services Configuration Guide.

Table 1 categorizes routes by different criteria.

Table 1 Route categories

Criterion

Categories

Destination

·         Network route—The destination is a network. The subnet mask is less than 32 bits.

·         Host route—The destination is a host. The subnet mask is 32 bits.

Whether the destination is directly connected

·         Direct route—The destination is directly connected.

·         Indirect route—The destination is indirectly connected.

Origin

·         Direct route—A direct route is discovered by the data link protocol on an interface, and is also called an interface route.

·         Static route—A static route is manually configured by an administrator.

·         Dynamic route—A dynamic route is dynamically discovered by a routing protocol.

 

To view brief information about a routing table, use the display ip routing-table command.

<Sysname> display ip routing-table

 

Destinations : 9        Routes : 9

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

0.0.0.0/32         Direct  0   0           127.0.0.1       InLoop0

3.3.3.3/32         Direct  0   0           127.0.0.1       InLoop0

127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0

127.0.0.0/32       Direct  0   0           127.0.0.1       InLoop0

127.0.0.1/32       Direct  0   0           127.0.0.1       InLoop0

127.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

...

A route entry includes the following key items:

·          Destination—IP address of the destination host or network.

·          Mask—Mask length of the IP address.

·          Proto—Protocol that installed the route.

·          Pre—Preference of the route. Among routes to the same destination, the route with the highest preference is optimal.

·          Cost—If multiple routes to a destination have the same preference, the one with the smallest cost is the optimal route.

·          NextHop—Next hop.

·          Interface—Output interface.

Dynamic routing protocols

Static routes work well in small, stable networks. They are easy to configure and require fewer system resources. However, in networks where topology changes occur frequently, a typical practice is to configure a dynamic routing protocol. Compared with static routing, a dynamic routing protocol is complicated to configure, requires more router resources, and consumes more network resources.

Dynamic routing protocols dynamically collect and report reachability information to adapt to topology changes. They are suitable for large networks.

Dynamic routing protocols can be classified by different criteria, as shown in Table 2.

Table 2 Categories of dynamic routing protocols

Criterion

Categories

Operation scope

·         IGPs—Work within an AS. Examples include RIP, OSPF, and IS-IS.

·         EGPs—Work between ASs. The most popular EGP is BGP.

Routing algorithm

·         Distance-vector protocols—Examples include RIP and BGP. BGP is also considered a path-vector protocol.

·         Link-state protocols—Examples include OSPF and IS-IS.

Destination address type

·         Unicast routing protocols—Examples include RIP, OSPF, BGP, and IS-IS.

·         Multicast routing protocols—Examples include PIM-SM and PIM-DM.

IP version

·         IPv4 routing protocols—Examples include RIP, OSPF, BGP, and IS-IS.

·         IPv6 routing protocols—Examples include RIPng, OSPFv3, IPv6 BGP, and IPv6 IS-IS.

 

An AS refers to a group of routers that use the same routing policy and work under the same administration.

Route preference

Routing protocols, including static and direct routing, each by default have a preference. If they find multiple routes to the same destination, the router selects the route with the highest preference as the optimal route.

The preference of a direct route is always 0 and cannot be changed. You can configure a preference for each static route and each dynamic routing protocol. The following table lists the route types and default preferences. The smaller the value, the higher the preference.

Table 3 Route types and default route preferences

Route type

Preference

Direct route

0

Multicast static route

1

OSPF

10

IS-IS

15

Unicast static route

60

RIP

100

OSPF ASE

150

OSPF NSSA

150

IBGP

255

EBGP

255

Unknown (route from an untrusted source)

256

 

Load sharing

A routing protocol might find multiple optimal equal-cost routes to the same destination. You can use these routes to implement equal-cost multi-path (ECMP) load sharing.

Static routing, IPv6 static routing, RIP, RIPng, OSPF, OSPFv3, BGP, IPv6 BGP, IS-IS, and IPv6 IS-IS support ECMP load sharing.

Route backup

Route backup can improve network availability. Among multiple routes to the same destination, the route with the highest priority is the primary route and others are secondary routes.

The router forwards matching packets through the primary route. When the primary route fails, the route with the highest preference among the secondary routes is selected to forward packets. When the primary route recovers, the router uses it to forward packets.

Route recursion

To use a BGP, static, or RIP route that has an indirectly connected next hop, a router must perform route recursion to find the output interface to reach the next hop.

Link-state routing protocols, such as OSPF and IS-IS, do not need route recursion, because they obtain directly connected next hops through route calculation.

The RIB records and saves route recursion information, including brief information about related routes, recursive paths, and recursion depth.

Route redistribution

Route redistribution enables routing protocols to learn routing information from each other. A dynamic routing protocol can redistribute routes from other routing protocols, including direct and static routing. For more information, see the respective chapters on those routing protocols in this configuration guide.

The RIB records redistribution relationships of routing protocols.

Extension attribute redistribution

Extension attribute redistribution enables routing protocols to learn route extension attributes from each other, including BGP extended community attributes, OSPF area IDs, route types, and router IDs.

The RIB records extended attributes of each routing protocol and redistribution relationships of different routing protocol extended attributes.

Setting the maximum lifetime for routes and labels in the RIB

Perform this task to prevent routes of a certain protocol from being aged out due to slow protocol convergence resulting from a large number of route entries or long GR period.

The configuration takes effect at the next protocol or RIB process switchover.

To set the maximum lifetime for routes and labels in the RIB (IPv4):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv4 address family and enter its view.

address-family ipv4

By default, no RIB IPv4 address family exists.

4.       Set the maximum lifetime for IPv4 routes and labels in the RIB.

protocol protocol [ instance instance-name ] lifetime seconds

By default, the maximum lifetime for routes and labels in the RIB is 480 seconds.

 

To set the maximum route lifetime for routes and labels in the RIB (IPv6):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv6 address family and enter its view.

address-family ipv6

By default, no RIB IPv6 address family exists.

4.       Set the maximum lifetime for IPv6 routes and labels in the RIB.

protocol protocol [ instance instance-name ] lifetime seconds

By default, the maximum lifetime for routes and labels in the RIB is 480 seconds.

 

Setting the maximum lifetime for routes in the FIB

When GR or NSR is disabled, FIB entries must be retained for some time after a protocol process switchover or RIB process switchover. When GR or NSR is enabled, FIB entries must be removed immediately after a protocol or RIB process switchover to avoid routing issues. Perform this task to meet such requirements.

To set the maximum lifetime for routes in the FIB (IPv4):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv4 address family and enter its view.

address-family ipv4

By default, no RIB IPv4 address family exists.

4.       Set the maximum lifetime for IPv4 routes in the FIB.

fib lifetime seconds

By default, the maximum lifetime for routes in the FIB is 600 seconds.

 

To set the maximum lifetime for routes in the FIB (IPv6):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv6 address family and enter its view.

address-family ipv6

By default, no RIB IPv6 address family exists.

4.       Set the maximum lifetime for IPv6 routes in the FIB.

fib lifetime seconds

By default, the maximum lifetime for routes in the FIB is 600 seconds.

 

Configuring RIB NSR

IMPORTANT

IMPORTANT:

Use this feature with protocol GR or NSR to avoid route timeouts and traffic interruption.

 

When an active/standby switchover occurs, nonstop routing (NSR) backs up routing information from the active process to the standby process to avoid routing flapping and ensure forwarding continuity.

RIB NSR provides faster route convergence than protocol NSR during an active/standby switchover.

Configuring IPv4 RIB NSR

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv4 address family and enter its view.

address-family ipv4

By default, no RIB IPv4 address family exists.

4.       Enable IPv4 RIB NSR.

non-stop-routing

By default, RIB NSR is disabled.

 

Configuring IPv6 RIB NSR

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv6 address family and enter its view.

address-family ipv6

By default, no RIB IPv6 address family exists.

4.       Enable IPv6 RIB NSR.

non-stop-routing

By default, RIB NSR is disabled.

 

Configuring inter-protocol FRR

CAUTION

CAUTION:

This feature uses the next hop of a route from a different protocol as the backup next hop for the faulty route, which might cause loops.

 

Inter-protocol fast reroute (FRR) enables fast rerouting between routes of different protocols. A backup next hop is automatically selected to reduce the service interruption time caused by unreachable next hops. When the next hop of the primary link fails, the traffic is redirected to the backup next hop.

Among the routes to the same destination in the RIB, a router adds the route with the highest preference to the FIB table. For example, if a static route and an OSPF route in the RIB have the same destination, the router adds the OSPF route to the FIB table by default. The next hop of the static route is selected as the backup next hop for the OSPF route. When the next hop of the OSPF route is unreachable, the backup next hop is used.

Configuring IPv4 RIB inter-protocol FRR

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv4 address family and enter its view.

address-family ipv4

By default, no RIB IPv4 address family exists.

4.       Enable IPv4 RIB inter-protocol FRR.

inter-protocol fast-reroute [ vpn-instance vpn-instance-name ]

By default, inter-protocol FRR is disabled.

If you do not specify a VPN instance, inter-protocol FRR is enabled for the public network.

 

Configuring IPv6 RIB inter-protocol FRR

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIB view.

rib

N/A

3.       Create the RIB IPv6 address family and enter its view.

address-family ipv6

By default, no RIB IPv6 address family exists.

4.       Enable IPv6 RIB inter-protocol FRR.

inter-protocol fast-reroute [ vpn-instance vpn-instance-name ]

By default, inter-protocol FRR is disabled.

If you do not specify a VPN instance, inter-protocol FRR is enabled for the public network.

 

Enabling the IPv4 enhanced ECMP mode

When one or multiple ECMP routes fail, the default ECMP mode enables the device to reallocate all traffic to the remaining routes.

The IPv4 enhanced ECMP mode enables the device to reallocate only the traffic of the failed routes to the remaining routes, which ensures forwarding continuity.

This configuration takes effect at reboot. Make sure the reboot does not impact your network.

To enable the IPv4 enhanced ECMP mode:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable the IPv4 enhanced ECMP mode.

ecmp mode enhanced

By default, the IPv4 enhanced ECMP mode is disabled.

 

Displaying and maintaining a routing table

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display the IPv4 ECMP mode.

display ecmp mode

Display routing table information.

display ip routing-table [ vpn-instance vpn-instance-name ] [ verbose ]

Display information about routes permitted by an IPv4 basic ACL.

display ip routing-table [ vpn-instance vpn-instance-name ] acl ipv4-acl-number [ verbose ]

Display information about routes to a specific destination address.

display ip routing-table [ vpn-instance vpn-instance-name ] ip-address [ mask-length | mask ] [ longer-match ] [ verbose ]

Display information about routes to a range of destination addresses.

display ip routing-table [ vpn-instance vpn-instance-name ] ip-address1 to ip-address2 [ verbose ]

Display information about routes permitted by an IP prefix list.

display ip routing-table [ vpn-instance vpn-instance-name ] prefix-list prefix-list-name [ verbose ]

Display information about routes installed by a protocol.

display ip routing-table [ vpn-instance vpn-instance-name ] protocol protocol [ inactive | verbose ]

Display IPv4 route statistics.

display ip routing-table [ vpn-instance vpn-instance-name ] statistics

Display brief IPv4 routing table information.

display ip routing-table [ vpn-instance vpn-instance-name ] summary

Display route attribute information in the RIB.

display rib attribute [ attribute-id ]

Display RIB GR state information.

display rib graceful-restart

Display next hop information in the RIB.

display rib nib [ self-originated ] [ nib-id ] [ verbose ]

display rib nib protocol protocol [ verbose ]

Display next hop information for direct routes.

display route-direct nib [ nib-id ] [ verbose ]

Clear IPv4 route statistics.

reset ip routing-table statistics protocol [ vpn-instance vpn-instance-name ] { protocol | all }

Display IPv6 routing table information.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] [ verbose ]

Display information about routes to an IPv6 destination address.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] ipv6-address [ prefix-length ] [ longer-match ] [ verbose ]

Display information about routes permitted by an IPv6 basic ACL.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] acl ipv6-acl-number [ verbose ]

Display information about routes to a range of IPv6 destination addresses.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] ipv6-address1 to ipv6-address2 [ verbose ]

Display information about routes permitted by an IPv6 prefix list.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] prefix-list prefix-list-name [ verbose ]

Display information about routes installed by an IPv6 protocol.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] protocol protocol [ inactive | verbose ]

Display IPv6 route statistics.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] statistics

Display brief IPv6 routing table information.

display ipv6 routing-table [ vpn-instance vpn-instance-name ] summary

Display route attribute information in the IPv6 RIB.

display ipv6 rib attribute [ attribute-id ]

Display IPv6 RIB GR state information.

display ipv6 rib graceful-restart

Display next hop information in the IPv6 RIB.

display ipv6 rib nib [ self-originated ] [ nib-id ] [ verbose ]

display ipv6 rib nib protocol protocol [ verbose ]

Display next hop information for IPv6 direct routes.

display ipv6 route-direct nib [ nib-id ] [ verbose ]

Clear IPv6 route statistics.

reset ipv6 routing-table statistics protocol [ vpn-instance vpn-instance-name ] { protocol | all }

 

 


Configuring static routing

Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work correctly.

Static routes cannot adapt to network topology changes. If a fault or a topological change occurs in the network, the network administrator must modify the static routes manually.

Configuring a static route

Before you configure a static route, complete the following tasks:

·          Configure the physical parameters for related interfaces.

·          Configure the link-layer attributes for related interfaces.

·          Configure the IP addresses for related interfaces.

You can associate Track with a static route to monitor the reachability of the next hops. For more information about Track, see High Availability Configuration Guide.

To configure a static route:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       (Optional.) Create a static route group and enter its view.

ip route-static-group group-name

By default, no static route group is configured.

3.       (Optional.) Add a static route prefix to the static route group.

prefix dest-address { mask-length | mask }

By default, no static route prefix is added to the static route group.

4.       (Optional.) Return to system view.

quit

N/A

5.       Configure a static route.

·         Method 1:
ip
route-static { dest-address { mask-length | mask } | group group-name } { interface-type interface-number [ next-hop-address ] | next-hop-address [ track track-entry-number ] | vpn-instance d-vpn-instance-name next-hop-address [ track track-entry-number ] } [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

·         Method 2:
ip route-static vpn-instance s-vpn-instance-name { dest-address { mask-length | mask } | group group-name } { interface-type interface-number [ next-hop-address ] | next-hop-address [ public ] [ track track-entry-number ] | vpn-instance d-vpn-instance-name next-hop-address [ track track-entry-number ] } [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

By default, no static route is configured.

6.       (Optional.) Configure the default preference for static routes.

ip route-static default-preference default-preference

The default setting is 60.

7.       (Optional.) Delete all static routes, including the default route.

delete [ vpn-instance vpn-instance-name ] static-routes all

To delete one static route, use the undo ip route-static command.

 

Configuring BFD for static routes

IMPORTANT

IMPORTANT:

Enabling BFD for a flapping route could worsen the situation.

 

BFD provides a general-purpose, standard, medium-, and protocol-independent fast failure detection mechanism. It can uniformly and quickly detect the failures of the bidirectional forwarding paths between two routers for protocols, such as routing protocols and MPLS.

For more information about BFD, see High Availability Configuration Guide.

Bidirectional control mode

To use BFD bidirectional control detection between two devices, enable BFD control mode for each device's static route destined to the peer.

To configure a static route and enable BFD control mode, use one of the following methods:

·          Specify an output interface and a direct next hop.

·          Specify an indirect next hop and a specific BFD packet source address for the static route.

To configure BFD control mode for a static route (direct next hop):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure BFD control mode for a static route.

·         Method 1:
ip route-static dest-address { mask-length | mask } interface-type interface-number next-hop-address bfd control-packet [ preference preference ] [ tag tag-value ] [ description text ]

·         Method 2:
ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } interface-type interface-number next-hop-address bfd control-packet [ preference preference ] [ tag tag-value ] [ description text ]

By default, BFD control mode for a static route is not configured.

 

To configure BFD control mode for a static route (indirect next hop):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure BFD control mode for a static route.

·         Method 1:
ip route-static dest-address { mask-length | mask } { next-hop-address bfd control-packet bfd-source ip-address | vpn-instance d-vpn-instance-name next-hop-address bfd control-packet bfd-source ip-address } [ preference preference ] [ tag tag-value ] [ description text ]

·         Method 2:
ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } { next-hop-address bfd control-packet bfd-source ip-address | vpn-instance d-vpn-instance-name next-hop-address bfd control-packet bfd-source ip-address } [ preference preference ] [ tag tag-value ] [ description text ]

By default, BFD control mode for a static route is not configured.

 

Single-hop echo mode

With BFD echo mode enabled for a static route, the output interface sends BFD echo packets to the destination device, which loops the packets back to test the link reachability.

 

IMPORTANT

IMPORTANT:

Do not use BFD for a static route with the output interface in spoofing state.

 

To configure BFD echo mode for a static route:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the source address of echo packets.

bfd echo-source-ip ip-address

By default, the source address of echo packets is not configured.

For more information about this command, see High Availability Command Reference.

3.       Configure BFD echo mode for a static route.

·         Method 1:
ip route-static dest-address { mask-length | mask } interface-type interface-number next-hop-address bfd echo-packet [ preference preference ] [ tag tag-value ] [ description text ]

·         Method 2:
ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } interface-type interface-number next-hop-address bfd echo-packet [ preference preference ] [ tag tag-value ] [ description text ]

By default, BFD echo mode for a static route is not configured.

 

Configuring static route FRR

A link or router failure on a path can cause packet loss and even routing loop. Static route fast reroute (FRR) enables fast rerouting to minimize the impact of link or node failures.

Figure 1 Network diagram

 

As shown in Figure 1, upon a link failure, packets are directed to the backup next hop to avoid traffic interruption. You can either specify a backup next hop for FRR or enable FRR to automatically select a backup next hop (which must be configured in advance).

Configuration guidelines

·          Do not use static route FRR and BFD (for a static route) at the same time.

·          Static route does not take effect when the backup output interface is unavailable.

·          Equal-cost routes do not support static route FRR.

·          The backup output interface and next hop must be different from the primary output interface and next hop.

·          To change the backup output interface or next hop, you must first remove the current setting.

·          Static route FRR is available only when the state of primary link (with Layer 3 interfaces staying up) changes from bidirectional to unidirectional or down.

Configuring static route FRR by specifying a backup next hop

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure static route FRR.

·         Method 1:
ip route-static dest-address { mask-length | mask } interface-type interface-number [ next-hop-address [ backup-interface interface-type interface-number [ backup-nexthop backup-nexthop-address ] ] ] [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

·         Method 2:
ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } interface-type interface-number [ next-hop-address [ backup-interface interface-type interface-number [ backup-nexthop backup-nexthop-address ] ] ] [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

By default, static route FRR is disabled.

 

Configuring static route FRR to automatically select a backup next hop

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure static route FRR to automatically select a backup next hop.

ip route-static fast-reroute auto

By default, static route FRR is disabled from automatically selecting a backup next hop.

 

Enabling BFD echo packet mode for static route FRR

By default, static route FRR uses ARP to detect primary link failures. Perform this task to enable static route FRR to use BFD echo packet mode for fast failure detection on the primary link.

To enable BFD echo packet mode for static route FRR:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the source IP address of BFD echo packets.

bfd echo-source-ip ip-address

By default, the source IP address of BFD echo packets is not configured.

The source IP address cannot be on the same network segment as any local interface's IP address.

For more information about this command, see High Availability Command Reference.

3.       Enable BFD echo packet mode for static route FRR.

ip route-static primary-path-detect bfd echo

By default, BFD echo mode for static route FRR is disabled.

 

Displaying and maintaining static routes

Execute display commands in any view.

 

Task

Command

Display static route information.

display ip routing-table protocol static [ inactive | verbose ]

Display static route next hop information.

display route-static nib [ nib-id ] [ verbose ]

Display static routing table information.

display route-static routing-table [ vpn-instance vpn-instance-name ] [ ip-address { mask-length | mask } ]

 

Static route configuration examples

Basic static route configuration example

Network requirements

As shown in Figure 2, configure static routes on the switches for interconnections between any two hosts.

Figure 2 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure static routes:

# Configure a default route on Switch A.

<SwitchA> system-view

[SwitchA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2

# Configure two static routes on Switch B.

<SwitchB> system-view

[SwitchB] ip route-static 1.1.2.0 255.255.255.0 1.1.4.1

[SwitchB] ip route-static 1.1.3.0 255.255.255.0 1.1.5.6

# Configure a default route on Switch C.

<SwitchC> system-view

[SwitchC] ip route-static 0.0.0.0 0.0.0.0 1.1.5.5

3.        Configure the default gateways of Host A, Host B, and Host C as 1.1.2.3, 1.1.6.1, and 1.1.3.1. (Details not shown.)

Verifying the configuration

# Display static routes on Switch A.

[SwitchA] display ip routing-table protocol static

 

Summary Count : 1

 

Static Routing table Status : <Active>

Summary Count : 1

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/0           Static 60   0            1.1.4.2         Vlan500

 

Static Routing table Status : <Inactive>

Summary Count : 0

# Display static routes on Switch B.

[SwitchB] display ip routing-table protocol static

 

Summary Count : 2

 

Static Routing table Status : <Active>

Summary Count : 2

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

1.1.2.0/24          Static 60   0            1.1.4.1         Vlan500

 

Static Routing table Status : <Inactive>

Summary Count : 0

# Use the ping command on Host B to test the reachability of Host A (Windows XP runs on the two hosts).

C:\Documents and Settings\Administrator>ping 1.1.2.2

 

Pinging 1.1.2.2 with 32 bytes of data:

 

Reply from 1.1.2.2: bytes=32 time=1ms TTL=126

Reply from 1.1.2.2: bytes=32 time=1ms TTL=126

Reply from 1.1.2.2: bytes=32 time=1ms TTL=126

Reply from 1.1.2.2: bytes=32 time=1ms TTL=126

 

Ping statistics for 1.1.2.2:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 1ms, Average = 1ms

# Use the tracert command on Host B to test the reachability of Host A.

C:\Documents and Settings\Administrator>tracert 1.1.2.2

 

Tracing route to 1.1.2.2 over a maximum of 30 hops

 

  1    <1 ms    <1 ms    <1 ms  1.1.6.1

  2    <1 ms    <1 ms    <1 ms  1.1.4.1

  3     1 ms    <1 ms    <1 ms  1.1.2.2

 

Trace complete.

BFD for static routes configuration example (direct next hop)

Network requirements

Configure the following, as shown in Figure 3:

·          Configure a static route to subnet 120.1.1.0/24 on Switch A.

·          Configure a static route to subnet 121.1.1.0/24 on Switch B.

·          Enable BFD for both routes.

·          Configure a static route to subnet 120.1.1.0/24 and a static route to subnet 121.1.1.0/24 on Switch C.

When the link between Switch A and Switch B through the Layer 2 switch fails, BFD can detect the failure immediately. Switch A then communicates with Switch B through Switch C.

Figure 3 Network diagram

 

Table 4 Interface and IP address assignment

Device

Interface

IP address

Switch A

VLAN-interface 10

12.1.1.1/24

Switch A

VLAN-interface 11

10.1.1.102/24

Switch B

VLAN-interface 10

12.1.1.2/24

Switch B

VLAN-interface 13

13.1.1.1/24

Switch C

VLAN-interface 11

10.1.1.100/24

Switch C

VLAN-interface 13

13.1.1.2/24

 

Configuration procedure

1.        Configure IP addresses for the interfaces. (Details not shown.)

2.        Configure static routes and BFD:

# Configure static routes on Switch A and enable BFD control mode for the static route that traverses the Layer 2 switch.

<SwitchA> system-view

[SwitchA] interface vlan-interface 10

[SwitchA-vlan-interface10] bfd min-transmit-interval 500

[SwitchA-vlan-interface10] bfd min-receive-interval 500

[SwitchA-vlan-interface10] bfd detect-multiplier 9

[SwitchA-vlan-interface10] quit

[SwitchA] ip route-static 120.1.1.0 24 vlan-interface 10 12.1.1.2 bfd control-packet

[SwitchA] ip route-static 120.1.1.0 24 vlan-interface 11 10.1.1.100 preference 65

[SwitchA] quit

# Configure static routes on Switch B and enable BFD control mode for the static route that traverses the Layer 2 switch.

<SwitchB> system-view

[SwitchB] interface vlan-interface 10

[SwitchB-vlan-interface10] bfd min-transmit-interval 500

[SwitchB-vlan-interface10] bfd min-receive-interval 500

[SwitchB-vlan-interface10] bfd detect-multiplier 9

[SwitchB-vlan-interface10] quit

[SwitchB] ip route-static 121.1.1.0 24 vlan-interface 10 12.1.1.1 bfd control-packet

[SwitchB] ip route-static 121.1.1.0 24 vlan-interface 13 13.1.1.2 preference 65

[SwitchB] quit

# Configure static routes on Switch C.

<SwitchC> system-view

[SwitchC] ip route-static 120.1.1.0 24 13.1.1.1

[SwitchC] ip route-static 121.1.1.0 24 10.1.1.102

Verifying the configuration

# Display BFD sessions on Switch A.

<SwitchA> display bfd session

 

 Total Session Num: 1     Up Session Num: 1     Init Mode: Active

 

 IPv4 Session Working Under Ctrl Mode:

 

 LD/RD          SourceAddr      DestAddr        State    Holdtime    Interface

 4/7            12.1.1.1        12.1.1.2        Up       2000ms      Vlan10

The output shows that the BFD session has been created.

# Display the static routes on Switch A.

<SwitchA> display ip routing-table protocol static

 

Summary Count : 1

 

Static Routing table Status : <Active>

Summary Count : 1

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

120.1.1.0/24        Static 60   0            12.1.1.2        Vlan10

 

Static Routing table Status : <Inactive>

Summary Count : 0

The output shows that Switch A communicates with Switch B through VLAN-interface 10. Then the link over VLAN-interface 10 fails.

# Display static routes on Switch A.

<SwitchA> display ip routing-table protocol static

 

Summary Count : 1

 

Static Routing table Status : <Active>

Summary Count : 1

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

120.1.1.0/24        Static 65   0            10.1.1.100      Vlan11

 

Static Routing table Status : <Inactive>

Summary Count : 0

The output shows that Switch A communicates with Switch B through VLAN-interface 11.

BFD for static routes configuration example (indirect next hop)

Network requirements

Figure 4 shows the network topology as follows:

·          Switch A has a route to interface Loopback 1 (2.2.2.9/32) on Switch B, with the output interface VLAN-interface 10.

·          Switch B has a route to interface Loopback 1 (1.1.1.9/32) on Switch A, with the output interface VLAN-interface 12.

·          Switch D has a route to 1.1.1.9/32, with the output interface VLAN-interface 10, and a route to 2.2.2.9/32, with the output interface VLAN-interface 12.

Configure the following:

·          Configure a static route to subnet 120.1.1.0/24 on Switch A.

·          Configure a static route to subnet 121.1.1.0/24 on Switch B.

·          Enable BFD for both routes.

·          Configure a static route to subnet 120.1.1.0/24 and a static route to subnet 121.1.1.0/24 on both Switch C and Switch D.

When the link between Switch A and Switch B through Switch D fails, BFD can detect the failure immediately. Switch A then communicates with Switch B through Switch C.

Figure 4 Network diagram

 

Table 5 Interface and IP address assignment

Device

Interface

IP address

Switch A

VLAN-interface 10

12.1.1.1/24

Switch A

VLAN-interface 11

10.1.1.102/24

Switch A

Loopback 1

1.1.1.9/32

Switch B

VLAN-interface 12

11.1.1.1/24

Switch B

VLAN-interface 13

13.1.1.1/24

Switch B

Loopback 1

2.2.2.9/32

Switch C

VLAN-interface 11

10.1.1.100/24

Switch C

VLAN-interface 13

13.1.1.2/24

Switch D

VLAN-interface 10

12.1.1.2/24

Switch D

VLAN-interface 12

11.1.1.2/24

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure static routes and BFD:

# Configure static routes on Switch A and enable BFD control mode for the static route that traverses Switch D.

<SwitchA> system-view

[SwitchA] bfd multi-hop min-transmit-interval 500

[SwitchA] bfd multi-hop min-receive-interval 500

[SwitchA] bfd multi-hop detect-multiplier 9

[SwitchA] ip route-static 120.1.1.0 24 2.2.2.9 bfd control-packet bfd-source 1.1.1.9

[SwitchA] ip route-static 120.1.1.0 24 vlan-interface 11 10.1.1.100 preference 65

[SwitchA] quit

# Configure static routes on Switch B and enable BFD control mode for the static route that traverses Switch D.

<SwitchB> system-view

[SwitchB] bfd multi-hop min-transmit-interval 500

[SwitchB] bfd multi-hop min-receive-interval 500

[SwitchB] bfd multi-hop detect-multiplier 9

[SwitchB] ip route-static 121.1.1.0 24 1.1.1.9 bfd control-packet bfd-source 2.2.2.9

[SwitchB] ip route-static 121.1.1.0 24 vlan-interface 13 13.1.1.2 preference 65

[SwitchB] quit

# Configure static routes on Switch C.

<SwitchC> system-view

[SwitchC] ip route-static 120.1.1.0 24 13.1.1.1

[SwitchC] ip route-static 121.1.1.0 24 10.1.1.102

# Configure static routes on Switch D.

<SwitchD> system-view

[SwitchD] ip route-static 120.1.1.0 24 11.1.1.1

[SwitchD] ip route-static 121.1.1.0 24 12.1.1.1

Verifying the configuration

# Display BFD sessions on Switch A.

<SwitchA> display bfd session

 

 Total Session Num: 1     Up Session Num: 1     Init Mode: Active

 

 IPv4 Session Working Under Ctrl Mode:

 

 LD/RD          SourceAddr      DestAddr        State    Holdtime    Interface

 4/7            1.1.1.9         2.2.2.9         Up       2000ms      N/A

The output shows that the BFD session has been created.

# Display the static routes on Switch A.

<SwitchA> display ip routing-table protocol static

 

Summary Count : 1

 

Static Routing table Status : <Active>

Summary Count : 1

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

120.1.1.0/24        Static 60   0            12.1.1.2        Vlan10

 

Static Routing table Status : <Inactive>

Summary Count : 0

The output shows that Switch A communicates with Switch B through VLAN-interface 10. Then the link over VLAN-interface 10 fails.

# Display static routes on Switch A.

<SwitchA> display ip routing-table protocol static

 

Summary Count : 1

 

Static Routing table Status : <Active>

Summary Count : 1

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

120.1.1.0/24        Static 65   0            10.1.1.100      Vlan11

 

Static Routing table Status : <Inactive>

Summary Count : 0

The output shows that Switch A communicates with Switch B through VLAN-interface 11.

Static route FRR configuration example

Network requirements

As shown in Figure 5, configure static routes on Switch A, Switch B, and Switch C, and configure static route FRR. When Link A becomes unidirectional, traffic can be switched to Link B immediately.

Figure 5 Network diagram

 

Table 6 Interface and IP address assignment

Device

Interface

IP address

Switch A

VLAN-interface 100

12.12.12.1/24

Switch A

VLAN-interface 200

13.13.13.1/24

Switch A

Loopback 0

1.1.1.1/32

Switch B

VLAN-interface 101

24.24.24.4/24

Switch B

VLAN-interface 200

13.13.13.2/24

Switch B

Loopback 0

4.4.4.4/32

Switch C

VLAN-interface 100

12.12.12.2/24

Switch C

VLAN-interface 101

24.24.24.2/24

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure static route FRR on link A by using one of the following methods:

?  (Method 1.) Specify a backup next hop for static route FRR:

# Configure a static route on Switch A, and specify VLAN-interface 100 as the backup output interface and 12.12.12.2 as the backup next hop.

<SwitchA> system-view

[SwitchA] ip route-static 4.4.4.4 32 vlan-interface 200 13.13.13.2 backup-interface vlan-interface 100 backup-nexthop 12.12.12.2

# Configure a static route on Switch B, and specify VLAN-interface 101 as the backup output interface and 24.24.24.2 as the backup next hop.

<SwitchB> system-view

[SwitchB] ip route-static 1.1.1.1 32 vlan-interface 200 13.13.13.1 backup-interface vlan-interface 101 backup-nexthop 24.24.24.2

?  (Method 2.) Configure static route FRR to automatically select a backup next hop:

# Configure static routes on Switch A, and enable static route FRR.

<SwitchA> system-view

[SwitchA] ip route-static 4.4.4.4 32 vlan-interface 200 13.13.13.2

[SwitchA] ip route-static 4.4.4.4 32 vlan-interface 100 12.12.12.2 preference 70

[SwitchA] ip route-static fast-reroute auto

# Configure static routes on Switch B, and enable static route FRR.

<SwitchB> system-view

[SwitchB] ip route-static 1.1.1.1 32 vlan-interface 200 13.13.13.1

[SwitchB] ip route-static 1.1.1.1 32 vlan-interface 101 24.24.24.2 preference 70

[SwitchB] ip route-static fast-reroute auto

3.        Configure static routes on Switch C.

<SwitchC> system-view

[SwitchC] ip route-static 4.4.4.4 32 vlan-interface 101 24.24.24.4

[SwitchC] ip route-static 1.1.1.1 32 vlan-interface 100 12.12.12.1

Verifying the configuration

# Display route 4.4.4.4/32 on Switch A to view the backup next hop information.

[SwitchA] display ip routing-table 4.4.4.4 verbose

 

Summary Count : 1

 

Destination: 4.4.4.4/32

   Protocol: Static          

 Process ID: 0

  SubProtID: 0x0                     Age: 04h20m37s

       Cost: 0                Preference: 60

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x26000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 0.0.0.0

      Flags: 0x1008c         OrigNextHop: 13.13.13.2

      Label: NULL            RealNextHop: 13.13.13.2

    BkLabel: NULL              BkNextHop: 12.12.12.2

  Tunnel ID: Invalid           Interface: Vlan-interface200

BkTunnel ID: Invalid         BkInterface: Vlan-interface100

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A

# Display route 1.1.1.1/32 on Switch B to view the backup next hop information.

[SwitchB] display ip routing-table 1.1.1.1 verbose

 

Summary Count : 1

 

Destination: 1.1.1.1/32

   Protocol: Static          

 Process ID: 0

  SubProtID: 0x0                     Age: 04h20m37s

       Cost: 0                Preference: 60

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x26000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 0.0.0.0

      Flags: 0x1008c         OrigNextHop: 13.13.13.1

      Label: NULL            RealNextHop: 13.13.13.1

    BkLabel: NULL              BkNextHop: 24.24.24.2

  Tunnel ID: Invalid           Interface: Vlan-interface200

BkTunnel ID: Invalid         BkInterface: Vlan-interface101

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A


Configuring a default route

A default route is used to forward packets that do not match any specific routing entry in the routing table. Without a default route, packets that do not match any routing entries are discarded.

A default route can be configured in either of the following ways:

·          The network administrator can configure a default route with both destination and mask being 0.0.0.0. For more information, see "Configuring static routing."

·          Some dynamic routing protocols, such as OSPF, IS-IS, and RIP, can generate a default route. For example, an upstream router running OSPF can generate a default route and advertise it to other routers. These routers install the default route with the next hop being the upstream router. For more information, see the respective chapters on these routing protocols in this configuration guide.

 


Configuring RIP

Overview

Routing Information Protocol (RIP) is a distance-vector IGP suited to small-sized networks. It employs UDP to exchange route information through port 520.

RIP uses a hop count to measure the distance to a destination. The hop count from a router to a directly connected network is 0. The hop count from a router to a directly connected router is 1. To limit convergence time, RIP restricts the value range of the metric from 0 to 15. A destination with a metric value of 16 (or greater) is considered unreachable. For this reason, RIP is not suitable for large-sized networks.

RIP route entries

RIP stores routing entries in a database. Each routing entry contains the following elements:

·          Destination address—IP address of a destination host or a network.

·          Next hop—IP address of the next hop.

·          Egress interface—Egress interface of the route.

·          Metric—Cost from the local router to the destination.

·          Route time—Time elapsed since the last update. The time is reset to 0 when the routing entry is updated.

·          Route tag—Used for route control. For more information, see "Configuring routing policies."

Routing loop prevention

RIP uses the following mechanisms to prevent routing loops:

·          Counting to infinity—A destination with a metric value of 16 is considered unreachable. When a routing loop occurs, the metric value of a route will increment to 16 to avoid endless looping.

·          Triggered updates—RIP immediately advertises triggered updates for topology changes to reduce the possibility of routing loops and to speed up convergence.

·          Split horizon—Disables RIP from sending routes through the interface where the routes were learned to prevent routing loops and save bandwidth.

·          Poison reverse—Enables RIP to set the metric of routes received from a neighbor to 16 and sends these routes back to the neighbor. The neighbor can delete such information from its routing table to prevent routing loops.

RIP operation

RIP works as follows:

1.        RIP sends request messages to neighboring routers. Neighboring routers return response messages that contain their routing tables.

2.        RIP uses the received responses to update the local routing table and sends triggered update messages to its neighbors. All RIP routers on the network do this to learn latest routing information.

3.        RIP periodically sends the local routing table to its neighbors. After a RIP neighbor receives the message, it updates its routing table, selects optimal routes, and sends an update to other neighbors. RIP ages routes to keep only valid routes.

RIP versions

There are two RIP versions, RIPv1 and RIPv2.

RIPv1 is a classful routing protocol. It advertises messages only through broadcast. RIPv1 messages do not carry mask information, so RIPv1 can only recognize natural networks such as Class A, B, and C. For this reason, RIPv1 does not support discontiguous subnets.

RIPv2 is a classless routing protocol. It has the following advantages over RIPv1:

·          Supports route tags to implement flexible route control through routing policies.

·          Supports masks, route summarization, and CIDR.

·          Supports designated next hops to select the best ones on broadcast networks.

·          Supports multicasting route updates so only RIPv2 routers can receive these updates to reduce resource consumption.

·          Supports plain text authentication and MD5 authentication to enhance security.

RIPv2 supports two transmission modes: broadcast and multicast. Multicast is the default mode using 224.0.0.9 as the multicast address. An interface operating in RIPv2 broadcast mode can also receive RIPv1 messages.

Protocols and standards

·          RFC 1058, Routing Information Protocol

·          RFC 1723, RIP Version 2 - Carrying Additional Information

·          RFC 1721, RIP Version 2 Protocol Analysis

·          RFC 1722, RIP Version 2 Protocol Applicability Statement

·          RFC 1724, RIP Version 2 MIB Extension

·          RFC 2082, RIPv2 MD5 Authentication

·          RFC 2453, RIP Version 2

RIP configuration task list

Tasks at a glance

Configuring basic RIP:

·         (Required.) Enabling RIP

·         (Optional.) Controlling RIP reception and advertisement on interfaces

·         (Optional.) Configuring a RIP version

(Optional.) Configuring RIP route control:

·         Configuring an additional routing metric

·         Configuring RIPv2 route summarization

·         Disabling host route reception

·         Advertising a default route

·         Configuring received/redistributed route filtering

·         Setting a preference for RIP

·         Configuring RIP route redistribution

(Optional.) Tuning and optimizing RIP networks:

·         Setting RIP timers

·         Enabling split horizon and poison reverse

·         Setting the maximum number of RIP ECMP routes

·         Enabling zero field check on incoming RIPv1 messages

·         Enabling source IP address check on incoming RIP updates

·         Configuring RIPv2 message authentication

·         Setting the RIP triggered update interval

·         Specifying a RIP neighbor

·         Configuring RIP network management

·         Configuring the RIP packet sending rate

·         Setting the maximum length of RIP packets

·         Setting the DSCP value for outgoing RIP packets

(Optional.) Configuring RIP GR

(Optional.) Enabling RIP NSR

(Optional.) Configuring BFD for RIP

(Optional.) Configuring RIP FRR

 

Configuring basic RIP

Before you configure basic RIP settings, complete the following tasks:

·          Configure the link layer protocol.

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring routers.

Enabling RIP

Follow these guidelines when you enable RIP:

·          To enable multiple RIP processes on a router, you must specify an ID for each process. A RIP process ID has only local significance. Two RIP routers having different process IDs can also exchange RIP packets.

·          If you configure RIP settings in interface view before enabling RIP, the settings do not take effect until RIP is enabled.

·          If a physical interface is attached to multiple networks, you cannot advertise these networks in different RIP processes.

·          You cannot enable multiple RIP processes on a physical interface.

·          The rip enable command takes precedence over the network command.

Enabling RIP on a network

You can enable RIP on a network and specify a wildcard mask for the network. After that, only the interface attached to the network runs RIP.

To enable RIP on a network:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable RIP and enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

By default, RIP is disabled.

3.       Enable RIP on a network.

network network-address [ wildcard-mask ]

By default, RIP is disabled on a network.

The network 0.0.0.0 command can enable RIP on all interfaces in a single process, but does not apply to multiple RIP processes.

 

Enabling RIP on an interface

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable RIP and enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

By default, RIP is disabled.

3.       Return to system view.

quit

N/A

4.       Enter interface view.

interface interface-type interface-number

N/A

5.       Enable RIP on the interface.

rip process-id enable [ exclude-subip ]

By default, RIP is disabled on an interface.

 

Controlling RIP reception and advertisement on interfaces

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Disable an interface from sending RIP messages.

silent-interface { interface-type interface-number | all }

By default, all RIP-enabled interfaces can send RIP messages.

The disabled interface can still receive RIP messages and respond to unicast requests containing unknown ports.

4.       Return to system view.

quit

N/A

5.       Enter interface view.

interface interface-type interface-number

N/A

6.       Enable an interface to receive RIP messages.

rip input

By default, a RIP-enabled interface can receive RIP messages.

7.       Enable an interface to send RIP messages.

rip output

By default, a RIP-enabled interface can send RIP messages.

 

Configuring a RIP version

You can configure a global RIP version in RIP view or an interface-specific RIP version in interface view.

An interface preferentially uses the interface-specific RIP version. If no interface-specific version is specified, the interface uses the global RIP version. If neither a global nor interface-specific RIP version is configured, the interface sends RIPv1 broadcasts and can receive the following:

·          RIPv1 broadcasts and unicasts.

·          RIPv2 broadcasts, multicasts, and unicasts.

To configure a RIP version:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Specify a global RIP version.

version { 1 | 2 }

By default, no global version is specified. An interface sends RIPv1 broadcasts, and can receive RIPv1 broadcasts and unicasts, and RIPv2 broadcasts, multicasts, and unicasts.

4.       Return to system view.

quit

N/A

5.       Enter interface view.

interface interface-type interface-number

N/A

6.       Specify a RIP version for the interface.

rip version { 1 | 2 [ broadcast | multicast ] }

By default, no interface-specific RIP version is specified. The interface sends RIPv1 broadcasts, and can receive RIPv1 broadcasts and unicasts, and RIPv2 broadcasts, multicasts, and unicasts.

 

Configuring RIP route control

Before you configure RIP route control, complete the following tasks:

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring routers.

·          Configure basic RIP.

Configuring an additional routing metric

An additional routing metric (hop count) can be added to the metric of an inbound or outbound RIP route.

An outbound additional metric is added to the metric of a sent route, and it does not change the route's metric in the routing table.

An inbound additional metric is added to the metric of a received route before the route is added into the routing table, and the route's metric is changed. If the sum of the additional metric and the original metric is greater than 16, the metric of the route is 16.

To configure additional routing metrics:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Specify an inbound additional routing metric.

rip metricin [ route-policy route-policy-name ] value

The default setting is 0.

4.       Specify an outbound additional routing metric.

rip metricout [ route-policy route-policy-name ] value

The default setting is 1.

 

Configuring RIPv2 route summarization

Perform this task to summarize contiguous subnets into a summary network and sends the network to neighbors. The smallest metric among all summarized routes is used as the metric of the summary route.

Enabling RIPv2 automatic route summarization

Automatic summarization enables RIPv2 to generate a natural network for contiguous subnets. For example, suppose there are three subnet routes 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24. Automatic summarization automatically creates and advertises a summary route 10.0.0.0/8 instead of the more specific routes.

To enable RIPv2 automatic route summarization:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       (Optional.) Enable RIPv2 automatic route summarization.

summary

By default, RIPv2 automatic route summarization is enabled.

If subnets in the routing table are not contiguous, disable automatic route summarization to advertise more specific routes.

 

Advertising a summary route

Perform this task to manually configure a summary route.

For example, suppose contiguous subnets routes 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24 exist in the routing table. You can create a summary route 10.1.0.0/16 on HundredGigE 1/0/1 to advertise the summary route instead of the more specific routes.

To configure a summary route:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Disable RIPv2 automatic route summarization.

undo summary

By default, RIPv2 automatic route summarization is enabled.

4.       Return to system view.

quit

N/A

5.       Enter interface view.

interface interface-type interface-number

N/A

6.       Configure a summary route.

rip summary-address ip-address { mask-length | mask }

By default, no summary route is configured.

 

Disabling host route reception

Perform this task to disable RIPv2 from receiving host routes from the same network to save network resources. This feature does not apply to RIPv1.

To disable RIP from receiving host routes:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Disable RIP from receiving host routes.

undo host-route

By default, RIP receives host routes.

 

Advertising a default route

You can advertise a default route on all RIP interfaces in RIP view or on a specific RIP interface in interface view. The interface view setting takes precedence over the RIP view settings.

To disable an interface from advertising a default route, use the rip default-route no-originate command on the interface.

To configure RIP to advertise a default route:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Enable RIP to advertise a default route.

default-route { only | originate } [ cost cost-value | route-policy route-policy-name ] *

By default, RIP does not advertise a default route.

4.       Return to system view.

quit

N/A

5.       Enter interface view.

interface interface-type interface-number

N/A

6.       Configure the RIP interface to advertise a default route.

rip default-route { { only | originate } [ cost cost-value | route-policy route-policy-name ] * | no-originate }

By default, a RIP interface can advertise a default route if the RIP process is enabled to advertise a default route.

 

 

NOTE:

The router enabled to advertise a default route does not accept default routes from RIP neighbors.

 

Configuring received/redistributed route filtering

Perform this task to filter received and redistributed routes by using a filtering policy.

To configure route filtering:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Configure the filtering of received routes.

filter-policy { ipv4-acl-number | gateway prefix-list-name | prefix-list prefix-list-name [ gateway prefix-list-name ] } import [ interface-type interface-number ]

By default, the filtering of received routes is not configured.

This command filters received routes. Filtered routes are not installed into the routing table or advertised to neighbors.

4.       Configure the filtering of redistributed routes.

filter-policy { ipv4-acl-number | prefix-list prefix-list-name } export [ protocol [ process-id ] | interface-type interface-number ]

By default, the filtering of redistributed routes is not configured.

This command filters redistributed routes, including routes redistributed with the import-route command.

 

Setting a preference for RIP

If multiple IGPs find routes to the same destination, the route found by the IGP that has the highest priority is selected as the optimal route. Perform this task to assign a preference to RIP. The smaller the preference value, the higher the priority.

To set a preference for RIP:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set a preference for RIP.

preference { preference | route-policy route-policy-name } *

The default setting is 100.

 

Configuring RIP route redistribution

Perform this task to configure RIP to redistribute routes from other routing protocols, including OSPF, IS-IS, BGP, static, and direct.

To configure RIP route redistribution:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Redistribute routes from another routing protocol.

import-route protocol [ as-number ] [ process-id | all-processes | allow-ibgp ] [ allow-direct | cost cost-value | route-policy route-policy-name | tag tag ] *

By default, RIP route redistribution is disabled.

This command can redistribute only active routes. To view active routes, use the display ip routing-table protocol command.

4.       (Optional.) Set a default cost for redistributed routes.

default cost cost-value

The default setting is 0.

 

Tuning and optimizing RIP networks

Configuration prerequisites

Before you tune and optimize RIP networks, complete the following tasks:

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring nodes.

·          Configure basic RIP.

Setting RIP timers

You can change the RIP network convergence speed by adjusting the following RIP timers:

·          Update timer—Specifies the interval between route updates.

·          Timeout timer—Specifies the route aging time. If no update for a route is received within the aging time, the metric of the route is set to 16.

·          Suppress timer—Specifies how long a RIP route stays in suppressed state. When the metric of a route is 16, the route enters the suppressed state. A suppressed route can be replaced by an updated route that is received from the same neighbor before the suppress timer expires and has a metric less than 16.

·          Garbage-collect timer—Specifies the interval from when the metric of a route becomes 16 to when it is deleted from the routing table. RIP advertises the route with a metric of 16. If no update is announced for that route before the garbage-collect timer expires, the route is deleted from the routing table.

 

IMPORTANT

IMPORTANT:

To avoid unnecessary traffic or route flapping, configure identical RIP timer settings on RIP routers.

 

To set RIP timers:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set RIP timers.

timers { garbage-collect garbage-collect-value | suppress suppress-value | timeout timeout-value | update update-value } *

By default:

·         The garbage-collect timer is 120 seconds.

·         The suppress timer is 120 seconds.

·         The timeout timer is 180 seconds.

·         The update timer is 30 seconds.

 

Enabling split horizon and poison reverse

The split horizon and poison reverse functions can prevent routing loops.

If both split horizon and poison reverse are configured, only the poison reverse function takes effect.

Enabling split horizon

Split horizon disables RIP from sending routes through the interface where the routes were learned to prevent routing loops between adjacent routers.

To enable split horizon:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Enable split horizon.

rip split-horizon

By default, split horizon is enabled.

 

Enabling poison reverse

Poison reverse allows RIP to send routes through the interface where the routes were learned. The metric of these routes is always set to 16 (unreachable) to avoid routing loops between neighbors.

To enable poison reverse:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Enable poison reverse.

rip poison-reverse

By default, poison reverse is disabled.

 

Setting the maximum number of RIP ECMP routes

Perform this task to implement load sharing over ECMP routes.

To set the maximum number of RIP ECMP routes:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set the maximum number of RIP ECMP routes.

maximum load-balancing number

By default, the maximum number of RIP ECMP routes equals the maximum number of ECMP routes supported by the system.

 

Enabling zero field check on incoming RIPv1 messages

Some fields in the RIPv1 message must be set to zero. These fields are called "zero fields." You can enable zero field check on incoming RIPv1 messages. If a zero field of a message contains a non-zero value, RIP does not process the message. If you are certain that all messages are trustworthy, disable zero field check to save CPU resources.

This feature does not apply to RIPv2 packets, because they have no zero fields.

To enable zero field check on incoming RIPv1 messages:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Enable zero field check on incoming RIPv1 messages.

checkzero

The default setting is enabled.

 

Enabling source IP address check on incoming RIP updates

Perform this task to enable source IP address check on incoming RIP updates.

Upon receiving a message on an Ethernet interface, RIP compares the source IP address of the message with the IP address of the interface. If they are not in the same network segment, RIP discards the message.

Upon receiving a message on a PPP interface, RIP checks whether the source address of the message is the IP address of the peer interface. If not, RIP discards the message.

To enable source IP address check on incoming RIP updates:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Enable source IP address check on incoming RIP messages.

validate-source-address

By default, this function is enabled.

 

Configuring RIPv2 message authentication

Perform this task to enable authentication on RIPv2 messages. This feature does not apply to RIPv1 because RIPv1 does not support authentication. Although you can specify an authentication mode for RIPv1 in interface view, the configuration does not take effect.

RIPv2 supports two authentication modes: simple authentication and MD5 authentication.

To configure RIPv2 message authentication:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Configure RIPv2 authentication.

rip authentication-mode { md5 { rfc2082 { cipher | plain } string key-id | rfc2453 { cipher | plain } string } | simple { cipher | plain } string }

By default, RIPv2 authentication is not configured.

 

Setting the RIP triggered update interval

Perform this task to avoid network overhead and reduce system resource consumption caused by frequent RIP triggered updates.

You can use the timer triggered command to set the maximum interval, minimum interval, and incremental interval for sending RIP triggered updates.

·          For a stable network, the minimum-interval is used.

·          If network changes become frequent, the incremental interval incremental-interval is used to extend the triggered update sending interval until the maximum-interval is reached.

To set the triggered update interval:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set the RIP triggered update interval.

timer triggered maximum-interval [ minimum-interval [ incremental-interval ] ]

By default:

·         The maximum interval is 5 seconds.

·         The minimum interval is 50 milliseconds.

·         The incremental interval is 200 milliseconds.

 

Specifying a RIP neighbor

Typically RIP messages are sent in broadcast or multicast. To enable RIP on a link that does not support broadcast or multicast, you must manually specify RIP neighbors.

Follow these guidelines when you specify a RIP neighbor:

·          Do not use the peer ip-address command when the neighbor is directly connected. Otherwise, the neighbor might receive both unicast and multicast (or broadcast) messages of the same routing information.

·          If the specified neighbor is not directly connected, disable source address check on incoming updates.

To specify a RIP neighbor:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Specify a RIP neighbor.

peer ip-address

By default, RIP does not unicast updates to any peer.

4.       Disable source IP address check on inbound RIP updates

undo validate-source-address

By default, source IP address check on inbound RIP updates is enabled.

 

Configuring RIP network management

You can use network management software to manage the RIP process to which MIB is bound.

To configure RIP network management:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Bind MIB to a RIP process.

rip mib-binding process-id

By default, MIB is bound to the RIP process with the smallest process ID.

 

Configuring the RIP packet sending rate

Perform this task to set the interval for sending RIP packets and the maximum number of RIP packets that can be sent at each interval. This feature can avoid excessive RIP packets from affecting system performance and consuming too much bandwidth.

To configure the RIP packet sending rate:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set the interval for sending RIP packets and the maximum number of RIP packets that can be sent at each interval.

output-delay time count count

By default, an interface sends up to three RIP packets every 20 milliseconds.

4.       Return to system view.

quit

N/A

5.       Enter interface view.

interface interface-type interface-number

N/A

6.       Set the interval for sending RIP packets and the maximum number of RIP packets that can be sent at each interval.

rip output-delay time count count

By default, the interface uses the RIP packet sending rate configured for the RIP process that the interface runs.

 

Setting the maximum length of RIP packets

CAUTION

CAUTION:

The supported maximum length of RIP packets varies by vendor. Use this feature with caution to avoid compatibility issues.

 

The packet length of RIP packets determines how many routes can be carried in a RIP packet. Set the maximum length of RIP packets to make good use of link bandwidth.

When authentication is enabled, follow these guidelines to ensure packet forwarding:

·          For simple authentication, the maximum length of RIP packets must be no less than 52 bytes.

·          For MD5 authentication (with packet format defined in RFC 2453), the maximum length of RIP packets must be no less than 56 bytes.

·          For MD5 authentication (with packet format defined in RFC 2082), the maximum length of RIP packets must be no less than 72 bytes.

To set the maximum length of RIP packets:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Set the maximum length of RIP packets.

rip max-packet-length value

By default, the maximum length of RIP packets is 512 bytes.

 

Setting the DSCP value for outgoing RIP packets

The DSCP value specifies the precedence of outgoing packets.

To set the DSCP value for outgoing RIP packets:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Set the DSCP value for outgoing RIP packets.

dscp dscp-value

By default, the DSCP value for outgoing RIP packets is 48.

 

Configuring RIP GR

GR ensures forwarding continuity when a routing protocol restarts or an active/standby switchover occurs.

Two routers are required to complete a GR process. The following are router roles in a GR process:

·          GR restarter—Graceful restarting router. It must have GR capability.

·          GR helper—A neighbor of the GR restarter. It helps the GR restarter to complete the GR process.

After RIP restarts on a router, the router must learn RIP routes again and update its FIB table, which causes network disconnections and route reconvergence.

With the GR feature, the restarting router (known as the GR restarter) can notify the event to its GR capable neighbors. GR capable neighbors (known as GR helpers) maintain their adjacencies with the router within a GR interval. During this process, the FIB table of the router does not change. After the restart, the router contacts its neighbors to retrieve its FIB.

By default, a RIP-enabled device acts as the GR helper. Perform this task on the GR restarter.

 

IMPORTANT

IMPORTANT:

You cannot enable RIP NSR on a device that acts as GR restarter.

 

To configure GR on the GR restarter:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Enable GR for RIP.

graceful-restart

By default, RIP GR is disabled.

4.       (Optional.) Set the GR interval.

graceful-restart interval interval

By default, the GR interval is 60 seconds.

 

Enabling RIP NSR

Nonstop Routing (NSR) allows the device to back up the routing information from the active RIP process to the standby RIP process. After an active/standby switchover, NSR can complete route regeneration without tearing down adjacencies or impacting forwarding services.

NSR does not require the cooperation of neighboring devices to recover routing information, and it is typically used more often than GR.

 

IMPORTANT

IMPORTANT:

A device that has RIP NSR enabled cannot act as GR restarter.

 

To enable RIP NSR:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Enable RIP NSR.

non-stop-routing

By default, RIP NSR is disabled.

RIP NSR enabled for a RIP process takes effect only on that process. As a best practice, enable RIP NSR for each process if multiple RIP processes exist.

 

Configuring BFD for RIP

RIP detects route failures by periodically sending requests. If it receives no response for a route within a certain time, RIP considers the route unreachable. To speed up convergence, perform this task to enable BFD for RIP. For more information about BFD, see High Availability Configuration Guide.

RIP supports the following BFD detection modes:

·          Single-hop echo detection—Detection mode for a direct neighbor. In this mode, a BFD session is established only when the directly connected neighbor has route information to send.

·          Single-hop echo detection for a specific destination—In this mode, a BFD session is established to the specified RIP neighbor when RIP is enabled on the local interface.

·          Bidirectional control detection—Detection mode for an indirect neighbor. In this mode, a BFD session is established only when both ends have routes to send and BFD is enabled on the receiving interface.

Configuring single-hop echo detection (for a directly connected RIP neighbor)

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the source IP address of BFD echo packets.

bfd echo-source-ip ip-address

By default, the source IP address of BFD echo packets is not configured.

3.       Enter interface view.

interface interface-type interface-number

N/A

4.       Enable BFD for RIP.

rip bfd enable

By default, BFD for RIP is disabled.

 

Configuring single-hop echo detection (for a specific destination)

When a unidirectional link occurs between the local device and a specific neighbor, BFD can detect the failure. The local device will not receive or send any RIP packets through the interface connected to the neighbor to improve convergence speed. When the link recovers, the interface can send RIP packets again.

This feature applies to RIP neighbors that are directly connected.

To configure BFD for RIP (single hop echo detection for a specific destination):

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the source IP address of BFD echo packets.

bfd echo-source-ip ip-address

By default, no source IP address is configured for BFD echo packets.

3.       Enter interface view.

interface interface-type interface-number

N/A

4.       Enable BFD for RIP.

rip bfd enable destination ip-address

By default, BFD for RIP is disabled.

 

Configuring bidirectional control detection

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Specify a RIP neighbor.

peer ip-address

By default, RIP does not unicast updates to any peer.

Because the undo peer command does not remove the neighbor relationship immediately, executing the command cannot bring down the BFD session immediately.

4.       Enter interface view.

interface interface-type interface-number

N/A

5.       Enable BFD on the RIP interface.

rip bfd enable

By default, BFD is disabled on a RIP interface.

 

Configuring RIP FRR

A link or router failure on a path can cause packet loss and even routing loop until RIP completes routing convergence based on the new network topology. FRR enables fast rerouting to minimize the impact of link or node failures.

Figure 6 Network diagram for RIP FRR

 

As shown in Figure 6, configure FRR on Router B by using a routing policy to specify a backup next hop. When the primary link fails, RIP directs packets to the backup next hop. At the same time, RIP calculates the shortest path based on the new network topology, and forwards packets over that path after network convergence.

Configuration restrictions and guidelines

·          RIP FRR takes effect only for RIP routes learned from directly connected neighbors.

·          RIP FRR is available only when the state of primary link (with Layer 3 interfaces staying up) changes from bidirectional to unidirectional or down.

·          Equal-cost routes do not support RIP FRR.

Configuration prerequisites

You must specify a next hop by using the apply fast-reroute backup-interface command in a routing policy and reference the routing policy for FRR. For more information about routing policy configuration, see "Configuring routing policies."

Configuring RIP FRR

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter RIP view.

rip [ process-id ] [ vpn-instance vpn-instance-name ]

N/A

3.       Configure RIP FRR.

fast-reroute route-policy route-policy-name

By default, RIP FRR is disabled.

 

Enabling BFD for RIP FRR

By default, RIP FRR does not use BFD to detect primary link failures. To speed up RIP convergence, enable BFD single-hop echo detection for RIP FRR to detect primary link failures.

To configure BFD for RIP FRR:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the source IP address of BFD echo packets.

bfd echo-source-ip ip-address

By default, the source IP address of BFD echo packets is not configured.

The source IP address cannot be on the same network segment as any local interface's IP address.

For more information about this command, see High Availability Command Reference.

3.       Enter interface view.

interface interface-type interface-number

N/A

4.       Enable BFD for RIP FRR.

rip primary-path-detect bfd echo

By default, BFD for RIP FRR is disabled.

 

Displaying and maintaining RIP

Execute display commands in any view and execute reset commands in user view.

 

Task

Command

Display RIP current status and configuration information.

display rip [ process-id ]

Display active routes in the RIP database.

display rip process-id database [ ip-address { mask-length | mask } ]

Display RIP GR information.

display rip [ process-id ] graceful-restart

Display RIP interface information.

display rip process-id interface [ interface-type interface-number ]

Display neighbor information for a RIP process.

display rip process-id neighbor [ interface-type interface-number ]

Display RIP NSR information.

display rip [ process-id ] non-stop-routing

Display routing information for a RIP process.

display rip process-id route [ ip-address { mask-length | mask } [ verbose ] | peer ip-address | statistics ]

Reset a RIP process.

reset rip process-id process

Clear the statistics for a RIP process.

reset rip process-id statistics

 

RIP configuration examples

Configuring basic RIP

Network requirements

As shown in Figure 7, enable RIPv2 on all interfaces on Switch A and Switch B. Configure Switch B to not advertise route 10.2.1.0/24 to Switch A, and to accept only route 2.1.1.0/24 from Switch A.

Figure 7 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP by using either of the following methods:

(Method 1) # Enable RIP on the specified networks on Switch A.

<SwitchA> system-view

[SwitchA] rip

[SwitchA-rip-1] network 1.0.0.0

[SwitchA-rip-1] network 2.0.0.0

[SwitchA-rip-1] network 3.0.0.0

[SwitchA-rip-1] quit

(Method 2) # Enable RIP on the specified interfaces on Switch B.

<SwitchB> system-view

[SwitchB] rip

[SwitchB-rip-1] quit

[SwitchB] interface vlan-interface 100

[SwitchB-Vlan-interface100] rip 1 enable

[SwitchB-Vlan-interface100] quit

[SwitchB] interface vlan-interface 101

[SwitchB-Vlan-interface101] rip 1 enable

[SwitchB-Vlan-interface101] quit

[SwitchB] interface vlan-interface 102

[SwitchB-Vlan-interface102] rip 1 enable

[SwitchB-Vlan-interface102] quit

# Display the RIP routing table of Switch A.

[SwitchA] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

----------------------------------------------------------------------------

 Peer 1.1.1.2 on Vlan-interface100

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      10.0.0.0/8              1.1.1.2           1       0       RAOF    11

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      1.1.1.0/24              0.0.0.0           0       0       RDOF    -

      2.1.1.0/24              0.0.0.0           0       0       RDOF    -

      3.1.1.0/24              0.0.0.0           0       0       RDOF    -

The output shows that RIPv1 uses a natural mask.

3.        Configure a RIP version:

# Configure RIPv2 on Switch A.

[SwitchA] rip

[SwitchA-rip-1] version 2

[SwitchA-rip-1] undo summary

[SwitchA-rip-1] quit

# Configure RIPv2 on Switch B.

[SwitchB] rip

[SwitchB-rip-1] version 2

[SwitchB-rip-1] undo summary

[SwitchB-rip-1] quit

# Display the RIP routing table on Switch A.

[SwitchA] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

----------------------------------------------------------------------------

 

 Peer 1.1.1.2 on Vlan-interface100

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      10.0.0.0/8              1.1.1.2           1       0       RAOF    50

      10.2.1.0/24             1.1.1.2           1       0       RAOF    16

      10.1.1.0/24             1.1.1.2           1       0       RAOF    16

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      1.1.1.0/24              0.0.0.0           0       0       RDOF    -

      2.1.1.0/24              0.0.0.0           0       0       RDOF    -

      3.1.1.0/24              0.0.0.0           0       0       RDOF    -

The output shows that RIPv2 uses classless subnet masks.

 

 

NOTE:

After RIPv2 is configured, RIPv1 routes might still exist in the routing table until they are aged out.

 

# Display the RIP routing table on Switch B.

[SwitchB] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

----------------------------------------------------------------------------

 Peer 1.1.1.1 on Vlan-interface100

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      2.1.1.0/24              192.168.1.3       1       0       RAOF    19

      3.1.1.0/24              192.168.1.3       1       0       RAOF    19

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      1.1.1.0/24              0.0.0.0           0       0       RDOF    -

      10.1.1.0/24             0.0.0.0           0       0       RDOF    -

      10.2.1.0/24             0.0.0.0           0       0       RDOF    -

4.        Configure route filtering:

# Reference IP prefix lists on Switch B to filter received and redistributed routes.

[SwitchB] ip prefix-list aaa index 10 permit 2.1.1.0 24

[SwitchB] ip prefix-list bbb index 10 permit 10.1.1.0 24

[SwitchB] ip prefix-list bbb index 11 permit 0.0.0.0 0 less-equal 32

[SwitchB] rip 1

[SwitchB-rip-1] filter-policy prefix-list aaa import

[SwitchB-rip-1] filter-policy prefix-list bbb export

[SwitchB-rip-1] quit

# Display the RIP routing table on Switch A.

[SwitchA] display rip 100 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

----------------------------------------------------------------------------

 Peer 1.1.1.2 on Vlan-interface100

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      10.1.1.0/24             1.1.1.2           1       0       RAOF    19

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      1.1.1.0/24              0.0.0.0           0       0       RDOF    -

      2.1.1.0/24              0.0.0.0           0       0       RDOF    -

      3.1.1.0/24              0.0.0.0           0       0       RDOF    -

# Display the RIP routing table on Switch B.

[SwitchB] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

----------------------------------------------------------------------------

 Peer 1.1.1.1 on Vlan-interface100

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      2.1.1.0/24              1.1.1.3           1       0       RAOF    19

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      1.1.1.0/24              0.0.0.0           0       0       RDOF    -

      10.1.1.0/24             0.0.0.0           0       0       RDOF    -

      10.2.1.0/24             0.0.0.0           0       0       RDOF    -

Configuring RIP route redistribution

Network requirements

As shown in Figure 8, Switch B communicates with Switch A through RIP 100 and with Switch C through RIP 200.

Configure RIP 200 to redistribute direct routes and routes from RIP 100 on Switch B so Switch C can learn routes destined for 10.2.1.0/24 and 11.1.1.0/24. Switch A cannot learn routes destined for 12.3.1.0/24 and 16.4.1.0/24.

Figure 8 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP:

# Enable RIP 100, and configure RIPv2 on Switch A.

<SwitchA> system-view

[SwitchA] rip 100

[SwitchA-rip-100] network 10.0.0.0

[SwitchA-rip-100] network 11.0.0.0

[SwitchA-rip-100] version 2

[SwitchA-rip-100] undo summary

[SwitchA-rip-100] quit

# Enable RIP 100 and RIP 200, and configure RIPv2 on Switch B.

<SwitchB> system-view

[SwitchB] rip 100

[SwitchB-rip-100] network 11.0.0.0

[SwitchB-rip-100] version 2

[SwitchB-rip-100] undo summary

[SwitchB-rip-100] quit

[SwitchB] rip 200

[SwitchB-rip-200] network 12.0.0.0

[SwitchB-rip-200] version 2

[SwitchB-rip-200] undo summary

[SwitchB-rip-200] quit

# Enable RIP 200, and configure RIPv2 on Switch C.

<SwitchC> system-view

[SwitchC] rip 200

[SwitchC-rip-200] network 12.0.0.0

[SwitchC-rip-200] network 16.0.0.0

[SwitchC-rip-200] version 2

[SwitchC-rip-200] undo summary

[SwitchC-rip-200] quit

# Display the IP routing table on Switch C.

[SwitchC] display ip routing-table

 

Destinations : 13        Routes : 13

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

12.3.1.0/24         Direct 0    0            12.3.1.2        Vlan200

12.3.1.0/32         Direct 0    0            12.3.1.2        Vlan200

12.3.1.2/32         Direct 0    0            127.0.0.1       InLoop0

12.3.1.255/32       Direct 0    0            12.3.1.2        Vlan200

16.4.1.0/24         Direct 0    0            16.4.1.1        Vlan400

16.4.1.0/32         Direct 0    0            16.4.1.1        Vlan400

16.4.1.1/32         Direct 0    0            127.0.0.1       InLoop0

16.4.1.255/32       Direct 0    0            16.4.1.1        Vlan400

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

3.        Configure route redistribution:

# Configure RIP 200 to redistribute routes from RIP 100 and direct routes on Switch B.

[SwitchB] rip 200

[SwitchB-rip-200] import-route rip 100

[SwitchB-rip-200] import-route direct

[SwitchB-rip-200] quit

# Display the IP routing table on Switch C.

[SwitchC] display ip routing-table

 

Destinations : 15        Routes : 15

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

10.2.1.0/24         RIP    100  1            12.3.1.1        Vlan200

11.1.1.0/24         RIP    100  1            12.3.1.1        Vlan200

12.3.1.0/24         Direct 0    0            12.3.1.2        Vlan200

12.3.1.0/32         Direct 0    0            12.3.1.2        Vlan200

12.3.1.2/32         Direct 0    0            127.0.0.1       InLoop0

12.3.1.255/32       Direct 0    0            12.3.1.2        Vlan200

16.4.1.0/24         Direct 0    0            16.4.1.1        Vlan400

16.4.1.0/32         Direct 0    0            16.4.1.1        Vlan400

16.4.1.1/32         Direct 0    0            127.0.0.1       InLoop0

16.4.1.255/32       Direct 0    0            16.4.1.1        Vlan400

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

Configuring an additional metric for a RIP interface

Network requirements

As shown in Figure 9, run RIPv2 on all the interfaces of Switch A, Switch B, Switch C, Switch D, and Switch E.

Switch A has two links to Switch D. The link from Switch B to Switch D is more stable than that from Switch C to Switch D. Configure an additional metric for RIP routes received from VLAN-interface 200 on Switch A so Switch A prefers route 1.1.5.0/24 learned from Switch B.

Figure 9 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] rip 1

[SwitchA-rip-1] network 1.0.0.0

[SwitchA-rip-1] version 2

[SwitchA-rip-1] undo summary

[SwitchA-rip-1] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] rip 1

[SwitchB-rip-1] network 1.0.0.0

[SwitchB-rip-1] version 2

[SwitchB-rip-1] undo summary

# Configure Switch C.

<SwitchC> system-view

[SwitchB] rip 1

[SwitchC-rip-1] network 1.0.0.0

[SwitchC-rip-1] version 2

[SwitchC-rip-1] undo summary

# Configure Switch D.

<SwitchD> system-view

[SwitchD] rip 1

[SwitchD-rip-1] network 1.0.0.0

[SwitchD-rip-1] version 2

[SwitchD-rip-1] undo summary

# Configure Switch E.

<SwitchE> system-view

[SwitchE] rip 1

[SwitchE-rip-1] network 1.0.0.0

[SwitchE-rip-1] version 2

[SwitchE-rip-1] undo summary

# Display all active routes in the RIP database on Switch A.

[SwitchA] display rip 1 database

   1.0.0.0/8, auto-summary

       1.1.1.0/24, cost 0, nexthop 1.1.1.1, RIP-interface

       1.1.2.0/24, cost 0, nexthop 1.1.2.1, RIP-interface

       1.1.3.0/24, cost 1, nexthop 1.1.1.2

       1.1.4.0/24, cost 1, nexthop 1.1.2.2

       1.1.5.0/24, cost 2, nexthop 1.1.1.2

       1.1.5.0/24, cost 2, nexthop 1.1.2.2

The output shows two RIP routes destined for network 1.1.5.0/24, with the next hops as Switch B (1.1.1.2) and Switch C (1.1.2.2), and with the same cost of 2.

3.        Configure an additional metric for a RIP interface:

# Configure an inbound additional metric of 3 for RIP-enabled interface VLAN-interface 200 on Switch A.

[SwitchA] interface vlan-interface 200

[SwitchA-Vlan-interface200] rip metricin 3

# Display all active routes in the RIP database on Switch A.

[SwitchA-Vlan-interface200] display rip 1 database

   1.0.0.0/8, auto-summary

       1.1.1.0/24, cost 0, nexthop 1.1.1.1, RIP-interface

       1.1.2.0/24, cost 0, nexthop 1.1.2.1, RIP-interface

       1.1.3.0/24, cost 1, nexthop 1.1.1.2

       1.1.4.0/24, cost 2, nexthop 1.1.1.2

       1.1.5.0/24, cost 2, nexthop 1.1.1.2

The output shows that only one RIP route reaches network 1.1.5.0/24, with the next hop as Switch B (1.1.1.2) and a cost of 2.

Configuring RIP to advertise a summary route

Network requirements

As shown in Figure 10, Switch A and Switch B run OSPF, Switch D runs RIP, and Switch C runs OSPF and RIP. Configure RIP to redistribute OSPF routes on Switch C so Switch D can learn routes destined for networks 10.1.1.0/24, 10.2.1.0/24, 10.5.1.0/24, and 10.6.1.0/24.

To reduce the routing table size of Switch D, configure route summarization on Switch C to advertise only the summary route 10.0.0.0/8 to Switch D.

Figure 10 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic OSPF:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] ospf

[SwitchA-ospf-1] area 0

[SwitchA-ospf-1-area-0.0.0.0] network 10.5.1.0 0.0.0.255

[SwitchA-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255

[SwitchA-ospf-1-area-0.0.0.0] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] ospf

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] network 10.6.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] ospf

[SwitchC-ospf-1] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

3.        Configure basic RIP:

# Configure Switch C.

[SwitchC] rip 1

[SwitchC-rip-1] network 11.3.1.0

[SwitchC-rip-1] version 2

[SwitchC-rip-1] undo summary

# Configure Switch D.

<SwitchD> system-view

[SwitchD] rip 1

[SwitchD-rip-1] network 11.0.0.0

[SwitchD-rip-1] version 2

[SwitchD-rip-1] undo summary

[SwitchD-rip-1] quit

# Configure RIP to redistribute routes from OSPF process 1 and direct routes on Switch C.

[SwitchC-rip-1] import-route direct

[SwitchC-rip-1] import-route ospf 1

[SwitchC-rip-1] quit

# Display the IP routing table on Switch D.

[SwitchD] display ip routing-table

 

Destinations : 15        Routes : 15

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

10.1.1.0/24         RIP    100  1            11.3.1.1        Vlan300

10.2.1.0/24         RIP    100  1            11.3.1.1        Vlan300

10.5.1.0/24         RIP    100  1            11.3.1.1        Vlan300

10.6.1.0/24         RIP    100  1            11.3.1.1        Vlan300

11.3.1.0/24         Direct 0    0            11.3.1.2        Vlan300

11.3.1.0/32         Direct 0    0            11.3.1.2        Vlan300

11.3.1.2/32         Direct 0    0            127.0.0.1       InLoop0

11.4.1.0/24         Direct 0    0            11.4.1.2        Vlan400

11.4.1.0/32         Direct 0    0            11.4.1.2        Vlan400

11.4.1.2/32         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

4.        Configure route summarization:

# Configure route summarization on Switch C and advertise only the summary route 10.0.0.0/8.

[SwitchC] interface vlan-interface 300

[SwitchC-Vlan-interface300] rip summary-address 10.0.0.0 8

# Display the IP routing table on Switch D.

[SwitchD] display ip routing-table

 

Destinations : 12        Routes : 12

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

10.0.0.0/8          RIP    100  1            11.3.1.1        Vlan300

11.3.1.0/24         Direct 0    0            11.3.1.2        Vlan300

11.3.1.0/32         Direct 0    0            11.3.1.2        Vlan300

11.3.1.2/32         Direct 0    0            127.0.0.1       InLoop0

11.4.1.0/24         Direct 0    0            11.4.1.2        Vlan400

11.4.1.0/32         Direct 0    0            11.4.1.2        Vlan400

11.4.1.2/32         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

Configuring RIP GR

Network requirements

As shown in Figure 11, Switch A, Switch B, and Switch C all run RIPv2.

·          Enable GR on Switch A. Switch A acts as the GR restarter.

·          Switch B and Switch C act as GR helpers to synchronize their routing tables with Switch A by using GR.

Figure 11 Network diagram

 

Configuration procedure

1.        Configure IP addresses and subnet masks for interfaces on the switches. (Details not shown.)

2.        Configure RIPv2 on the switches to ensure the following: (Details not shown.)

?  Switch A, Switch B, and Switch C can communicate with each other at Layer 3.

?  Dynamic route update can be implemented among them with RIPv2.

3.        Enable RIP GR on Switch A.

<SwitchA> system-view

[SwitchA] rip

[SwitchA-rip-1] graceful-restart

Verifying the configuration

# Restart RIP process 1 on Switch A.

[SwitchA-rip-1] return

<SwitchA> reset rip 1 process

Reset RIP process? [Y/N]:y

# Display GR status on Switch A.

<SwitchA> display rip graceful-restart

 RIP process: 1

 Graceful Restart capability     : Enabled

 Current GR state                : Normal

 Graceful Restart period         : 60  seconds

 Graceful Restart remaining time : 0   seconds

Configuring RIP NSR

Network requirements

As shown in Figure 12, Switch A, Switch B, and Switch S all run RIPv2.

Enable RIP NSR on Switch S to ensure correct routing when an active/standby switchover occurs on Switch S.

Figure 12 Network diagram

 

Configuration procedure

1.        Configure IP addresses and subnet masks for interfaces on the switches. (Details not shown.)

2.        Configure RIPv2 on the switches to ensure the following: (Details not shown.)

?  Switch A, Switch B, and Switch S can communicate with each other at Layer 3.

?  Dynamic route update can be implemented among them with RIPv2.

3.        Enable RIP NSR on Switch S.

<SwitchS> system-view

[SwitchS] rip 100

[SwitchS-rip-100] non-stop-routing

[SwitchS-rip-100] quit

Verifying the configuration

# Perform an active/standby switchover on Switch S.

[SwitchS] placement reoptimize

Predicted changes to the placement

Program                           Current location       New location

---------------------------------------------------------------------

lb                                0/0                    0/0

lsm                               0/0                    0/0

slsp                              0/0                    0/0

rib6                              0/0                    0/0

routepolicy                       0/0                    0/0

rib                               0/0                    0/0

staticroute6                      0/0                    0/0

staticroute                       0/0                    0/0

ospf                              0/0                    1/0

Continue? [y/n]:y

Re-optimization of the placement start. You will be notified on completion

Re-optimization of the placement complete. Use 'display placement' to view the new placement

# Display neighbor information and route information on Switch A.

[SwitchA] display rip 1 neighbor

 Neighbor Address: 12.12.12.2

     Interface  : Vlan-interface200

     Version    : RIPv2     Last update: 00h00m13s

     Relay nbr  : No        BFD session: None

     Bad packets: 0         Bad routes : 0

[SwitchA] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

 ----------------------------------------------------------------------------

 Peer 12.12.12.2 on Vlan-interface200

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      14.0.0.0/8              12.12.12.2        1       0       RAOF    16

      44.0.0.0/8              12.12.12.2        2       0       RAOF    16

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      12.12.12.0/24           0.0.0.0           0       0       RDOF    -

      22.22.22.22/32          0.0.0.0           0       0       RDOF    -

# Display neighbor information and route information on Switch B.

[SwitchB] display rip 1 neighbor

 Neighbor Address: 14.14.14.2

     Interface  : Vlan-interface200

     Version    : RIPv2     Last update: 00h00m32s

     Relay nbr  : No        BFD session: None

     Bad packets: 0         Bad routes : 0

[SwitchB] display rip 1 route

 Route Flags: R - RIP, T - TRIP

              P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect

              D - Direct, O - Optimal, F - Flush to RIB

 ----------------------------------------------------------------------------

 Peer 14.14.14.2 on Vlan-interface200

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      12.0.0.0/8              14.14.14.2        1       0       RAOF    1

      22.0.0.0/8              14.14.14.2        2       0       RAOF    1

 Local route

      Destination/Mask        Nexthop           Cost    Tag     Flags   Sec

      44.44.44.44/32          0.0.0.0           0       0       RDOF    -

      14.14.14.0/24           0.0.0.0           0       0       RDOF    -

The output shows that the neighbor and route information on Switch A and Switch B keep unchanged during the active/standby switchover on Switch S. The traffic from Switch A to Switch B has not been impacted.

Configuring BFD for RIP (single-hop echo detection for a directly connected neighbor)

Network requirements

As shown in Figure 13, VLAN-interface 100 of Switch A and Switch C runs RIP process 1. VLAN-interface 200 of Switch A runs RIP process 2. VLAN-interface 300 of Switch C and VLAN-interface 200 and VLAN-interface 300 of Switch B run RIP process 1.

·          Configure a static route destined for 100.1.1.1/24 and enable static route redistribution into RIP on Switch C. This allows Switch A to learn two routes destined for 100.1.1.1/24 through VLAN-interface 100 and VLAN-interface 200 respectively, and uses the one through VLAN-interface 100.

·          Enable BFD for RIP on VLAN-interface 100 of Switch A. When the link over VLAN-interface 100 fails, BFD can quickly detect the failure and notify RIP. RIP deletes the neighbor relationship and route information learned on VLAN-interface 100, and uses the route destined for 100.1.1.1 24 through VLAN-interface 200.

Figure 13 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] rip 1

[SwitchA-rip-1] version 2

[SwitchA-rip-1] undo summary

[SwitchA-rip-1] network 192.168.1.0

[SwitchA-rip-1] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] rip bfd enable

[SwitchA-Vlan-interface100] quit

[SwitchA] rip 2

[SwitchA-rip-2] version 2

[SwitchA-rip-2] undo summary

[SwitchA-rip-2] network 192.168.2.0

[SwitchA-rip-2] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] rip 1

[SwitchB-rip-1] version 2

[SwitchB-rip-1] undo summary

[SwitchB-rip-1] network 192.168.2.0

[SwitchB-rip-1] network 192.168.3.0

[SwitchB-rip-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] rip 1

[SwitchC-rip-1] version 2

[SwitchC-rip-1] undo summary

[SwitchC-rip-1] network 192.168.1.0

[SwitchC-rip-1] network 192.168.3.0

[SwitchC-rip-1] import-route static

[SwitchC-rip-1] quit

3.        Configure BFD parameters on VLAN-interface 100 of Switch A.

[SwitchA] bfd echo-source-ip 11.11.11.11

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] bfd min-transmit-interval 500

[SwitchA-Vlan-interface100] bfd min-receive-interval 500

[SwitchA-Vlan-interface100] bfd detect-multiplier 7

[SwitchA-Vlan-interface100] quit

[SwitchA] quit

4.        Configure a static route on Switch C.

[SwitchC] ip route-static 120.1.1.1 24 null 0

Verifying the configuration

# Display the BFD session information on Switch A.

<SwitchA> display bfd session

 

 Total Session Num: 1     Up Session Num: 1     Init Mode: Active

 

 IPv4 Session Working Under Echo Mode:

 

 LD          SourceAddr      DestAddr        State    Holdtime    Interface

 4            192.168.1.1     192.168.1.2     Up       2000ms      Vlan100

# Display RIP routes destined for 120.1.1.0/24 on Switch A.

<SwitchA> display ip routing-table 120.1.1.0 24

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

120.1.1.0/24       RIP     100 1           192.168.1.2     Vlan-interface100

The output shows that Switch A communicates with Switch C through VLAN-interface 100. Then the link over VLAN-interface 100 fails.

# Display RIP routes destined for 120.1.1.0/24 on Switch A.

<SwitchA> display ip routing-table 120.1.1.0 24

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

120.1.1.0/24       RIP     100 1           192.168.2.2     Vlan-interface200

The output shows that Switch A communicates with Switch C through VLAN-interface 200.

Configuring BFD for RIP (single hop echo detection for a specific destination)

Network requirements

As shown in Figure 14, VLAN-interface 100 of Switch A and Switch B runs RIP process 1. VLAN-interface 200 of Switch B and Switch C runs RIP process 1.

·          Configure a static route destined for 100.1.1.0/24 and enable static route redistribution into RIP on both Switch A and Switch C. This allows Switch B to learn two routes destined for 100.1.1.0/24 through VLAN-interface 100 and VLAN-interface 200. The route redistributed from Switch A has a smaller cost than that redistributed from Switch C, so Switch B uses the route through VLAN-interface 200.

·          Enable BFD for RIP on VLAN-interface 100 of Switch A, and specify VLAN-interface 100 of Switch B as the destination. When a unidirectional link occurs between Switch A and Switch B, BFD can quickly detect the link failure and notify RIP. Switch B then deletes the neighbor relationship and the route information learned on VLAN-interface 100. It does not receive or send any packets from VLAN-interface 100. When the route learned from Switch A ages out, Switch B uses the route destined for 100.1.1.1 24 through VLAN-interface 200.

Figure 14 Network diagram

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP and enable BFD on the interfaces:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] rip 1

[SwitchA-rip-1] network 192.168.2.0

[SwitchA-rip-1] import-route static

[SwitchA-rip-1] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] rip bfd enable destination 192.168.2.2

[SwitchA-Vlan-interface100] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] rip 1

[SwitchB-rip-1] network 192.168.2.0

[SwitchB-rip-1] network 192.168.3.0

[SwitchB-rip-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] rip 1

[SwitchC-rip-1] network 192.168.3.0

[SwitchC-rip-1] import-route static cost 3

[SwitchC-rip-1] quit

3.        Configure BFD parameters on VLAN-interface 100 of Switch A.

[SwitchA] bfd echo-source-ip 11.11.11.11

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] bfd min-echo-receive-interval 500

[SwitchA-Vlan-interface100] return

4.        Configure static routes:

# Configure a static route on Switch A.

[SwitchA] ip route-static 100.1.1.0 24 null 0

# Configure a static route on Switch C.

[SwitchA] ip route-static 100.1.1.0 24 null 0

Verifying the configuration

# Display BFD session information on Switch A.

<SwitchA> display bfd session

 

 Total Session Num: 1     Up Session Num: 1     Init Mode: Active

 

 IPv4 session working under Echo mode:

 

 LD             SourceAddr      DestAddr        State    Holdtime    Interface

 3              192.168.2.1     192.168.2.2     Up       2000ms      vlan100

# Display routes destined for 100.1.1.0/24 on Switch B.

<SwitchB> display ip routing-table 100.1.1.0 24 verbose

 

Summary Count : 1

 

Destination: 100.1.1.0/24

   Protocol: RIP            

 Process ID: 1

  SubProtID: 0x1                     Age: 00h02m47s

       Cost: 1                Preference: 100

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x12000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 192.168.2.1

      Flags: 0x1008c         OrigNextHop: 192.168.2.1

      Label: NULL            RealNextHop: 192.168.2.1

    BkLabel: NULL              BkNextHop: N/A

  Tunnel ID: Invalid           Interface: vlan-interface 100

BkTunnel ID: Invalid         BkInterface: N/A

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A

# Display routes destined for 100.1.1.0/24 on Switch B when the link between Switch A and Switch B fails.

<SwitchB> display ip routing-table 100.1.1.0 24 verbose

 

Summary Count : 1

 

Destination: 100.1.1.0/24

   Protocol: RIP            

 Process ID: 1

  SubProtID: 0x1                     Age: 00h21m23s

       Cost: 4                Preference: 100

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x12000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 192.168.3.2

      Flags: 0x1008c         OrigNextHop: 192.168.3.2

      Label: NULL            RealNextHop: 192.168.3.2

    BkLabel: NULL              BkNextHop: N/A

  Tunnel ID: Invalid           Interface: vlan-interface 200

BkTunnel ID: Invalid         BkInterface: N/A

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A

Configuring BFD for RIP (bidirectional detection in BFD control packet mode)

Network requirements

As shown in Figure 15, VLAN-interface 100 of Switch A and VLAN-interface 200 of Switch C run RIP process 1.

VLAN-interface 300 of Switch A runs RIP process 2. VLAN-interface 400 of Switch C, and VLAN-interface 300 and VLAN-interface 400 of Switch D run RIP process 1.

·          Configure a static route destined for 100.1.1.0/24 on Switch A.

·          Configure a static route destined for 101.1.1.0/24 on Switch C.

·          Enable static route redistribution into RIP on Switch A and Switch C. This allows Switch A to learn two routes destined for 100.1.1.0/24 through VLAN-interface 100 and VLAN-interface 300. It uses the route through VLAN-interface 100.

·          Enable BFD on VLAN-interface 100 of Switch A and VLAN-interface 200 of Switch C.

When the link over VLAN-interface 100 fails, BFD can quickly detect the link failure and notify RIP. RIP deletes the neighbor relationship and the route information received learned on VLAN-interface 100. It uses the route destined for 100.1.1.0/24 through VLAN-interface 300.

Figure 15 Network diagram

 

Table 7 Interface and IP address assignment

Device

Interface

IP address

Switch A

VLAN-interface 300

192.168.3.1/24

Switch A

VLAN-interface 100

192.168.1.1/24

Switch B

VLAN-interface 100

192.168.1.2/24

Switch B

VLAN-interface 200

192.168.2.1/24

Switch C

VLAN-interface 200

192.168.2.2/24

Switch C

VLAN-interface 400

192.168.4.2/24

Switch D

VLAN-interface 300

192.168.3.2/24

Switch D

VLAN-interface 400

192.168.4.1/24

 

Configuration procedure

1.        Configure IP addresses for interfaces. (Details not shown.)

2.        Configure basic RIP and enable static route redistribution into RIP so Switch A and Switch C have routes to send to each other:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] rip 1

[SwitchA-rip-1] version 2

[SwitchA-rip-1] undo summary

[SwitchA-rip-1] network 192.168.1.0

[SwitchA-rip-1] network 101.1.1.0

[SwitchA-rip-1] peer 192.168.2.2

[SwitchA-rip-1] undo validate-source-address

[SwitchA-rip-1] import-route static

[SwitchA-rip-1] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] rip bfd enable

[SwitchA-Vlan-interface100] quit

[SwitchA] rip 2

[SwitchA-rip-2] version 2

[SwitchA-rip-2] undo summary

[SwitchA-rip-2] network 192.168.3.0

[SwitchA-rip-2] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] rip 1

[SwitchC-rip-1] version 2

[SwitchC-rip-1] undo summary

[SwitchC-rip-1] network 192.168.2.0

[SwitchC-rip-1] network 192.168.4.0

[SwitchC-rip-1] network 100.1.1.0

[SwitchC-rip-1] peer 192.168.1.1

[SwitchC-rip-1] undo validate-source-address

[SwitchC-rip-1] import-route static

[SwitchC-rip-1] quit

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] rip bfd enable

[SwitchC-Vlan-interface200] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] rip 1

[SwitchD-rip-1] version 2

[SwitchD-rip-1] undo summary

[SwitchD-rip-1] network 192.168.3.0

[SwitchD-rip-1] network 192.168.4.0

3.        Configure BFD parameters:

# Configure Switch A.

[SwitchA] bfd session init-mode active

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] bfd min-transmit-interval 500

[SwitchA-Vlan-interface100] bfd min-receive-interval 500

[SwitchA-Vlan-interface100] bfd detect-multiplier 7

[SwitchA-Vlan-interface100] quit

# Configure Switch C.

[SwitchC] bfd session init-mode active

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] bfd min-transmit-interval 500

[SwitchC-Vlan-interface200] bfd min-receive-interval 500

[SwitchC-Vlan-interface200] bfd detect-multiplier 7

[SwitchC-Vlan-interface200] quit

4.        Configure static routes:

# Configure a static route to Switch C on Switch A.

[SwitchA] ip route-static 192.168.2.0 24 vlan-interface 100 192.168.1.2

[SwitchA] quit

# Configure a static route to Switch A on Switch C.

[SwitchC] ip route-static 192.168.1.0 24 vlan-interface 200 192.168.2.1

Verifying the configuration

# Display the BFD session information on Switch A.

<SwitchA> display bfd session

 

 Total Session Num: 1     Up Session Num: 1     Init Mode: Active

 

 IPv4 session working under Ctrl mode:

 

 LD/RD             SourceAddr      DestAddr        State    Holdtime    Interface

 513/513           192.168.1.1     192.168.2.2     Up       1700ms      vlan100

# Display RIP routes destined for 100.1.1.0/24 on Switch A.

<SwitchA> display ip routing-table 100.1.1.0 24

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

100.1.1.0/24       RIP     100 1           192.168.2.2     vlan-interface 100

The output shows that Switch A communicates with Switch C through VLAN-interface 100. Then the link over VLAN-interface 100 fails.

# Display RIP routes destined for 100.1.1.0/24 on Switch A.

<SwitchA> display ip routing-table 100.1.1.0 24

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

100.1.1.0/24       RIP     100 2           192.168.3.2     vlan-interface 300

The output shows that Switch A communicates with Switch C through VLAN-interface 300.

Configuring RIP FRR

Network requirements

As shown in Figure 16, Switch A, Switch B, and Switch C run RIPv2. Configure RIP FRR so that when Link A becomes unidirectional, services can be switched to Link B immediately.

Figure 16 Network diagram

 

Table 8 Interface and IP address assignment

Device

Interface

IP address

Switch A

VLAN-interface 100

12.12.12.1/24

Switch A

VLAN-interface 200

13.13.13.1/24

Switch A

Loopback 0

1.1.1.1/32

Switch B

VLAN-interface 101

24.24.24.4/24

Switch B

VLAN-interface 200

13.13.13.2/24

Switch B

Loopback 0

4.4.4.4/32

Switch C

VLAN-interface 100

12.12.12.2/24

Switch C

VLAN-interface 101

24.24.24.2/24

 

Configuration procedure

1.        Configure IP addresses and subnet masks for interfaces on the switches. (Details not shown.)

2.        Configure RIPv2 on the switches to make sure Switch A, Switch B, and Switch C can communicate with each other at Layer 3. (Details not shown.)

3.        Configure RIP FRR:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] ip prefix-list abc index 10 permit 4.4.4.4 32

[SwitchA] route-policy frr permit node 10

[SwitchA-route-policy-frr-10] if-match ip address prefix-list abc

[SwitchA-route-policy-frr-10] apply fast-reroute backup-interface vlan-interface 100 backup-nexthop 12.12.12.2

[SwitchA-route-policy-frr-10] quit

[SwitchA] rip 1

[SwitchA-rip-1] fast-reroute route-policy frr

[SwitchA-rip-1] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] ip prefix-list abc index 10 permit 1.1.1.1 32

[SwitchB] route-policy frr permit node 10

[SwitchB-route-policy-frr-10] if-match ip address prefix-list abc

[SwitchB-route-policy-frr-10] apply fast-reroute backup-interface vlan-interface 101 backup-nexthop 24.24.24.2

[SwitchB-route-policy-frr-10] quit

[SwitchB] rip 1

[SwitchB-rip-1] fast-reroute route-policy frr

[SwitchB-rip-1] quit

Verifying the configuration

# Display route 4.4.4.4/32 on Switch A to view the backup next hop information.

[SwitchA] display ip routing-table 4.4.4.4 verbose

 

Summary Count : 1

 

Destination: 4.4.4.4/32

   Protocol: RIP            

 Process ID: 1

  SubProtID: 0x1                     Age: 04h20m37s

       Cost: 1                Preference: 100

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x26000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 13.13.13.2

      Flags: 0x1008c         OrigNextHop: 13.13.13.2

      Label: NULL            RealNextHop: 13.13.13.2

    BkLabel: NULL              BkNextHop: 12.12.12.2

  Tunnel ID: Invalid           Interface: Vlan-interface200

BkTunnel ID: Invalid         BkInterface: Vlan-interface100

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A

# Display route 1.1.1.1/32 on Switch B to view the backup next hop information.

[SwitchB] display ip routing-table 1.1.1.1 verbose

 

Summary Count : 1

 

Destination: 1.1.1.1/32

   Protocol: RIP            

 Process ID: 1

  SubProtID: 0x1                     Age: 04h20m37s

       Cost: 1                Preference: 100

      IpPre: N/A              QosLocalID: N/A

        Tag: 0                     State: Active Adv

  OrigTblID: 0x0                 OrigVrf: default-vrf

    TableID: 0x2                  OrigAs: 0

      NibID: 0x26000002           LastAs: 0

     AttrID: 0xffffffff         Neighbor: 13.13.13.1

      Flags: 0x1008c         OrigNextHop: 13.13.13.1

      Label: NULL            RealNextHop: 13.13.13.1

    BkLabel: NULL              BkNextHop: 24.24.24.2

  Tunnel ID: Invalid           Interface: Vlan-interface200

BkTunnel ID: Invalid         BkInterface: Vlan-interface101

   FtnIndex: 0x0            TrafficIndex: N/A

  Connector: N/A

 


Configuring OSPF

Overview

Open Shortest Path First (OSPF) is a link-state IGP developed by the OSPF working group of the IETF. OSPF version 2 is used for IPv4. OSPF refers to OSPFv2 throughout this chapter.

OSPF has the following features:

·          Wide scope—Supports multiple network sizes and several hundred routers in an OSPF routing domain.

·          Fast convergence—Advertises routing updates instantly upon network topology changes.

·          Loop free—Computes routes with the SPF algorithm to avoid routing loops.

·          Area-based network partition—Splits an AS into multiple areas to facilitate management. This feature reduces the LSDB size on routers to save memory and CPU resources, and reduces route updates transmitted between areas to save bandwidth.

·          ECMP routing—Supports multiple equal-cost routes to a destination.

·          Routing hierarchy—Supports a 4-level routing hierarchy that prioritizes routes into intra-area, inter-area, external Type-1, and external Type-2 routes.

·          Authentication—Supports area- and interface-based packet authentication to ensure secure packet exchange.

·          Support for multicasting—Multicasts protocol packets on some types of links to avoid impacting other devices.

OSPF packets

OSPF messages are carried directly over IP. The protocol number is 89.

OSPF uses the following packet types:

·          Hello—Periodically sent to find and maintain neighbors, containing timer values, information about the DR, BDR, and known neighbors.

·          Database description (DD)—Describes the digest of each LSA in the LSDB, exchanged between two routers for data synchronization.

·          Link state request (LSR)—Requests needed LSAs from a neighbor. After exchanging the DD packets, the two routers know which LSAs of the neighbor are missing from their LSDBs. They then exchange LSR packets requesting the missing LSAs. LSR packets contain the digest of the missing LSAs.

·          Link state update (LSU)—Transmits the requested LSAs to the neighbor.

·          Link state acknowledgment (LSAck)—Acknowledges received LSU packets. It contains the headers of received LSAs (an LSAck packet can acknowledge multiple LSAs).

LSA types

OSPF advertises routing information in Link State Advertisements (LSAs). The following LSAs are commonly used:

·          Router LSA—Type-1 LSA, originated by all routers and flooded throughout a single area only. This LSA describes the collected states of the router's interfaces to an area.

·          Network LSA—Type-2 LSA, originated for broadcast and NBMA networks by the designated router, and flooded throughout a single area only. This LSA contains the list of routers connected to the network.

·          Network Summary LSA—Type-3 LSA, originated by Area Border Routers (ABRs), and flooded throughout the LSA's associated area. Each summary-LSA describes a route to a destination outside the area, yet still inside the AS (an inter-area route).

·          ASBR Summary LSA—Type-4 LSA, originated by ABRs and flooded throughout the LSA's associated area. Type 4 summary-LSAs describe routes to Autonomous System Boundary Router (ASBR).

·          AS External LSA—Type-5 LSA, originated by ASBRs, and flooded throughout the AS (except stub and NSSA areas). Each AS-external-LSA describes a route to another AS.

·          NSSA LSA—Type-7 LSA, as defined in RFC 1587, originated by ASBRs in NSSAs and flooded throughout a single NSSA. NSSA LSAs describe routes to other ASs.

·          Opaque LSA—A proposed type of LSA. Its format consists of a standard LSA header and application specific information. Opaque LSAs are used by the OSPF protocol or by some applications to distribute information into the OSPF routing domain. The opaque LSA includes Type 9, Type 10, and Type 11. The Type 9 opaque LSA is flooded into the local subnet, the Type 10 is flooded into the local area, and the Type 11 is flooded throughout the AS.

OSPF areas

In large OSPF routing domains, SPF route computations consume too many storage and CPU resources, and enormous OSPF packets generated for route synchronization occupy excessive bandwidth.

To resolve these issues, OSPF splits an AS into multiple areas. Each area is identified by an area ID. The boundaries between areas are routers rather than links. A network segment (or a link) can only reside in one area as shown in Figure 17.

You can configure route summarization on ABRs to reduce the number of LSAs advertised to other areas and minimize the effect of topology changes.

Figure 17 Area-based OSPF network partition

 

Backbone area and virtual links

Each AS has a backbone area that distributes routing information between non-backbone areas. Routing information between non-backbone areas must be forwarded by the backbone area. OSPF has the following requirements:

·          All non-backbone areas must maintain connectivity to the backbone area.

·          The backbone area must maintain connectivity within itself.

In practice, these requirements might not be met due to lack of physical links. OSPF virtual links can solve this issue.

A virtual link is established between two ABRs through a non-backbone area. It must be configured on both ABRs to take effect. The non-backbone area is called a transit area.

As shown in Figure 18, Area 2 has no direct physical link to the backbone Area 0. You can configure a virtual link between the two ABRs to connect Area 2 to the backbone area.

Figure 18 Virtual link application 1

 

Virtual links can also be used as redundant links. If a physical link failure breaks the internal connectivity of the backbone area, you can configure a virtual link to replace the failed physical link, as shown in Figure 19.

Figure 19 Virtual link application 2

 

The virtual link between the two ABRs acts as a point-to-point connection. You can configure interface parameters, such as hello interval, on the virtual link as they are configured on a physical interface.

The two ABRs on the virtual link unicast OSPF packets to each other, and the OSPF routers in between convey these OSPF packets as normal IP packets.

Stub area and totally stub area

A stub area does not distribute Type-5 LSAs to reduce the routing table size and LSAs advertised within the area. The ABR of the stub area advertises a default route in a Type-3 LSA so that the routers in the area can reach external networks through the default route.

To further reduce the routing table size and advertised LSAs, you can configure the stub area as a totally stub area. The ABR of a totally stub area does not advertise inter-area routes or external routes. It advertises a default route in a Type-3 LSA so that the routers in the area can reach external networks through the default route.

NSSA area and totally NSSA area

An NSSA area does not import AS external LSAs (Type-5 LSAs) but can import Type-7 LSAs generated by the NSSA ASBR. The NSSA ABR translates Type-7 LSAs into Type-5 LSAs and advertises the Type-5 LSAs to other areas.

As shown in Figure 20, the OSPF AS contains Area 1, Area 2, and Area 0. The other two ASs run RIP. Area 1 is an NSSA area where the ASBR redistributes RIP routes in Type-7 LSAs into Area 1. Upon receiving the Type-7 LSAs, the NSSA ABR translates them to Type-5 LSAs, and advertises the Type-5 LSAs to Area 0.

The ASBR of Area 2 redistributes RIP routes in Type-5 LSAs into the OSPF routing domain. However, Area 1 does not receive Type-5 LSAs because it is an NSSA area.

Figure 20 NSSA area

 

Router types

OSPF routers are classified into the following types based on their positions in the AS:

·          Internal router—All interfaces on an internal router belong to one OSPF area.

·          ABR—Belongs to more than two areas, one of which must be the backbone area. ABR connects the backbone area to a non-backbone area. An ABR and the backbone area can be connected through a physical or logical link.

·          Backbone router—No less than one interface of a backbone router must reside in the backbone area. All ABRs and internal routers in Area 0 are backbone routers.

·          ASBR—Exchanges routing information with another AS is an ASBR. An ASBR might not reside on the border of the AS. It can be an internal router or an ABR.

Figure 21 OSPF router types

 

Route types

OSPF prioritizes routes into the following route levels:

·          Intra-area route.

·          Inter-area route.

·          Type-1 external route.

·          Type-2 external route.

The intra-area and inter-area routes describe the network topology of the AS. The external routes describe routes to external ASs.

A Type-1 external route has high credibility. The cost of a Type-1 external route = the cost from the router to the corresponding ASBR + the cost from the ASBR to the destination of the external route.

A Type-2 external route has low credibility. OSPF considers that the cost from the ASBR to the destination of a Type-2 external route is much greater than the cost from the ASBR to an OSPF internal router. The cost of a Type-2 external route = the cost from the ASBR to the destination of the Type-2 external route. If two Type-2 routes to the same destination have the same cost, OSPF takes the cost from the router to the ASBR into consideration to determine the best route.

Route calculation

OSPF computes routes in an area as follows:

·          Each router generates LSAs based on the network topology around itself, and sends them to other routers in update packets.

·          Each OSPF router collects LSAs from other routers to compose an LSDB. An LSA describes the network topology around a router, and the LSDB describes the entire network topology of the area.

·          Each router transforms the LSDB to a weighted directed graph that shows the topology of the area. All the routers within the area have the same graph.

·          Each router uses the SPF algorithm to compute a shortest path tree that shows the routes to the nodes in the area. The router itself is the root of the tree.

OSPF network types

OSPF classifies networks into the following types, depending on different link layer protocols:

·          Broadcast—If the link layer protocol is Ethernet or FDDI, OSPF considers the network type as broadcast by default. On a broadcast network, hello, LSU, and LSAck packets are multicast to 224.0.0.5 that identifies all OSPF routers or to 224.0.0.6 that identifies the DR and BDR. DD packets and LSR packets are unicast.

·          NBMA—If the link layer protocol is Frame Relay, ATM, or X.25, OSPF considers the network type as NBMA by default. OSPF packets are unicast on an NBMA network.

·          P2MP—No link is P2MP type by default. P2MP must be a conversion from other network types such as NBMA. On a P2MP network, OSPF packets are multicast to 224.0.0.5.

·          P2P—If the link layer protocol is PPP or HDLC, OSPF considers the network type as P2P. On a P2P network, OSPF packets are multicast to 224.0.0.5.

The following are the differences between NBMA and P2MP networks:

·          NBMA networks are fully meshed. P2MP networks are not required to be fully meshed.

·          NBMA networks require DR and BDR election. P2MP networks do not have DR or BDR.

·          On an NBMA network, OSPF packets are unicast, and neighbors are manually configured. On a P2MP network, OSPF packets are multicast by default, and you can configure OSPF to unicast protocol packets.

DR and BDR

DR and BDR mechanism

On a broadcast or NBMA network, any two routers must establish an adjacency to exchange routing information with each other. If n routers are present on the network, n(n-1)/2 adjacencies are established. Any topology change on the network results in an increase in traffic for route synchronization, which consumes a large amount of system and bandwidth resources.

Using the DR and BDR mechanisms can solve this problem.

·          DR—Elected to advertise routing information among other routers. If the DR fails, routers on the network must elect another DR and synchronize information with the new DR. Using this mechanism without BDR is time-consuming and is prone to route calculation errors.

·          BDR—Elected along with the DR to establish adjacencies with all other routers. If the DR fails, the BDR immediately becomes the new DR, and other routers elect a new BDR.

Routers other than the DR and BDR are called DR Others. They do not establish adjacencies with one another, so the number of adjacencies is reduced.

The role of a router is subnet (or interface) specific. It might be a DR on one interface and a BDR or DR Other on another interface.

As shown in Figure 22, solid lines are Ethernet physical links, and dashed lines represent OSPF adjacencies. With the DR and BDR, only seven adjacencies are established.

Figure 22 DR and BDR in a network

 

 

NOTE:

In OSPF, neighbor and adjacency are different concepts. After startup, OSPF sends a hello packet on each OSPF interface. A receiving router checks parameters in the packet. If the parameters match its own, the receiving router considers the sending router an OSPF neighbor. Two OSPF neighbors establish an adjacency relationship after they synchronize their LSDBs through exchange of DD packets and LSAs.

 

DR and BDR election

DR election is performed on broadcast or NBMA networks but not on P2P and P2MP networks.

Routers in a broadcast or NBMA network elect the DR and BDR by router priority and ID. Routers with a router priority value higher than 0 are candidates for DR and BDR election.

The election votes are hello packets. Each router sends the DR elected by itself in a hello packet to all the other routers. If two routers on the network declare themselves as the DR, the router with the higher router priority wins. If router priorities are the same, the router with the higher router ID wins.

If a router with a higher router priority becomes active after DR and BDR election, the router cannot replace the DR or BDR until a new election is performed. Therefore, the DR of a network might not be the router with the highest priority, and the BDR might not be the router with the second highest priority.

Protocols and standards

·          RFC 1765, OSPF Database Overflow

·          RFC 2328, OSPF Version 2

·          RFC 3101, OSPF Not-So-Stubby Area (NSSA) Option

·          RFC 3137, OSPF Stub Router Advertisement

·          RFC 4811, OSPF Out-of-Band LSDB Resynchronization

·          RFC 4812, OSPF Restart Signaling

·          RFC 4813, OSPF Link-Local Signaling

OSPF configuration task list

To run OSPF, you must first enable OSPF on the router. Make a proper configuration plan to avoid incorrect settings that can result in route blocking and routing loops.

To configure OSPF, perform the following tasks:

 

Tasks at a glance

(Required.) Enabling OSPF

(Optional.) Configuring OSPF areas:

·         Configuring a stub area

·         Configuring an NSSA area

·         Configuring a virtual link

(Optional.) Configuring OSPF network types:

·         Configuring the broadcast network type for an interface

·         Configuring the NBMA network type for an interface

·         Configuring the P2MP network type for an interface

·         Configuring the P2P network type for an interface

(Optional.) Configuring OSPF route control:

·         Configuring OSPF route summarization

?  Configuring route summarization on an ABR

?  Configuring route summarization on an ASBR

·         Configuring received OSPF route filtering

·         Configuring Type-3 LSA filtering

·         Setting an OSPF cost for an interface

·         Setting the maximum number of ECMP routes

·         Setting OSPF preference

·         Configuring discard routes for summary networks

·         Configuring OSPF route redistribution

?  Redistributing routes from another routing protocol

?  Redistributing a default route

?  Configuring default parameters for redistributed routes

·         Advertising a host route

·         Excluding interfaces in an OSPF area from the base topology

(Optional.) Tuning and optimizing OSPF networks:

·         Setting OSPF timers

·         Setting LSA transmission delay

·         Setting SPF calculation interval

·         Setting the LSA arrival interval

·         Setting the LSA generation interval

·         Disabling interfaces from receiving and sending OSPF packets

·         Configuring stub routers

·         Configuring OSPF authentication

·         Adding the interface MTU into DD packets

·         Setting the DSCP value for outgoing OSPF packets

·         Setting the maximum number of external LSAs in LSDB

·         Setting OSPF exit overflow interval

·         Enabling compatibility with RFC 1583

·         Logging neighbor state changes

·         Configuring OSPF network management

·         Setting the LSU transmit rate

·         Setting the maximum length of OSPF packets that can be sent by an interface

·         Enabling OSPF ISPF

·         Configuring prefix suppression

·         Configuring prefix prioritization

·         Configuring OSPF PIC

·         Setting the number of OSPF logs

·         Filtering outbound LSAs on an interface

·         Filtering LSAs for the specified neighbor

·         Configuring GTSM for OSPF

(Optional.) Configuring OSPF GR

·         Configuring OSPF GR restarter

·         Configuring OSPF GR helper

·         Triggering OSPF GR

(Optional.) Configuring OSPF NSR

(Optional.) Configuring BFD for OSPF

(Optional.) Configuring OSPF FRR

(Optional.) Advertising OSPF link state information to BGP

 

Enabling OSPF

Enable OSPF before you perform other OSPF configuration tasks.

Configuration prerequisites

Configure the link layer protocol and IP addresses for interfaces to ensure IP connectivity between neighboring nodes.

Configuration guidelines

To enable OSPF on an interface, you can enable OSPF on the network where the interface resides or directly enable OSPF on that interface. If you configure both, the latter takes precedence.

You can specify a global router ID, or specify a router ID when you create an OSPF process.

·          If you specify a router ID when you create an OSPF process, any two routers in an AS must have different router IDs. A common practice is to specify the IP address of an interface as the router ID.

·          If you specify no router ID when you create the OSPF process, the global router ID is used. As a best practice, specify a router ID when you create the OSPF process.

OSPF supports multiple processes and VPNs.

·          To run multiple OSPF processes, you must specify an ID for each process. The process IDs take effect locally and has no influence on packet exchange between routers. Two routers with different process IDs can exchange packets.

·          You can configure an OSPF process to run in a specified VPN instance. For more information about VPN, see MPLS Configuration Guide.

Enabling OSPF on a network

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       (Optional.) Configure a global router ID.

router id router-id

By default, no global router ID is configured.

If no global router ID is configured, the highest loopback interface IP address, if any, is used as the router ID. If no loopback interface IP address is available, the highest physical interface IP address is used, regardless of the interface status (up or down).

3.       Enable an OSPF process and enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

By default, OSPF is disabled.

4.       (Optional.) Configure a description for the OSPF process.

description text

By default, no description is configured for the OSPF process.

As a best practice, configure a description for each OSPF process.

5.       Create an OSPF area and enter OSPF area view.

area area-id

By default, no OSPF areas exist.

6.       (Optional.) Configure a description for the area.

description text

By default, no description is configured for the area.

As a best practice, configure a description for each OSPF area.

7.       Specify a network to enable the interface attached to the network to run the OSPF process in the area.

network ip-address wildcard-mask

By default, no network is specified.

A network can be added to only one area.

 

Enabling OSPF on an interface

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Enable an OSPF process on the interface.

ospf process-id area area-id [ exclude-subip ]

By default, OSPF is disabled on an interface.

If the specified OSPF process and area do not exist, the command creates the OSPF process and area. Disabling an OSPF process on an interface does not delete the OSPF process or the area.

 

Configuring OSPF areas

Before you configure an OSPF area, perform the following tasks:

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring nodes.

·          Enable OSPF.

Configuring a stub area

You can configure a non-backbone area at an AS edge as a stub area. To do so, execute the stub command on all routers attached to the area. The routing table size is reduced because Type-5 LSAs will not be flooded within the stub area. The ABR generates a default route into the stub area so all packets destined outside of the AS are sent through the default route.

To further reduce the routing table size and routing information exchanged in the stub area, configure a totally stub area by using the stub no-summary command on the ABR. AS external routes and inter-area routes will not be distributed into the area. All the packets destined outside of the AS or area will be sent to the ABR for forwarding.

A stub or totally stub area cannot have an ASBR because external routes cannot be distributed into the area.

To configure an OSPF stub area:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

N/A

3.       Enter area view.

area area-id

N/A

4.       Configure the area as a stub area.

stub [ default-route-advertise-always | no-summary ] *

By default, no stub area is configured.

5.       (Optional.) Set a cost for the default route advertised to the stub area.

default-cost cost-value

The default setting is 1.

The default-cost cost command takes effect only on the ABR of a stub area or totally stub area.

 

Configuring an NSSA area

A stub area cannot import external routes, but an NSSA area can import external routes into the OSPF routing domain while retaining other stub area characteristics.

Do not configure the backbone area as an NSSA area or totally NSSA area.

To configure an NSSA area, configure the nssa command on all the routers attached to the area.

To configure a totally NSSA area, configure the nssa command on all the routers attached to the area and configure the nssa no-summary command on the ABR. The ABR of a totally NSSA area does not advertise inter-area routes into the area.

To configure an NSSA area:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

N/A

3.       Enter area view.

area area-id

N/A

4.       Configure the area as an NSSA area.

nssa [ default-route-advertise [ cost cost-value | nssa-only | route-policy route-policy-name | type type ] * | no-import-route | no-summary | suppress-fa | [ [ [ translate-always ] [ translate-ignore-checking-backbone ] ] | translate-never ] | translator-stability-interval value ] *

By default, no area is configured as an NSSA area.

5.       (Optional.) Set a cost for the default route advertised to the NSSA area.

default-cost cost-value

The default setting is 1.

This command takes effect only on the ABR/ASBR of an NSSA or totally NSSA area.

 

Configuring a virtual link

Virtual links are configured for connecting backbone area routers that have no direct physical links.

To configure a virtual link:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

N/A

3.       Enter area view.

area area-id

N/A

4.       Configure a virtual link.

vlink-peer router-id [ dead seconds | hello seconds | { { hmac-md5 | md5 } key-id { cipher | plain } string | keychain keychain-name | simple { cipher | plain } string } | retransmit seconds | trans-delay seconds ] *

By default, no virtual links exist.

Configure this command on both ends of a virtual link. The hello and dead intervals must be identical on both ends of the virtual link.

 

Configuring OSPF network types

OSPF classifies networks into the following types based on the link layer protocol:

·          BroadcastWhen the link layer protocol is Ethernet or FDDI, OSPF classifies the network type as broadcast by default.

·          NBMAWhen the link layer protocol is Frame Relay, ATM, or X.25, OSPF classifies the network type as NBMA by default.

·          P2PWhen the link layer protocol is PPP, LAPB, or HDLC, OSPF classifies the network type as P2P by default.

When you change the network type of an interface, follow these guidelines:

·          When an NBMA network becomes fully meshed, change the network type to broadcast to avoid manual configuration of neighbors.

·          If any routers in a broadcast network do not support multicasting, change the network type to NBMA.

·          An NBMA network must be fully meshed. OSPF requires that an NBMA network be fully meshed. If a network is partially meshed, change the network type to P2MP.

·          If a router on an NBMA network has only one neighbor, you can change the network type to P2P to save costs.

Two broadcast-, NBMA-, and P2MP-interfaces can establish a neighbor relationship only when they are on the same network segment.

Configuration prerequisites

Before you configure OSPF network types, perform the following tasks:

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring nodes.

·          Enable OSPF.

Configuring the broadcast network type for an interface

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Configure the OSPF network type for the interface as broadcast.

ospf network-type broadcast

By default, the network type of an interface depends on the link layer protocol.

4.       (Optional.) Set a router priority for the interface.

ospf dr-priority priority

The default router priority is 1.

 

Configuring the NBMA network type for an interface

After you configure the network type as NBMA, you must specify neighbors and their router priorities because NBMA interfaces cannot find neighbors by broadcasting hello packets.

To configure the NBMA network type for an interface:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Configure the OSPF network type for the interface as NBMA.

ospf network-type nbma

By default, the network type of an interface depends on the link layer protocol.

4.       (Optional.) Set a router priority for the interface.

ospf dr-priority priority

The default setting is 1.

The router priority configured with this command is for DR election.

5.       Return to system view.

quit

N/A

6.       Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

N/A

7.       Specify a neighbor and set its router priority.

peer ip-address [ dr-priority priority ]

By default, no neighbor is specified.

The priority configured with this command indicates whether a neighbor has the election right or not. If you configure the router priority for a neighbor as 0, the local router determines the neighbor has no election right, and does not send hello packets to this neighbor. However, if the local router is the DR or BDR, it still sends hello packets to the neighbor for neighbor relationship establishment.

 

Configuring the P2MP network type for an interface

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Configure the OSPF network type for the interface as P2MP.

ospf network-type p2mp [ unicast ]

By default, the network type of an interface depends on the link layer protocol.

After you configure the OSPF network type for an interface as P2MP unicast, all packets are unicast over the interface. The interface cannot broadcast hello packets to discover neighbors, so you must manually specify the neighbors.

4.       Return to system view.

quit

N/A

5.       Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

N/A

6.       (Optional.) Specify a neighbor and set its router priority.

peer ip-address [ cost cost-value ]

By default, no neighbor is specified.

This step must be performed if the network type is P2MP unicast, and is optional if the network type is P2MP.

 

Configuring the P2P network type for an interface

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Configure the OSPF network type for the interface as P2P.

ospf network-type p2p [ peer-address-check ]

By default, the network type of an interface depends on the link layer protocol.

 

Configuring OSPF route control

This section describes how to control the advertisement and reception of OSPF routing information, as well as route redistribution from other protocols.

Configuration prerequisites

Before you configure OSPF route control, perform the following tasks:

·          Configure IP addresses for interfaces to ensure IP connectivity between neighboring nodes.

·          Enable OSPF.

·          Configure filters if routing information filtering is needed.

Configuring OSPF route summarization

Route summarization enables an ABR or ASBR to summarize contiguous networks into a single network and advertise the network to other areas.

Route summarization reduces the routing information exchanged between areas and the size of routing tables, and improves routing performance. For example, three internal networks 19.1.1.0/24, 19.1.2.0/24, and 19.1.3.0/24 are available within an area. You can summarize the three networks into network 19.1.0.0/16, and advertise the summary network to other areas.

Configuring route summarization on an ABR

After you configure a summary route on an ABR, the ABR generates a summary LSA instead of specific LSAs. The scale of LSDBs on routers in other areas and the influence of topology changes are reduced.

To configure route summarization on an ABR:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter OSPF view.