Configuration - HPE Support Center

Configuration - HPE Support Center
HP MSR Router Series
Layer 3 - IP Routing
Configuration Guide(V5)
Part number: 5998-8186
Software version: CMW520-R2513
Document version: 6PW106-20150808
Legal and notice information
© Copyright 2015 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
i
Contents
IP routing basics ··························································································································································· 1 Routing table ······································································································································································ 1 Dynamic routing protocols ··············································································································································· 2 Route preference ······························································································································································· 2 Load sharing ······································································································································································ 3 Route backup ····································································································································································· 3 Route recursion ·································································································································································· 3 Route redistribution ··························································································································································· 3 Displaying and maintaining a routing table ·················································································································· 4 Configuring static routing ············································································································································ 6 Configuring a static route················································································································································· 6 Configuring BFD for static routes····································································································································· 7 BFD control packet mode ········································································································································ 7 BFD echo packet mode ············································································································································ 8 Configuring static route FRR ············································································································································· 9 Configuration prerequisites ····································································································································· 9 Configuration guidelines ········································································································································· 9 Configuration procedure ········································································································································· 9 Displaying and maintaining static routes ···················································································································· 10 Static route configuration examples ····························································································································· 10 Basic static route configuration example ············································································································ 10 BFD for static routes configuration example (direct next hop) ·········································································· 12 BFD for static routes configuration example (indirect next hop) ······································································· 14 Configuring a default route ······································································································································· 18 Configuring RIP ·························································································································································· 19 Overview········································································································································································· 19 RIP route entries ····················································································································································· 19 RIP timers ································································································································································ 19 Routing loop prevention ········································································································································ 19 RIP operation ·························································································································································· 20 RIP versions ···························································································································································· 20 TRIP ········································································································································································· 20 Supported RIP features ·········································································································································· 21 Protocols and standards ······································································································································· 21 RIP configuration task list ··············································································································································· 22 Configuring basic RIP ···················································································································································· 22 Enabling RIP ··························································································································································· 22 Configuring the interface behavior ····················································································································· 23 Configuring a RIP version ····································································································································· 23 Configuring RIP route control ········································································································································ 24 Configuring an additional routing metric ··········································································································· 24 Configuring RIPv2 route summarization·············································································································· 25 Disabling host route reception ····························································································································· 26 Advertising a default route ··································································································································· 26 Configuring received/redistributed route filtering ····························································································· 27 Configuring a preference for RIP ························································································································· 27 Configuring RIP route redistribution····················································································································· 28 i
Tuning and optimizing RIP networks ···························································································································· 28 Configuration prerequisites ·································································································································· 28 Configuring RIP timers··········································································································································· 28 Configuring split horizon and poison reverse ···································································································· 29 Configuring the maximum number of ECMP routes ·························································································· 30 Enabling zero field check on incoming RIPv1 messages ·················································································· 30 Enabling source IP address check on incoming RIP updates ············································································ 30 Configuring RIPv2 message authentication ········································································································ 31 Specifying a RIP neighbor ···································································································································· 31 Configuring TRIP ···················································································································································· 32 Configuring RIP-to-MIB binding ···························································································································· 32 Configuring the RIP packet sending rate ············································································································ 33 Configuring BFD for RIP················································································································································· 33 Enabling single-hop echo detection (for a directly connected RIP neighbor)·················································· 33 Enabling single-hop detection in BFD echo packet (for a specific destination) ·············································· 34 Enabling bidirectional control detection ············································································································· 34 Displaying and maintaining RIP ··································································································································· 35 RIP configuration examples ··········································································································································· 35 Configuring RIP version ········································································································································ 35 Configuring RIP route redistribution····················································································································· 37 Configuring an additional metric for a RIP interface ························································································· 39 Configuring RIP to advertise a summary route ··································································································· 41 Configuring BFD for RIP (single-hop echo detection for a directly connected RIP neighbor) ························ 43 Configuring BFD for RIP (single-hop echo detection for a specified destination) ··········································· 46 Configuring BFD for RIP (bidirectional control detection) ················································································· 49 Troubleshooting RIP ························································································································································ 53 No RIP updates received ······································································································································ 53 Route oscillation occurred ···································································································································· 53 Configuring OSPF ······················································································································································ 54 Overview········································································································································································· 54 OSPF packets ························································································································································· 54 LSA types ································································································································································ 55 OSPF area ······························································································································································ 55 Router types···························································································································································· 58 Route types ····························································································································································· 58 Route calculation ··················································································································································· 59 OSPF network types ·············································································································································· 59 DR and BDR ··························································································································································· 59 Protocols and standards ······································································································································· 60 OSPF configuration task list ·········································································································································· 61 Enabling OSPF ······························································································································································· 62 Configuration prerequisites ·································································································································· 62 Configuration guidelines ······································································································································ 62 Configuration procedure ······································································································································ 63 Configuring OSPF areas ··············································································································································· 63 Configuration prerequisites ·································································································································· 63 Configuring a stub area ······································································································································· 63 Configuring an NSSA area·································································································································· 64 Configuring a virtual link ······································································································································ 65 Configuring OSPF network types ································································································································· 65 Configuration prerequisites ·································································································································· 66 Configuring the broadcast network type for an interface ················································································· 66 Configuring the NBMA network type for an interface ······················································································ 66 Configuring the P2MP network type for an interface ························································································ 67 ii
Configuring the P2P network type for an interface ··························································································· 68 Configuring OSPF route control ··································································································································· 68 Configuration prerequisites ·································································································································· 68 Configuring OSPF route summarization ············································································································· 68 Configuring OSPF inbound route filtering ·········································································································· 69 Configuring ABR Type-3 LSA filtering ················································································································· 70 Configuring an OSPF cost for an interface ········································································································ 70 Configuring the maximum number of ECMP routes ·························································································· 71 Configuring OSPF preference ······························································································································ 71 Configuring OSPF route redistribution ················································································································ 71 Advertising a host route ········································································································································ 73 Tuning and optimizing OSPF networks························································································································ 73 Configuration prerequisites ·································································································································· 73 Configuring OSPF packet timers·························································································································· 73 Specifying LSA transmission delay ······················································································································ 74 Specifying SPF calculation interval ······················································································································ 75 Specifying the LSA arrival interval······················································································································· 75 Specifying the LSA generation interval ··············································································································· 76 Disabling interfaces from receiving and sending OSPF packets······································································ 76 Configuring stub routers ······································································································································· 76 Configuring OSPF authentication ························································································································ 77 Adding the interface MTU into DD packets ········································································································ 78 Configuring the maximum number of external LSAs in LSDB ··········································································· 78 Enabling compatibility with RFC 1583 ··············································································································· 78 Logging neighbor state changes·························································································································· 79 Configuring OSPF network management ··········································································································· 79 Enabling message logging ··································································································································· 80 Enabling the advertisement and reception of opaque LSAs ············································································· 80 Configuring OSPF to give priority to receiving and processing hello packets ··············································· 80 Configuring the LSU transmit rate ························································································································ 81 Enabling OSPF ISPF ·············································································································································· 81 Configuring OSPF GR ··················································································································································· 81 Configuring the OSPF GR helper ························································································································ 82 Triggering OSPF GR ············································································································································· 82 Configuring BFD for OSPF ············································································································································ 83 Configuring control packet bidirectional detection ··························································································· 83 Configuring echo packet single-hop detection ··································································································· 83 Displaying and maintaining OSPF ······························································································································· 83 OSPF configuration examples ······································································································································ 85 Configuring OSPF basic functions ······················································································································· 85 Configuring OSPF route redistribution ················································································································ 88 Configuring OSPF to advertise a summary route······························································································· 89 Configuring an OSPF stub area··························································································································· 92 Configuring an OSPF NSSA area ······················································································································· 94 Configuring OSPF DR election ····························································································································· 96 Configuring OSPF virtual links ··························································································································· 100 Configuring OSPF Graceful Restart ··················································································································· 102 Configuring route filtering ·································································································································· 105 Configuring BFD for OSPF ································································································································· 107 Troubleshooting OSPF configuration ························································································································· 111 No OSPF neighbor relationship established ···································································································· 111 Incorrect routing information ······························································································································ 111 Configuring IS-IS ····················································································································································· 113 Overview······································································································································································· 113 iii
Terminology ························································································································································· 113 IS-IS address format············································································································································· 113 NET ······································································································································································· 114 IS-IS area ······························································································································································ 115 IS-IS network types ·············································································································································· 117 IS-IS PDUs ····························································································································································· 118 Supported IS-IS features ······································································································································ 124 Protocols and standards ····································································································································· 126 IS-IS configuration task list ··········································································································································· 126 Configuring IS-IS basic functions ································································································································ 127 Configuration prerequisites ································································································································ 127 Enabling IS-IS ······················································································································································· 128 Configuring the IS level and circuit level ·········································································································· 128 Configuring the network type of an interface as P2P ······················································································ 128 Configuring IS-IS routing information control ············································································································ 129 Configuration prerequisites ································································································································ 129 Configuring IS-IS link cost ··································································································································· 129 Specifying a priority for IS-IS ····························································································································· 131 Configuring the maximum number of ECMP routes ························································································ 131 Configuring IS-IS route summarization ·············································································································· 131 Advertising a default route ································································································································· 132 Configuring IS-IS route redistribution ················································································································ 132 Configuring IS-IS route filtering ·························································································································· 132 Configuring IS-IS route leaking ·························································································································· 133 Tuning and optimizing IS-IS networks ························································································································ 134 Configuration prerequisites ································································································································ 134 Specifying intervals for sending IS-IS hello and CSNP packets ····································································· 134 Specifying the IS-IS hello multiplier ···················································································································· 134 Configuring a DIS priority for an interface ······································································································· 135 Disabling an interface from sending/receiving IS-IS packets ········································································· 135 Disabling hello source address check for a PPP interface ·············································································· 135 Enabling an interface to send small hello packets ··························································································· 136 Configuring LSP parameters ······························································································································· 136 Configuring SPF parameters ······························································································································ 139 Assigning a high priority to IS-IS routes ············································································································ 140 Setting the LSDB overload bit ····························································································································· 140 Configuring system ID to host name mappings································································································ 141 Enabling the logging of neighbor state changes ····························································································· 142 Enhancing IS-IS network security ································································································································ 142 Configuration prerequisites ································································································································ 142 Configuring neighbor relationship authentication ··························································································· 142 Configuring area authentication ························································································································ 143 Configuring routing domain authentication······································································································ 143 Configuring IS-IS GR ···················································································································································· 144 Enabling IS-IS SNMP trap ··········································································································································· 144 Binding an IS-IS process with MIBs ···························································································································· 145 Configuring BFD for IS-IS············································································································································· 145 Displaying and maintaining IS-IS ······························································································································· 145 IS-IS configuration examples ······································································································································· 146 IS-IS basic configuration ····································································································································· 146 DIS election configuration ·································································································································· 151 Configuring IS-IS route redistribution ················································································································ 155 IS-IS GR configuration example ························································································································· 158 IS-IS authentication configuration example······································································································· 160 iv
Configuring BFD for IS-IS ···································································································································· 162 Configuring BGP ····················································································································································· 167 Overview······································································································································································· 167 BGP speaker and BGP peer ······························································································································· 167 BGP message types ············································································································································· 167 BGP path attributes ············································································································································· 168 BGP route selection ············································································································································· 172 BGP route advertisement rules ··························································································································· 172 BGP load balancing ············································································································································ 172 Settlements for problems in large-scale BGP networks ···················································································· 173 MP-BGP································································································································································· 176 BGP configuration views ···································································································································· 177 Protocols and standards ····································································································································· 178 BGP configuration task list ·········································································································································· 179 Configuring basic BGP ················································································································································ 180 Enabling BGP······················································································································································· 180 Configuring a BGP peer ····································································································································· 181 Configuring a BGP peer group·························································································································· 182 Specifying the source interface for TCP connections ······················································································· 184 Generating BGP routes ················································································································································ 185 Configuration prerequisites ································································································································ 185 Injecting a local network ···································································································································· 185 Redistributing IGP routes····································································································································· 186 Controlling route distribution and reception ············································································································· 186 Configuring BGP route summarization ············································································································· 186 Advertising a default route to a peer or peer group ······················································································· 187 Configuring BGP route distribution/reception filtering policies ····································································· 188 Enabling BGP and IGP route synchronization ································································································· 190 Limiting prefixes received from a peer or peer group ····················································································· 191 Configuring BGP route dampening ··················································································································· 192 Controlling BGP path selection ··································································································································· 192 Specifying a preferred value for routes received ····························································································· 192 Configuring preferences for BGP routes ··········································································································· 193 Configure the default local preference ············································································································· 194 Configuring the MED attribute ··························································································································· 194 Configuring the NEXT_HOP attribute ················································································································ 197 Configuring the AS_PATH attribute ··················································································································· 198 Tuning and optimizing BGP networks························································································································ 201 Configuring the BGP keepalive interval and holdtime ···················································································· 201 Configuring the interval for sending the same update ···················································································· 202 Allowing establishment of EBGP session to an indirectly connected peer or peer group ··························· 202 Enabling the BGP ORF capability······················································································································ 203 Enabling 4-byte AS number suppression ·········································································································· 204 Enabling quick reestablishment of direct EBGP session ·················································································· 204 Enabling MD5 authentication for BGP peers ··································································································· 205 Configuring BGP load balancing ······················································································································ 205 Forbidding session establishment with a peer or peer group ········································································ 206 Configuring BGP soft-reset·································································································································· 206 Configuring a large scale BGP network ···················································································································· 208 Configuration prerequisites ································································································································ 208 Configuring BGP community ······························································································································ 208 Configuring a BGP route reflector ····················································································································· 209 Configuring a BGP confederation ····················································································································· 210 Configuring BGP GR ··················································································································································· 211 v
Enabling trap ································································································································································ 212 Enabling logging of session state changes ··············································································································· 212 Configuring BFD for BGP ············································································································································ 213 Displaying and maintaining BGP ······························································································································· 213 Displaying BGP···················································································································································· 213 Resetting BGP session ········································································································································· 215 Clearing BGP information ·································································································································· 215 BGP configuration examples ······································································································································ 215 BGP basic configuration ····································································································································· 215 BGP and IGP synchronization configuration ···································································································· 219 BGP load balancing configuration ···················································································································· 222 BGP route summarization configuration ··········································································································· 224 BGP community configuration ···························································································································· 228 BGP route reflector configuration ······················································································································ 230 BGP confederation configuration ······················································································································ 231 BGP path selection configuration ······················································································································ 235 BGP GR configuration········································································································································· 238 Configuring BFD for BGP ··································································································································· 239 Troubleshooting BGP ··················································································································································· 243 BGP peer relationship not established ·············································································································· 243 Configuring routing policies ··································································································································· 245 Overview······································································································································································· 245 Filters ····································································································································································· 245 Configuring filters ························································································································································· 246 Configuration prerequisites ································································································································ 246 Configuring an IP-prefix list ································································································································ 246 Configuring an AS path list ································································································································ 247 Configuring a community list ····························································································································· 247 Configuring an extended community list ·········································································································· 248 Configuring a routing policy······································································································································· 248 Configuration prerequisites ································································································································ 248 Creating a routing policy ··································································································································· 248 Configuring if-match clauses ······························································································································ 249 Configuring apply clauses·································································································································· 250 Configuring a continue clause ··························································································································· 251 Displaying and maintaining the routing policy ········································································································· 252 Routing policy configuration examples ······················································································································ 252 Applying a routing policy to IPv4 route redistribution····················································································· 252 Applying a routing policy to IPv6 route redistribution····················································································· 255 Applying a routing policy to filter received BGP routes ·················································································· 257 Troubleshooting routing policy configuration ··········································································································· 259 IPv4 routing information filtering failure············································································································ 259 IPv6 routing information filtering failure············································································································ 259 Configuring PBR ······················································································································································ 260 Overview······································································································································································· 260 Policy ···································································································································································· 260 PBR and Track ······················································································································································ 262 PBR configuration task list ··········································································································································· 262 Configuring a policy ···················································································································································· 262 Creating a node ·················································································································································· 262 Configuring match criteria for a node ·············································································································· 262 Configuring actions for a node·························································································································· 263 Configuring PBR ··························································································································································· 264 vi
Configuring local PBR ········································································································································· 264 Configuring interface PBR ·································································································································· 264 Displaying and maintaining PBR ································································································································ 264 PBR configuration examples········································································································································ 265 Configuring local PBR based on packet type ··································································································· 265 Configuring interface PBR based on packet type ···························································································· 266 Configuring interface PBR based on packet length ························································································· 268 Configuring local PBR to specify output interface and next hop ···································································· 271 Configuring IPv6 static routing ······························································································································· 273 Overview······································································································································································· 273 Configuring IPv6 static routing ··································································································································· 273 Displaying and maintaining IPv6 static routes ·········································································································· 274 IPv6 static routing configuration example ················································································································· 274 Configuring an IPv6 default route ·························································································································· 276 Configuring RIPng ··················································································································································· 277 Overview······································································································································································· 277 RIPng working mechanism·································································································································· 277 RIPng packet format ············································································································································ 277 RIPng packet processing procedure ·················································································································· 278 Protocols and standards ····································································································································· 279 RIPng configuration task list ········································································································································ 279 Configuring RIPng basic functions ······························································································································ 279 Configuration prerequisites ································································································································ 280 Configuration procedure ···································································································································· 280 Configuring RIPng route control ································································································································· 280 Configuring an additional routing metric ········································································································· 280 Configuring RIPng route summarization ··········································································································· 281 Advertising a default route ································································································································· 281 Configuring a RIPng route filtering policy········································································································· 281 Configuring a priority for RIPng ························································································································· 282 Configuring RIPng route redistribution ·············································································································· 282 Tuning and optimizing the RIPng network ················································································································· 282 Configuring RIPng timers ···································································································································· 282 Configuring split horizon and poison reverse ·································································································· 283 Configuring zero field check on RIPng packets ······························································································· 284 Configuring the maximum number of ECMP routes ························································································ 284 Applying IPsec policies for RIPng ······························································································································· 284 Displaying and maintaining RIPng ····························································································································· 285 RIPng configuration examples····································································································································· 286 Configuring RIPng basic functions ····················································································································· 286 Configuring RIPng route redistribution ·············································································································· 288 Configuring RIPng IPsec policies ······················································································································· 290 Configuring OSPFv3 ··············································································································································· 294 Overview······································································································································································· 294 Packets ·································································································································································· 294 LSA types ······························································································································································ 294 Timers···································································································································································· 295 Supported features ·············································································································································· 296 Protocols and standards ····································································································································· 296 OSPFv3 configuration task list ···································································································································· 296 Enabling OSPFv3 ························································································································································· 297 Configuration prerequisites ································································································································ 297 vii
Enabling OSPFv3 ················································································································································ 297 Configuring OSPFv3 area parameters ······················································································································ 297 Configuration prerequisites ································································································································ 298 Configuring an OSPFv3 stub area ···················································································································· 298 Configuring an OSPFv3 virtual link ··················································································································· 298 Configuring OSPFv3 network types ··························································································································· 299 Configuration prerequisites ································································································································ 299 Configuring the OSPFv3 network type for an interface ·················································································· 299 Configuring an NBMA or P2MP neighbor ······································································································· 300 Configuring OSPFv3 routing information control ····································································································· 300 Configuration prerequisites ································································································································ 300 Configuring OSPFv3 route summarization ······································································································· 300 Configuring OSPFv3 inbound route filtering ···································································································· 300 Configuring an OSPFv3 cost for an interface ·································································································· 301 Configuring the maximum number of OSPFv3 ECMP routes ········································································· 301 Configuring a priority for OSPFv3 ···················································································································· 302 Configuring OSPFv3 route redistribution ·········································································································· 302 Tuning and optimizing OSPFv3 networks ················································································································· 303 Configuration prerequisites ································································································································ 303 Configuring OSPFv3 timers ································································································································ 303 Configuring a DR priority for an interface ········································································································ 304 Ignoring MTU check for DD packets ················································································································· 304 Disabling interfaces from receiving and sending OSPFv3 packets ······························································· 305 Enabling the logging of neighbor state changes ····························································································· 305 Configuring OSPFv3 GR ············································································································································· 305 Configuring GR helper········································································································································ 306 Configuring BFD for OSPFv3 ······································································································································ 306 Applying IPsec policies for OSPFv3 ··························································································································· 307 Displaying and maintaining OSPFv3 ························································································································· 308 OSPFv3 configuration examples ································································································································ 309 Configuring OSPFv3 areas ································································································································ 309 Configuring OSPFv3 DR election······················································································································· 313 Configuring OSPFv3 route redistribution ·········································································································· 315 Configuring OSPFv3 GR ···································································································································· 318 Configuring BFD for OSPFv3 ····························································································································· 320 Configuring OSPFv3 IPsec policies ··················································································································· 323 Troubleshooting OSPFv3 configuration ····················································································································· 326 No OSPFv3 neighbor relationship established ································································································ 326 Incorrect routing information ······························································································································ 327 Configuring IPv6 IS-IS ············································································································································· 328 Overview······································································································································································· 328 Configuring basic IPv6 IS-IS ········································································································································ 328 Configuration prerequisites ································································································································ 328 Configuration procedure ···································································································································· 328 Configuring IPv6 IS-IS route control ··························································································································· 329 Configuring BFD for IPv6 IS-IS ···································································································································· 330 Configuring IPv6 IS-IS MTR ········································································································································· 330 Displaying and maintaining IPv6 IS-IS ······················································································································· 331 IPv6 IS-IS configuration examples ······························································································································ 332 IPv6 IS-IS basic configuration example ············································································································· 332 Configuring BFD for IPv6 IS-IS ··························································································································· 337 Configuring IPv6 IS-IS MTR································································································································· 340 viii
Configuring IPv6 BGP ············································································································································· 343 IPv6 BGP overview ······················································································································································· 343 IPv6 BGP configuration task list ·································································································································· 343 Configuring IPv6 BGP basic functions ······················································································································· 344 Configuration prerequisites ································································································································ 344 Specifying an IPv6 BGP peer ····························································································································· 344 Injecting a local IPv6 route ································································································································· 345 Configuring a preferred value for routes from a peer or peer group···························································· 345 Specifying the source interface for establishing TCP connections ································································· 346 Allowing the establishment of an indirect EBGP connection ·········································································· 346 Configuring a description for an IPv6 peer or peer group ············································································· 347 Disabling session establishment to an IPv6 peer or peer group ···································································· 347 Logging IPv6 peer or peer group state changes ······························································································ 347 Controlling route distribution and reception ············································································································· 348 Configuration prerequisites ································································································································ 348 Configuring IPv6 BGP route redistribution ········································································································ 348 Configuring IPv6 BGP route summarization ····································································································· 348 Advertising a default route to an IPv6 peer or peer group············································································· 349 Configuring outbound route filtering ················································································································· 349 Configuring inbound route filtering ··················································································································· 350 Configuring IPv6 BGP and IGP route synchronization ···················································································· 350 Configuring route dampening···························································································································· 351 Configuring IPv6 BGP route attributes ······················································································································· 351 Configuration prerequisites ································································································································ 351 Configuring IPv6 BGP preference and default LOCAL_PREF and NEXT_HOP attributes ···························· 351 Configuring the MED attribute ··························································································································· 352 Configuring the AS_PATH attribute ··················································································································· 353 Tuning and optimizing IPv6 BGP networks ··············································································································· 353 Configuration prerequisites ································································································································ 354 Configuring IPv6 BGP timers ······························································································································ 354 Configuring IPv6 BGP soft reset ························································································································· 355 Enabling the IPv6 BGP ORF capability ············································································································· 355 Enabling 4-byte AS number suppression ·········································································································· 356 Configuring the maximum number of ECMP routes ························································································ 357 Enabling MD5 authentication for TCP connections ························································································· 357 Applying an IPsec policy to an IPv6 BGP peer or peer group ······································································· 358 Configuring a large-scale IPv6 BGP network ············································································································ 358 Configuration prerequisites ································································································································ 359 Configuring IPv6 BGP peer group····················································································································· 359 Configuring IPv6 BGP community ····················································································································· 360 Configuring an IPv6 BGP route reflector··········································································································· 361 Configuring 6PE ··························································································································································· 361 Configuration prerequisites ································································································································ 362 Configuring basic 6PE capabilities ··················································································································· 362 Configuring optional 6PE capabilities ·············································································································· 362 Configuring BFD for IPv6 BGP ···································································································································· 364 Displaying and maintaining IPv6 BGP······················································································································· 365 Displaying BGP···················································································································································· 365 Resetting IPv6 BGP connections ························································································································· 366 Clearing IPv6 BGP information ·························································································································· 366 IPv6 BGP configuration examples ······························································································································ 366 IPv6 BGP basic configuration ···························································································································· 367 IPv6 BGP route reflector configuration ·············································································································· 369 6PE configuration ················································································································································ 370 ix
IPv6 BGP IPsec policy configuration·················································································································· 374 Configuring BFD for IPv6 BGP ··························································································································· 379 Troubleshooting IPv6 BGP configuration ··················································································································· 383 IPv6 BGP peer relationship not established ······································································································ 383 Configuring IPv6 PBR ·············································································································································· 384 Introduction to IPv6 policy-based routing ·················································································································· 384 Policy ···································································································································································· 384 IPv6 PBR configuration task list ··································································································································· 385 Configuring an IPv6 policy ········································································································································· 386 Creating an IPv6 node ········································································································································ 386 Configuring match criteria for an IPv6 node ···································································································· 386 Configuring actions for an IPv6 node ··············································································································· 386 Configuring IPv6 PBR ··················································································································································· 387 Configuring IPv6 local PBR································································································································· 387 Configuring IPv6 interface PBR ·························································································································· 387 Displaying and maintaining IPv6 PBR ························································································································ 388 IPv6 PBR configuration examples ······························································································································· 388 Configuring IPv6 local PBR based on packet type ·························································································· 388 Configuring IPv6 interface PBR based on packet type ···················································································· 389 Configuring IPv6 interface PBR based on packet length ················································································· 391 Support and other resources ·································································································································· 395 Contacting HP ······························································································································································ 395 Subscription service ············································································································································ 395 Related information ······················································································································································ 395 Documents ···························································································································································· 395 Websites······························································································································································· 395 Conventions ·································································································································································· 396 Index ········································································································································································ 398 x
IP routing basics
IP routing directs the forwarding of IP packets on routers based on a routing table. This book focuses on
unicast routing protocols. For more information about multicast routing protocols, see IP Multicast
Configuration Guide.
Routing table
A router maintains at least two routing tables: one global routing table and one forwarding information
base (FIB). The FIB table contains only the optimal routes, and the global routing table contains all routes.
The router uses the FIB table to forward packets. For more information about the FIB table, see Layer 3—IP
Services Configuration Guide.
Routes can be classified by different criteria, as shown in Table 1.
Table 1 Categories of routes
Criterion
Categories
Destination
• Network route—Destination is a network. The subnet mask is less than 32 bits.
• Host route—Destination is a host. The subnet mask is 32 bits.
Whether the
destination is directly
connected
• Direct route—Destination is directly connected.
• Indirect route—Destination is indirectly connected.
• Direct route—A direct route is discovered by the data link protocol on an interface,
and is also called an "interface route."
Origin
• Static route—A static route is manually configured by an administrator.
• Dynamic route—A dynamic route is dynamically discovered by a routing protocol.
Static routes are easy to configure and require less system resources. They work well in small and stable
networks. In networks where topology changes occur frequently, using a dynamic routing protocol is
better.
To view brief information about a routing table, use the display ip routing-table command, as shown in
the following example:
<Sysname> display ip routing-table
Routing Tables: Public
Destinations : 7
Destination/Mask
Proto
1.1.1.0/24
2.2.2.0/24
80.1.1.0/24
Routes : 7
Pre
Cost
NextHop
Interface
Direct 0
0
1.1.1.1
Eth1/1
Static 60
0
12.2.2.2
Eth1/2
OSPF
2
80.1.1.1
Eth1/3
10
…(Part of the output information is not shown)
A route entry includes the following key items:
•
Destination—IP address of the destination host or network.
1
•
Mask—Mask length of the IP address.
•
Pre—Preference of the route. Among routes to the same destination, the one with the highest
preference is optimal.
•
Cost—When multiple routes to a destination have the same preference, the one with the smallest
cost becomes the optimal route.
•
NextHop—Next hop.
•
Interface—Output interface.
Dynamic routing protocols
Dynamic routing protocols dynamically collect and report reachability information to adapt to topology
changes. They are suitable for large networks.
Compared with static routing, dynamic routing protocols require more resources, and are complicated to
configure.
Dynamic routing protocols can be classified by different criteria, as shown in Table 2:
Table 2 Categories of dynamic routing protocols
Criterion
Categories
• Interior gateway protocols (IGPs)—Work within an autonomous system (AS).
Optional scope
Examples include RIP, OSPF, and IS-IS.
• Exterior gateway protocols (EGPs)—Work between ASs. The most popular one is
BGP.
• Distance-vector protocols—RIP and BGP. BGP is also considered a path-vector
Routing algorithm
Destination address
type
IP version
protocol.
• Link-state protocols—OSPF and IS-IS.
• Unicast routing protocols—RIP, OSPF, BGP, and IS-IS.
• Multicast routing protocols—PIM-SM and PIM-DM (For more information, see IP
Multicast Configuration Guide).
• IPv4 routing protocols—RIP, OSPF, BGP, and IS-IS.
• IPv6 routing protocols—RIPng, OSPFv3, IPv6 BGP, and IPv6 IS-IS.
NOTE:
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 as required. The following table lists the route types
and their default preferences. The smaller the value, the higher the preference.
2
Table 3 Route types and their default route preferences
Routing type
Preference
Direct route
0
OSPF
10
IS-IS
15
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, and IS-IS/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 main route and others are backup routes.
The router forwards matching packets through the main route. When the main route fails, the route with
the highest preference among the backup routes is selected to forward packets. When the main 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 outgoing 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.
Route redistribution
Route redistribution enables routing protocols to learn route 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.
3
Displaying and maintaining a routing table
Task
Command
Remarks
Display the routing table.
display ip routing-table [ vpn-instance
vpn-instance-name ] [ verbose ] [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display routes matching an IPv4
basic ACL.
display ip routing-table [ vpn-instance
vpn-instance-name ] acl acl-number
[ verbose ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display routes to the specified
destination.
display ip routing-table [ vpn-instance
vpn-instance-name ] ip-address [ mask |
mask-length ] [ longer-match ] [ verbose ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display routes with destination
addresses in the specified range.
display ip routing-table [ vpn-instance
vpn-instance-name ] ip-address1 { mask |
mask-length } ip-address2 { mask |
mask-length } [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display routing information
matching an IPv4 prefix list.
display ip routing-table [ vpn-instance
vpn-instance-name ] ip-prefix
ip-prefix-name [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display the routes of a routing
protocol.
display ip routing-table [ vpn-instance
vpn-instance-name ] protocol protocol
[ inactive | verbose ] [ | { begin | exclude
| include } regular-expression ] [ | { begin
| exclude | include } regular-expression ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display statistics about the routing
table.
display ip routing-table [ vpn-instance
vpn-instance-name ] statistics [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Clear statistics for the routing table.
reset ip routing-table statistics protocol
[ vpn-instance vpn-instance-name ]
{ protocol | all }
Available in user view.
Display IPv6 routing table
information.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] [ verbose ] [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display routes matching an IPv6
ACL.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] acl acl6-number
[ verbose ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display routing information for a
specified destination IPv6 address.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] ipv6-address
[ prefix-length ] [ longer-match ]
[ verbose ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
4
Task
Command
Remarks
Display IPv6 routes with
destination addresses in an IPv6
address range.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] ipv6-address1
prefix-length1 ipv6-address2
prefix-length2 [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display routing information
permitted by an IPv6 prefix list.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] ipv6-prefix
ipv6-prefix-name [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display routes of an IPv6 routing
protocol.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] protocol protocol
[ inactive | verbose ] [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Display IPv6 routing statistics.
display ipv6 routing-table [ vpn-instance
vpn-instance-name ] statistics [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Clear specified IPv6 routing
statistics.
reset ipv6 routing-table statistics protocol
[ vpn-instance vpn-instance-name ]
{ protocol | all }
Available in user view.
5
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 physical parameters for related interfaces.
•
Configure link-layer attributes for related interfaces.
•
Configure IP addresses for related interfaces.
Follow these guidelines when you configure a static route:
•
The next hop address of a static route cannot be the IP address of a local interface.
•
You can associate a track entry with a static route to monitor the reachability of the next hops. For
more information about Track, see High Availability Configuration Guide.
•
The device supports VPN instances for static routes. For information about specifying VPN instances
for static routes, see MPLS Configuration Guide.
To configure a static route:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Method 1:
ip route-static dest-address { mask | mask-length }
{ next-hop-address [ track track-entry-number ] |
interface-type interface-number [ next-hop-address ] |
vpn-instance d-vpn-instance-name next-hop-address
[ track track-entry-number ] } [ preference
preference-value ] [ tag tag-value ] [ permanent ]
[ description description-text ]
2.
3.
Configure a static
route.
Configure the
default preference
for static routes.
• Method 2:
ip route-static vpn-instance
s-vpn-instance-name&<1-6> dest-address { mask |
mask-length } { next-hop-address [ public ] [ track
track-entry-number ] | interface-type interface-number
[ next-hop-address ] | vpn-instance
d-vpn-instance-name next-hop-address [ track
track-entry-number ] } [ preference preference-value ]
[ tag tag-value ] [ permanent ] [ description
description-text ]
ip route-static default-preference default-preference-value
6
Use either method.
By default, no static
route is configured.
Optional.
60 by default.
Step
Command
Remarks
Optional.
4.
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
Bidirectional forwarding detection (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
Multiprotocol Label Switching (MPLS). For more information about BFD, see High Availability
Configuration Guide.
BFD control packet mode
To use BFD control packets for bidirectional detection between two devices, enable BFD control packet
mode on each device for the static route destined to the peer.
To configure a static route and enable BFD control packet mode for it, specify an outgoing interface and
a direct next hop, or specify an indirect next hop and a specific BFD packet source address for the static
route.
To configure a static route with BFD control packet mode enabled (direct next hop):
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Method 1:
2.
Configure a static
route and enable
BFD control packet
mode for it.
ip route-static dest-address { mask | mask-length }
interface-type interface-number next-hop-address bfd
control-packet [ preference preference-value ] [ tag
tag-value ] [ description description-text ]
• Method 2:
ip route-static vpn-instance s-vpn-instance-name&<1-6>
dest-address { mask | mask-length } interface-type
interface-number next-hop-address bfd control-packet
[ preference preference-value ] [ tag tag-value ] [ description
description-text ]
Use either
method.
Support for the
keyword
vpn-instance
depends on the
device model.
To configure a static route with BFD control packet mode enabled (indirect next hop):
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
7
Step
Command
Remarks
• Method 1:
2.
Configure a static
route and enable
BFD control packet
mode for it.
ip route-static dest-address { mask | mask-length }
next-hop-address bfd control-packet bfd-source ip-address
[ preference preference-value ] [ tag tag-value ] [ description
description-text ]
• Method 2:
ip route-static vpn-instance s-vpn-instance-name&<1-6>
dest-address { mask | mask-length } next-hop-address bfd
control-packet bfd-source ip-address [ preference
preference-value ] [ tag tag-value ] [ description
description-text ]
Use either
method.
BFD echo packet mode
With BFD echo packet mode enabled for a static route, the outgoing interface sends BFD echo packets
to the destination device, which loops the packets back to test the link reachability.
IMPORTANT:
• Enabling BFD for a flapping route could worsen the situation.
• Do not use BFD for a static route with the outgoing interface in spoofing state.
To configure BFD echo packet mode for static routes:
Step
1.
Enter system view.
2.
Configure the source
address of echo
packets.
Command
Remarks
system-view
N/A
Not configured by default.
bfd echo-source-ip ip-address
For more information about this
command, see High
Availability Command
Reference.
• Method 1:
3.
Enable BFD echo
packet mode for
static routes.
ip route-static dest-address { mask |
mask-length } interface-type
interface-number next-hop-address bfd
echo-packet [ preference preference-value ]
[ tag tag-value ] [ description
description-text ]
Use either method.
• Method 2:
ip route-static vpn-instance
s-vpn-instance-name&<1-6> dest-address
{ mask | mask-length } interface-type
interface-number next-hop-address bfd
echo-packet [ preference preference-value ]
[ tag tag-value ] [ description
description-text ]
8
Configuring static route FRR
NOTE:
Support for this feature depends on the device model.
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 for static route FRR
As shown in Figure 1, upon a link failure, FRR designates a backup next hop by using a routing policy for
routes matching the specified criteria. Packets are directed to the backup next hop to avoid traffic
interruption.
Configuration prerequisites
Create a routing policy to be referenced by FRR and use the apply fast-reroute backup-interface
command to specify a backup next hop in the routing policy. For more information about the command
and routing policy configurations, see "Configuring routing policies."
Configuration guidelines
•
FRR takes effect only for static routes that have both an outgoing interface and next hop.
•
Do not use FRR and BFD at the same time.
Configuration procedure
To configure static route FRR:
Step
Command
Remarks
system-view
N/A
1.
Enter system view.
2.
Configure the source address
of BFD echo packets.
bfd echo-source-ip ip-address
Configure static route FRR.
ip route-static [ vpn-instance
vpn-instance-name ] fast-reroute
route-policy route-policy-name
Not configured by default.
3.
9
For more information about this
command, see High Availability
Command Reference.
Not configured by default.
Support for the keyword
vpn-instance depends on the
device model.
Displaying and maintaining static routes
Task
Command
Remarks
Display information of static
routes.
display ip routing-table protocol static [ inactive |
verbose ] [ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Static route configuration examples
Basic static route configuration example
Network requirements
Configure static routes in Figure 2 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 Router A.
<RouterA> system-view
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two static routes on Router B.
<RouterB> system-view
[RouterB] ip route-static 1.1.2.0 255.255.255.0 1.1.4.1
[RouterB] ip route-static 1.1.3.0 255.255.255.0 1.1.5.6
# Configure a default route on Router C.
<RouterC> system-view
[RouterC] ip route-static 0.0.0.0 0.0.0.0 1.1.5.5
3.
Configure the hosts:
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,
respectively. (Details not shown.)
10
4.
Verify the configuration:
# Display the IP routing table of Router A.
[RouterA] display ip routing-table
Routing Tables: Public
Destinations : 7
Destination/Mask
Proto
0.0.0.0/0
1.1.2.0/24
Routes : 7
Pre
Cost
NextHop
Interface
Static 60
0
1.1.4.2
Eth1/2
Direct 0
0
1.1.2.3
Eth1/1
1.1.2.3/32
Direct 0
0
127.0.0.1
InLoop0
1.1.4.0/30
Direct 0
0
1.1.4.1
Eth1/2
1.1.4.1/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.1/32
Direct 0
0
127.0.0.1
InLoop0
Cost
NextHop
Interface
# Display the IP routing table of Router B.
[RouterB] display ip routing-table
Routing Tables: Public
Destinations : 10
Routes : 10
Destination/Mask
Proto
Pre
1.1.2.0/24
Static 60
0
1.1.4.1
Eth1/1
1.1.3.0/24
Static 60
0
1.1.5.6
Eth1/2
1.1.4.0/30
Direct 0
0
1.1.4.2
Eth1/1
1.1.4.2/32
Direct 0
0
127.0.0.1
InLoop0
1.1.5.0/30
Direct 0
0
1.1.5.5
Eth1/2
1.1.5.5/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.1/32
Direct 0
0
127.0.0.1
InLoop0
1.1.6.0/24
Direct 0
0
1.1.6.1
Eth1/3
1.1.6.1/32
Direct 0
0
127.0.0.1
InLoop0
# 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.
11
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
In Figure 3, configure a static route to subnet 120.1.1.0/24 on Router A, configure a static route to subnet
121.1.1.0/24 on Router B, and 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 Router C. When the link between Router A and Router B
through the Layer 2 switch fails, BFD can detect the failure immediately and inform Router A and Router
B to communicate through Router C.
Figure 3 Network diagram
121.1.1.0/24
120.1.1.0/24
Router A
L2 Switch
Router B
Eth1/1
Eth1/1
Eth1/2
Eth1/2
BFD
Eth1/1
Eth1/2
Router C
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth 1/1
12.1.1.1/24
Router B
Eth 1/1
12.1.1.2/24
Eth 1/2
10.1.1.102/24
Eth 1/2
13.1.1.1/24
Router C
Eth 1/1
10.1.1.100/24
Eth 1/2
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 Router A and enable BFD control packet mode for the static route
through the Layer 2 switch.
<RouterA> system-view
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] bfd min-transmit-interval 500
[RouterA-Ethernet1/1] bfd min-receive-interval 500
[RouterA-Ethernet1/1] bfd detect-multiplier 9
[RouterA-Ethernet1/1] quit
[RouterA] ip route-static 120.1.1.0 24 ethernet 1/1 12.1.1.2 bfd control-packet
12
[RouterA] ip route-static 120.1.1.0 24 ethernet 1/2 10.1.1.100 preference 65
[RouterA] quit
# Configure static routes on Router B and enable BFD control packet mode for the static route
through the Layer 2 switch.
<RouterB> system-view
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] bfd min-transmit-interval 500
[RouterB-Ethernet1/1] bfd min-receive-interval 500
[RouterB-Ethernet1/1] bfd detect-multiplier 9
[RouterB-Ethernet1/1] quit
[RouterB] ip route-static 121.1.1.0 24 ethernet 1/1 12.1.1.1 bfd control-packet
[RouterB] ip route-static 121.1.1.0 24 ethernet 1/2 13.1.1.2 preference 65
[RouterB] quit
# Configure static routes on Router C.
<RouterC> system-view
[RouterC] ip route-static 120.1.1.0 24 ethernet 1/2 13.1.1.1
[RouterC] ip route-static 121.1.1.0 24 ethernet 1/1 10.1.1.102
3.
Verify the configuration:
# Display BFD sessions on Router A.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
LD/RD
SourceAddr
DestAddr
State Holdtime Interface
4/7
12.1.1.1
12.1.1.2
Up
2000ms
Ethernet1/1
The output shows that the BFD session has been created.
# Display static routes on Router A. The static route to Router B through the Layer 2 switch is
displayed in the output.
<RouterA> display ip routing-table protocol static
Public Routing Table : Static
Summary Count : 2
Static Routing table Status : <Active>
Summary Count : 1
Destination/Mask
Proto
Pre
120.1.1.0/24
Static 60
Cost
NextHop
Interface
0
12.1.1.2
Eth1/1
Cost
NextHop
Interface
0
10.1.1.100
Eth1/2
Direct Routing table Status : <Inactive>
Summary Count : 1
Destination/Mask
Proto
Pre
120.1.1.0/24
Static 65
# Enable BFD debugging. When the link between Router A and the switch fails, Router A can
detect the failure.
13
<RouterA> debugging bfd event
<RouterA> debugging bfd scm
<RouterA> terminal debugging
%Jul 27 10:18:18:672 2007 RouterA BFD/4/LOG:Sess[12.1.1.1/12.1.1.2,
Ethernet1/1,Ctrl], Sta: UP->DOWN, Diag: 1
*Jul 27 10:18:18:672 2007 RouterA BFD/7/EVENT:Send sess-down Msg,
[Src:12.1.1.1,Dst:12.1.1.2,Ethernet1/1,Ctrl], instance:0, protocol:STATIC
*Jul 27 10:18:19:172 2007 RouterA BFD/7/EVENT:Receive Delete-sess,
[Src:12.1.1.1,Dst:12.1.1.2,Ethernet1/1,Ctrl], Direct, Instance:0x0, Proto:STATIC
*Jul 27 10:18:19:172 2007 RouterA BFD/7/EVENT:Notify driver to stop receiving bf
# Display the static route information again. Router A communicates with Router B over the static
route passing Router C now.
<RouterA> display ip routing-table protocol static
Public Routing Table : Static
Summary Count : 2
Static Routing table Status : <Active>
Summary Count : 1
Destination/Mask
Proto
Pre
120.1.1.0/24
Static 65
Cost
NextHop
Interface
0
10.1.1.100
Eth1/2
Cost
NextHop
Interface
0
12.1.1.2
Eth1/1
Static Routing table Status : < Inactive>
Summary Count : 1
Destination/Mask
Proto
Pre
120.1.1.0/24
Static 60
BFD for static routes configuration example (indirect next hop)
Network requirements
In Figure 4, Router A has a route to interface Loopback 1 (2.2.2.9/32) on Router B, with the outgoing
interface Ethernet 1/1. Router B has a route to interface Loopback 1 (1.1.1.9/32) on Router A, with the
outgoing interface Ethernet 1/1. Router D has a route to 1.1.1.9/32, with the outgoing interface Ethernet
1/1, and a route to 2.2.2.9/32, with the outgoing interface Ethernet 1/2.
Configure a static route to subnet 120.1.1.0/24 on Router A, configure a static route to subnet
121.1.1.0/24 on Router B, and 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 Router C and Router D. When the link between Router
A and Router B through Router D fails, BFD can detect the failure immediately and Router A and Router
B can communicate through Router C.
14
Figure 4 Network diagram
121.1.1.0/24
Loop1
2.2.2.9/32
Loop1
1.1.1.9/32
120.1.1.0/24
Router D
Eth1/1
Eth1/1
/2
h1
Et
Router A
Eth1/2
Et
h1
/2
Eth1/1
BFD
Eth1/1
Router B
Eth1/2
Router C
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth1/1
12.1.1.1/24
Router B
Eth1/1
11.1.1.2/24
Eth1/2
10.1.1.102/24
Eth1/2
13.1.1.1/24
Loop1
1.1.1.9/32
Loop1
2.2.2.9/32
Eth1/1
10.1.1.100/24
Eth1/1
12.1.1.2/24
Eth1/2
13.1.1.2/24
Eth1/2
11.1.1.1/24
Router C
Router D
Configuration procedure
1.
Configure IP addresses for the interfaces. (Details not shown.)
2.
Configure static routes and BFD:
# Configure static routes on Router A and enable BFD control packet mode for the static route
through Router D.
<RouterA> system-view
[RouterA] interface loopback 1
[RouterA-LoopBack1] bfd min-transmit-interval 500
[RouterA-LoopBack1] bfd min-receive-interval 500
[RouterA-LoopBack1] bfd detect-multiplier 9
[RouterA-LoopBack1] quit
[RouterA] ip route-static 120.1.1.0 24 2.2.2.9 bfd control-packet bfd-source 1.1.1.9
[RouterA] ip route-static 120.1.1.0 24 ethernet 1/2 10.1.1.100 preference 65
[RouterA] quit
# Configure static routes on Router B and enable BFD control packet mode for the static route
through Router D.
<RouterB> system-view
[RouterB] interface loopback 1
[RouterB-LoopBack1] bfd min-transmit-interval 500
[RouterB-LoopBack1] bfd min-receive-interval 500
[RouterB-LoopBack1] bfd detect-multiplier 9
[RouterB-LoopBack1] quit
[RouterB] ip route-static 121.1.1.0 24 1.1.1.9 bfd control-packet bfd-source 2.2.2.9
[RouterB] ip route-static 121.1.1.0 24 ethernet 1/2 13.1.1.2 preference 65
[RouterB] quit
# Configure static routes on Router C.
<RouterC> system-view
[RouterC] ip route-static 120.1.1.0 24 ethernet 1/2 13.1.1.1
15
[RouterC] ip route-static 121.1.1.0 24 ethernet 1/1 10.1.1.102
# Configure static routes on Router D.
<RouterD> system-view
[RouterD] ip route-static 120.1.1.0 24 ethernet 1/2 11.1.1.2
[RouterD] ip route-static 121.1.1.0 24 ethernet 1/1 12.1.1.1
3.
Verify the configuration:
The following operations are performed on Router A. The operations on Router B are similar.
# Display the BFD session information.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
LD/RD
SourceAddr
DestAddr
State Holdtime Interface
4/7
1.1.1.9
2.2.2.9
Up
2000ms
Loop1
# Display the static route information. The static route to Router B through Router D is displayed in
the output.
<RouterA> display ip routing-table protocol static
Public Routing Table : Static
Summary Count : 2
Static Routing table Status : <Active>
Summary Count : 1
Destination/Mask
Proto
Pre
120.1.1.0/24
Static 60
Cost
NextHop
Interface
0
2.2.2.9
Eth1/1
Cost
NextHop
Interface
0
10.1.1.100
Eth1/2
Static Routing table Status : <Inactive>
Summary Count : 1
Destination/Mask
Proto
120.1.1.0/24
Static 65
Pre
# Enable BFD debugging. When the link between Router A and Router D fails, Router A can detect
the failure.
<RouterA> debugging bfd event
<RouterA> debugging bfd scm
<RouterA> terminal debugging
%Oct 10 10:18:18:672 2010 RouterA BFD/4/LOG:Sess[1.1.1.9/2.2.2.9, Loop1,Ctrl], Sta:
UP->DOWN, Diag: 1
*Oct 10 10:18:18:672 2010 RouterA BFD/7/EVENT:Send sess-down Msg,
[Src:1.1.1.9,Dst:2.2.2.9,Loop1,Ctrl], instance:0, protocol:STATIC
# Display the static route information again. Router A communicates with Router B over the static
route passing Router C now.
<RouterA> display ip routing-table protocol static
Public Routing Table : Static
Summary Count : 2
16
Static Routing table Status : <Active>
Summary Count : 1
Destination/Mask
Proto
120.1.1.0/24
Static 65
Pre
Cost
NextHop
Interface
0
10.1.1.100
Eth1/2
Cost
NextHop
Interface
0
2.2.2.9
Static Routing table Status : <Inactive>
Summary Count : 1
Destination/Mask
Proto
120.1.1.0/24
Static 60
Pre
17
Configuring a default route
A default route is used to forward packets that match no entry in the routing table.
Without a default route, a packet that does not match any routing entries is 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, RIP, and IS-IS, can generate a default route. For
example, an upstream router running OSPF can generate a default route and advertise it to other
routers, which install the default route with the next hop being the upstream router. For more
information, see the chapters on these routing protocols.
18
Configuring RIP
Routing Information Protocol (RIP) is a distance-vector simple interior gateway protocol suited to
small-sized networks. It employs UDP to exchange route information through port 520.
Overview
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 metric range from 0 to 15. A destination of 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 every time the routing entry
is updated.
•
Route tag—Used for control routes. For more information, see "Configuring routing policies."
RIP timers
RIP uses the following 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 the duration 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 update
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.
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 loopings.
19
•
Split horizon—Disables RIP from sending routing information on the interface from which the
information was 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
back these routes to the neighbor so the neighbor can delete such information from its routing table
to prevent routing loops.
•
Triggered updates—RIP immediately advertises triggered updates for topology changes to reduce
the possibility of routing loops and to speed up convergence.
RIP operation
RIP works as follows:
1.
RIP sends request messages to neighboring routers. Neighboring routers return response
messages containing 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 through broadcast only. 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 non-contiguous 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 simple 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 the RIPv2 broadcast mode can also
receive RIPv1 messages.
TRIP
Triggered RIP (TRIP), a RIP extension for WANs, is mainly used in dial-up networks.
Working mechanism
Routing information is sent in triggered updates rather than in periodic broadcasts to reduce route
management cost on WANs.
•
A routing update message is sent when data in the routing table changes or the next hop is
unreachable.
20
•
Because the periodic update delivery is canceled, an acknowledgement and retransmission
mechanism is required to guarantee successful updates transmission on WANs.
Message types
RIP uses the following new types of message which are identified by the value of the command field:
•
Update request (Type-9)—Requests the needed routes from the neighbor.
•
Update response (Type-10)—Contains the routes requested by the neighbor.
•
Update Acknowledge (Type-11)—Acknowledges received update responses.
TRIP retransmission mechanism
•
If the router receives no update responses within a specified interval after sending an update
request, it sends the request again. If the router still receives no update response after the upper limit
for sending requests is reached, it considers the neighbor unreachable.
•
If the router receives no update acknowledge within a specified interval after sending an update
response, it sends the update response again. If the router still receives no update acknowledge
after the upper limit for sending update responses is reached, it considers the neighbor
unreachable.
Supported RIP features
The current implementation supports the following RIP features:
•
RIPv1 and RIPv2
•
RIP support for multi-VPN-instance
RIP can serve as the IGP running between CE and PE on a BGP/MPLS VPN network. For related
information, see MPLS Configuration Guide.
•
TRIP
•
BFD
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. This detection mechanism is not fast enough. To speed
up convergence, enable BFD for RIP.
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 2091, Triggered Extensions to RIP to Support Demand Circuits
•
RFC 2453, RIP Version 2
21
RIP configuration task list
Task
Remarks
Configuring basic RIP
Required.
Configuring RIP route
control
Tuning and optimizing
RIP networks
Configuring BFD for RIP
Configuring an additional routing metric
Optional.
Configuring RIPv2 route summarization
Optional.
Disabling host route reception
Optional.
Advertising a default route
Optional.
Configuring received/redistributed route filtering
Optional.
Configuring a preference for RIP
Optional.
Configuring RIP route redistribution
Optional.
Configuring RIP timers
Optional.
Configuring split horizon and poison reverse
Optional.
Configuring the maximum number of ECMP routes
Optional.
Enabling zero field check on incoming RIPv1
messages
Optional.
Enabling source IP address check on incoming RIP
updates
Optional.
Configuring RIPv2 message authentication
Optional.
Specifying a RIP neighbor
Optional.
Configuring TRIP
Optional.
Configuring RIP-to-MIB binding
Optional.
Configuring the RIP packet sending rate
Optional.
Enabling single-hop echo detection (for a directly
connected RIP neighbor)
Optional.
Enabling single-hop detection in BFD echo packet
(for a specific destination)
Optional.
Enabling bidirectional control detection
Optional.
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
Perform this task to create a RIP process and enable the RIP process on the interface attached to the
specified network. An interface that is not on the specified network does not run RIP.
22
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.
To enable RIP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable a RIP process and
enter RIP view.
rip [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Enable RIP on the interface
attached to the specified
network.
network network-address
By default, RIP is disabled on
interfaces.
Configuring the interface behavior
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 the specified interface
from sending routing updates
(the interfaces can still receive
updates).
silent-interface { interface-type
interface-number | all }
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Enable the interface to receive
RIP messages.
rip input
Enable the interface to send
RIP messages.
rip output
7.
Optional.
All interfaces can send routing
updates by default.
Optional.
Enabled by default.
Optional.
Enabled by default.
Configuring a RIP version
You can configure a RIP version in RIP or interface view.
•
If neither global nor interface RIP version is configured, the interface sends RIPv1 broadcasts and
can receive the following packets: RIPv1 broadcast, RIPv1 unicast, RIPv2 broadcast, RIPv2 multicast,
and RIPv2 unicast.
•
If an interface has no RIP version configured, it uses the global RIP version; otherwise it uses the RIP
version configured on it.
With RIPv1 configured, an interface sends RIPv1 broadcasts, and can receive RIPv1 broadcasts and
RIPv1 unicasts.
With RIPv2 configured, a multicast interface sends RIPv2 multicasts and can receive RIPv2 unicasts,
broadcasts, and multicasts.
23
With RIPv2 configured, a broadcast interface sends RIPv2 broadcasts and can receive RIPv1 unicasts,
and broadcasts, and 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
Optional.
By default, if an interface has an
interface-specific RIP version, the
version takes precedence over the
global one. If no interface-specific
RIP version is specified, the
interface can send RIPv1
broadcasts, and receive RIPv1
broadcasts and unicasts, and
RIPv2 broadcasts, multicasts, and
unicasts.
3.
Specify a global RIP version.
version { 1 | 2 }
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
Optional.
6.
Specify a RIP version for the
interface.
rip version { 1 | 2 [ broadcast |
multicast ] }
By default, if an interface has no
RIP version specified, the global
version takes effect. If no global RIP
version is specified, the interface
can send RIPv1 broadcasts, and
receive RIPv1 broadcasts and
unicasts, and RIPv2 broadcasts,
multicasts, and unicasts.
Configuring RIP route control
Before you configure RIP routing feature, 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 becomes 16.
24
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
Optional.
Specify an outbound
additional routing metric.
rip metricout [ route-policy
route-policy-name ] value
Optional.
4.
The default setting is 0.
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
Optional.
3.
Enable RIPv2 automatic route
summarization.
By default, RIPv2 automatic route
summarization is enabled.
summary
If the 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 Ethernet 1/1 to advertise the summary
route instead of the more specific routes.
To configure a summary route:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
25
Step
Command
Remarks
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 | mask-length }
N/A
Disabling host route reception
Perform this task to disable RIPv2 from receiving host routes from the same network and 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 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 ]
Optional.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
26
Not enabled by default.
Step
Command
Remarks
Optional.
6.
Configure the RIP interface to
advertise a default route.
rip default-route { { only |
originate } [ cost cost ] |
no-originate }
By default, a RIP interface can
advertise a default route if the RIP
process is configured with default
route advertisement.
NOTE:
The router enabled to advertise a default route does not receive default routes from RIP neighbors.
Configuring received/redistributed route filtering
Perform this task to filter received and redistributed routes by using an ACL or IP prefix list. You can also
configure RIP to receive routes only from a specified neighbor.
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
Configure the filtering of
received routes.
filter-policy { acl-number |
gateway ip-prefix-name | ip-prefix
ip-prefix-name [ gateway
ip-prefix-name ] } import
[ interface-type interface-number ]
3.
4.
Configure the filtering of
redistributed routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } export
[ protocol [ process-id ] |
interface-type interface-number ]
By default, the filtering of received
routes is not configured.
The filter-policy import command
filters received routes. Filtered
routes are not installed into the
routing table or advertised to
neighbors.
By default, the filtering of
redistributed routes is not
configured.
The filter-policy export command
filters redistributed routes,
including routes redistributed with
the import-route command.
Configuring 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 configure a preference for RIP. The smaller the
preference value, the higher the priority.
To configure 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
27
Step
Configure a preference for
RIP.
3.
Command
Remarks
preference [ route-policy
route-policy-name ] value
Optional.
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 routes. Only active routes can be redistributed. To display active routes, use the
display ip routing-table protocol command.
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.
Configure a default metric for
redistributed routes.
default cost value
Redistribute routes from other
routing protocols.
import-route protocol [ process-id
| all-processes | allow-ibgp ] [ cost
cost | route-policy
route-policy-name | tag tag ] *
4.
Optional.
The default setting is 0.
By default, route redistribution is
disabled.
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.
Configuring RIP timers
You can change the RIP network convergence speed by adjusting RIP timers. Based on network
performance, configure identical RIP timer settings to avoid unnecessary traffic or route flapping.
To configure 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
28
Step
Command
Remarks
Optional.
By default:
3.
Configure RIP timers.
timers { garbage-collect
garbage-collect-value | suppress
suppress-value | timeout
timeout-value | update
update-value } *
• The update timer is 30 seconds.
• The timeout timer is 180
seconds.
• The suppress timer is 120
seconds.
• The garbage-collect timer is
120 seconds.
Configuring 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.
On NBMA networks such as FR and X.25 where multiple VCs are configured on the primary and
secondary interfaces, disable split horizon to ensure correct route advertisement. For more information,
see Layer 2—WAN Configuration Guide.
Disabling split horizon on point-to-point links does not take effect.
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
Optional.
By default, split horizon is enabled.
Enabling poison reverse
Poison reverse allows RIP to send routes through the interface where the routes were learned, but 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.
29
Configuring the maximum number of ECMP routes
Perform this task to implement load sharing over ECMP routes.
To configure the maximum number of 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.
Configure the maximum
number of ECMP routes.
Optional.
maximum load-balancing number
By default, the maximum number is
8.
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, RIPv1 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
Optional.
By default, this function 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 serial interface, RIP checks whether the source address of the message
is the IP address of the peer interface. If not, RIP discards the message.
IMPORTANT:
Disable the source IP address check feature if the RIP neighbor is not directly connected.
To enable source IP address check on incoming RIP updates:
30
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
Optional.
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
1.
Enter system view.
system-view
2.
Enter interface view.
interface interface-type interface-number
3.
Configure RIPv2 authentication.
rip authentication-mode { md5 { rfc2082 [ cipher ] key-string
key-id | rfc2453 [ cipher ] key-string } | simple [ cipher ]
password }
Specifying a RIP neighbor
Usually, RIP sends messages to broadcast or multicast addresses. On non-broadcast or multicast links,
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 the unicast and multicast (or broadcast) of the same routing
information.
•
If a 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
N/A
4.
Disable source address check
on incoming RIP updates.
undo validate-source-address
By default, this function is not
disabled.
31
Configuring TRIP
In a connection oriented network, a router can establish connections to multiple remote devices. In a
WAN, links are created and removed as needed. In such applications, a link created between two
nodes for data transmission is temporary and infrequently.
TRIP should be enabled when it is necessary to exchange routing information through on-demand links
or triggered RIP.
If RIP is disabled, TRIP is also disabled.
Enabling TRIP
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable RIP.
rip [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Return to system view.
quit
N/A
4.
Enter interface view.
interface interface-type
interface-number
N/A
5.
Enable TRIP.
rip triggered
By default, TRIP is disabled.
Configuring TRIP retransmission parameters
You can specify the interval and count for retransmitting a request or response as needed. The maximum
retransmission interval (count × interval) for a packet cannot be so long that the router still resends the
packet when its neighbor is down.
For two routers on an analog dial-up link, the difference between retransmission intervals on the two ends
must be greater than 50 seconds. Otherwise, they cannot become TRIP neighbors.
To configure TRIP retransmission parameters:
Step
Command
Remarks
1.
Enter system view
system-view
N/A
2.
Enable RIP and enter its view.
rip [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Configure the interval for
retransmitting an update
request or update response.
trip retransmit timer
retransmit-time-value
The default interval is 5 seconds.
Configure the maximum count
for retransmitting an update
request or update response.
trip retransmit count
retransmit-count-value
4.
Optional.
The default is 36.
Configuring RIP-to-MIB binding
This task allows you to enable a specific RIP process to receive SNMP requests.
To bind RIP to MIB:
32
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Bind RIP to MIB.
rip mib-binding process-id
Optional.
By default, MIB is bound to RIP
process 1.
Configuring the RIP packet sending rate
Perform this task to specify 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.
Specify the interval for
sending RIP packets and the
maximum number of RIP
packets that can be sent at
each interval.
Optional.
output-delay time count count
By default, an interface sends up to
three RIP packets every 20
milliseconds.
Configuring BFD for RIP
BFD for RIP provides the following link detection modes:
•
Single-hop echo detection mode for a directly-connected RIP neighbors. In this mode, a BFD session
is established only when the 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 only when the RIP-enabled interface is up.
•
Bidirectional control detection mode for an indirectly-connected 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.
For more information about BFD, see High Availability Configuration Guide.
Enabling 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, no source IP address is
configured for BFD echo packets.
33
Step
3.
Enter interface view.
Command
Remarks
interface interface-type
interface-number
N/A
By default, BFD for RIP is disabled.
4.
Enable BFD for RIP.
rip bfd enable
This command and the rip bfd
enable destination command are
mutually exclusive and cannot be
configured on a device at the same
time.
Enabling single-hop detection in BFD echo packet (for a
specific destination)
Configure this feature when the peer device does not support BFD. When a unidirectional link occurs
between the local device and a specific neighbor, BFD can detect the failure and the local device does
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.
To configure BFD for RIP (single-hop echo detection for specific 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, no source IP address is
configured for BFD echo packets.
3.
Enter interface view.
interface interface-type
interface-number
N/A
By default, BFD for RIP is disabled.
4.
Enable BFD for RIP.
rip bfd enable destination
ip-address
This command and the rip bfd enable
command are mutually exclusive and
cannot be configured on a device at
the same time.
Enabling bidirectional control detection
This feature only works for RIP neighbors that are directly connected (one hop away from each other).
To configure BFD for RIP (bidirectional control detection):
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIP process and
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.
34
Step
Command
Remarks
4.
Enter interface view.
interface interface-type
interface-number
N/A
5.
Enable BFD on the RIP
interface.
rip bfd enable
Disabled by default.
NOTE:
Because the undo peer command does not remove the neighbor relationship at once, executing the
command cannot bring down the BFD session at once.
Displaying and maintaining RIP
Task
Command
Remarks
Display RIP current status and
configuration information.
display rip [ process-id |
vpn-instance vpn-instance-name ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display all active routes in RIP
database.
display rip process-id database [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display RIP interface information.
display rip process-id interface
[ interface-type interface-number ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display routing information about
a specified RIP process.
display rip process-id route
[ ip-address { mask | mask-length }
| peer ip-address | statistics ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Reset a RIP process.
reset rip process-id process
Available in user view.
Clear the statistics of a RIP process.
reset rip process-id statistics
Available in user view.
RIP configuration examples
Configuring RIP version
Network requirements
As shown in Figure 5, enable RIPv2 on all interfaces on Router A and Router B.
35
Figure 5 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic RIP:
# Configure Router A.
<RouterA> system-view
[RouterA] rip
[RouterA-rip-1] network 1.0.0.0
[RouterA-rip-1] network 2.0.0.0
[RouterA-rip-1] network 3.0.0.0
[RouterA-rip-1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] rip
[RouterB-rip-1] network 1.0.0.0
[RouterB-rip-1] network 10.0.0.0
[RouterB-rip-1] quit
# Display the RIP routing table on Router A.
[RouterA] display rip 1 route
Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
---------------------------------------------------------------------------Peer 1.1.1.2
on Ethernet1/1
Destination/Mask
10.0.0.0/8
Nexthop
1.1.1.2
Cost
1
Tag
0
Flags
RA
Sec
9
The output shows that RIPv1 uses natural masks to advertise routing information.
3.
Configure a RIP version:
# Configure RIPv2 on Router A.
[RouterA] rip
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
[RouterA-rip-1] quit
# Configure RIPv2 on Router B.
[RouterB] rip
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
# Display the RIP routing table on Router A.
[RouterA] display rip 1 route
Route Flags: R - RIP, T - TRIP
36
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
---------------------------------------------------------------------------Peer 1.1.1.2
on Ethernet1/1
Destination/Mask
Nexthop
Cost
Tag
Flags
Sec
10.0.0.0/8
1.1.1.2
1
0
RA
87
10.1.1.0/24
1.1.1.2
1
0
RA
19
10.2.1.0/24
1.1.1.2
1
0
RA
19
The output shows that RIPv2 uses classless subnet mask.
NOTE:
After RIPv2 is configured, RIPv1 routes might still exist in the routing table until they are aged out.
Configuring RIP route redistribution
Network requirements
As shown in Figure 6, Router B communicates with Router A through RIP 100 and with Router C through
RIP 200.
Configure RIP 200 to redistribute direct routes and routes from RIP 100 on Router B so Router C can learn
routes destined for 10.2.1.0/24 and 11.1.1.0/24. Router A cannot learn routes destined for 12.3.1.0/24
and 16.4.1.0/24.
Configure Router B to not advertise route 10.2.1.1/24 to Router C.
Figure 6 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic RIP basic functions:
# Enable RIP 100, and configure a RIPv2 on Router A.
<RouterA> system-view
[RouterA] rip 100
[RouterA-rip-100] network 10.0.0.0
[RouterA-rip-100] network 11.0.0.0
[RouterA-rip-100] version 2
[RouterA-rip-100] undo summary
[RouterA-rip-100] quit
# Enable RIP 100 and RIP 200, configure RIPv2 on Router B.
<RouterB> system-view
[RouterB] rip 100
[RouterB-rip-100] network 11.0.0.0
[RouterB-rip-100] version 2
37
[RouterB-rip-100] undo summary
[RouterB-rip-100] quit
[RouterB] rip 200
[RouterB-rip-200] network 12.0.0.0
[RouterB-rip-200] version 2
[RouterB-rip-200] undo summary
[RouterB-rip-200] quit
# Enable RIP 200 and configure RIPv2 on Router C.
<RouterC> system-view
[RouterC] rip 200
[RouterC-rip-200] network 12.0.0.0
[RouterC-rip-200] network 16.0.0.0
[RouterC-rip-200] version 2
[RouterC-rip-200] undo summary
[RouterC-rip-200] quit
# Display the routing table on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 6
3.
Routes : 6
Destination/Mask
Proto
Cost
NextHop
Interface
12.3.1.0/24
Direct 0
Pre
0
12.3.1.2
Eth1/1
12.3.1.2/32
Direct 0
0
127.0.0.1
InLoop0
16.4.1.0/24
Direct 0
0
16.4.1.1
Eth1/2
16.4.1.1/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.1/32
Direct 0
0
127.0.0.1
InLoop0
Configure RIP route redistribution:
# Configure RIP 200 to redistribute direct routes and routes from RIP 100 on Router B.
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
[RouterB-rip-200] import-route direct
[RouterB-rip-200] quit
# Display the routing table of Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 8
4.
Routes : 8
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.2.1.0/24
RIP
100
1
12.3.1.1
Eth1/1
11.1.1.0/24
RIP
100
1
12.3.1.1
Eth1/1
12.3.1.0/24
Direct 0
0
12.3.1.2
Eth1/1
12.3.1.2/32
Direct 0
0
127.0.0.1
InLoop0
16.4.1.0/24
Direct 0
0
16.4.1.1
Eth1/2
16.4.1.1/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.1/32
Direct 0
0
127.0.0.1
InLoop0
Configure a filtering policy for redistributed routes:
38
# On Router B, define ACL 2000 and reference it to a filtering policy to filter routes redistributed
from RIP 100, making the route not advertised to Router C.
[RouterB] acl number 2000
[RouterB-acl-basic-2000] rule deny source 10.2.1.1 0.0.0.255
[RouterB-acl-basic-2000] rule permit
[RouterB-acl-basic-2000] quit
[RouterB] rip 200
[RouterB-rip-200] filter-policy 2000 export rip 100
# Display the routing table on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 7
Routes : 7
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
11.1.1.0/24
RIP
100
1
12.3.1.1
Eth1/1
12.3.1.0/24
Direct 0
0
12.3.1.2
Eth1/1
12.3.1.2/32
Direct 0
0
127.0.0.1
InLoop0
16.4.1.0/24
Direct 0
0
16.4.1.1
Eth1/2
16.4.1.1/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.1/32
Direct 0
0
127.0.0.1
InLoop0
Configuring an additional metric for a RIP interface
Network requirements
As shown in Figure 7, run RIPv2 is enabled on all the interfaces of Router A, Router B, Router C, Router
D, and Router E.
Router A has two links to Router D. The link from Router B to Router D is more stable than that from Router
C to Router D. Configure an additional metric for RIP routes received from Ethernet 1/2 on Router A so
Router A prefers route 1.1.5.0/24 learned from Router B.
Figure 7 Network diagram
Configuration procedure
1.
Configure IP addresses for the interfaces. (Details not shown.)
2.
Configure basic RIP:
# Configure Router A.
<RouterA> system-view
[RouterA] rip
39
[RouterA-rip-1] network 1.0.0.0
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
[RouterA-rip-1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] rip
[RouterB-rip-1] network 1.0.0.0
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
# Configure Router C.
<RouterC> system-view
[RouterB] rip
[RouterC-rip-1] network 1.0.0.0
[RouterC-rip-1] version 2
[RouterC-rip-1] undo summary
# Configure Router D.
<RouterD> system-view
[RouterD] rip
[RouterD-rip-1] network 1.0.0.0
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
# Configure Router E.
<RouterE> system-view
[RouterE] rip
[RouterE-rip-1] network 1.0.0.0
[RouterE-rip-1] version 2
[RouterE-rip-1] undo summary
# Display the IP routing table on Router A.
[RouterA] display rip 1 database
1.0.0.0/8, cost 0, ClassfulSumm
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 that two RIP routes can reach network 1.1.5.0/24. Their next hops are Router B
(1.1.1.2) and Router C (1.1.2.2), respectively, with the same cost of 2. Router C is the next hop
router to reach network 1.1.4.0/24, with a cost of 1.
3.
Configure an additional metric for the RIP interface:
# Configure an additional metric of 3 for Ethernet 1/2 on Router A.
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] rip metricin 3
[RouterA-Ethernet1/2] display rip 1 database
1.0.0.0/8, cost 0, ClassfulSumm
1.1.1.0/24, cost 0, nexthop 1.1.1.1, Rip-interface
40
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 Router
B (1.1.1.2) and a cost of 2.
Configuring RIP to advertise a summary route
Network requirements
As shown in Figure 8, Router A and Router B run OSPF; Router D runs RIP; and Router C runs OSPF and
RIP. Configure RIP to redistribute OSPF routes on Router C so Router 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 Router D, configure route summarization on Router C to advertise only
the summary route 10.0.0.0/8 to Router D.
Figure 8 Network diagram
Eth1/1
10.1.1.1/24
Eth1/2
10.6.1.2/24
Router B
Eth1/3
OSPF
10.1.1.2/24
Eth1/2
Eth1/1
Eth1/2
10.5.1.2/24
10.2.1.2/24
11.3.1.1/24
Eth1/1
10.2.1.1/24
Router C
RIP
Eth1/2
11.4.1.2/24
Router A
Eth1/1
11.3.1.2/24
Router D
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic OSPF:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.5.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] network 10.6.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
# Configure Router C.
41
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
3.
Configure basic RIP:
# Configure Router C.
[RouterC] rip 1
[RouterC-rip-1] network 11.3.1.0
[RouterC-rip-1] version 2
[RouterC-rip-1] undo summary
# Configure Router D.
<RouterD> system-view
[RouterD] rip 1
[RouterD-rip-1] network 11.0.0.0
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
[RouterD-rip-1] quit
# Configure RIP to redistribute the routes from OSPF process 1 and direct routes on Router C.
[RouterC-rip-1] import-route direct
[RouterC-rip-1] import-route ospf 1
[RouterC-rip-1] quit
# Display the IP routing table on Router D.
[RouterD] display ip routing-table
Routing Tables: Public
Destinations : 10
4.
Routes : 10
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.1.1.0/24
RIP
100
1
11.3.1.1
Eth1/1
10.2.1.0/24
RIP
100
1
11.3.1.1
Eth1/1
10.5.1.0/24
RIP
100
1
11.3.1.1
Eth1/1
10.6.1.0/24
RIP
100
1
11.3.1.1
Eth1/1
11.3.1.0/24
Direct 0
0
11.3.1.2
Eth1/1
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
Eth1/2
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.1/32
Direct 0
0
127.0.0.1
InLoop0
Configure route summarization on Router C to advertise only the summary route 10.0.0.0/8:
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] rip summary-address 10.0.0.0 8
# Display the IP routing table on Router D.
[RouterD] display ip routing-table
Routing Tables: Public
42
Destinations : 7
Routes : 7
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.0.0.0/8
RIP
100
1
11.3.1.1
Eth1/1
11.3.1.0/24
Direct 0
0
11.3.1.2
Eth1/1
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
Eth1/2
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.1/32
Direct 0
0
127.0.0.1
InLoop0
Configuring BFD for RIP (single-hop echo detection for a
directly connected RIP neighbor)
Network requirements
As shown in Figure 9, Ethernet 1/1 of Router A and Router C runs RIP process 1. Ethernet 1/2 of Router
A runs RIP process 2. Ethernet 1/2 on Router C and Ethernet 1/1 and Ethernet 1/2 on Router B run RIP
process 1.
Configure a static route destined for 100.1.1.1/24 and enable static route redistribution into RIP on Router
C so Router A can learn two routes destined for 100.1.1.1/24 through Ethernet 1/1 and Ethernet 1/2,
respectively, and uses the one through Ethernet 1/1.
Enable BFD for RIP on Ethernet 1/1 of Router A. When the link over Ethernet 1/1 fails, BFD can quickly
detect the link failure and notify it to RIP so RIP deletes the neighbor relationship and the route information
learned on Ethernet 1/1, and uses the route destined for 100.1.1.1 24 through Ethernet 1/2.
Figure 9 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic RIP and enable BFD on the interfaces:
# Configure Router A.
<RouterA> system-view
[RouterA] rip 1
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
43
[RouterA-rip-1] network 192.168.1.0
[RouterA-rip-1] quit
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] rip bfd enable
[RouterA-Ethernet1/1] quit
[RouterA] rip 2
[RouterA-rip-2] network 192.168.2.0
[RouterA-rip-2] quit
# Configure Router B.
<RouterB> system-view
[RouterB] rip 1
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
[RouterB-rip-1] network 192.168.2.0
[RouterB-rip-1] network 192.168.3.0
[RouterB-rip-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] rip 1
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
[RouterC-rip-1] network 192.168.1.0
[RouterC-rip-1] network 192.168.3.0
[RouterC-rip-1] import-route static
[RouterC-rip-1] quit
3.
Configure the BFD parameters on Ethernet 1/1 of Router A:
[RouterA] bfd session init-mode active
[RouterA] bfd echo-source-ip 11.11.11.11
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] bfd min-transmit-interval 500
[RouterA-Ethernet1/1] bfd min-receive-interval 500
[RouterA-Ethernet1/1] bfd detect-multiplier 7
[RouterA-Ethernet1/1] return
4.
Configure a static route on Router C:
[RouterC] ip route-static 100.1.1.1 24 null 0
5.
Verify the configuration:
# Display the BFD session information of Router A.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Echo Mode:
LD
SourceAddr
DestAddr
State
Holdtime
Interface
3
192.168.1.1
192.168.1.2
Up
2000ms
Eth1/1
# Display RIP routes destined for 100.1.1.0/24 on Router A.
<RouterA> display ip routing-table 100.1.1.0 24 verbose
Routing Table : Public
Summary Count : 2
Destination: 100.1.1.0/24
44
Protocol: RIP
Process ID: 1
Preference: 100
Cost: 1
IpPrecedence:
QosLcId:
NextHop: 192.168.1.2
BkNextHop: 0.0.0.0
Interface: Ethernet1/1
BkInterface:
RelyNextHop: 0.0.0.0
Neighbor : 192.168.1.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h00m47s
Tag: 0
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 2
Preference: 100
Cost: 2
IpPrecedence:
QosLcId:
NextHop: 192.168.2.2
BkNextHop: 0.0.0.0
Interface: Ethernet1/2
BkInterface:
RelyNextHop: 0.0.0.0
Neighbor : 192.168.2.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Inactive Adv
Age: 00h12m50s
Tag: 0
# Enable RIP event debugging on Router A.
<RouterA> debugging rip 1 event
<RouterA> terminal debugging
# When the link over Ethernet 1/1 fails, Router A quickly detects the link state change.
%Jan 19 10:41:51:203 2008 RouterA BFD/4/LOG:Sess[192.168.1.1/192.168.1.2,
Eth1/1,Ctrl], Sta: UP->DOWN, Diag: 1
*Jan 19 10:33:12:813 2008 RouterA RM/6/RMDEBUG: RIP-BFD: Message Type Disable, Connect
Type Direct-connect, Pkt Type Echo, Src IP Address 192.168.1.1, Src IFIndex4, Nbr IP
Address 192.168.1.2.
# Display the BFD information of Router A.
<RouterA> display bfd session
The output shows that Router A has deleted the BFD session to Router C and displays no output.
# Display the RIP routes of RIP process 1 on Router A.
<RouterA> display rip 1 route
Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------------------
The output shows that the RIP route learned from Router C no longer exists.
# Display the RIP route destined for 100.1.1.0/24 on Router A.
<RouterA> display ip routing-table 100.1.1.0 24 verbose
Routing Table : Public
Summary Count : 1
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 2
Preference: 100
Cost: 2
45
IpPrecedence:
NextHop: 192.168.2.2
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 192.168.2.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h18m40s
Tag: 0
Configuring BFD for RIP (single-hop echo detection for a
specified destination)
Network requirements
As shown in Figure 10:
•
Ethernet 1/2 of Router A and Ethernet 1/1 of Router B run RIP process 1. Ethernet 1/2 of Router B
and Router 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 Router A and Router C so Router B can learn two routes destined for 100.1.1.0/24 through
Ethernet 1/1 and Ethernet 1/2. The route redistributed from Router A has a smaller cost than that
redistributed from Router C, so Router B uses the route from Ethernet 1/1.
•
Enable BFD for RIP on Ethernet 1/2 of Router A, and specify Ethernet 1/1 of Router B as the
destination. When a unidirectional link occurs (packets from Router A can reach Router B, but
packets from Router B cannot reach Router A), BFD can quickly detect the link failure and notify it
to RIP. RIP then deletes the neighbor relationship and route information learned on Ethernet 1/2
and does not receive or send any packets on Ethernet 1/2. When the route learned from Router A
ages out, Router B uses the route destined for 100.1.1.1 24 through Ethernet 1/2.
Figure 10 Network requirements
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic RIP and enable BFD on the interfaces:
# Configure Router A.
<RouterA> system-view
[RouterA] rip 1
46
[RouterA-rip-1] network 192.168.2.0
[RouterA-rip-1] import-route static
[RouterA-rip-1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] rip bfd enable destination 192.168.2.2
[RouterA-Ethernet1/2] quit
# Configure Router B.
<RouterB> system-view
[RouterB] rip 1
[RouterB-rip-1] network 192.168.2.0
[RouterB-rip-1] network 192.168.3.0
[RouterB-rip-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] rip 1
[RouterC-rip-1] network 192.168.3.0
[RouterC-rip-1] import-route static cost 3
[RouterC-rip-1] quit
3.
Configure the BFD parameters on Ethernet 1/2 of Router A.
[RouterA] bfd echo-source-ip 11.11.11.11
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] bfd min-echo-receive-interval 500
[RouterA-Ethernet1/2] quit
4.
Configure static routes.
# Configure a static route on Router A.
[RouterA] ip route-static 100.1.1.0 24 null 0
# Configure a static route on Router C.
[RouterC] ip route-static 100.1.1.0 24 null 0
5.
Verify the configuration:
# Display the BFD session information on Router A.
<RouterA> display bfd session
Total session number: 1
Up session number: 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
Eth1/2
# Display routes destined for 100.1.1.0/24 on Router B.
<RouterB> display ip routing-table 100.1.1.0 24 verbose
Routing Table : Public
Summary Count : 2
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 1
Preference: 100
Cost: 1
IpPrecedence:
NextHop: 192.168.2.1
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
QosLcId:
Interface: Ethernet1/1
BkInterface:
Neighbor : 192.168.2.1
47
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h02m47s
Tag: 0
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 1
Preference: 100
Cost: 4
IpPrecedence:
QosLcId:
NextHop: 192.168.3.2
Interface: Ethernet1/2
BkNextHop: 0.0.0.0
BkInterface:
RelyNextHop: 0.0.0.0
Neighbor : 192.168.3.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Inactive Adv
Age: 00h05m50s
Tag: 0
# Enable RIP event debugging on Router A.
<RouterA> debugging rip 1 event
<RouterA> terminal debugging
# When the link over Ethernet 1/2 becomes unidirectional (packets from Router A can reach
Router B, but packets Router B cannot reach Router A), Router A quickly detects the link state
change.
%Oct 15 09:41:51:212 2011 RouterA BFD/4/LOG:Sess[192.168.2.1/192.168.2.2,
Eth1/2,Echo], Sta: UP->DOWN, Diag: 1
*Oct 15 09:41:51:813 2011 RouterA RM/6/RMDEBUG: RIP-BFD: Receive BFD session down,
Pkt Type Echo, Src IP Address 192.168.2.1, Src IFIndex 4, Dst IP Address 192.168.2.2.
# Display the BFD session information on Router A.
<RouterA> display bfd session
Total session number: 1
Up session number: 0
Init Mode: Active
IPv4 session working under Echo mode:
LD
SourceAddr
DestAddr
State
Holdtime
3
192.168.2.1
192.168.2.2
Down
/
Interface
Eth1/2
The output shows that the BFD session to the specified destination is down.
# Display routes destined for 100.1.1.0/24 on Router B when the route learned from Router A
ages out.
<RouterB> display ip routing-table 100.1.1.0 24 verbose
Routing Table : Public
Summary Count : 1
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 1
Preference: 100
IpPrecedence:
NextHop: 192.168.3.2
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
Cost: 4
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 192.168.3.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h21m23s
48
Tag: 0
Configuring BFD for RIP (bidirectional control detection)
Network requirements
As shown in Figure 11, Ethernet 1/2 of Router A and Ethernet 1/1 of Router C run RIP process 1. Ethernet
1/1 on Router A runs RIP process 2. Ethernet 1/2 on Router C, and Ethernet 1/1 and Ethernet 1/2 on
Router D run RIP process 1.
Configure a static route destined for 100.1.1.0/24 on Router A, configure a static route destined for
101.1.1.0/24 on Router C, and enable static route redistribution into RIP on Router A and Router C so
Router A can learn two routes destined for 100.1.1.0/24 through Ethernet 1/2 and Ethernet 1/1,
respectively, and uses the one through Ethernet 1/2.
Enable BFD for RIP on Ethernet 1/2 of Router A and Ethernet 1/1 of Router C. When the link over
Ethernet 1/2 fails, BFD can quickly detect the link failure and notify it to RIP so RIP deletes the neighbor
relationship and the route information learned on Ethernet 1/2, and uses the route destined for
00.1.1.0/24 through Ethernet 1/1.
Figure 11 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth1/1
192.168.3.1/24
Router B
Eth1/1
192.168.2.1/24
Eth1/2
192.168.1.1/24
Eth1/2
192.168.1.2/24
Router C
Eth1/1
192.168.2.2/24
Router D
Eth1/1
192.168.3.2/24
Eth1/2
192.168.4.2/24
Eth1/2
192.168.4.1/24
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure basic RIP basic and enable static route redistribution into RIP so Router A and Router C
have routes to send to each other:
# Configure Router A.
<RouterA> system-view
[RouterA] rip 1
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
[RouterA-rip-1] network 192.168.1.0
49
[RouterA-rip-1] network 101.1.1.0
[RouterA-rip-1] peer 192.168.2.2
[RouterA-rip-1] undo validate-source-address
[RouterA-rip-1] import-route static
[RouterA-rip-1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] rip bfd enable
[RouterA-Ethernet1/2] quit
[RouterA] rip 2
[RouterA-rip-2] version 2
[RouterA-rip-2] undo summary
[RouterA-rip-2] network 192.168.3.0
[RouterA-rip-2] quit
# Configure Router C.
<RouterC> system-view
[RouterC] rip 1
[RouterC-rip-1] version 2
[RouterC-rip-1] undo summary
[RouterC-rip-1] network 192.168.2.0
[RouterC-rip-1] network 192.168.4.0
[RouterC-rip-1] network 100.1.1.0
[RouterC-rip-1] peer 192.168.1.1
[RouterC-rip-1] undo validate-source-address
[RouterC-rip-1] import-route static
[RouterC-rip-1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] rip bfd enable
[RouterC-Ethernet1/1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] rip 1
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
[RouterD-rip-1] network 192.168.3.0
[RouterD-rip-1] network 192.168.4.0
[RouterD-rip-1] quit
3.
Configure BFD parameters for the interfaces:
# Configure Router A.
[RouterA] bfd session init-mode active
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ip address 192.168.3.1 24
[RouterA-Ethernet1/1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] ip address 192.168.1.1 24
[RouterA-Ethernet1/2] bfd min-transmit-interval 500
[RouterA-Ethernet1/2] bfd min-receive-interval 500
[RouterA-Ethernet1/2] bfd detect-multiplier 7
[RouterA-Ethernet1/2] quit
50
# Configure Router B.
<RouterB> system-view
[RouterB] interface ethernet 1/2
[RouterB-Ethernet1/2] ip address 192.168.1.2 24
[RouterB-Ethernet1/2] quit
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] ip address 192.168.2.1 24
# Configure Router C.
[RouterC] bfd session init-mode active
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] ip address 192.168.2.2 24
[RouterC-Ethernet1/1] bfd min-transmit-interval 500
[RouterC-Ethernet1/1] bfd min-receive-interval 500
[RouterC-Ethernet1/1] bfd detect-multiplier 6
[RouterC-Ethernet1/1] quit
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] ip address 192.168.4.2 24
[RouterC-Ethernet1/2] quit
# Configure Router D.
[RouterD] interface ethernet 1/2
[RouterD-Ethernet1/2] ip address 192.168.4.1 24
[RouterD-Ethernet1/2] quit
[RouterD] interface ethernet 1/1
[RouterD-Ethernet1/1] ip address 192.168.3.2 24
[RouterD-Ethernet1/1] quit
4.
Configure static routes:
# Configure a static route to Router C on Router A.
[RouterA] ip route-static 192.168.2.0 24 ethernet1/2 192.168.1.2
[RouterA] quit
# Configure a static route to Router A on Router C.
[RouterC] ip route-static 192.168.1.0 24 ethernet1/1 192.168.2.1
5.
Verify the configuration:
# Display the BFD session information of Router A.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
LD/RD
SourceAddr
DestAddr
State Holdtime Interface
6/1
192.168.1.1
192.168.2.2
Up
1700ms
# Display RIP routes destined for 100.1.1.0/24 learned on Router A.
<RouterA> display ip routing-table 100.1.1.0 verbose
Routing Table : Public
Summary Count : 2
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 1
Preference: 100
Cost: 1
IpPrecedence:
QosLcId:
51
Eth1/2
NextHop: 192.168.2.2
BkNextHop: 0.0.0.0
Interface: Ethernet1/2
BkInterface:
RelyNextHop: 192.168.1.2
Neighbor : 192.168.2.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv GotQ
Age: 00h04m02s
Tag: 0
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 2
Preference: 100
Cost: 2
IpPrecedence:
QosLcId:
NextHop: 192.168.3.2
BkNextHop: 0.0.0.0
Interface: Ethernet1/1
BkInterface:
RelyNextHop: 0.0.0.0
Neighbor : 192.168.3.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Inactive Adv
Age: 00h03m57s
Tag: 0
# Enable RIP event debugging on Router A.
<RouterA> debugging rip 1 event
<RouterA> terminal debugging
# When the link over Ethernet 1/2 fails, Router A quickly detects the link state change.
%Jan 19 10:41:51:203 2008 RouterA BFD/4/LOG:Sess[192.168.1.1/192.168.2.2, Eth1/2,
Ctrl], Sta: UP->DOWN, Diag: 1
*Jan 19 10:41:51:203 2008 RouterA RM/6/RMDEBUG: RIP-BFD: Message Type Disable, Connect
Type Indirect-connect, Pkt Type Control, Src IP Address 192.168.1.1, Src IFIndex 4,
Nbr IP Address 192.168.2.2.
# Display the BFD information on Router A.
<RouterA> display bfd session
The output shows that Router A has deleted the BFD session to Router C and displays no output.
# Display the RIP routes of RIP process 1 on Router A.
<RouterA> display rip 1 route
Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------------------
The output shows that the RIP route learned from Router C no longer exists.
# Display the RIP route destined for 100.1.1.0/24 on Router A.
<RouterA> display ip routing-table 100.1.1.0 verbose
Routing Table : Public
Summary Count : 1
Destination: 100.1.1.0/24
Protocol: RIP
Process ID: 2
Preference: 100
Cost: 2
IpPrecedence:
NextHop: 192.168.3.2
BkNextHop: 0.0.0.0
QosLcId:
Interface: Ethernet1/2
BkInterface:
52
RelyNextHop: 0.0.0.0
Neighbor : 192.168.3.2
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h10m35s
Tag: 0
Troubleshooting RIP
No RIP updates received
Symptom
No RIP updates are received when the links work correctly.
Analysis
After enabling RIP, use the network command to enable corresponding interfaces. Make sure no
interfaces are disabled from handling RIP messages.
If the peer is configured to send multicast messages, the same should be configured on the local end.
Solution
•
Use the display current-configuration command to check RIP configuration.
•
Use the display rip command to check whether an interface is disabled.
Route oscillation occurred
Symptom
When all links work correctly, route oscillation occurs on the RIP network. After displaying the routing
table, you might find some routes intermittently appear and disappear in the routing table.
Analysis
In the RIP network, make sure that all the same timers within the entire network are identical and have
logical relationships between them. For example, the timeout timer value should be greater than the
update timer value.
Solution
•
Use the display rip command to check the configuration of RIP timers.
•
Use the timers command to adjust timers.
53
Configuring OSPF
This chapter describes how to configure OSPF.
Overview
Open Shortest Path First (OSPF) is a link state interior gateway protocol developed by the OSPF working
group of the IETF. OSPF version 2 is used for IPv4. Unless otherwise stated, OSPF refers to OSPFv2
throughout this document.
OSPF has the following features:
•
Wide scope—Supports various network sizes and up to 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.
•
Equal-cost multi-path (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 the security of
packet exchange.
•
Support for multicasting—Multicasts protocol packets on some types of links to avoid impacting
other devices.
OSPF packets
OSPF packets are encapsulated into IP packets and use the protocol number 89.
OSPF uses the following packet types:
•
Hello—Periodically sent to find and maintain neighbors, containing the values of some timers, and
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 the neighbor. After exchanging the DD
packets, the two routers know which LSAs of the neighbor are missing from their LSDBs. They then
send an LSR packet to each other, requesting the missing LSAs.
•
Link state update (LSU)—Transmits the requested LSAs to the neighbor.
•
Link state acknowledgment (LSAck)—Acknowledges received LSU packets.
54
LSA types
OSPF advertises routing information in Link State Advertisements (LSAs). The following describes some
commonly used LSAs:
•
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 ABRs (Area Border Routers), 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 ASBR (Autonomous System Boundary
Router).
•
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 (Not-So-Stubby
Areas) and flooded throughout a single NSSA. NSSA LSAs describe routes to other ASs.
•
Opaque LSA—Used by OSPF or by some other 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, such as the Grace LSA that supports Graceful Restart (GR).The Type
10 is flooded into the local area, such as the LSA that supports MPLS TE. The Type 11 is flooded
throughout the AS.
OSPF area
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 12.
You can configure route summarization on ABRs to reduce the number of LSAs advertised to other areas
and minimize the effect of topology changes.
55
Figure 12 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 requires the
following:
•
All non-backbone areas must maintain connectivity to the backbone area.
•
The backbone area must maintain connectivity within itself.
In practice, the requirements might not be satisfied due to lack of physical links. OSPF virtual links can
resolve this issue.
A virtual link is established between two ABRs through a non-backbone area and is configured on both
ABRs to take effect. The non-backbone area is called a transit area.
In Figure 13, 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 13 Virtual link application 1
Virtual links can also be used to provide redundant links. If the backbone area cannot maintain internal
connectivity due to the failure of a physical link, you can configure a virtual link to replace the failed
physical link, as shown in Figure 14.
56
Figure 14 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 the 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 no 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
A Not-So-Stubby Area (NSSA) area does not import AS external LSAs (Type-5 LSAs) but it 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.
You can configure an NSSA area as a totally NSSA area. The ABR of a totally NSSA area does no
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.
In Figure 15, 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 these
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. Area 1 cannot
receive these Type-5 LSAs because it is an NSSA area.
Figure 15 NSSA area
57
Router types
OSPF classifies routers into the following types based on their positions in the AS:
•
Internal router—All interfaces on an internal router belong to one OSPF area.
•
Area Border Router (ABR)—Belongs to more than two areas, one of which must be the backbone
area. An 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—At least one interface of a backbone router must reside in the backbone area.
All ABRs and internal routers in area 0 are backbone routers.
•
Autonomous System Boundary Router (ASBR)—Exchanges routing information with another AS. An
ASBR might not reside on the border of the AS. It can be an internal router or an ABR.
Figure 16 OSPF router types
RIP
IS-IS
ASBR
Area 1
Area 4
Backbone router
Internal router
Area 0
ABR
Area 3
Area 2
Route types
OSPF prioritizes routes into the following 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 from a router to the destination 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.
58
A Type-2 external route has low credibility. OSPF considers 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
from the internal router to the destination of the 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 224.0.0.6 that identifies the DR, and DD packets and
LSR packets are unicast.
•
NBMA (Non-Broadcast Multi-Access)—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 a NBMA
network.
•
P2MP (point-to-multipoint)—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 (point-to-point)—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 a 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
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, consuming
many system and bandwidth resources.
The DR and BDR mechanisms can solve this problem.
59
•
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
alone is time-consuming and prone to route calculation errors.
•
BDR—Elected along with the DR to establish adjacencies with all other routers. When 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 "DROthers." 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
DROther on another interface.
In Figure 17, solid lines are Ethernet physical links, and dashed lines represent OSPF adjacencies. With
the DR and BDR, only seven adjacencies are established.
Figure 17 DR and BDR in a network
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 or 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 is added to the network after DR and BDR election, the router
cannot become the DR or BDR immediately because no DR election is performed for it. 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
60
•
RFC 3630, Traffic Engineering Extensions to OSPF Version 2
•
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 in a routing domain, you must first enable OSPF on the routers. Make a proper configuration
plan to avoid wrong settings that can result in route blocking and routing loops.
Complete the following tasks to configure OSPF:
Task
Remarks
Enabling OSPF
Required.
Configuring a stub area
Configuring OSPF areas
Configuring an NSSA area
Optional.
Configuring a virtual link
Configuring OSPF
network types
Configuring OSPF route
control
Tuning and optimizing
OSPF networks
Configuring the broadcast network type for an interface
Optional.
Configuring the NBMA network type for an interface
Optional.
Configuring the P2MP network type for an interface
Optional.
Configuring the P2P network type for an interface
Optional.
Configuring OSPF route summarization
Optional.
Configuring OSPF inbound route filtering
Optional.
Configuring ABR Type-3 LSA filtering
Optional.
Configuring an OSPF cost for an interface
Optional.
Configuring the maximum number of ECMP routes
Optional.
Configuring OSPF preference
Optional.
Configuring OSPF route redistribution
Optional.
Advertising a host route
Optional.
Configuring OSPF packet timers
Optional.
Specifying LSA transmission delay
Optional.
Specifying SPF calculation interval
Optional.
Specifying the LSA arrival interval
Optional.
Specifying the LSA generation interval
Optional.
Disabling interfaces from receiving and sending OSPF
packets
Optional.
Configuring stub routers
Optional.
Configuring OSPF authentication
Optional.
Adding the interface MTU into DD packets
Optional.
Configuring the maximum number of external LSAs in LSDB
Optional.
61
Task
Configuring OSPF GR
Remarks
Enabling compatibility with RFC 1583
Optional.
Logging neighbor state changes
Optional.
Configuring OSPF network management
Optional.
Enabling message logging
Optional.
Enabling the advertisement and reception of opaque LSAs
Optional.
Configuring OSPF to give priority to receiving and processing
hello packets
Optional.
Configuring the LSU transmit rate
Optional.
Enabling OSPF ISPF
Optional.
Configuring the OSPF GR helper
Optional.
Triggering OSPF GR
Optional.
Configuring BFD for OSPF
Optional.
Enabling OSPF
Enable OSPF before you perform other OSPF configuration tasks.
Configuration prerequisites
Configure the link layer protocol and IP addresses for interfaces so that neighboring nodes can
communicate with each other.
Configuration guidelines
Complete the following tasks to enable an interface to run an OSPF process in an area:
•
Enable the OSPF process
•
Create the area for the OSPF process
•
Add the network segment where the interface resides to the area. The OSPF process advertises the
direct route of the interface.
•
Specify a router ID, the unique identifier of the router in the AS.
Following is additional information about router IDs:
•
You can specify a router ID when you create an OSPF process. Any two routers in an AS must have
different router IDs. A typical practice is to specify the IP address of an interface as the router ID.
•
If you specify no router ID when creating the OSPF process, the global router ID is used. HP
recommends specifying a router ID when you create the OSPF process.
OSPF can run multiple processes and supports 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.
•
VPN support enables an OSPF process to run in a specified VPN. For more information about VPN,
see MPLS Configuration Guide.
62
Configuration procedure
To enable OSPF:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
Not configured by default.
2.
Configure a global router
ID.
router id router-id
3.
Enable an OSPF process
and enter OSPF view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
4.
Configure a description for
the OSPF process.
description description
5.
Configure an OSPF area
and enter OSPF area view.
area area-id
6.
Configure a description for
the area.
description description
Specify a network to enable
the interface attached to the
network to run the OSPF
process in the area.
network ip-address
wildcard-mask
7.
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.
Not enabled by default.
Optional.
Not configured by default.
Not configured by default.
Optional.
Not configured by default.
Not configured by default.
A network segment can belong to only one
area.
Configuring OSPF areas
After you split an OSPF AS into multiple areas, you can configure some areas as stub areas or NSSA
areas as needed.
If no connectivity can be achieved between the backbone and a non-backbone area, or within the
backbone itself, configure virtual links to solve it.
Configuration prerequisites
Before you configure an OSPF area, complete the following tasks:
•
Configure IP addresses for interfaces.
•
Enable OSPF.
Configuring a stub area
You can configure a non-backbone area at an AS edge as a stub area. To do so, issue the stub command
on all the routers attached to the area. The routing table size is reduced because Type-5 LSAs are not
63
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, you can
configure it as a totally stub area by using the stub no-summary command on the ABR. AS external
routes and inter-area routes are not distributed into the area. All the packets destined outside of the area
are sent to the ABR for forwarding.
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
Not configured by default.
4.
Configure the area as a stub
area.
stub
[ default-route-advertise-always |
no-summary ] *
You cannot configure the
backbone area as a stub or totally
stub area.
A stub or totally stub area cannot
have an ASBR because external
routes cannot be distributed into
the area.
Optional.
5.
Specify a cost for the default
route advertised to the stub
area.
The default cost is 1.
default-cost cost
The default-cost command takes
effect only on the ABR of a stub
area or totally stub area.
NOTE:
Virtual links cannot transit 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 keeping other stub area characteristics.
To configure an NSSA area, issue the nssa command on all the routers attached to the area. To configure
a totally NSSA area, you also need to 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
64
Step
3.
4.
Command
Remarks
Enter area view.
area area-id
N/A
Configure the area as an
NSSA area.
nssa [ default-route-advertise |
no-import-route | no-summary |
translate-always |
translator-stability-interval value ]
*
Not configured by default.
Optional.
Specify a cost for the default
route advertised to the
NSSA area.
5.
The default cost is 1.
default-cost cost
The default-cost command takes
effect only on the ABR/ASBR of an
NSSA area and a totally NSSA
area.
NOTE:
Virtual links cannot transit an NSSA area or totally NSSA area.
Configuring a virtual link
Non-backbone areas exchange routing information through the backbone area. Connectivity between
the backbone and non-backbone areas and within the backbone must be available.
You can configure virtual links to ensure the connectivity when physical links are not enough. Virtual links
cannot transit a stub area, totally stub area, NSSA area, or totally NSSA area. MD5/HMAC-MD5
authentication supports MD5 key rollover. For more information, see "Configuring OSPF authentication."
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
Configure this command on both
ends of a virtual link.
Configure a virtual link.
vlink-peer router-id [ hello seconds
| retransmit seconds | trans-delay
seconds | dead seconds | { simple
[ plain | cipher ] password | { md5
| hmac-md5 } key-id [ plain |
cipher ] password } ] *
4.
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:
•
Broadcast—When the link layer protocol is Ethernet or FDDI, OSPF considers the network type as
broadcast by default.
65
•
NBMA—When the link layer protocol is Frame Relay, ATM, or X.25, OSPF considers the network
type as NBMA by default.
•
P2P—When the link layer protocol is PPP, LAPB, or HDLC, OSPF considers the network type as P2P
by default.
Follow these guidelines when you change the network type of an interface:
•
When an NBMA network becomes fully meshed (any two routers in the network have a direct
virtual circuit in between), change the network type to broadcast to avoid manual configuration of
neighbors.
•
If some routers in a broadcast network do not support multicasting, change the network type to
NBMA.
•
An NBMA network must be fully meshed. If it is partially meshed, change the network type to P2MP
to simplify configuration and save costs.
•
If a router on an NBMA network has only one neighbor, change the network type to P2P to save
costs.
Two broadcast-, NBMA-, P2MP-type interfaces can establish a neighbor relationship only when they are
on the same network segment.
Configuration prerequisites
Before you configure OSPF network types, complete the following tasks:
•
Configure IP addresses for interfaces so neighboring nodes can reach each other at network layer.
•
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.
Configure a router priority for
the interface.
ospf dr-priority priority
4.
Optional.
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.
A router priority of 0 means the neighbor does not have the right for DR election. A router priority greater
than 0 means the neighbor has the right for DR election.
66
The router priority configured with the ospf dr-priority command is for actual DR election. The priority
configured with the peer 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 will assume the neighbor has no election
right, and thus send no hello packets to this neighbor. However, if the local router is the DR or BDR, it still
sends hello packets to the neighbor with priority 0 for neighborship establishment.
To configure the OSPF network type for an Interface as NBMA:
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.
Configure a router priority
for the interface.
ospf dr-priority priority
5.
Exit 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 its
router priority.
peer ip-address [ cost value |
dr-priority dr-priority ]
By default, no neighbor is specified.
4.
Optional.
The default router priority is 1.
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
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.
Configure the OSPF network
type for the interface as
P2MP.
ospf network-type p2mp [ unicast ]
4.
Exit to system view.
quit
N/A
5.
Enter OSPF view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
N/A
3.
67
Step
Command
Remarks
Optional.
Specify a neighbor and its
router priority.
6.
peer ip-address [ cost value |
dr-priority dr-priority ]
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
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, complete the following tasks:
•
Configure IP addresses for interfaces.
•
Enable OSPF.
•
Configure filters if routing information filtering is needed.
Configuring OSPF route summarization
You can configure route summarization on an ABR or ASBR to summarize routes with the same prefix into
a single route and distribute it to other areas.
Route summarization reduces the routing information exchanged between areas and the sizes of routing
tables, improving router performance.
Configuring route summarization on an ABR
If contiguous network segments are available in the area, you can summarize them into a single network
segment. An ABR generates Type-3 LSAs on a per network segment basis for an attached non-backbone
area. In this way, the ABR in the area distributes only the summary LSA to reduce the scale of LSDBs on
routers in other areas and the influence of topology changes.
For example, in an area are three internal routes 19.1.1.0/24, 19.1.2.0/24, and 19.1.3.0/24. By
configuring route summarization on the ABR, the three routes are summarized into the route 19.1.0.0/16
that is advertised to other areas.
To configure route summarization on an ABR:
68
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 OSPF area view.
area area-id
N/A
4.
Configure ABR route
summarization.
abr-summary ip-address { mask |
mask-length } [ advertise |
not-advertise ] [ cost cost ]
Not configured by default.
The command is available on an
ABR only.
Configuring route summarization when redistributing routes into OSPF on an ASBR
Without route summarization, an ASBR advertises each redistributed route in a separate ASE LSA. After
a summary route is configured, the ASBR advertises only the summary route in an ASE LSA instead of
more specific routes, reducing the number of LSAs in the LSDB.
The ASBR summarizes redistributed Type-5 LSAs within the specified address range. If the ASBR is in an
NSSA area, it also summarizes Type-7 LSAs within the specified address range. If the ASBR is also the
ABR, it summarizes Type-5 LSAs translated from Type-7 LSAs.
To configure route summarization when redistributing routes into OSPF on an ASBR:
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.
Configure ASBR route
summarization.
asbr-summary ip-address { mask |
mask-length } [ tag tag | not-advertise
| cost cost ] *
The command is available on an
ASBR only.
Not configured by default.
Configuring OSPF inbound route filtering
OSPF calculates routes by using LSAs. The calculated routes can be filtered and only permitted routes are
installed into the OSPF routing table.
OSPF provides the following filtering methods:
•
Filters routing information by destination address through ACLs and IP address prefixes.
•
Filters routing information by next hop through the filtering criteria configured with the gateway
keyword.
•
Filters routing information by destination address through ACLs and IP address prefixes and by next
hop through the filtering criteria configured with the gateway keyword.
•
Filters routing information by routing policy specified by the route-policy keyword.
For more information about IP prefix list and routing policy, see "Configuring routing policies."
To configure inbound route filtering:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
69
Step
2.
3.
Command
Remarks
Enter OSPF view.
ospf [ process-id | router-id router-id |
vpn-instance vpn-instance-name ] *
N/A
Configure inbound
route filtering.
filter-policy { acl-number [ gateway
ip-prefix-name ] | gateway ip-prefix-name |
ip-prefix ip-prefix-name [ gateway
ip-prefix-name ] | route-policy
route-policy-name } import
Not configured by default.
Configuring ABR Type-3 LSA filtering
You can configure an ABR to filter Type-3 LSAs advertised to an area.
To configure Type-3 LSA filtering on an ABR:
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 ABR Type-3 LSA
filtering.
filter { acl-number | ip-prefix
ip-prefix-name } { import | export }
Not configured by
default.
Configuring an OSPF cost for an interface
You can configure an OSPF cost for an interface by using either of the following methods:
•
Configure the cost value in interface view
•
Configure a bandwidth reference value for the interface. OSPF computes the cost with this formula:
Interface OSPF cost = Bandwidth reference value (100 Mbps)/Interface bandwidth (Mbps). If the
calculated cost is greater than 65,535, the value of 65,535 is used. If the calculated cost is less
than 1, the value of 1 is used. If no cost or bandwidth reference value is configured for an interface,
OSPF computes the interface cost based on the interface bandwidth and default bandwidth
reference value.
To configure an OSPF cost 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
Optional.
3.
Configure an OSPF cost
for the interface.
The default cost depends on the interface
type: 1 for a VLAN interface and 0 for a
loopback interface, computed according
to the bandwidth for other interfaces.
ospf cost value
To configure a bandwidth reference value:
70
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.
Configure a bandwidth
reference value.
bandwidth-reference value
Optional.
The value defaults to 100
Mbps.
Configuring the maximum number of ECMP routes
Perform this task to implement load sharing over ECMP routes.
To configure the maximum number of ECMP routes:
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.
Configure the maximum
number of ECMP routes.
Optional.
maximum load-balancing maximum
By default, the
maximum number is 8.
Configuring OSPF preference
A router can run multiple routing protocols, and each protocol is assigned a preference. When the
routing protocols find routes to the same destination, the route found by the protocol with the highest
preference is selected as the best route.
To configure OSPF preference:
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.
Configure a
preference for OSPF.
preference [ ase ] [ route-policy
route-policy-name ] value
Optional.
By default, the preference of OSPF
internal routes is 10, and the preference
of OSPF external routes is 150.
Configuring OSPF route redistribution
This section describes configuring OSPF to redistribute manually configured routes or routes discovered
by other routing protocols.
Only active routes can be redistributed. Use the display ip routing-table protocol command to view route
state information.
71
Configuring OSPF to redistribute routes from other routing protocols
On a router running OSPF and other routing protocols, you can configure OSPF to redistribute routes
from other protocols such as RIP, IS-IS, BGP, static routes, and direct routes, and advertise them in Type-5
LSAs or Type-7 LSAs. In addition, you can filter redistributed routes so that OSPF advertises only permitted
routes in Type-5 LSAs or Type-7 LSAs.
To configure OSPF route redistribution:
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.
Configure OSPF to
redistribute routes from a
different protocol.
import-route protocol [ process-id |
all-processes | allow-ibgp ] [ cost cost | type
type | tag tag | route-policy
route-policy-name ] *
By default, OSPF does not
redistribute routes.
4.
Configure OSPF to filter
redistributed routes before
advertisement.
filter-policy { acl-number | ip-prefix
ip-prefix-name } export [ protocol
[ process-id ] ]
Optional.
By default, OSPF does not
filter redistributed routes
before advertisement.
Configuring OSPF to redistribute a default route
The import-route command cannot redistribute a default external route. Perform this task to redistribute a
default external route.
To configure OSPF to redistribute a default external route:
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
Not redistributed by
default.
3.
Redistribute a default
route.
default-route-advertise [ [ [ always |
permit-calculate-other ] | cost cost |
route-policy route-policy-name | type type ] * |
summary cost cost ]
The default-route-advertise
summary cost command is
applicable only to VPNs.
The PE router advertises the
default route in a Type-3
LSA to the CE router.
Configuring the default parameters for redistributed routes
Perform this task to configure default parameters cost, tag, and type for redistributed routes. Tags indicate
information related to protocols. For example, when redistributing BGP routes, OSPF uses tags to identify
AS IDs.
To configure the default parameters for redistributed routes:
72
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
Optional.
Configure the default
parameters for
redistributed routes (cost,
upper limit, tag, and
type).
3.
default { cost cost | limit limit | tag tag | type
type } *
The default cost is 1, the
default maximum number
of routes redistributed per
time is 1000, the default
tag is 1, and default type
of redistributed routes is
Type-2.
Advertising a host route
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.
Advertise a host route.
host-advertise ip-address cost
Not advertised by default.
Tuning and optimizing OSPF networks
You can optimize an OSPF network in the following ways:
•
Change OSPF packet timers to adjust the convergence speed and network load. On low-speed
links, consider the delay time for sending LSAs.
•
Change the SPF calculation interval to reduce resource consumption caused by frequent network
changes.
•
Configure OSPF authentication to improve security.
Configuration prerequisites
Before you configure OSPF network optimization, complete the following tasks:
•
Configure IP addresses for interfaces.
•
Enable OSPF.
Configuring OSPF packet timers
You can configure the following timers on OSPF interfaces as needed.
•
Hello timer—Interval for sending hello packets. It must be identical on OSPF neighbors.
73
•
Poll timer—Interval for sending hello packets to a neighbor that is down on the NBMA network. The
poll interval is at least four times the hello interval.
•
Dead timer—Interval within which if the interface receives no hello packet from the neighbor, it
declares the neighbor is down. The dead interval must be at least four times the hello interval on an
interface.
•
LSA retransmission timer—Interval within which if the interface receives no acknowledgement
packets after sending a LSA to the neighbor, it retransmits the LSA. An interval setting that is too
small can cause unnecessary LSA retransmissions. This interval is typically set bigger than the
round-trip time of a packet between two neighbors.
To configure timers for OSPF packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface
view.
interface interface-type
interface-number
N/A
Optional.
3.
Specify the hello
interval.
ospf timer hello seconds
The hello interval defaults to 10 seconds on P2P
and broadcast interfaces, and defaults to 30
seconds on P2MP and NBMA interfaces.
The default hello interval is restored when the
network type for an interface is changed.
4.
Specify the poll
interval.
ospf timer poll seconds
Optional.
The poll interval defaults to 120 seconds.
Optional.
5.
Specify the dead
interval.
ospf timer dead seconds
The default dead interval is 40 seconds on P2P
and broadcast interfaces and 120 seconds on
P2MP and NBMA interfaces.
The default dead interval is restored when the
network type for an interface is changed.
6.
Specify the
retransmission
interval.
Optional.
ospf timer retransmit interval
The retransmission interval defaults to 5
seconds.
Specifying LSA transmission delay
Each LSA in the LSDB has an age that is incremented by 1 every second, but the age does not change
during transmission. Therefore, it is necessary to add a transmission delay into the age time, especially
for low-speed links.
To specify the LSA transmission delay 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
74
Step
3.
Command
Specify the LSA transmission
delay.
ospf trans-delay seconds
Remarks
Optional.
The default setting is 1 second.
Specifying SPF calculation interval
LSDB changes result in SPF calculations. When the topology changes frequently, a large amount of
network and router resources are occupied by SPF calculation. You can adjust the SPF calculation
interval to reduce the impact.
When network changes are not frequent, the minimum-interval is adopted. If network changes become
frequent, the SPF calculation interval is incremented by incremental-interval × 2n-2 (n is the number of
calculation times) each time a calculation occurs until the maximum-interval is reached.
To configure SPF calculation interval:
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.
Specify the SPF
calculation interval.
spf-schedule-interval maximum-interval
[ minimum-interval
[ incremental-interval ] ]
Optional.
By default, the interval is 5
seconds.
Specifying the LSA arrival interval
If OSPF receives an LSA that has the same LSA type, LS ID, and router ID as the previously received LSA
within the LSA arrival interval, OSPF discards the LSA to save bandwidth and route resources.
To configure the LSA arrival interval:
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
Optional.
3.
Configure the LSA arrival
interval.
The default interval is
1000 milliseconds.
lsa-arrival-interval interval
75
Make sure this interval is
smaller than or equal to
the interval set with the
lsa-generation-interval
command.
Specifying the LSA generation interval
You can adjust the LSA generation interval to protect network resources and routers from being over
consumed by frequent network changes.
When network changes are not frequent, LSAs are generated at the minimum-interval. If network
changes become frequent, the LSA generation interval is incremented by incremental-interval × 2n-2 (n is
the number of generation times) each time a LSA generation occurs until the maximum-interval is
reached.
To configure the LSA generation interval:
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
Optional.
Configure the LSA
generation interval.
3.
lsa-generation-interval
maximum-interval [ initial-interval
[ incremental-interval ] ]
By default, the maximum interval is 5
seconds, the minimum interval is 0
milliseconds, and the incremental
interval is 5000 milliseconds.
Disabling interfaces from receiving and sending OSPF packets
Follow these guidelines when you disable interfaces from receiving and sending OSPF packets:
•
Different OSPF processes can disable the same interface from receiving and sending OSPF packets.
The silent-interface command disables only the interfaces associated with the current process rather
than interfaces associated with other processes.
•
After an OSPF interface is set to "silent," other interfaces on the router can still advertise direct
routes of the interface in Router LSAs, but the interface cannot send any packet. This configuration
can enhance OSPF networking adaptability and reduce resource consumption.
To disable interfaces from receiving and sending routing information:
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.
Disable interfaces from
receiving and sending
OSPF packets.
silent-interface { interface-type
interface-number | all }
Optional.
By default, interfaces receive and
send OSPF packets.
Configuring stub routers
A stub router is used for traffic control. It tells other OSPF routers to not use it to forward data although
they can have a route to it. A stub router has nothing to do with a stub area.
Router LSAs from the stub router might contain different link type values. A value of 3 means a link to a
stub network, and the cost of the link will not be changed. A value of 1, 2 or 4 means a point-to-point link,
76
a link to a transit network, or a virtual link. On such links, a maximum cost value of 65,535 is used.
Neighbors do not send packets to the stub router as long as they have a route with a smaller cost.
To configure a router as a stub router:
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.
Configure the router as a
stub router.
stub-router
By default, the router is not a stub
router in any OSPF process.
Configuring OSPF authentication
Perform this task to configure OSPF area and interface authentication.
OSPF adds the configured password into outgoing OSPF packets, and uses the password to authenticate
incoming OSPF packets. Only OSPF packets that pass the authentication can be received. If a packet
fails the authentication, the OSPF neighbor relationship cannot be established.
If you configure OSPF authentication for both an area and an interface in that area, the interface uses the
OSPF authentication configured on it.
You must configure the same authentication mode and password for all routers on the same network
segment.
To modify the MD5/HMAC-MD5 authentication password without tearing down OSPF neighbor
connections, perform the following key rollover configurations:
1.
Configure a new MD5/HMAC-MD5 authentication password. If the neighbors have not been
configured with the new password, this configuration triggers a key rollover process, during which,
OSPF advertises both the new and old passwords so all neighbors can pass the authentication.
2.
Configure the new MD5/HMAC-MD5 authentication password on all neighbors. After OSPF
receives packets carrying the new password from all neighbors, it quits the key rollover process.
3.
Remove the old MD5/HMAC-MD5 authentication password from the local device and all its
neighbors. This operation can avoid attacks that use the old password and reduce bandwidth
consumption by key rollover.
Configuring OSPF area authentication
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
• Configure simple authentication:
4.
Configure OSPF area
authentication mode.
authentication-mode simple [ cipher |
plain ] password
• Configure MD5 authentication:
authentication-mode { hmac-md5 |
md5 } key-id [ cipher | plain ] password
77
Use either method.
By default, no
authentication is
configured.
Configuring OSPF interface authentication
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type interface-number
N/A
• Configure simple authentication:
3.
Configure OSPF interface
authentication mode.
ospf authentication-mode simple [ cipher
| plain ] password
• Configure MD5 authentication:
ospf authentication-mode { hmac-md5 |
md5 } key-id [ cipher | plain ] password
Use either method.
By default, no
authentication is
configured.
Adding the interface MTU into DD packets
By default, an interface adds 0 into the interface MTU field of a DD packet to be sent rather than the
interface MTU. You can enable an interface to add its MTU into DD packets.
To add the interface MTU into DD packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Enable the interface to add its
MTU into DD packets.
ospf mtu-enable
Optional.
Not enabled by default.
Configuring the maximum number of external LSAs in LSDB
To configure the maximum number of external LSAs in the LSDB:
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.
Specify the maximum number
of external LSAs in the LSDB.
lsdb-overflow-limit number
Optional.
Not specified by
default.
Enabling compatibility with RFC 1583
RFC 1583 specifies a different method than RFC 2328 for selecting an external route from multiple LSAs.
This task enables RFC 2328 to be compatible with RFC 1583 so that the intra-area route in the backbone
area is preferred. If they are not compatible, the intra-area route in a non-backbone area is preferred to
reduce the burden of the backbone area.
78
To avoid routing loops, configure all the routers in a routing domain to be either compatible or
incompatible with RFC 1583.
To make them compatible:
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.
Enable compatibility
with RFC 1583.
rfc1583 compatible
Optional.
Enabled by default.
Logging neighbor state changes
Perform this task to enable output of log information to the terminal upon neighbor state changes.
To enable the logging of neighbor state changes:
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.
Enable the logging of
neighbor state changes.
log-peer-change
Optional.
Enabled by default.
Configuring OSPF network management
With trap generation enabled, OSPF generates traps to report important events. Traps include the
following levels:
•
Level-3—Fault traps
•
Level-4—Alarm traps
•
Level-5—Normal but important traps
•
Level-6—Notification traps
The generated traps are sent to the information center of the device. The output rules of the traps (whether
to output the traps and the output direction) are determined according to the information center
configuration. (For more information about information center, see Network Management and
Monitoring Configuration Guide.)
To configure OSPF network management:
Step
1.
Enter system view.
2.
Bind OSPF MIB to an
OSPF process.
Command
Remarks
system-view
N/A
Optional.
ospf mib-binding process-id
79
The OSPF process with the smallest
process-id is bound with OSPF MIB
by default.
Step
3.
Command
Enable OSPF trap
generation.
Remarks
snmp-agent trap enable ospf [ process-id ]
[ ifauthfail | ifcfgerror | ifrxbadpkt |
ifstatechange | iftxretransmit |
lsdbapproachoverflow | lsdboverflow |
maxagelsa | nbrstatechange | originatelsa
| vifcfgerror | virifauthfail | virifrxbadpkt
| virifstatechange | viriftxretransmit |
virnbrstatechange ] *
Optional.
Enabled by default.
Enabling message logging
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.
Enable message
logging.
enable log [ config | error | state ]
By default, the function is
disabled.
Enabling the advertisement and reception of opaque LSAs
With this feature enabled, OSPF can receive and advertise Type 9, Type 10, and Type 11 opaque LSAs.
To enable the advertisement and reception of opaque LSAs:
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.
Enable the advertisement and
reception of opaque LSAs.
opaque-capability enable
Optional.
By default, the
function is disabled.
Configuring OSPF to give priority to receiving and processing
hello packets
To make sure OSPF runs correctly, a router receives and processes hello packets and other protocol
packets at the same time. When the router has established neighbor relationships with multiple routers,
and the routing table size is big, the router must receive and process large numbers of packets. In this
case, you can configure OSPF to give priority to receiving and processing Hello packets to ensure stable
neighbor relationships.
To configure OSPF to give priority to receiving and processing Hello packets:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
80
Step
Configure OSPF to give priority
to receiving and processing
hello packets.
2.
Command
Remarks
ospf packet-process
prioritized-treatment
Not configured by default.
Configuring the LSU transmit rate
Sending large numbers of LSU packets affects router performance and consumes too much network
bandwidth. You can configure the router to send LSU packets at a proper interval and limit the maximum
number of LSU packets sent out of an OSPF interface each time.
To configure the LSU transmit rate:
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.
Configure the LSU
transmit rate.
Optional.
transmit-pacing interval interval count count
By default, an OSPF interface
sends up to three LSU packets
every 20 milliseconds.
Enabling OSPF ISPF
When the topology changes, Incremental Shortest Path First (ISPF) computes only the affected part of the
SPT, instead of the entire SPT.
To enable OSPF ISPF:
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.
Enable OSPF ISPF.
ispf enable
By default, OSPF ISPF is
disabled.
Configuring OSPF GR
NOTE:
The device can act as only GR helper.
GR ensures the continuity of packet forwarding when a routing protocol restarts or an active/standby
switchover occurs.
•
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.
OSPF GR involves:
81
•
IETF standard GR—Uses Opaque LSAs to implement GR.
•
Non IETF standard GR—Uses link local signaling (LLS) to advertise GR capability and uses out of
band synchronization to synchronize the LSDB.
Configuring the OSPF GR helper
You can configure the IETF standard or non IETF standard OSPF GR helper.
Configuring the IETF standard OSPF GR helper
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable OSPF and enter its
view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
N/A
3.
Enable opaque LSA reception
and advertisement.
opaque-capability enable
Not enabled by default.
4.
Configure the neighbors for
which the router can serve as
a GR helper.
graceful-restart help { acl-number
| prefix prefix-list }
Optional.
The router can serve as a GR
helper for any OSPF neighbor by
default.
Configuring the non-IETF standard OSPF GR helper
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable OSPF and enter its
view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
N/A
3.
Enable the link-local signaling
capability.
enable link-local-signaling
Disabled by default.
4.
Enable the out-of-band
re-synchronization capability.
enable
out-of-band-resynchronization
Disabled by default.
5.
Configure the neighbors for
which the router can serve as
a GR helper.
Optional.
graceful-restart help { acl-number
| prefix prefix-list }
The router can serve as a GR
helper for any OSPF neighbor by
default.
Triggering OSPF GR
An OSPF Graceful Restart can be triggered by execution of the reset ospf [ process-id ] process
graceful-restart command on an OSPF router.
To trigger OSPF Graceful Restart, perform the following command in user view:
Task
Command
Trigger OSPF Graceful Restart.
reset ospf [ process-id ] process graceful-restart
82
Configuring BFD for OSPF
Bidirectional forwarding detection (BFD) provides a single mechanism to quickly detect and monitor the
connectivity of links between OSPF neighbors, reducing network convergence time. For more information
about BFD, see High Availability Configuration Guide.
OSPF supports the following BFD detection methods:
•
Control packet bidirectional detection, which requires BFD configuration to be made on both OSPF
routers on the link.
•
Echo packet single-hop detection, which requires BFD configuration to be made on one OSPF router
on the link.
Configuring control packet bidirectional detection
Both ends of a BFD session must be on the same network segment and in the same area. One network
segment can only belong to one area.
To enable BFD control packet bidirectional detection on an OSPF 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 BFD control packet bidirectional
detection on the interface.
ospf bfd enable
Not enabled by
default.
Configuring echo packet single-hop detection
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
Not configured by
default.
3.
Enter interface view.
interface interface-type
interface-number
N/A
4.
Enable BFD echo packet single-hop
detection on the interface.
ospf bfd enable echo
Not enabled by
default.
Displaying and maintaining OSPF
Task
Command
Remarks
Display OSPF brief information.
display ospf [ process-id ] brief [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display OSPF statistics.
display ospf [ process-id ] cumulative [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
83
Task
Command
Remarks
Display Link State Database
information.
display ospf [ process-id ] lsdb [ brief | [ { ase |
router | network | summary | asbr | nssa |
opaque-link | opaque-area | opaque-as }
[ link-state-id ] ] [ originate-router
advertising-router-id | self-originate ] ] [ | { begin
| exclude | include } regular-expression ]
Available in any
view.
Display OSPF neighbor
information.
display ospf [ process-id ] peer [ verbose ]
[ interface-type interface-number ] [ neighbor-id ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display neighbor statistics of OSPF
areas.
display ospf [ process-id ] peer statistics [ | { begin
| exclude | include } regular-expression ]
Available in any
view.
Display next hop information.
display ospf [ process-id ] nexthop [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display routing table information.
display ospf [ process-id ] routing [ interface
interface-type interface-number ] [ nexthop
nexthop-address ] [ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display virtual link information.
display ospf [ process-id ] vlink [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display OSPF request queue
information.
display ospf [ process-id ] request-queue
[ interface-type interface-number ] [ neighbor-id ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display OSPF retransmission
queue information.
display ospf [ process-id ] retrans-queue
[ interface-type interface-number ] [ neighbor-id ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display OSPF ABR and ASBR
information.
display ospf [ process-id ] abr-asbr [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display OSPF interface
information.
display ospf [ process-id ] interface [ all |
interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display OSPF error information.
display ospf [ process-id ] error [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display OSPF ASBR
summarization information.
display ospf [ process-id ] asbr-summary
[ ip-address { mask | mask-length } ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display the global router ID.
display router id [ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Clear OSPF statistics.
reset ospf [ process-id ] counters [ neighbor
[ interface-type interface-number ] [ router-id ] ]
Available in user
view.
Reset an OSPF process.
reset ospf [ process-id ] process [ graceful-restart ]
Available in user
view.
Re-enable OSPF route
redistribution.
reset ospf [ process-id ] redistribution
Available in user
view.
84
OSPF configuration examples
These configuration examples only cover OSPF configuration related commands.
Configuring OSPF basic functions
Network requirements
•
Enable OSPF on all routers, and split the AS into three areas.
•
Configure Router A and Router B as ABRs.
Figure 18 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] area 1
[RouterA-ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.1] quit
[RouterA-ospf-1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] area 2
[RouterB-ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.2] quit
[RouterB-ospf-1] quit
# Configure Router C.
85
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.1] network 10.4.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] ospf
[RouterD-ospf-1] area 2
[RouterD-ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.2] network 10.5.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.2] quit
[RouterD-ospf-1] quit
3.
Verify the configuration:
# Display the OSPF neighbors of Router A.
[RouterA] display ospf peer verbose
OSPF Process 1 with Router ID 10.2.1.1
Neighbors
Area 0.0.0.0 interface 10.1.1.1(Ethernet1/1)'s neighbors
Router ID: 10.3.1.1
State: Full
DR: 10.1.1.1
Address: 10.1.1.2
Mode: Nbr is Master
BDR: 10.1.1.2
Dead timer due in 37
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 06:03:59
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
Neighbors
Area 0.0.0.1 interface 10.2.1.1(Ethernet1/2)'s neighbors
Router ID: 10.4.1.1
State: Full
DR: 10.2.1.1
Address: 10.2.1.2
Mode: Nbr is Master
BDR: 10.2.1.2
Dead timer due in 32
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 06:03:12
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
# Display OSPF routing information on Router A.
[RouterA] display ospf routing
OSPF Process 1 with Router ID 10.2.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
86
AdvRouter
Area
10.2.1.0/24
1
Transit 10.2.1.1
10.2.1.1
0.0.0.1
10.3.1.0/24
2
Inter
10.1.1.2
10.3.1.1
0.0.0.0
10.4.1.0/24
2
Stub
10.2.1.2
10.4.1.1
0.0.0.1
10.5.1.0/24
3
Inter
10.1.1.2
10.3.1.1
0.0.0.0
10.1.1.0/24
1
Transit 10.1.1.1
10.2.1.1
0.0.0.0
Total Nets: 5
Intra Area: 3
Inter Area: 2
ASE: 0
NSSA: 0
# Display the Link State Database on Router A.
[RouterA] display ospf lsdb
OSPF Process 1 with Router ID 10.2.1.1
Link State Database
Area: 0.0.0.0
Type
LinkState ID
AdvRouter
Age
Len
Sequence
Router
10.2.1.1
10.2.1.1
1069
36
80000012
Metric
0
Router
10.3.1.1
10.3.1.1
780
36
80000011
0
Network
10.1.1.1
10.2.1.1
1069
32
80000010
0
Sum-Net
10.5.1.0
10.3.1.1
780
28
80000003
1
Sum-Net
10.2.1.0
10.2.1.1
1069
28
8000000F
2
Sum-Net
10.3.1.0
10.3.1.1
780
28
80000014
2
Sum-Net
10.4.1.0
10.2.1.1
769
28
8000000F
1
Type
LinkState ID
AdvRouter
Age
Len
Sequence
Router
10.2.1.1
10.2.1.1
769
36
80000012
0
Router
10.4.1.1
10.4.1.1
1663
48
80000012
0
Network
10.2.1.1
10.2.1.1
769
32
80000010
0
Sum-Net
10.5.1.0
10.2.1.1
769
28
80000003
3
Sum-Net
10.3.1.0
10.2.1.1
1069
28
8000000F
2
Sum-Net
10.1.1.0
10.2.1.1
1069
28
8000000F
1
Sum-Asbr
10.3.1.1
10.2.1.1
1069
28
8000000F
1
Area: 0.0.0.1
Metric
# Display OSPF routing information on Router D.
[RouterD] display ospf routing
OSPF Process 1 with Router ID 10.5.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
AdvRouter
Area
10.2.1.0/24
3
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.3.1.0/24
1
Transit 10.3.1.2
10.3.1.1
0.0.0.2
10.4.1.0/24
4
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.5.1.0/24
1
Stub
10.5.1.1
10.5.1.1
0.0.0.2
10.1.1.0/24
2
Inter
10.3.1.1
10.3.1.1
0.0.0.2
Total Nets: 5
Intra Area: 2
Inter Area: 3
ASE: 0
87
NSSA: 0
# Ping 10.4.1.1 to check connectivity.
[RouterD] ping 10.4.1.1
PING 10.4.1.1: 56
data bytes, press CTRL_C to break
Reply from 10.4.1.1: bytes=56 Sequence=2 ttl=253 time=2 ms
Reply from 10.4.1.1: bytes=56 Sequence=2 ttl=253 time=1 ms
Reply from 10.4.1.1: bytes=56 Sequence=3 ttl=253 time=1 ms
Reply from 10.4.1.1: bytes=56 Sequence=4 ttl=253 time=1 ms
Reply from 10.4.1.1: bytes=56 Sequence=5 ttl=253 time=1 ms
--- 10.4.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
Configuring OSPF route redistribution
Network requirements
•
Enable OSPF on all the routers, and split the AS into three areas.
•
Configure Router A and Router B as ABRs.
•
Configure Router C as an ASBR to redistribute external routes (static routes).
Figure 19 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions (see "Configuring OSPF basic functions").
3.
Configure OSPF to redistribute routes:
# On Router C, configure a static route destined for network 3.1.2.0/24.
<RouterC> system-view
[RouterC] ip route-static 3.1.2.1 24 10.4.1.2
# On Router C, configure OSPF to redistribute the static route.
[RouterC] ospf 1
[RouterC-ospf-1] import-route static
4.
Verify the configuration:
# Display ABR/ASBR information on Router D.
88
<RouterD> display ospf abr-asbr
OSPF Process 1 with Router ID 10.5.1.1
Routing Table to ABR and ASBR
Type
Destination
Area
Cost
Nexthop
RtType
Intra
10.3.1.1
0.0.0.2
10
10.3.1.1
ABR
Inter
10.4.1.1
0.0.0.2
22
10.3.1.1
ASBR
# Display the OSPF routing table of Router D.
<RouterD> display ospf routing
OSPF Process 1 with Router ID 10.5.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
AdvRouter
Area
10.2.1.0/24
22
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.3.1.0/24
10
Transit 10.3.1.2
10.3.1.1
0.0.0.2
10.4.1.0/24
25
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.5.1.0/24
10
Stub
10.5.1.1
10.5.1.1
0.0.0.2
10.1.1.0/24
12
Inter
10.3.1.1
10.3.1.1
0.0.0.2
Destination
Cost
Type
Tag
NextHop
AdvRouter
3.1.2.0/24
1
Type2
1
10.3.1.1
10.4.1.1
Routing for ASEs
Total Nets: 6
Intra Area: 2
Inter Area: 3
ASE: 1
NSSA: 0
Configuring OSPF to advertise a summary route
Network requirements
•
Configure OSPF on Router A and Router B in AS 200.
•
Configure OSPF on Router C, Router D, and Router E in AS 100.
•
Configure an EBGP connection between Router B and Router C. Configure Router B and Router C
to redistribute OSPF routes and direct routes into BGP and BGP routes into OSPF.
•
Configure Router B to advertise only summary route 10.0.0.0/8 to Router A.
89
Figure 20 Network diagram
Eth1/2
10.4.1.1/24
Eth1/2
10.3.1.1/24
Eth1/1
10.1.1.1/24
Eth1/1
10.2.1.2/24
Router E
Router D
Eth1/1
10.1.1.2/24
Eth1/3
10.2.1.1/24
Router C
Eth1/2
11.1.1.2/24
AS 100
EBGP
Eth1/2
11.1.1.1/24
Router B
Eth1/1
11.2.1.1/24
Eth1/1
11.2.1.2/24
AS 200
Router A
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 11.2.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 11.2.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] ospf
90
[RouterD-ospf-1] area 0
[RouterD-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] network 10.3.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
# Configure Router E.
<RouterE> system-view
[RouterE] ospf
[RouterE-ospf-1] area 0
[RouterE-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterE-ospf-1-area-0.0.0.0] network 10.4.1.0 0.0.0.255
[RouterE-ospf-1-area-0.0.0.0] quit
[RouterE-ospf-1] quit
3.
Configure BGP to redistribute OSPF routes and direct routes:
# Configure Router B.
[RouterB] bgp 200
[RouterB-bgp] peer 11.1.1.2 as-number 100
[RouterB-bgp] import-route ospf
[RouterB-bgp] import-route direct
[RouterB-bgp] quit
# Configure Router C.
[RouterC] bgp 100
[RouterC-bgp] peer 11.1.1.1 as-number 200
[RouterC-bgp] import-route ospf
[RouterC-bgp] import-route direct
[RouterC-bgp] quit
4.
Configure Router B and Router C to redistribute BGP routes into OSPF:
# Configure OSPF to redistribute routes from BGP on Router B.
[RouterB] ospf
[RouterB-ospf-1] import-route bgp
# Configure OSPF to redistribute routes from BGP on Router C.
[RouterC] ospf
[RouterC-ospf-1] import-route bgp
# Display the routing table of Router A.
[RouterA] display ip routing-table
Routing Tables: Public
Destinations : 8
Routes : 8
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.1.1.0/24
O_ASE
150
1
11.2.1.1
Eth1/1
10.2.1.0/24
O_ASE
150
1
11.2.1.1
Eth1/1
10.3.1.0/24
O_ASE
150
1
11.2.1.1
Eth1/1
10.4.1.0/24
O_ASE
150
1
11.2.1.1
Eth1/1
11.2.1.0/24
Direct 0
0
11.2.1.2
Eth1/1
11.2.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.1/32
Direct 0
0
127.0.0.1
InLoop0
91
5.
Configure summary route 10.0.0.0/8 on Router B and advertise it:
[RouterB-ospf-1] asbr-summary 10.0.0.0 8
# Display the routing table of Router A.
[RouterA] display ip routing-table
Routing Tables: Public
Destinations : 5
Routes : 5
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.0.0.0/8
O_ASE
150
2
11.2.1.1
Eth1/1
11.2.1.0/24
Direct 0
0
11.2.1.2
Eth1/1
11.2.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.1/32
Direct 0
0
127.0.0.1
InLoop0
The output shows that routes 10.1.1.0/24, 10.2.1.0/24, 10.3.1.0/24 and 10.4.1.0/24 are
summarized into one route 10.0.0.0/8.
Configuring an OSPF stub area
Network requirements
•
Enable OSPF on all routers, split the AS into three areas.
•
Configure Router A and Router B as ABRs to forward routing information between areas.
•
Configure Router D as the ASBR to redistribute static routes.
•
Configure Area 1 as a stub area to reduce LSAs advertised without influencing reachability.
Figure 21 Network diagram
Router A
Area 0
Eth1/2
10.2.1.1/24
Area 1
Stub
Router B
Eth1/1
10.1.1.1/24
Eth1/1
10.2.1.2/24
Eth1/1
10.1.1.2/24
Area 2
Eth1/2
10.3.1.1/24
Eth1/1
10.3.1.2/24
ASBR
Router C
Eth1/2
10.4.1.1/24
Eth1/2
10.5.1.1/24 Router D
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions (see "Configuring OSPF basic functions").
3.
Configure Router D to redistribute static routes:
<RouterD> system-view
[RouterD] ip route-static 3.1.2.1 24 10.5.1.2
[RouterD] ospf
[RouterD-ospf-1] import-route static
[RouterD-ospf-1] quit
92
# Display ABR/ASBR information on Router C.
<RouterC> display ospf abr-asbr
OSPF Process 1 with Router ID 10.4.1.1
Routing Table to ABR and ASBR
Type
Destination
Area
Cost
Nexthop
RtType
Intra
10.2.1.1
0.0.0.1
3
10.2.1.1
ABR
Inter
10.3.1.1
0.0.0.1
5
10.2.1.1
ABR
Inter
10.5.1.1
0.0.0.1
7
10.2.1.1
ASBR
# Display OSPF routing information on Router C.
<RouterC> display ospf routing
OSPF Process 1 with Router ID 10.4.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
10.2.1.0/24
3
10.3.1.0/24
7
10.4.1.0/24
10.5.1.0/24
10.1.1.0/24
NextHop
AdvRouter
Area
Transit 10.2.1.2
10.2.1.1
0.0.0.1
Inter
10.2.1.1
10.2.1.1
0.0.0.1
3
Stub
10.4.1.1
10.4.1.1
0.0.0.1
17
Inter
10.2.1.1
10.2.1.1
0.0.0.1
5
Inter
10.2.1.1
10.2.1.1
0.0.0.1
Destination
Cost
Type
Tag
NextHop
AdvRouter
3.1.2.0/24
1
Type2
1
10.2.1.1
10.5.1.1
Routing for ASEs
Total Nets: 6
Intra Area: 2
Inter Area: 3
ASE: 1
NSSA: 0
Because Router C resides in a normal OSPF area, its routing table contains an AS external route.
4.
Configure Area 1 as a stub area:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 1
[RouterA-ospf-1-area-0.0.0.1] stub
[RouterA-ospf-1-area-0.0.0.1] quit
[RouterA-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] stub
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterC-ospf-1] quit
# Display routing information on Router C.
93
[RouterC] display ospf routing
OSPF Process 1 with Router ID 10.4.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
AdvRouter
Area
0.0.0.0/0
4
Inter
10.2.1.1
10.2.1.1
0.0.0.1
10.2.1.0/24
3
Transit 10.2.1.2
10.2.1.1
0.0.0.1
10.3.1.0/24
7
Inter
10.2.1.1
10.2.1.1
0.0.0.1
10.4.1.0/24
3
Stub
10.4.1.1
10.4.1.1
0.0.0.1
10.5.1.0/24
17
Inter
10.2.1.1
10.2.1.1
0.0.0.1
10.1.1.0/24
5
Inter
10.2.1.1
10.2.1.1
0.0.0.1
Total Nets: 6
Intra Area: 2
Inter Area: 4
ASE: 0
NSSA: 0
After the area where Router C resides is configured as a stub area, a default route replaces the AS
external route.
# Configure the area as a totally stub area by filtering Type-3 LSAs out of the Stub area.
[RouterA] ospf
[RouterA-ospf-1] area 1
[RouterA-ospf-1-area-0.0.0.1] stub no-summary
[RouterA-ospf-1-area-0.0.0.1] quit
# Display OSPF routing information on Router C.
[RouterC] display ospf routing
OSPF Process 1 with Router ID 10.4.1.1
Routing Tables
Routing for Network
Destination
Cost
0.0.0.0/0
4
Inter
Type
10.2.1.1
NextHop
10.2.1.1
0.0.0.1
10.2.1.0/24
3
Transit 10.2.1.2
10.4.1.1
0.0.0.1
10.4.1.0/24
3
Stub
10.4.1.1
0.0.0.1
10.4.1.1
AdvRouter
Area
Total Nets: 3
Intra Area: 2
Inter Area: 1
ASE: 0
NSSA: 0
The output shows that inter-area routes are removed, and only one external route (a default route)
exists.
Configuring an OSPF NSSA area
Network requirements
•
Configure OSPF on all routers and split AS into three areas.
•
Configure Router A and Router B as ABRs to forward routing information between areas.
•
Configure Area 1 as an NSSA area and configure Router C as an ASBR to redistribute static routes
into the AS.
94
Figure 22 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configuring OSPF basic functions (see "Configuring OSPF basic functions").
3.
Configure Area 1 as an NSSA area:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 1
[RouterA-ospf-1-area-0.0.0.1] nssa
[RouterA-ospf-1-area-0.0.0.1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] nssa
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterC-ospf-1] quit
NOTE:
• To allow Router C in the NSSA area to reach other areas within the AS, you must provide the
keyword default-route-advertise for the nssa command issued on Router A (the ABR) so Router C
can obtain a default route.
• Configuring the nssa command with the keyword no-summary on Router A can reduce the routing
table size on NSSA routers. On other NSSA routers, you only need to configure the nssa command.
# Display routing information on Router C
[RouterC] display ospf routing
OSPF Process 1 with Router ID 10.4.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
10.2.1.0/24
3
Transit 10.2.1.2
95
AdvRouter
Area
10.4.1.1
0.0.0.1
10.3.1.0/24
7
Inter
10.2.1.1
10.2.1.1
0.0.0.1
10.4.1.0/24
3
Stub
10.4.1.1
10.4.1.1
0.0.0.1
10.5.1.0/24
17
Inter
10.2.1.1
10.2.1.1
0.0.0.1
10.1.1.0/24
5
Inter
10.2.1.1
10.2.1.1
0.0.0.1
Total Nets: 5
Intra Area: 2
4.
Inter Area: 3
ASE: 0
NSSA: 0
Configure a static route and configure OSPF to redistribute the static route on Router C:
[RouterC] ip route-static 3.1.2.1 24 10.4.1.2
[RouterC] ospf
[RouterC-ospf-1] import-route static
[RouterC-ospf-1] quit
# Display routing information on Router D.
<RouterD> display ospf routing
OSPF Process 1 with Router ID 10.5.1.1
Routing Tables
Routing for Network
Destination
Cost
Type
NextHop
AdvRouter
Area
10.2.1.0/24
22
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.3.1.0/24
10
Transit 10.3.1.2
10.3.1.1
0.0.0.2
10.4.1.0/24
25
Inter
10.3.1.1
10.3.1.1
0.0.0.2
10.5.1.0/24
10
Stub
10.5.1.1
10.5.1.1
0.0.0.2
10.1.1.0/24
12
Inter
10.3.1.1
10.3.1.1
0.0.0.2
Destination
Cost
Type
Tag
NextHop
AdvRouter
3.1.2.0/24
1
Type2
1
10.3.1.1
10.2.1.1
Routing for ASEs
Total Nets: 6
Intra Area: 2
Inter Area: 3
ASE: 1
NSSA: 0
The output shows an external route imported from the NSSA area on Router D.
Configuring OSPF DR election
Network requirements
•
Enable OSPF on Routers A, B, C, and D on the same network.
•
Configure Router A as the DR and configure Router C as the BDR.
96
Figure 23 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] router id 1.1.1.1
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] router id 2.2.2.2
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] router id 3.3.3.3
[RouterC] ospf
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] router id 4.4.4.4
[RouterD] ospf
[RouterD-ospf-1] area 0
[RouterD-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
97
[RouterD-ospf-1] return
# Display neighbor information on Router A.
[RouterA] display ospf peer verbose
OSPF Process 1 with Router ID 1.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(Ethernet1/1)'s neighbors
Router ID: 2.2.2.2
State: 2-Way
Address: 192.168.1.2
Mode: None
DR: 192.168.1.4
Priority: 1
BDR: 192.168.1.3
Dead timer due in 38
GR State: Normal
MTU: 0
sec
Neighbor is up for 00:01:31
Authentication Sequence: [ 0 ]
Router ID: 3.3.3.3
State: Full
Address: 192.168.1.3
Mode: Nbr is Master
DR: 192.168.1.4
BDR: 192.168.1.3
Dead timer due in 31
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 00:01:28
Authentication Sequence: [ 0 ]
Router ID: 4.4.4.4
State: Full
Address: 192.168.1.4
Mode: Nbr is Master
DR: 192.168.1.4
BDR: 192.168.1.3
Dead timer due in 31
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 00:01:28
Authentication Sequence: [ 0 ]
The output shows that Router D is the DR and Router C is the BDR.
3.
Configure router priorities on interfaces:
# Configure Router A.
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ospf dr-priority 100
[RouterA-Ethernet1/1] quit
# Configure Router B.
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] ospf dr-priority 0
[RouterB-Ethernet1/1] quit
# Configure Router C.
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] ospf dr-priority 2
[RouterC-Ethernet1/1] quit
# Display information about neighbors on Router D.
<RouterD> display ospf peer verbose
OSPF Process 1 with Router ID 4.4.4.4
Neighbors
98
Area 0.0.0.0 interface 192.168.1.4(Ethernet1/1)'s neighbors
Router ID: 1.1.1.1
State: Full
Address: 192.168.1.1
Mode:Nbr is
DR: 192.168.1.4
Slave
BDR: 192.168.1.3
Dead timer due in 31
GR State: Normal
Priority: 100
MTU: 0
sec
Neighbor is up for 00:11:17
Authentication Sequence: [ 0 ]
Router ID: 2.2.2.2
State: Full
Address: 192.168.1.2
Mode:Nbr is
DR: 192.168.1.4
Slave
Priority: 0
BDR: 192.168.1.3
Dead timer due in 35
GR State: Normal
MTU: 0
sec
Neighbor is up for 00:11:19
Authentication Sequence: [ 0 ]
Router ID: 3.3.3.3
State: Full
Address: 192.168.1.3
Mode:Nbr is
DR: 192.168.1.4
Slave
BDR: 192.168.1.3
Dead timer due in 33
GR State: Normal
Priority: 2
MTU: 0
sec
Neighbor is up for 00:11:15
Authentication Sequence: [ 0 ]
The DR and BDR are not changed, because the new router priority settings do not take effect
immediately.
4.
Restart the OSPF process:
# Restart the OSPF process on Router D.
<RouterD> reset ospf 1 process
Warning : Reset OSPF process? [Y/N]:y
# Display neighbor information on Router D.
<RouterD> display ospf peer verbose
OSPF Process 1 with Router ID 4.4.4.4
Neighbors
Area 0.0.0.0 interface 192.168.1.4(Ethernet1/1)'s neighbors
Router ID: 1.1.1.1
State: Full
Address: 192.168.1.1
Mode: Nbr is Slave
DR: 192.168.1.1
BDR: 192.168.1.3
Dead timer due in 39
GR State: Normal
Priority: 100
MTU: 0
sec
Neighbor is up for 00:01:40
Authentication Sequence: [ 0 ]
Router ID: 2.2.2.2
State: 2-Way
Address: 192.168.1.2
Mode: None
DR: 192.168.1.1
Priority: 0
BDR: 192.168.1.3
Dead timer due in 35
sec
Neighbor is up for 00:01:44
Authentication Sequence: [ 0 ]
99
MTU: 0
GR State: Normal
Router ID: 3.3.3.3
State: Full
Address: 192.168.1.3
Mode: Nbr is Slave
DR: 192.168.1.1
Priority: 2
BDR: 192.168.1.3
Dead timer due in 39
GR State: Normal
MTU: 0
sec
Neighbor is up for 00:01:41
Authentication Sequence: [ 0 ]
The output shows that Router A becomes the DR and Router C becomes the BDR.
The full neighbor state means an adjacency has been established. The 2-way neighbor state
means the two routers are not the DR or BDR, and they do not exchange LSAs.
# Display OSPF interface information
[RouterA] display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0
IP Address
Type
State
192.168.1.1
Broadcast DR
Cost
Pri
DR
BDR
1
100
192.168.1.1
192.168.1.3
[RouterB] display ospf interface
OSPF Process 1 with Router ID 2.2.2.2
Interfaces
Area: 0.0.0.0
IP Address
Type
State
192.168.1.2
Broadcast DROther
Cost
Pri
DR
BDR
1
0
192.168.1.1
192.168.1.3
The interface state DROther means the interface is not the DR or BDR.
Configuring OSPF virtual links
Network requirements
Configure a virtual link between Router B and Router C to connect Area 2 to the backbone area. After
configuration, Router B can learn routes to Area 2.
Figure 24 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
100
2.
Configure OSPF basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf 1 router-id 1.1.1.1
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
# Configure Router B.
<RouterB> system-view
[RouterB] ospf 1 router-id 2.2.2.2
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] area 1
[RouterB–ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[RouterB–ospf-1-area-0.0.0.1] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf 1 router-id 3.3.3.3
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] network 10.2.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterC-ospf-1] area 2
[RouterC–ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[RouterC–ospf-1-area-0.0.0.2] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] ospf 1 router-id 4.4.4.4
[RouterD-ospf-1] area 2
[RouterD-ospf-1-area-0.0.0.2] network 10.3.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.2] quit
# Display OSPF routing information on Router B.
[RouterB] display ospf routing
OSPF Process 1 with Router ID 2.2.2.2
Routing Tables
Routing for Network
Destination
Cost
Type
10.2.1.0/24
2
10.1.1.0/24
2
NextHop
AdvRouter
Area
Transit 10.2.1.1
3.3.3.3
0.0.0.1
Transit 10.1.1.2
2.2.2.2
0.0.0.0
Total Nets: 2
Intra Area: 2
Inter Area: 0
ASE: 0
NSSA: 0
Area 0 has no direct connection to Area 2, so the OSPF routing table of Router B has no route to
Area 2.
3.
Configure a virtual link:
101
# Configure Router B.
[RouterB] ospf
[RouterB-ospf-1] area 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 3.3.3.3
[RouterB-ospf-1-area-0.0.0.1] quit
[RouterB-ospf-1] quit
# Configure Router C.
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterC-ospf-1-area-0.0.0.1] quit
# Display OSPF routing information on Router B.
[RouterB] display ospf routing
OSPF Process 1 with Router ID 2.2.2.2
Routing Tables
Routing for Network
Destination
Cost
Type
AdvRouter
Area
10.2.1.0/24
2
Transit 10.2.1.1
NextHop
3.3.3.3
0.0.0.1
10.3.1.0/24
5
Inter
10.2.1.2
3.3.3.3
0.0.0.0
10.1.1.0/24
2
Transit 10.1.1.2
2.2.2.2
0.0.0.0
Total Nets: 3
Intra Area: 2
Inter Area: 1
ASE: 0
NSSA: 0
Router B has learned the route 10.3.1.0/24 to Area 2.
Configuring OSPF Graceful Restart
Network requirements
•
As shown in Figure 25, Router A, Router B, and Router C that belong to the same autonomous
system and the same OSPF routing domain are GR capable.
•
Router A acts as the non-IETF standard GR restarter. Router B and Router C are the GR helpers and
re-synchronize their LSDB with Router A through OOB communication of GR.
102
Figure 25 Network diagram
Configuration procedure
1.
Configure IP address for interfaces. (Details not shown.)
2.
Configure OSPF basic functions:
# Configure Router A
<RouterA> system-view
[RouterA] router id 1.1.1.1
[RouterA] ospf 100
[RouterA-ospf-100] area 0
[RouterA-ospf-100-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[RouterA-ospf-100-area-0.0.0.0] quit
# Configure Router B
<RouterB> system-view
[RouterB] router id 2.2.2.2
[RouterB] ospf 100
[RouterB-ospf-100] area 0
[RouterB-ospf-100-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterB-ospf-100-area-0.0.0.0] quit
# Configure Router C
<RouterC> system-view
[RouterC] router id 3.3.3.3
[RouterC] ospf 100
[RouterC-ospf-100] area 0
[RouterC-ospf-100-area-0.0.0.0] network 10.1.1.0
0.0.0.255
[RouterC-ospf-100-area-0.0.0.0] quit
3.
Configure OSPF GR:
# Configure Router A as the non-IETF standard OSPF GR restarter: enable the link-local signaling
capability, the out-of-band re-synchronization capability, and non-IETF standard Graceful Restart
capability for OSPF process 100.
[RouterA-ospf-100] enable link-local-signaling
[RouterA-ospf-100] enable out-of-band-resynchronization
[RouterA-ospf-100] graceful-restart
[RouterA-ospf-100] return
103
# Configure Router B as the GR helper: enable the link-local signaling capability and the
out-of-band re-synchronization capability for OSPF process 100.
[RouterB-ospf-100] enable link-local-signaling
[RouterB-ospf-100] enable out-of-band-resynchronization
# Configure Router C as the GR helper: enable the link-local signaling capability and the
out-of-band re-synchronization capability for OSPF process 100.
[RouterC-ospf-100] enable link-local-signaling
[RouterC-ospf-100] enable out-of-band-resynchronization
4.
Verify the configuration:
# If all routers function steadily after the above configurations, enable OSPF Graceful Restart event
debugging, and then restart the OSPF process using GR on Router A.
<RouterA> debugging ospf event graceful-restart
<RouterA> terminal monitor
<RouterA> terminal debugging
<RouterA> reset ospf 100 process graceful-restart
Warning : Reset OSPF process? [Y/N]:y
%Dec 12 09:36:12:500 2006 RouterA RM/3/RMLOG:OSPF-NBRCHANGE: Process 100, Neighbour
192.1.1.1(Ethernet1/1) from Full to Down
OSPF 100: Intf 192.1.1.1 Rcv InterfaceDown State BackupDR -> Down.
OSPF 100 nonstandard GR Started for OSPF Router
OSPF 100 notify RM that OSPF process will enter GR.
OSPF 100 created GR wait timer, timeout interval is 40(s).
OSPF 100 created GR Interval timer,timeout interval is 120(s).
OSPF 100: Intf 192.1.1.1 Rcv InterfaceUp State Down -> Waiting.
OSPF 100: Intf 192.1.1.1 Rcv BackupSeen State Waiting -> BackupDR.
OSPF 100 created OOB Progress timer for neighbor 192.1.1.2.
OSPF 100 restarted OOB Progress timer for neighbor 192.1.1.2.
OSPF 100 restarted OOB Progress timer for neighbor 192.1.1.2.
%Oct 22 09:36:12:566 2008 RouterA RM/3/RMLOG:OSPF-NBRCHANGE: Process 100, Neighbour
192.1.1.2(Ethernet1/1) from Loading to Full
OSPF 100 restarted OOB Progress timer for neighbor 192.1.1.2.
OSPF 100 deleted OOB Progress timer for neighbor 192.1.1.2.
OSPF 100 Gr Wait Timeout timer fired.
OSPF 100 deleted GR wait timer.
OSPF 100 deleted GR Interval timer.
OSPF 100 GR Completed for OSPF Router
OSPF 100 notified RM that OSPF process left GR.
RM notified that all protocol left GR.
OSPF 100 started flushing STALE LSA after all protocol left GR.
OSPF 100: Flush Stale Area LSAs
OSPF 100: Start Flush Stale ASE + NSSA LSAs
OSPF 100: End Flush Stale ASE + NSSA LSAs
Router A completes GR with the help of Router B.
104
Configuring route filtering
Network requirements
•
In Figure 26, all the routers in the network run OSPF. The AS is divided into three areas.
•
Router A works as the ABR between Area 0 and Area 1. Router B works as the ABR between Area
0 and Area 2.
•
Configure Router C as an ASBR to redistribute external routes (static routes), and configure a filter
policy on Router C to filter out route 3.1.3.0/24.
•
Configure a routing policy on Router A to filter route 10.5.1.0/24.
Figure 26 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF basic functions (see "Configuring OSPF basic functions").
3.
Configure OSPF to redistribute routes:
# On Router C, configure a static route destined for network 3.1.1.0/24.
<RouterC> system-view
[RouterC] ip route-static 3.1.1.0 24 10.4.1.2
# On Router C, configure a static route destined for network 3.1.2.0/24.
[RouterC] ip route-static 3.1.2.0 24 10.4.1.2
# On Router C, configure a static route destined for network 3.1.3.0/24.
[RouterC] ip route-static 3.1.3.0 24 10.4.1.2
# Configure OSPF to redistribute static routes on Router C.
[RouterC] ospf 1
[RouterC-ospf-1] import-route static
[RouterC-ospf-1] quit
# Display the OSPF routing table of Router A.
<RouterA> display ip routing-table
Routing Tables: Public
Destinations : 12
Routes : 12
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
3.1.1.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
105
4.
3.1.2.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
3.1.3.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
10.1.1.0/24
Direct 0
0
10.1.1.1
Eth1/1
10.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.2.1.0/24
Direct 0
0
10.2.1.1
Eth1/2
10.2.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
OSPF
10
4
10.1.1.2
Eth1/1
10.4.1.0/24
OSPF
10
13
10.2.1.2
Eth1/2
10.5.1.0/24
OSPF
10
14
10.1.1.2
Eth1/1
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
Configure Router C to filter out the route 3.1.3.0/24:
# Configure the IPv4 prefix list.
[RouterC] ip ip-prefix prefix1 index 1 deny 3.1.3.0 24
[RouterC] ip ip-prefix prefix1 index 2 permit 3.1.1.0 24
[RouterC] ip ip-prefix prefix1 index 3 permit 3.1.2.0 24
# Reference the prefix list to filter out the route 3.1.3.0/24.
[RouterC] ospf 1
[RouterC-ospf-1] filter-policy ip-prefix prefix1 export static
# Display the OSPF routing table of Router A.
<RouterA> display ip routing-table
Routing Tables: Public
Destinations : 11
Routes : 11
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
3.1.1.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
3.1.2.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
10.1.1.0/24
Direct 0
0
10.1.1.1
Eth1/1
10.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.2.1.0/24
Direct 0
0
10.2.1.1
Eth1/2
10.2.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
OSPF
10
4
10.1.1.2
Eth1/1
10.4.1.0/24
OSPF
10
13
10.2.1.2
Eth1/2
10.5.1.0/24
OSPF
10
14
10.1.1.2
Eth1/1
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
The route destined for network 3.1.3.0/24 is filtered out.
5.
Configure Router A to filter out route 10.5.1.1/24:
# Configure the ACL on Router A.
<RouterA> system-view
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule 0 deny source 10.5.1.0 0.0.0.255
[RouterA-acl-basic-2000] rule 1 permit source any
[RouterA-acl-basic-2000] quit
# Use the ACL to filter route 10.5.1.0/24.
[RouterA] ospf 1
106
[RouterA-ospf-1] filter-policy 2000 import
[RouterA-ospf-1] quit
# Display the OSPF routing table of Router A.
[RouterA] display ip routing-table
Routing Tables: Public
Destinations : 10
Routes : 10
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
3.1.1.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
3.1.2.0/24
O_ASE
150
1
10.2.1.2
Eth1/2
10.1.1.0/24
Direct 0
0
10.1.1.1
Eth1/1
10.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.2.1.0/24
Direct 0
0
10.2.1.1
Eth1/2
10.2.1.1/32
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
OSPF
10
4
10.1.1.2
Eth1/1
10.4.1.0/24
OSPF
10
13
10.2.1.2
Eth1/2
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
The route to 10.5.1.1/24 is filtered out.
Configuring BFD for OSPF
Network requirements
As shown in Figure 27:
•
OSPF is enabled on Router A, Router B, and Router C so that they are reachable to each other at
the network layer.
•
After the link over which Router A and Router B communicate through a Layer 2 switch fails, BFD
can quickly detect the failure and notify OSPF of the failure. Router A and Router B then
communicate through Router C.
Figure 27 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth 1/1
192.168.0.102/24
Router B
Eth 1/1
192.168.0.100/24
Eth 1/2
10.1.1.102/24
Eth 1/2
13.1.1.1/24
107
Router C
Eth 1/1
10.1.1.100/24
Eth 1/2
13.1.1.2/24
Configuration procedure
1.
Configure IP addresses for the interfaces. (Details not shown.)
2.
Configure OSPF basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] network 121.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] ospf cost 2
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] network 13.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] network 120.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
[RouterB] interface ethernet 1/2
[RouterB-Ethernet1/2] ospf cost 2
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 13.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
3.
Configure BFD:
# Enable BFD on Router A and configure BFD parameters.
[RouterA] bfd session init-mode active
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ospf bfd enable
[RouterA-Ethernet1/1] bfd min-transmit-interval 500
[RouterA-Ethernet1/1] bfd min-receive-interval 500
[RouterA-Ethernet1/1] bfd detect-multiplier 7
[RouterA-Ethernet1/1] return
# Enable BFD on Router B and configure BFD parameters.
108
[RouterB] bfd session init-mode active
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] ospf bfd enable
[RouterB-Ethernet1/1] bfd min-transmit-interval 500
[RouterB-Ethernet1/1] bfd min-receive-interval 500
[RouterB-Ethernet1/1] bfd detect-multiplier 6
4.
Verify the configuration:
The following operations are performed on Router A. The operations on Router B and Router C are
similar. (Details not shown.)
# Display BFD information on Router A.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
LD/RD
SourceAddr
DestAddr
State Holdtime Interface
3/1
192.168.0.102
192.168.0.100
Up
1700ms
Eth1/1
# Display routes to 120.1.1.0/24 on Router A, and you can see that Router A communicates with
Router B through the Layer 2 switch.
<RouterA> display ip routing-table 120.1.1.0 verbose
Routing Table : Public
Summary Count : 2
Destination: 120.1.1.0/24
Protocol: OSPF
Process ID: 0
Preference: 0
Cost: 2
IpPrecedence:
NextHop: 192.168.0.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
QosLcId:
Interface: Ethernet1/1
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h58m10s
Tag: 0
Destination: 120.1.1.0/24
Protocol: OSPF
Process ID: 1
Preference: 10
Cost: 4
IpPrecedence:
NextHop: 10.1.1.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Invalid Adv
Age: 00h58m05s
Tag: 0
# Enable BFD debugging on Router A.
<RouterA> debugging bfd scm
<RouterA> debugging bfd event
<RouterA> debugging ospf event bfd
<RouterA> terminal debugging
109
# After the link over which Router A and Router B communicates through the Layer 2 switch fails,
Router A quickly detects the change on Router B.
%Nov 12 18:34:48:823 2005 RouterA BFD/5/LOG: Sess[192.168.0.102/192.168.0.100,
Eth1/1], Sta : UP->DOWN, Diag: 1
%Nov 12 18:34:48:824 2005 RouterA RM/4/RMLOG:OSPF-NBRCHANGE: Process 1, Neighbour
192.168.0.102 (Ethernet1/1) from Full to Down
*0.50673825 RouterA BFD/8/SCM:Sess[192.168.0.102/192.168.0.100,Eth1/1],Oper: Reset
*0.50673825 RouterA BFD/8/EVENT:Send sess-down Msg, [Src:192.168.0.102,
Dst:192.168.0.100, Ethernet1/1] Protocol: OSPF
*0.50673826 RouterA RM/7/RMDEBUG:OSPF-BFD: Message Type rcv BFD down, Connect Type
direct-connect, Src IP Address 192.168.0.102, Src IFIndex 5, Dst IP Address
192.168.0.100
*0.50673827 RouterA RM/7/RMDEBUG:OSPF-BFD: Message Type delete session, Connect Type
direct-connect, Src IP Address 192.168.0.102, Src IFIndex 5, Dst IP Address
192.168.0.100
OSPF 1: Nbr 192.168.0.100 Rcv KillNbr State Full -> Down.
*0.50673829 RouterA BFD/8/EVENT:Receive Delete-sess, [Src:192.168.0.102,
Dst:192.168.0.100,Ethernet1/1], Direct, Proto:OSPF
*0.50673830 RouterA BFD/8/SCM:Sess[192.168.0.102/192.168.0.100,Eth1/1], Oper: Del
application(OSPF)
*0.50673831 RouterA BFD/8/SCM:No application in session, delete
session[192.168.0.102/192.168.0.100,Eth1/1]
*0.50673831 RouterA BFD/8/SCM:Sess[192.168.0.102/192.168.0.100,Eth1/1], Oper:
Delete
*0.50673832 RouterA BFD/8/SCM:Delete send-packet timer
*0.50673833 RouterA BFD/8/SCM:Delete session entry
*0.50673833 RouterA BFD/8/SCM:Delete session from IP hash table
*0.50673834 RouterA BFD/8/SCM:Delete session from bfd interface
*0.50673834 RouterA BFD/8/SCM:No session under bfd-int[Ethernet1/1] with default
configuration, delete bfd-if
*0.50673835 RouterA BFD/8/SCM:Bfd-if[Ethernet1/1], Oper: Delete
*0.50673840 RouterA BFD/8/SCM:No bfd session exists, stop receiving any bfd packets
# Display BFD information on Router A.
The BFD session between Router A and Router B is deleted, so no information is output.
<RouterA> display bfd session
# Display routes to 120.1.1.0/24 on Router A, and you can see that Router A communicates with
Router B through Router C.
<RouterA> display ip routing-table 120.1.1.0 verbose
Routing Table : Public
Summary Count : 2
Destination: 120.1.1.0/24
Protocol: OSPF
Process ID: 1
Preference: 10
IpPrecedence:
NextHop: 10.1.1.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
Cost: 4
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h58m10s
110
Tag: 0
Destination: 120.1.1.0/24
Protocol: OSPF
Process ID: 0
Preference: 0
Cost: 2
IpPrecedence:
QosLcId:
NextHop: 192.168.0.100
BkNextHop: 0.0.0.0
Interface: Ethernet1/1
BkInterface:
RelyNextHop: 0.0.0.0
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Invalid Adv
Age: 00h58m05s
Tag: 0
Troubleshooting OSPF configuration
No OSPF neighbor relationship established
Symptom
No OSPF neighbor relationship can be established.
Analysis
If the physical link and lower layer protocols work well, check OSPF parameters configured on interfaces.
Two neighbors must have the same parameters, such as the area ID, network segment, and mask (a P2P
or virtual link might have different network segments and masks).
Solution
1.
Verify OSPF neighbor information with the display ospf peer command.
2.
Verify OSPF interface information with the display ospf interface command.
3.
Ping the neighbor router's IP address to check connectivity.
4.
Examine OSPF timers. The dead interval on an interface must be at least four times the hello
interval.
5.
On an NBMA network, use the peer ip-address command to manually specify the neighbor.
6.
At least one interface must have a router priority higher than 0 on an NBMA or a broadcast
network.
Incorrect routing information
Symptom
OSPF cannot find routes to other areas.
Analysis
The backbone area must maintain connectivity to all other areas. If a router connects to more than one
area, at least one area must be connected to the backbone. The backbone cannot be configured as a
stub area.
In a stub area, all routers cannot receive external routes, and all interfaces connected to the stub area
must belong to the stub area.
111
Solution
1.
Use the display ospf peer command to verify neighbor information.
2.
Use the display ospf interface command to verify OSPF interface information.
3.
Use the display ospf lsdb command to verify the LSDB.
4.
Use the display current-configuration configuration ospf command to verify area configuration. If
more than two areas are configured, at least one area is connected to the backbone.
5.
In a stub area, all routers attached are configured with the stub command. In an NSSA area, all
routers attached are configured with the nssa command.
6.
If a virtual link is configured, use the display ospf vlink command to verify the state of the virtual
link.
112
Configuring IS-IS
This chapter describes how to configure IS-IS for an IPv4 network.
Overview
Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol designed by the
International Organization for Standardization (ISO) to operate on the connectionless network protocol
(CLNP).
IS-IS was modified and extended in RFC 1195 by the IETF for application in both TCP/IP and OSI
reference models, and the new one is called "Integrated IS-IS" or "Dual IS-IS."
IS-IS is an IGP used within an AS, and uses the SPF algorithm for route calculation.
Terminology
•
Intermediate system (IS)—Similar to a router in TCP/IP, it is the basic unit in an IS-IS routing domain
to generate and propagate routing information. In the following text, an IS refers to a router.
•
End system (ES)—Similar to a host system in TCP/IP, an ES does not run IS-IS. ISO defines the ES-IS
protocol for communication between an ES and an IS.
•
Routing domain (RD)—An RD comprises a group of ISs that exchange routing information with each
other by using the same routing protocol.
•
Area—An IS-IS routing domain can be split into multiple areas.
•
Link State Database (LSDB)—All link states in the network forms the LSDB. Each IS has at least one
LSDB. An IS uses the SPF algorithm and LSDB to generate IS-IS routes.
•
Link State Protocol Data Unit (LSPDU) or Link State Packet (LSP)—An IS advertises all its link state
information in an LSP.
•
Network Protocol Data Unit (NPDU)—A network layer protocol packet in OSI, similar to an IP
packet in TCP/IP.
•
Designated IS—Elected on a broadcast network.
•
Network service access point (NSAP)—An NSAP is an OSI network layer address. It identifies an
abstract network service access point and describes the network address format in the OSI
reference model.
IS-IS address format
NSAP
As shown in Figure 28, an NSAP address comprises the initial domain part (IDP) and the domain specific
part (DSP). The IDP is equal to the network ID of an IP address, and the DSP is equal to the subnet and
host ID.
The IDP includes the authority and format identifier (AFI) and the initial domain identifier (IDI).
The DSP includes the high order part of DSP (HO-DSP), System ID, and SEL, where the HO-DSP identifies
the area, the System ID identifies the host, and the SEL identifies the type of service.
113
The IDP and DSP are variable in length. The length of an NSAP address varies from 8 bytes to 20 bytes.
Figure 28 NSAP address format
Area address
The area address comprises the IDP and the HO-DSP of the DSP, which identify the area and the routing
domain. Different routing domains cannot have the same area address.
Typically, a router only needs one area address, and all nodes in the same area must have the same area
address. To support smooth area merging, partitioning, and switching, a router can have a maximum of
three area addresses.
System ID
A system ID uniquely identifies a host or router. It has a fixed length of 48 bits (6 bytes).
The system ID of a device can be generated from the router ID. For example, suppose a router uses the
IP address 168.10.1.1 of Loopback 0 as the router ID. The system ID can be obtained through the
following steps:
1.
Extend each decimal number of the IP address to 3 digits by adding 0s from the left, such as
168.010.001.001.
2.
Divide the extended IP address into three sections that each has 4 digits in each section to get the
system ID 1680.1000.1001.
If you use other methods to define a system ID, make sure that it can uniquely identify the host or router.
SEL
The SEL, or the NSAP selector (N-SEL), is similar to the protocol identifier in IP. Different transport layer
protocols correspond to different SELs. All SELs in IP are 00.
Routing method
The IS-IS address format identifies the area, so a Level-1 router can easily identify packets destined to
other areas, IS-IS routers perform routing as follows:
•
A Level-1 router performs intra-area routing according to the system ID. If the destination address of
a packet does not belong to the local area, the Level-1 router forwards it to the nearest Level-1-2
router.
•
A Level-2 router performs inter-area routing according to the area address.
NET
A network entity title (NET) indicates the network layer information of an IS. It does not include transport
layer information. A NET is a special NSAP address with the SEL being 0. The length of a NET is in the
range of 8 bytes to 20 bytes, same as a NSAP address.
A NET comprises the following parts:
•
Area ID—Has a length of 1 to 13 bytes.
114
•
System ID—A system ID uniquely identifies a host or router in the area and has a fixed length of
6-byte.
•
SEL—Has a value of 0 and a fixed length of 1-byte.
For example, for a NET is ab.cdef.1234.5678.9abc.00, the area ID is ab.cdef, the system ID is
1234.5678.9abc, and the SEL is 00.
Typically, a router only needs one NET, but it can have a maximum of three NETs for smooth area
merging and partitioning. When you configure multiple NETs, make sure their system IDs are the same.
IS-IS area
IS-IS has a 2-level hierarchy to support large-scale networks. A large-scale routing domain is divided into
multiple areas. Typically, a Level-1 router is deployed within an area, a Level-2 router is deployed
between areas, and a Level-1-2 router is deployed between Level-1 and Level-2 routers.
Level-1 and Level-2
•
Level-1 router—A Level-1 router establishes neighbor relationships with Level-1 and Level-1-2 routers
in the same area. It maintains an LSDB comprising intra-area routing information. A Level-1 router
forwards packets destined for external areas to the nearest Level-1-2 router.
•
Level-2 router—A Level-2 router establishes neighbor relationships with the Level-2 and Level-1-2
routers in the same or in different areas. It maintains a Level-2 LSDB containing inter-area routing
information. All the Level-2 and Level-1-2 routers must be contiguous to form the backbone of the IS-IS
routing domain.
•
Level-1-2 router—A router with both Level-1 and Level-2 router functions. It can establish Level-1
neighbor relationships with the Level-1 and Level-1-2 routers in the same area, and establish Level-2
neighbor relationships with the Level-2 and Level-1-2 routers in different areas. A Level-1 router can
reach other areas only through a Level-1-2 router. The Level-1-2 router maintains two LSDBs, a Level-1
LSDB for intra-area routing and a Level-2 LSDB for inter-area routing.
Level-1 routers in different areas cannot establish neighbor relationships. Whether Level-2 routers
establish neighbor relationships does not depend on areas.
Figure 29 shows one IS-IS network topology. Area 1 is the backbone that comprises a set of Level-2
routers. The other four areas are non-backbone areas connected to the backbone through Level-1-2
routers.
115
Figure 29 IS-IS topology 1
Figure 30 shows another IS-IS topology. The Level-1-2 routers connect to the Level-1 and Level-2 routers,
and form the IS-IS backbone together with the Level-2 routers. No area is defined as the backbone in this
topology. The backbone comprises all contiguous Level-2 and Level-1-2 routers in different areas.
Figure 30 IS-IS topology 2
NOTE:
The IS-IS backbone does not need to be a specific area.
Both the Level-1 and Level-2 routers use the SPF algorithm to generate the shortest path tree.
Route leaking
Level-2 and Level-1-2 routers form a Level-2 area. An IS-IS routing domain comprises only one Level-2 area
and multiple Level-1 areas. A Level-1 area must connect to the Level-2 area rather than other Level-1 areas.
The routing information of each Level-1 area is sent to the Level-2 area through a Level-1-2 router, so a
Level-2 router knows the routing information of the entire IS-IS routing domain. By default, a Level-1-2
116
router does not advertise the routing information of other Level-1 areas and the Level-2 area to a Level-1
area, so a Level-1 router sends packets destined for other areas to the nearest Level-1-2 router. The path
passing through the Level-1-2 router might not be the best. To solve this problem, IS-IS provides the route
leaking feature.
Route leaking enables a Level-1-2 router to advertise the routes of other Level-1 areas and the Level-2 area
to the connected Level-1 area so that the Level-1 routers can select the optimal routes for packets.
IS-IS network types
Network types
IS-IS supports the following network types:
•
Broadcast network—such as Ethernet and Token-Ring.
•
Point-to-point network—such as PPP and HDLC.
For an NBMA interface, such as an ATM interface, you need to configure subinterfaces for it and
configure the interface type for the subinterfaces as point-to-point or broadcast. IS-IS cannot run on point
to multipoint (P2MP) links.
DIS and pseudonodes
IS-IS routers on broadcast network must elect a DIS.
The Level-1 and Level-2 DISs are elected separately. You can assign different priorities to a router for
different level DIS elections. The higher the router priority, the more likely the router becomes the DIS. If
multiple routers with the same highest DIS priority exist, the one with the highest SNPA (Subnetwork Point
of Attachment) address (MAC address on a broadcast network) will be elected. A router can be the DIS
for different levels.
IS-IS DIS election differs from OSPF DIS election in the following ways:
•
A router with priority 0 can also participate in the DIS election.
•
When a router with a higher priority is added to the network, an LSP flooding process is performed
to elect the router as the new DIS.
As shown in Figure 31, the same level routers on a network, including non-DIS routers, establish
adjacencies with each other.
Figure 31 DIS in the IS-IS broadcast network
The DIS creates and updates pseudonodes, as well as generates their LSPs, to describe all routers on the
network.
117
A pseudonode represents a virtual node on the broadcast network. It is not a real router. In IS-IS, it is
identified by the system ID of the DIS and a 1-byte Circuit ID (a non-zero value).
Using pseudonodes can reduce the resources consumed by SPF and simplify network topology.
NOTE:
On an IS-IS broadcast networks, all routers establish adjacency relationships, but they synchronize their
LSDBs through the DIS.
IS-IS PDUs
PDU
IS-IS PDUs are encapsulated in link layer frames. An IS-IS PDU has two parts, the headers and the
variable length fields. The headers comprise the PDU common header and the PDU specific header. All
PDUs have the same PDU common header. The specific headers vary by PDU type.
Figure 32 PDU format
Common header format
Figure 33 PDU common header format
Intradomain routing protocol discriminator
R
R
No. of Octets
1
Length indicator
1
Version/Protocol ID extension
1
ID length
1
R
PDU type
1
Version
1
Reserved
1
Maximum area address
1
Major fields of the PDU common header are as follows:
•
Intradomain routing protocol discriminator—Set to 0x83.
•
Length indicator—Length of the PDU header in bytes, including both common and specific headers.
•
Version/Protocol ID extension—Set to 1(0x01).
•
ID length—Length of the NSAP address and NET ID.
•
R(Reserved)—Set to 0.
•
PDU type—For detailed information, see Table 4.
•
Version—Set to 1(0x01).
•
Maximum area address—Maximum number of area addresses supported.
118
Table 4 PDU types
Type
PDU Type
Acronym
15
Level-1 LAN IS-IS hello PDU
L1 LAN IIH
16
Level-2 LAN IS-IS hello PDU
L2 LAN IIH
17
Point-to-Point IS-IS hello PDU
P2P IIH
18
Level-1 Link State PDU
L1 LSP
20
Level-2 Link State PDU
L2 LSP
24
Level-1 Complete Sequence Numbers PDU
L1 CSNP
25
Level-2 Complete Sequence Numbers PDU
L2 CSNP
26
Level-1 Partial Sequence Numbers PDU
L1 PSNP
27
Level-2 Partial Sequence Numbers PDU
L2 PSNP
Hello PDU
IS-to-IS hello PDUs (IIHs) are used by routers to establish and maintain neighbor relationships. On
broadcast networks, the Level-1 routers use the Level-1 LAN IIHs, and the Level-2 routers use the Level-2
LAN IIHs. The P2P IIHs are used on point-to-point networks.
Figure 34 illustrates the hello packet format in broadcast networks, where the blue fields are the common
header.
Figure 34 L1/L2 LAN IIH format
Major fields of the L1/L2 LAN IIH are as follows:
•
Reserved/Circuit type—The first 6 bits are reserved with a value of 0. The last 2 bits indicate the
router type—00 means reserved, 01 indicates L1, 10 indicates L2, and 11 indicates L1/2.
•
Source ID—System ID of the router advertising the hello packet.
119
•
Holding time—If no hello packets are received from the neighbor within the holding time, the
neighbor is considered down.
•
PDU length—Total length of the PDU in bytes.
•
Priority—DIS priority.
•
LAN ID—Includes the system ID and a 1-byte pseudonode ID.
Figure 35 shows the hello packet format on the point-to-point networks.
Figure 35 P2P IIH format
Instead of the priority and LAN ID fields in the LAN IIH, the P2P IIH has a Local Circuit ID field.
LSP
The Link State PDUs (LSPs) carry link state information. LSPs include Level-1 LSPs and Level-2 LSP. The
Level-2 LSPs are sent by the Level-2 routers, and the Level-1 LSPs are sent by the Level-1 routers. The Level-1-2
router can send both types of LSPs.
The two types of LSPs have the same format, as shown in Figure 36.
120
Figure 36 L1/L2 LSP format
Major fields of the L1/L2 LSP are as follows:
•
PDU length—Total length of the PDU in bytes.
•
Remaining lifetime—LSP remaining lifetime in seconds.
•
LSP ID—Consists of the system ID, the pseudonode ID (1 byte) and the LSP fragment number (1
byte).
•
Sequence number—LSP sequence number.
•
Checksum—LSP checksum.
•
P (Partition)—Partition bit that is only for L2 LSPs. This field indicates whether the router supports
partition repair.
•
ATT (Attach)—Attach bit that is generated by a L1/L1 router for L1 LSPs only. This field indicates that
the router generating the LSP is connected to multiple areas.
•
OL (Overload)—Indicates that the LSDB is not complete because the router has run out of memory.
Other routers will not send packets to the overloaded router, except packets destined to the
networks directly connected to the router. For example, in Figure 37, Router A forwards packets to
Router C through Router B. Once other routers know the OL field of LSPs from Router B is set to 1,
Router A will send packets to Router C through Router D and Router E, but still send to Router B
packets destined to the network directly connected to Router B.
•
IS type—Type of the router generating the LSP.
121
Figure 37 LSDB overload
SNP
A sequence number PDU (SNP) describes the complete or partial LSPs for LSDB synchronization.
SNPs include Complete SNP (CSNP) and Partial SNP (PSNP), which are further divided into Level-1 CSNP,
Level-2 CSNP, Level-1 PSNP and Level-2 PSNP.
A CSNP describes the summary of all LSPs for LSDB synchronization between neighboring routers. On
broadcast networks, CSNPs are sent by the DIS periodically (10 seconds by default). On point-to-point
networks, CSNPs are only sent during the adjacency establishment.
The CSNP packet format is shown in Figure 38.
Figure 38 L1/L2 CSNP format
A PSNP only contains the sequence numbers of one or multiple latest received LSPs. It can acknowledge
multiple LSPs at one time. When LSDBs are not synchronized, a PSNP is used to request missing LSPs from
a neighbor.
122
Figure 39 L1/L2 PSNP format
No. of Octets
1
Intradomain routing protocol discriminator
R
Length indicator
1
Version/Protocol ID extension
1
ID length
1
R
R
1
PDU type
Version
1
Reserved
1
Maximum area address
1
PDU length
2
Source ID
ID length+1
Variable length fields
CLV
The variable fields of PDU comprise multiple Code-Length-Value (CLV) triplets.
Figure 40 CLV format
Table 5 shows that different PDUs contain different CLVs. Code 1 through 10 of are defined in ISO 10589
(code 3 and 5 are not shown in the table), and others are defined in RFC 1195.
Table 5 CLV codes and PDU types
CLV Code
Name
PDU Type
1
Area Addresses
IIH, LSP
2
IS Neighbors (LSP)
LSP
4
Partition Designated Level 2 IS
L2 LSP
6
IS Neighbors (MAC Address)
LAN IIH
7
IS Neighbors (SNPA Address)
LAN IIH
8
Padding
IIH
9
LSP Entries
SNP
10
Authentication Information
IIH, LSP, SNP
128
IP Internal Reachability Information
LSP
129
Protocols Supported
IIH, LSP
130
IP External Reachability Information
L2 LSP
131
Inter-Domain Routing Protocol Information
L2 LSP
123
CLV Code
Name
PDU Type
132
IP Interface Address
IIH, LSP
Supported IS-IS features
Multiple instances and processes
IS-IS supports multiple instances and processes. Multiple processes allow an IS-IS process to work in
concert with a group of interfaces. A router can run multiple IS-IS processes, and each process
corresponds to a unique group of interfaces.
For routers supporting VPN, each IS-IS process is associated with a VPN instance, which means the VPN
instance is also associated with interfaces of the process.
Active/standby failover
IS-IS supports the following backup modes:
•
Nonstop routing (NSR)—Backs up all IS-IS data. After an active/standby MPU switchover, IS-IS can
work immediately.
•
Graceful restart (GR)—Backs up only the configuration of IS-IS. After an active/standby MPU
switchover, IS-IS performs graceful restart to synchronize the LSDB with neighbors.
The MSR series routers do not support IS-IS NSR.
IS-IS Graceful Restart
GR ensures the continuity of packet forwarding when a routing protocol restarts or an active/standby
switchover occurs:
•
GR restarter—Graceful restarting router. It must be GR capable.
•
GR helper—A neighbor of the GR restarter. It helps the GR restarter to complete the GR process.
After an IS-IS GR restarter restarts, it must complete the following tasks to synchronize the LSDB with its
neighbors:
•
Obtain IS-IS neighbor information without changing adjacencies.
•
Obtain the LSDB.
To complete these tasks, the GR restarter sends an OSPF GR signal to GR helpers so that the GR helpers
keep their adjacencies with the GR restarter, and restores the neighbor table after receiving responses
from neighbors. The GR restarter then synchronizes the LSDB with all GR-capable neighbors, calculates
routes, updates its routing table and forwarding table, and removes stale routes. The IS-IS routing
convergence is then complete.
IS-IS TE
IS-IS traffic engineering (TE) creates and maintains the Label Switched Path (LSP).
When creating the Constraint-based Routed LSP (CR LSP), MPLS must get the traffic attributes of all links
in the local area. MPLS obtains the traffic engineering information of links from IS-IS. For more
information about configuring IS-IS TE, see MPLS Configuration Guide.
Management tag
Management tag simplifies routing information management by carrying the management information
of the IP address prefixes (to control route redistribution from other routing protocols) and BGP community
and extended community attributes.
124
LSP fragment extension
IS-IS advertises link state information by flooding LSPs. Because one LSP carries a limited amount of link
state information, IS-IS fragments LSPs. Each LSP fragment is uniquely identified by a combination of the
System ID, Pseudonode ID (0 for a common LSP or a non-zero value for a Pseudonode LSP), and LSP
Number (LSP fragment number) of the node or pseudo node that generated the LSP. The 1-byte LSP
Number field, allowing a maximum of only 256 fragments to be generated by an IS-IS router, limits the
amount of link information the IS-IS router can advertise.
The LSP fragment extension feature allows an IS-IS router to generate more LSP fragments. Up to 50
additional virtual systems can be configured on the router, and each virtual system is capable of
generating 256 LSP fragments to enable the IS-IS router to generate up to 13056 LSP fragments.
•
Terms:
{
{
{
{
{
{
•
Originating system—The router actually running IS-IS. After LSP fragment extension is enabled,
additional virtual systems can be configured for the router. Originating system is the IS-IS
process that originally runs.
System ID—The system ID of the originating system.
Additional system ID—Additional virtual system IDs are configured for the IS-IS router after LSP
fragment extension is enabled. Each additional system ID can generate 256 LSP fragments.
Both the additional system ID and the system ID must be unique in the entire routing domain.
Virtual system—A virtual system is identified by an additional system ID and generates
extended LSP fragments.
Original LSP—The LSP generated by the originating system. The system ID in its LSP ID field is
the system ID of the originating system.
Extended LSP—Extended LSPs are generated by virtual systems. The system ID in its LSP ID field
is the virtual system ID. After additional system IDs are configured, an IS-IS router can advertise
more link state information in extended LSP fragments. Each virtual system can be considered a
virtual router. An extended LSP fragment is advertised by a virtual system identified by an
additional system ID.
Operation modes:
The LSP fragment extension feature operates in the following modes:
{
{
Mode-1—Applicable to a network where some routers do not support LSP fragment extension.
In this mode, adjacencies are formed between the originating system and virtual systems, with
the link cost from the originating system to each virtual system as 0. Each virtual system acts as
a router connected to the originating system in the network, but the virtual systems are
reachable through the originating system only. The IS-IS routers not supporting LSP fragment
extension can operate correctly without modifying the extended LSP fragments received, but
some limitation is imposed on the link state information in the extended LSP fragments
advertised by the virtual systems.
Mode-2—Applicable to a network where all the routers support LSP fragment extension. In this
mode, all the IS-IS routers know which virtual system belongs to which originating system. No
limitation is imposed on the link state information of the extended LSP fragments advertised by
the virtual systems.
The operation mode of LSP fragment extension is configured based on area and routing level.
Mode-1 allows the routers supporting and not supporting LSP fragment extension to interoperate
with each other, but it restricts the link state information in the extended fragments. Mode-2 does
not restrict the link state information in the extended fragments, and is recommended for an area
where all the routers are at the same routing level and support LSP fragment extension.
125
Dynamic host name mapping mechanism
The dynamic host name mapping mechanism provides the mappings between the host names and the
system IDs for the IS-IS routers. The dynamic host name information is announced in the dynamic host
name CLV of an LSP.
This mechanism also provides the mapping between a host name and the DIS of a broadcast network,
which is announced in the dynamic host name TLV of a pseudonode LSP.
A host name is easier to remember than a system ID. After enabling this feature on the router, you can see
the host names instead of system IDs by using the display command.
BFD
BFD provides a single mechanism to quickly detect any link failures between IS-IS neighbors to reduce
network convergence time.
For more information about BFD, see High Availability Configuration Guide.
Protocols and standards
•
ISO 10589, ISO IS-IS Routing Protocol
•
ISO 9542, ES-IS Routing Protocol
•
ISO 8348/Ad2, Network Services Access Points
•
RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
•
RFC 2763, Dynamic Hostname Exchange Mechanism for IS-IS
•
RFC 2966, Domain-wide Prefix Distribution with Two-Level IS-IS
•
RFC 2973, IS-IS Mesh Groups
•
RFC 3277, IS-IS Transient Blackhole Avoidance
•
RFC 3358, Optional Checksums in ISIS
•
RFC 3373, Three-Way Handshake for IS-IS Point-to-Point Adjacencies
•
RFC 3567, Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication
•
RFC 3719, Recommendations for Interoperable Networks using IS-IS
•
RFC 3786, Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
•
RFC 3787, Recommendations for Interoperable IP Networks using IS-IS
•
RFC 3784, IS-IS extensions for Traffic Engineering
•
RFC 3847, Restart signaling for IS-IS
IS-IS configuration task list
Task
Remarks
Enabling IS-IS
Configuring IS-IS
basic functions
Configuring the IS level and circuit level
Required.
Configuring the network type of an interface as P2P
Configuring IS-IS
routing information
Configuring IS-IS link cost
Optional.
Specifying a priority for IS-IS
Required.
126
Task
control
Configuring a DIS
priority for an
interface
Enhancing IS-IS
network security
Remarks
Configuring the maximum number of ECMP routes
Optional.
Configuring IS-IS route summarization
Optional.
Advertising a default route
Optional.
Configuring IS-IS route redistribution
Optional.
Configuring IS-IS route filtering
Optional.
Configuring IS-IS route leaking
Optional.
Specifying intervals for sending IS-IS hello and CSNP packets
Optional.
Specifying the IS-IS hello multiplier
Optional.
Configuring a DIS priority for an interface
Optional.
Disabling an interface from sending/receiving IS-IS packets
Optional.
Disabling hello source address check for a PPP interface
Optional.
Enabling an interface to send small hello packets
Optional.
Configuring LSP parameters
Optional.
Configuring SPF parameters
Optional.
Assigning a high priority to IS-IS routes
Optional.
Setting the LSDB overload bit
Optional.
Configuring system ID to host name mappings
Optional.
Enabling the logging of neighbor state changes
Optional.
Configuring neighbor relationship authentication
Optional.
Configuring area authentication
Optional.
Configuring routing domain authentication
Optional.
Configuring IS-IS GR
Optional.
Enabling IS-IS SNMP trap
Optional
Binding an IS-IS process with MIBs
Optional
Configuring BFD for IS-IS
Optional.
Configuring IS-IS basic functions
This section describes the basic settings required for an IS-IS network to run.
Configuration prerequisites
Before the configuration, complete the following tasks:
•
Configure the link layer protocol.
•
Configure IP addresses for all interfaces, and make sure that all neighboring nodes are reachable
to each other at the network layer.
127
Enabling IS-IS
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the IS-IS routing
process and enter its view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
Not enabled by default.
3.
Assign a network entity title.
network-entity net
Not assigned by default.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Enable an IS-IS process on the
interface.
isis enable [ process-id ]
Disabled by default.
Configuring the IS level and circuit level
If only one area exists, perform the following operations:
•
Configure the IS level of all routers as Level-1 or Level-2 rather than different levels because the
routers do not need to maintain two identical LSDBs.
•
Configure the IS level as Level-2 on all routers in an IP network for good scalability.
For an interface of a Level-1 (or Level-2) router, the circuit level can only be Level-1 (or Level-2). For an
interface of a Level-1-2 router, the default circuit level is Level-1-2; if the router only needs to form Level-1 (or
Level-2) neighbor relationships, configure the circuit level for its interfaces as Level-1 (or Level-2) to limit
neighbor relationship establishment.
To configure the IS level and circuit level:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the IS level.
is-level { level-1 | level-1-2 |
level-2 }
Optional.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
The default is Level-1-2.
Optional.
6.
Specify the circuit level.
isis circuit-level [ level-1 | level-1-2
| level-2 ]
An interface can establish either the
Level-1 or Level-2 adjacency by
default.
Configuring the network type of an interface as P2P
Perform this task only for a broadcast network that has up to two attached routers.
128
Interfaces with different network types operate differently. For example, broadcast interfaces on a
network must elect the DIS and flood CSNP packets to synchronize the LSDBs, but P2P interfaces on a
network do not need to elect the DIS, and have a different LSDB synchronization mechanism.
If only two routers exist on a broadcast network, configure the network type of attached interfaces as P2P
to avoid DIS election and CSNP flooding, saving network bandwidth and speeding up network
convergence.
To configure the network type of 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 network type for the
interface as P2P.
Optional.
isis circuit-type p2p
By default, the network type
of an interface depends on
the physical media.
Configuring IS-IS routing information control
Perform the tasks in this section to affect IS-IS route selection.
Configuration prerequisites
Before the configuration, complete the following tasks:
•
Configure IP addresses for all interfaces, and make sure that all neighboring nodes are reachable
to each other at the network layer.
•
Enable IS-IS.
Configuring IS-IS link cost
The IS-IS cost of an interface is determined in the following order:
1.
IS-IS cost specified in interface view.
2.
IS-IS cost specified in system view. The cost is applied to the interfaces associated with the IS-IS
process.
3.
Automatically calculated cost. If the cost style is wide or wide-compatible, IS-IS automatically
calculates the cost using the formula: Interface cost = (Bandwidth reference value / Interface
bandwidth) ×10, which is in the range of 1 to 16777214. For other cost styles, Table 6 applies.
Table 6 Automatic cost calculation scheme for cost styles other than wide and wide-compatible
Interface bandwidth
Interface cost
≤ 10 Mbps
60
≤ 100 Mbps
50
≤ 155 Mbps
40
≤ 622 Mbps
30
129
Interface bandwidth
Interface cost
≤ 2500 Mbps
20
> 2500 Mbps
10
4.
If none of the above costs is used, a default cost of 10 applies.
Configuring an IS-IS cost for an interface
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify an IS-IS cost style.
cost-style { narrow | wide | wide-compatible
| { compatible | narrow-compatible }
[ relax-spf-limit ] }
Optional.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type interface-number
N/A
6.
Specify a cost for the
interface.
isis [ ipv6-unicast ] cost value [ level-1 |
level-2 ]
The default is narrow.
Optional.
No cost is specified for the
interface by default.
Configuring a global IS-IS cost
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Specify an IS-IS
cost style.
cost-style { narrow | wide | wide-compatible |
{ compatible | narrow-compatible }
[ relax-spf-limit ] }
Optional.
Specify a global
IS-IS cost.
circuit-cost value [ level-1 | level-2 ]
4.
narrow by default.
No global cost is specified
by default.
Enabling automatic IS-IS cost calculation
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify an IS-IS cost style.
cost-style { wide | wide-compatible }
narrow by default.
4.
Enable automatic IS-IS cost
calculation.
auto-cost enable
Disabled by default.
5.
Configure a bandwidth
reference value for
automatic IS-IS cost
calculation.
bandwidth-reference value
130
Optional.
100 Mbps by default.
Specifying a priority for IS-IS
A router can run multiple routing protocols. When routes to the same destination are found by multiple
routing protocols, the route learned by the protocol with the highest priority is adopted. You can
reference a routing policy to specify a priority for specific routes. For information about routing policy,
see "Configuring routing policies."
To configure the priority of IS-IS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Specify a priority for IS-IS.
preference { route-policy route-policy-name |
preference } *
15 by default.
Configuring the maximum number of ECMP routes
Perform this task to implement load sharing over ECMP routes.
To configure the maximum number of ECMP routes:
Step
Command
1.
Enter system view.
system-view
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
3.
Specify the maximum number of ECMP
routes for load balancing.
maximum load-balancing number
Configuring IS-IS route summarization
This task allows you to configure a summary route, so routes within the network range of the summary
route are summarized into one route for advertisement. Doing so can reduce the size of routing tables, as
well as the scale of LSP and LSDB. Both IS-IS routes and redistributed routes can be summarized.
The router summarizes only the routes in the locally generated LSPs. The cost of the summary route is the
lowest one among the costs of summarized routes.
To configure route summarization:
Step
Command
Remarks
1.
Enter system
view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Configure IS-IS
route
summarization.
summary ip-address { mask | mask-length }
[ avoid-feedback | generate_null0_route |
[ level-1 | level-1-2 | level-2 | tag tag ] *
No route summarization is
configured by default.
131
Advertising a default route
A router running IS-IS cannot redistribute any default routes or advertise a default route to neighbors.
Perform this task to advertise a default route of 0.0.0.0/0 to the same level neighbors.
You can use a routing policy to generate the default route only when a local routing entry is matched by
the policy.
To advertise a default route:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Advertise a default
route.
default-route-advertise [ route-policy
route-policy-name | [ level-1 | level-1-2 |
level-2 ] ] *
By default, the function is disabled.
Configuring IS-IS route redistribution
Redistributing large numbers of routes on a device might affect the performance of other devices in the
network. If this happens, you can configure a limit on the number of redistributed routes in order to limit
the number of routes to be advertised.
Only active routes can be redistributed. To verify route state, use the display ip routing-table protocol
command.
To configure IS-IS route redistribution from other routing protocols:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Redistribute routes
from another routing
protocol.
import-route protocol [ process-id |
all-processes | allow-ibgp ] [ cost cost |
cost-type { external | internal } | [ level-1 |
level-1-2 | level-2 ] | route-policy
route-policy-name | tag tag ] *
No route is redistributed by
default.
Configure the
maximum number of
redistributed Level
1/Level 2 IPv4
routes.
import-route limit number
Optional.
4.
If no level is specified, routes are
redistributed into the Level-2
routing table by default.
Configuring IS-IS route filtering
You can reference a configured ACL, IP prefix list, or routing policy to filter routes calculated from the
received LSPs and the routes redistributed from other routing protocols.
132
Filtering routes calculated from received LSPs
IS-IS saves the LSPs received from neighbors in the LSDB, uses the SPF algorithm to calculate the shortest
path tree with itself as the root, and installs the routes into the IS-IS routing table.
By referencing a configured ACL, IP prefix list, or routing policy, you can filter the calculated routes. Only
the routes matching the filter can be added into the IS-IS routing table.
To filter routes calculated from received LSPs:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Filter routes calculated
from received LSPs.
filter-policy { acl-number | ip-prefix
ip-prefix-name | route-policy route-policy-name }
import
No filtering is configured by
default.
Filtering redistributed routes
IS-IS can redistribute routes from other routing protocols or other IS-IS processes, add them into the IS-IS
routing table, and advertise them in LSPs.
By reference a configured ACL, IP prefix list, or routing policy, you can filter redistributed routes and only
the routes matching the filter can be added into the IS-IS routing table and advertised to neighbors.
To configure the filtering of redistributed routes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Configure the filtering of
routes redistributed from
another routing protocol or
IS-IS process.
filter-policy { acl-number | ip-prefix
ip-prefix-name | route-policy
route-policy-name } export [ protocol
[ process-id ] ]
Not configured by
default.
Configuring IS-IS route leaking
With IS-IS route leaking enabled, the Level-1-2 router can advertise the routing information of other Level-1
areas and Level-2 area routing information to Level-1 routers.
If a filter policy is specified, only routes passing it can be advertised into Level-1 area.
You can specify a routing policy in the import-route isis level-2 into level-1 command to filter routes from
Level-2 to Level-1. Other routing policies specified for route reception and redistribution does not affect the
route leaking.
To configure IS-IS route leaking:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
133
Step
Command
Remarks
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Enable IS-IS route
leaking.
import-route isis level-2 into level-1 [ filter-policy
{ acl-number | ip-prefix ip-prefix-name | route-policy
route-policy-name } | tag tag ] *
Disabled by
default.
Tuning and optimizing IS-IS networks
Configuration prerequisites
Before the configuration, complete the following tasks:
•
Configure IP addresses for all interfaces, and make sure that all neighboring nodes are reachable
to each other at the network layer.
•
Enable IS-IS.
Specifying intervals for sending IS-IS hello and CSNP packets
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Specify the interval for
sending hello packets.
isis timer hello seconds [ level-1 |
level-2 ]
Optional.
Specify the interval for
sending CSNP packets on the
DIS of a broadcast network.
isis timer csnp seconds [ level-1 |
level-2 ]
Optional.
4.
10 seconds by default.
10 seconds by default.
The interval between hello packets sent by the DIS is 1/3 the hello interval set with the isis timer hello
command.
Specifying the IS-IS hello multiplier
If a neighbor receives no hello packets from the router within the advertised hold time, it considers the
router down and recalculates the routes.
With GR enabled, the hold time is the hello multiplier multiplied by the hello interval.
Without GR enabled, the hold time is the GR interval.
On a broadcast link, Level-1 and Level-2 hello packets are advertised separately. You must set a hello
multiplier for each level.
On a P2P link, Level-1 and Level-2 hello packets are advertised in P2P hello packets. You do not need to
specify Level-1 or Level-2.
To specify the IS-IS hello multiplier:
134
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Specify the number of hello packets a
neighbor must miss before declaring
the router is down.
isis timer holding-multiplier value
[ level-1 | level-2 ]
Optional.
3 by default.
Configuring a DIS priority for an interface
On a broadcast network, ISIS must elect a router as the DIS at a routing level. You can specify a DIS
priority at a level for an interface. The greater the interface's priority, the more likely it becomes the DIS.
If multiple routers in the broadcast network have the same highest DIS priority, the router with the highest
MAC address becomes the DIS.
To specify a DIS priority 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.
Specify a DIS priority for the
interface.
isis dis-priority value [ level-1 |
level-2 ]
Optional.
64 by default.
Disabling an interface from sending/receiving IS-IS packets
After being disabled from sending and receiving hello packets, an interface cannot form any neighbor
relationship, but can advertise directly connected networks in LSPs through other interfaces. This can save
bandwidth and CPU resources, and ensures other routers know networks directly connected to the
interface.
To disable an interface from sending and receiving IS-IS packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Disable the interface from
sending and receiving IS-IS
packets.
isis silent
Not disabled by default.
Disabling hello source address check for a PPP interface
On a P2P link, IS-IS verifies the source IP address of the incoming hello packets is in the same network
segment as the IP address of the receiving interface. If not, it discards the hello packets, and no neighbor
relationship can be established with the peer router.
135
If a PPP interface's peer IP address is on a different network segment, disable the hello source address
check for the PPP interface to establish the neighbor relationship with the peer.
To enable neighbor relationships over different network segments:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Disable hello source
address check for the PPP
interface.
isis peer-ip-ignore
The command only applies to the PPP
interface.
By default, hello source address check
is enabled.
Enabling an interface to send small hello packets
IS-IS messages cannot be fragmented at the IP layer because they are directly encapsulated into frames.
Any two IS-IS neighboring routers must negotiate a common MTU. To avoid sending big hellos for saving
bandwidth, enable the interface to send small hello packets without CLVs.
To enable an interface to send small hello packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Enable the interface to send
small hello packets without
CLVs.
isis small-hello
Standard hello packets are sent by
default.
Configuring LSP parameters
Configuring LSP timers
1.
Specify the maximum age of LSPs
Each LSP has an age that decreases in the LSDB. Any LSP with an age of 0 is deleted from the LSDB.
You can adjust the age value based on the scale of a network.
To specify the maximum age of LSPs:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the maximum LSP
age.
timer lsp-max-age seconds
2.
Specify the LSP refresh interval and generation interval
136
Optional.
1200 seconds by default.
Each router needs to refresh LSPs generated by itself at a configurable interval and send them to
other routers to prevent valid routes from being aged out. A smaller refresh interval speeds up
network convergence but consumes more bandwidth.
When the network topology changes, for example, a neighbor is down or up, or the interface
metric, system ID, or area ID is changed, the router generates an LSP after a configurable interval.
If such a change occurs frequently, excessive LSPs are generated, consuming a large amount of
router resources and bandwidth. To resolve this issue, you can adjust the LSP generation interval.
To specify the LSP refresh interval and generation interval:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the LSP refresh
interval.
timer lsp-refresh seconds
The default interval is
900 seconds.
4.
Specify the LSP
generation interval.
timer lsp-generation maximum-interval
[ initial-interval [ second-wait-interval ] ] [ level-1
| level-2 ]
Optional.
3.
Optional.
The default interval is
2 seconds.
Specify LSP sending intervals
If a change occurs in the LSDB, IS-IS advertises the changed LSP to neighbors. You can specify the
minimum interval for sending such LSPs.
On a P2P link, IS-IS requires an advertised LSP be acknowledged. If no acknowledgement is
received within a configurable interval, IS-IS will retransmit the LSP.
To configure LSP sending intervals:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Specify the minimum
interval for sending LSPs
and the maximum LSP
number that can be sent at a
time.
Optional.
isis timer lsp time [ count
count ]
By default, the minimum interval is
33 milliseconds, and the maximum
LSP number that can be sent at a
time is 5.
Optional.
4.
Specify the LSP
retransmission interval on a
P2P link.
5 seconds by default.
isis timer retransmit seconds
Configure a proper LSP
retransmission interval to avoid
unnecessary retransmissions.
Specifying LSP lengths
IS-IS messages cannot be fragmented at the IP layer because they are directly encapsulated in frames.
IS-IS routers in an area must send LSPs smaller than the smallest interface MTU in this area.
137
If the IS-IS routers have different interface MTUs, HP recommends configuring the maximum size of
generated LSP packets to be smaller than the smallest interface MTU in this area. Otherwise, the routers
must dynamically adjust the LSP packet size to fit the smallest interface MTU, which takes time and affects
other services.
To specify LSP lengths:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the maximum length
of generated Level-1 LSPs or
Level-2 LSPs.
lsp-length originate size [ level-1 | level-2 ]
1497 bytes by default.
Specify the maximum length
of received LSPs.
lsp-length receive size
1497 bytes by default.
4.
Enabling LSP flash flooding
Changed LSPs can trigger SPF recalculation. To advertise the changed LSPs before the router recalculates
routes for faster network convergence, enable LSP flash flooding.
To enable LSP flash flooding:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Enable LSP flash
flooding.
flash-flood [ flood-count flooding-count |
max-timer-interval flooding-interval | [ level-1 |
level-2 ] ] *
Not enabled by
default.
Enabling LSP fragment extension
After LSP fragment extension is enabled for an IS-IS process, the MTUs of all the interfaces running the
IS-IS process must not be less than 512. Otherwise, LSP fragment extension will not take effect.
At least one virtual system must be configured for the router to generate extended LSP fragments. An IS-IS
process allows a maximum of 50 virtual systems.
To enable LSP fragment extension:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Enable LSP fragment
extension and specify the
working mode.
lsp-fragments-extend [ [ level-1 | level-1-2 |
level-2 ] | [ mode-1 | mode-2 ] ] *
Not enabled by default.
Configure a virtual system
ID.
virtual-system virtual-system-id
Not configured by default.
4.
138
Limiting LSP flooding
In well-connected ATM, FR and NBMA networks, many P2P links exist. Figure 41 shows a fully meshed
network, where Routers A, B, C and D run IS-IS. When Router A generates an LSP, it floods the LSP out
of Ethernet 1/1, Ethernet 1/2 and Ethernet 1/3. After receiving the LSP from Ethernet 1/3, Router D
floods it out of Ethernet 1/1 and Ethernet 1/2 to Router B and Router C. However, Router B and Router
C have already received the LSP from Router A. LSP flooding consumes extra bandwidth.
Figure 41 Network diagram of a fully meshed network
Router D
Router A
Eth1/1
Eth1/2
Eth1/3
Eth1/1
Eth1/2
Eth1/3
Eth1/3
Eth1/2
Eth1/2
Eth1/1
Eth1/1
Eth1/3
Router B
Router C
To avoid this, configure some interfaces as a mesh group, configure the blocked interfaces, or both.
•
After receiving an LSP, a member interface in a mesh group floods it out of the interfaces that do not
belong to the mesh group.
•
If an interface is blocked, it does not send LSPs unless the neighbor sends LSP requests to it.
Before you configure this task, you must consider redundancy for interfaces in case that LSP packets
cannot be flooded due to link failures.
To add an interface into a mesh group and block an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
• Add the interface to a mesh
Use either method.
3.
Add the interface to a mesh
group, or block the interface.
group:
isis mesh-group
mesh-group-number
• Block the interface:
isis mesh-group mesh-blocked
By default, the interface neither
belongs to any mesh group nor is it
blocked.
The mesh group feature takes effect
only on P2P interfaces.
Configuring SPF parameters
When the LSDB changes on a router, a route calculation starts. Frequent route calculations consume a lot
of system resources. You can set an appropriate interval for SPF calculations to improve efficiency.
To configure the SPF parameters:
139
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Configure the SPF
calculation interval.
timer spf maximum-interval [ initial-interval
[ second-wait-interval ] ]
Optional.
The default SPF calculation
interval is 10 seconds.
Assigning a high priority to IS-IS routes
An IS-IS topology change causes network convergence. By assigning a high priority to specific IS-IS
routes, you can achieve faster network convergence.
To assign a high priority to IS-IS routes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
Optional.
Not assigned by default.
3.
Assign a high priority to IS-IS
routes.
priority high { ip-prefix
prefix-name | tag tag-value }
If no IS-IS route is assigned a high
priority, IS-IS host routes are
processed first in network
convergence because they have
higher priority than other types of
IS-IS routes.
Setting the LSDB overload bit
By setting the overload bit in sent LSPs, a router informs other routers of a failure that makes it incapable
of routing and forwarding packets.
When an IS-IS router cannot record the complete LSDB due to running out of memory or some other
reasons, it will calculate wrong routes. To make troubleshooting easier, temporarily isolate the router from
the IS-IS network by setting the overload bit.
To set the LSDB overload bit:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Set the overload bit.
set-overload [ on-startup [ [ start-from-nbr system-id
[ timeout1 [ nbr-timeout ] ] ] | timeout2 ] [ allow { external
| interlevel } * ]
Not set by default.
140
Configuring system ID to host name mappings
In IS-IS, a system ID identifies a router or host uniquely. A system ID has a fixed length of 6 bytes. When
an administrator needs to view IS-IS neighbor information, routing table, or LSDB information, using the
system IDs in dotted decimal notation is not convenient. To solve it, configure the mappings between
system IDs and host names, as host names are easier to remember and use.
Such mappings can be configured manually or dynamically. Note the following:
•
When you use the display isis lsdb command on a router configured with dynamic system ID to host
name mapping, router names rather than system IDs are displayed.
•
If you configure both dynamic and static system ID to host name mappings on a router, the host
name for dynamic system ID to host name mapping applies.
Configuring a static system ID to host name mapping
To configure a static system ID to host name mapping:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Configure a system ID to host
name mapping for a remote
IS.
is-name map sys-id map-sys-name
A system ID can only correspond to
a host name.
Configuring dynamic system ID to host name mapping
You must configure a static system ID to host name mapping for any other router in a network. When a
new router is added into the network or a mapping must be modified, perform configuration on all
routers.
You can configure dynamic system ID to host name mapping. To do so, you must configure a host name
for each router in the network. Each router advertises the host name in dynamic host name CLVs to other
routers. All routers in the network then have all the mappings to generate a mapping table.
To help check the origin of LSPs in the LSDB, you can configure a name for the DIS in a broadcast
network.
To configure dynamic system ID to host name mapping:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify a host name
for the router.
is-name sys-name
Not specified by default.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
141
Step
Command
Remarks
Optional.
Not configured by default.
Configure a DIS name.
6.
isis dis-name symbolic-name
This command takes effect only on a
router with dynamic system ID to host
name mapping configured.
This command is not supported on P2P
interfaces.
Enabling the logging of neighbor state changes
Logging of neighbor state changes enables the router to output neighbor state changes to the console
terminal.
To enable the logging of neighbor state changes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Enable the logging of
neighbor state changes.
log-peer-change
Enabled by default.
Enhancing IS-IS network security
To enhance the security of an IS-IS network, you can configure IS-IS authentication. IS-IS authentication
involves neighbor relationship authentication, area authentication, and routing domain authentication.
Configuration prerequisites
Before the configuration, complete the following tasks:
•
Configure network layer addresses for interfaces to make neighboring nodes accessible to each
other at the network layer.
•
Enable IS-IS.
Configuring neighbor relationship authentication
With neighbor relationship authentication configured, an interface adds the password in the specified
mode into hello packets to the peer and checks the password in the received hello packets. If the
authentication succeeds, it forms the neighbor relationship with the peer.
Follow these guidelines when you configure neighbor relationship authentication:
•
The authentication mode and password at both ends must be identical.
•
The level-1 and level-2 keywords are configurable on an interface that has IS-IS enabled with the
isis enable command.
•
If you configure an authentication mode and a password without specifying a level, the
authentication mode and password apply to both Level-1 and Level-2.
142
If neither ip nor osi is specified, the OSI related fields in LSPs are checked.
•
To configure neighbor relationship authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type interface-number
N/A
3.
Specify the authentication
mode and password.
isis authentication-mode { md5 | simple }
[ cipher ] password [ level-1 | level-2 ]
[ ip | osi ]
By default, no authentication
is configured.
Configuring area authentication
Area authentication enables a router not to install routing information from untrusted routers into the
Level-1 LSDB. The router encapsulates the authentication password in the specified mode into Level-1
packets (LSP, CSNP, and PSNP) and check the password in received Level-1 packets.
Routers in a common area must have the same authentication mode and password.
To configure area authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the area
authentication mode and
password.
area-authentication-mode { md5 |
simple } [ cipher ] password [ ip | osi ]
By default, no area authentication
is configured.
Configuring routing domain authentication
Routing domain authentication prevents untrusted routing information from entering into a routing
domain. A router with the authentication configured encapsulates the password in the specified mode
into Level-2 packets (LSP, CSNP, and PSNP) and check the password in received Level-2 packets.
All the routers in the backbone must have the same authentication mode and password.
To configure routing domain authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Specify the routing domain
authentication mode and
password.
domain-authentication-mode
{ md5 | simple } [ cipher ]
password [ ip | osi ]
By default, no routing domain
authentication is configured by
default.
143
Configuring IS-IS GR
Restarting IS-IS on a router will cause 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") keep their adjacencies with the
router within a configurable GR interval. After the restart, the router contacts its neighbors to retrieve its
routing table.
During this process, the network keeps stable.
To configure GR on the GR restarter and GR helper:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable IS-IS and
enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
Disabled by default.
3.
Enable the GR
capability for IS-IS.
graceful-restart
Disabled by default.
300 seconds by default.
4.
Set the Graceful
Restart interval.
graceful-restart interval timer
The Graceful Restart interval is set as the
holding time in the hello PDUs. Within the
interval, the neighbors will keep their
adjacency with the GR restarter.
Optional.
5.
Suppress the SA bit
during restart.
By default, the SA bit is not suppressed.
graceful-restart suppress-sa
By enabling the GR restarter to suppress the
Suppress-Advertisement (SA) bit in the hello
PDUs, the neighbors will still advertise their
adjacency with the GR restarter.
Enabling IS-IS SNMP trap
This task enables IS-IS to generate traps and send them to the information center of the device. The
information center determines whether to output the traps and where to output. For more information
about information center, see Network Management and Monitoring Configuration Guide.
To enable IS-IS SNMP trap:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance vpn-instance-name ]
N/A
3.
Enable SNMP trap.
is-snmp-traps enable
Enabled by default.
144
Binding an IS-IS process with MIBs
This task allows you to bind MIB with an IS-IS process to send and collect information. For more
information about MIB, see Network Management and Monitoring Configuration Guide.
To bind an IS-IS process with MIBs:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ] [ vpn-instance
vpn-instance-name ]
N/A
3.
Bind the IS-IS process with
MIBs.
isis mib-binding process-id
By default, MIBs are bound with
IS-IS process 1.
Configuring BFD for IS-IS
To enable BFD on an IS-IS 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 IS-IS on the interface.
isis enable [ process-id ]
Disabled by default.
4.
Enable BFD on the IS-IS
interface.
isis bfd enable
Not enabled by default.
Displaying and maintaining IS-IS
Task
Command
Remarks
Display brief IS-IS configuration
information.
display isis brief [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display the status of IS-IS debug
switches.
display isis debug-switches { process-id |
vpn-instance vpn-instance-name } [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display the IS-IS GR state.
display isis graceful-restart status [ level-1 |
level-2 ] [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display information about IS-IS
enabled interfaces.
display isis interface [ statistics | [ interface-type
interface-number ] [ verbose ] ] [ process-id |
vpn-instance vpn-instance-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
145
Task
Command
Remarks
Display IS-IS LSDB information.
display isis lsdb [ [ l1 | l2 | level-1 | level-2 ] |
[ lsp-id lspid | lsp-name lspname ] | local |
verbose ] * [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display IS-IS mesh group
information.
display isis mesh-group [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display the host-name-to-system-ID
mapping table.
display isis name-table [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display IS-IS neighbor information.
display isis peer [ statistics | verbose ] [ process-id
| vpn-instance vpn-instance-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display IS-IS IPv4 routing
information.
display isis route [ ipv4 ] [ [ level-1 | level-2 ] |
verbose ] * [ process-id
| vpn-instance vpn-instance-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display IS-IS SPF calculation log
information.
display isis spf-log [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display IS-IS statistics.
display isis statistics [ level-1 | level-1-2 | level-2 ]
[ process-id | vpn-instance vpn-instance-name ] [ |
{ begin | exclude | include } regular-expression ]
Available in any
view.
Clear IS-IS process data structure
information.
reset isis all [ process-id | vpn-instance
vpn-instance-name ]
Available in user
view.
Clear the data structure
information of an IS-IS neighbor.
reset isis peer system-id [ process-id | vpn-instance
vpn-instance-name ]
Available in user
view.
IS-IS configuration examples
IS-IS basic configuration
Network requirements
As shown in Figure 42, Routers A, B, C, and D reside in an autonomous system. They are interconnected
through IS-IS.
Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router C is a Level-1-2 router
connecting two areas. Router A, Router B, and Router C are in area 10, and Router D is in area 20.
146
Figure 42 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IS-IS:
# Configure Router A.
<RouterA> system-view
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA] interface serial 2/0
[RouterA-Serial2/0] isis enable 1
[RouterA-Serial2/0] quit
# Configure Router B.
<RouterB> system-view
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB] interface serial 2/0
[RouterB-Serial2/0] isis enable 1
[RouterB-Serial2/0] quit
# Configure Router C.
<RouterC> system-view
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC] interface serial 2/0
[RouterC-Serial2/0] isis enable 1
[RouterC-Serial2/0] quit
[RouterC] interface serial 2/1
[RouterC-Serial2/1] isis enable 1
[RouterC-Serial2/1] quit
147
[RouterC] interface serial 2/2
[RouterC-Serial2/2] isis enable 1
[RouterC-Serial2/2] quit
# Configure Router D.
<RouterD> system-view
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD] interface ethernet 1/1
[RouterD-Ethernet1/1] isis enable 1
[RouterD-Ethernet1/1] quit
[RouterD] interface serial 2/0
[RouterD-Serial2/0] isis enable 1
[RouterD-Serial2/0] quit
3.
Verify the configuration:
# Display the IS-IS LSDB information.
[RouterA] display isis lsdb
Database information for ISIS(1)
-------------------------------Level-1 Link State Database
LSPID
Seq Num
Checksum
Holdtime
Length
ATT/P/OL
-------------------------------------------------------------------------0000.0000.0001.00-00* 0x0000000d
0xb184
879
68
0/0/0
0000.0000.0002.00-00
0x0000000c
0xcf65
493
68
0/0/0
0000.0000.0003.00-00
0x00000013
0x2f38
594
111
1/0/0
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
[RouterB] display isis lsdb
Database information for ISIS(1)
-------------------------------Level-1 Link State Database
LSPID
Seq Num
Checksum
Holdtime
Length
ATT/P/OL
-------------------------------------------------------------------------0000.0000.0001.00-00
0x0000000d
0xb184
707
68
0/0/0
0000.0000.0002.00-00* 0x0000000c
0xcd66
1167
68
0/0/0
0000.0000.0003.00-00
0x2d39
1136
111
1/0/0
0x00000013
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
[RouterC] display isis lsdb
148
Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID
Seq Num
Checksum
Holdtime
Length
ATT/P/OL
-----------------------------------------------------------------------0000.0000.0001.00-00
0x0000000d
0xc57a
991
68
0/0/0
0000.0000.0002.00-00
0x0000000c
0xef4d
1025
68
0/0/0
0000.0000.0003.00-00* 0x00000013
0x93dd
1026
111
1/0/0
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
Level-2 Link State Database
LSPID
Seq Num
Checksum
Holdtime
Length
ATT/P/OL
-----------------------------------------------------------------------0000.0000.0003.00-00* 0x00000013
0xbb56
1026
100
0/0/0
0000.0000.0004.00-00
0xd086
904
84
0/0/0
0x00000005
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
[RouterD] display isis lsdb
Database information for ISIS(1)
--------------------------------
Level-2 Link State Database
LSPID
Seq Num
Checksum
Holdtime
Length
ATT/P/OL
-----------------------------------------------------------------------0000.0000.0003.00-00
0x00000013
0xbb56
910
100
0/0/0
0000.0000.0004.00-00* 0x00000005
0xd086
791
84
0/0/0
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
# Display the IS-IS routing information on each router. The routing table of Level-1 routers must
contain a default route with the next hop being the Level-1-2 router. The routing table of Level-2
router must contain all Level-1 and Level-2 routes.
[RouterA] display isis route
Route information for ISIS(1)
-----------------------------
ISIS(1) IPv4 Level-1 Forwarding Table
-------------------------------------
149
IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/0
Direct
D/L/-
10.1.2.0/24
20
NULL
S2/0
10.1.1.1
R/-/-
192.168.0.0/24
20
NULL
S2/0
10.1.1.1
R/-/-
0.0.0.0/0
10
NULL
S2/0
10.1.1.1
R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterC] display isis route
Route information for ISIS(1)
----------------------------ISIS(1) IPv4 Level-1 Forwarding Table
------------------------------------IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
ISIS(1) IPv4 Level-2 Forwarding Table
------------------------------------IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
172.16.0.0/16
20
NULL
S2/2
192.168.0.2
R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterD] display isis route
Route information for ISIS(1)
-----------------------------
ISIS(1) IPv4 Level-2 Forwarding Table
-------------------------------------
IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
--------------------------------------------------------------------------
150
192.168.0.0/24
10
NULL
S2/0
Direct
D/L/-
10.1.1.0/24
20
NULL
S2/0
192.168.0.1
R/-/-
10.1.2.0/24
20
NULL
S2/0
192.168.0.1
R/-/-
172.16.0.0/16
10
NULL
Eth1/1
Direct
D/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
DIS election configuration
Network requirements
As shown in Figure 43, on a broadcast network (Ethernet), Router A, Router B, Router C, and Router D
reside in IS-IS area 10. Router A and Router B are Level-1-2 routers, Router C is a Level-1 router, and Router
D is a Level-2 router.
Change the DIS priority of Router A to make it elected as the Level-1-2 DIS router.
Figure 43 Network diagram
Router A
L1/L2
Router B
L1/L2
Eth1/1
10.1.1.1/24
Eth1/1
10.1.1.3/24
Eth1/1
10.1.1.2/24
Eth1/1
10.1.1.4/24
Router C
L1
Router D
L2
Configuration procedure
1.
Configure an IP address for each interface. (Details not shown.)
2.
Enable IS-IS:
# Configure Router A.
<RouterA> system-view
[RouterA] isis 1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis enable 1
[RouterA-Ethernet1/1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] isis 1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
151
[RouterB-isis-1] quit
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] isis enable 1
[RouterB-Ethernet1/1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] is-level level-1
[RouterC-isis-1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] isis enable 1
[RouterC-Ethernet1/1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] isis 1
[RouterD-isis-1] network-entity 10.0000.0000.0004.00
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] quit
[RouterD] interface ethernet 1/1
[RouterD-Ethernet1/1] isis enable 1
[RouterD-Ethernet1/1] quit
# Display information about IS-IS neighbors of Router A.
[RouterA] display isis peer
Peer information for ISIS(1)
---------------------------System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0003.01
State: Up
Type: L1(L1L2)
HoldTime: 21s
PRI: 64
System Id: 0000.0000.0003
Interface: Ethernet1/1
Circuit Id: 0000.0000.0003.01
State: Up
Type: L1
HoldTime: 6s
PRI: 64
System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0004.01
State: Up
Type: L2(L1L2)
HoldTime: 23s
PRI: 64
System Id: 0000.0000.0004
Interface: Ethernet1/1
Circuit Id: 0000.0000.0004.01
State: Up
Type: L2
HoldTime: 23s
PRI: 64
# Display information about IS-IS interfaces of Router A.
[RouterA] display isis interface
Interface information for ISIS(1)
---------------------------------
152
Interface: Ethernet1/1
Id
IPV4.State
IPV6.State
MTU
Type
DIS
001
Up
Down
1497
L1/L2
No/No
# Display IS-IS interfaces of Router C.
[RouterC] display isis interface
Interface information for ISIS(1)
--------------------------------Interface: Ethernet1/1
Id
IPV4.State
001
Up
IPV6.State
Down
MTU
Type
DIS
1497
L1/L2
Yes/No
# Display information about IS-IS interfaces of Router D.
[RouterD] display isis interface
Interface information for ISIS(1)
--------------------------------Interface: Ethernet1/1
Id
IPV4.State
001
Up
IPV6.State
Down
MTU
Type
DIS
1497
L1/L2
No/Yes
By using the default DIS priority, Router C is the Level-1 DIS, and Router D is the Level-2 DIS. The
pseudonodes of Level-1 and Level-2 are 0000.0000.0003.01 and 0000.0000.0004.01,
respectively.
3.
Configure the DIS priority of Router A:
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis dis-priority 100
# Display information about IS-IS neighbors of Router A.
[RouterA] display isis peer
Peer information for ISIS(1)
---------------------------System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L1(L1L2)
HoldTime: 29s
PRI: 64
System Id: 0000.0000.0003
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L1
HoldTime: 22s
PRI: 64
System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L2(L1L2)
HoldTime: 22s
PRI: 64
System Id: 0000.0000.0004
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L2
HoldTime: 22s
153
PRI: 64
# Display information about IS-IS interfaces of Router A.
[RouterA] display isis interface
Interface information for ISIS(1)
--------------------------------Interface: Ethernet1/1
Id
IPV4.State
001
Up
IPV6.State
Down
MTU
Type
DIS
1497
L1/L2
Yes/Yes
After the DIS priority configuration, you can see Router A is the DIS for Level-1-2, and the
pseudonode is 0000.0000.0001.01.
# Display information about IS-IS neighbors and interfaces of Router C.
[RouterC] display isis peer
Peer information for ISIS(1)
----------------------------
System Id: 0000.0000.0001
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L1
HoldTime: 7s
PRI: 100
System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L1
HoldTime: 23s
PRI: 64
[RouterC] display isis interface
Interface information for ISIS(1)
--------------------------------Interface: Ethernet1/1
Id
IPV4.State
IPV6.State
MTU
Type
DIS
001
Up
Down
1497
L1/L2
No/No
# Display information about IS-IS neighbors and interfaces of Router D.
[RouterD] display isis peer
Peer information for ISIS(1)
----------------------------
System Id: 0000.0000.0001
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L2
HoldTime: 7s
PRI: 100
System Id: 0000.0000.0002
Interface: Ethernet1/1
Circuit Id: 0000.0000.0001.01
State: Up
Type: L2
HoldTime: 26s
PRI: 64
[RouterD] display isis interface
Interface information for ISIS(1)
--------------------------------Interface: Ethernet1/1
154
Id
IPV4.State
IPV6.State
MTU
Type
DIS
001
Up
Down
1497
L1/L2
No/No
Configuring IS-IS route redistribution
Network requirements
As shown in Figure 44, Router A, Router B, Router C, and Router D reside in the same AS. They use IS-IS
to interconnect. Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router C is a
Level-1-2 router.
Redistribute RIP routes into IS-IS on Router D.
Figure 44 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IS-IS basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA] interface serial 2/0
[RouterA-Serial2/0] isis enable 1
[RouterA-Serial2/0] quit
# Configure Router B.
<RouterB> system-view
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB] interface serial 2/0
[RouterB-Serial2/0] isis enable 1
[RouterB-Serial2/0] quit
155
# Configure Router C.
<RouterC> system-view
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC] interface serial 2/0
[RouterC-Serial2/0] isis enable 1
[RouterC-Serial2/0] quit
[RouterC] interface serial 2/1
[RouterC-Serial2/1] isis enable 1
[RouterC-Serial2/1] quit
[RouterC] interface serial 2/2
[RouterC-Serial2/2] isis enable 1
[RouterC-Serial2/2] quit
# Configure Router D.
<RouterD> system-view
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD] interface serial 2/0
[RouterD-Serial2/0] isis enable 1
[RouterD-Serial2/0] quit
# Display IS-IS routing information on each router.
[RouterA] display isis route
Route information for ISIS(1)
----------------------------ISIS(1) IPv4 Level-1 Forwarding Table
------------------------------------IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/0
Direct
D/L/-
10.1.2.0/24
20
NULL
S2/0
10.1.1.1
R/-/-
192.168.0.0/24
20
NULL
S2/0
10.1.1.1
R/-/-
0.0.0.0/0
10
NULL
S2/0
10.1.1.1
R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterC] display isis route
Route information for ISIS(1)
-----------------------------
ISIS(1) IPv4 Level-1 Forwarding Table
-------------------------------------
156
IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
ISIS(1) IPv4 Level-2 Forwarding Table
-------------------------------------
IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterD] display isis route
Route information for ISIS(1)
-----------------------------
ISIS(1) IPv4 Level-2 Forwarding Table
-------------------------------------
IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------192.168.0.0/24
10
NULL
S2/0
Direct
D/L/-
10.1.1.0/24
20
NULL
S2/0
192.168.0.1
R/-/-
10.1.2.0/24
20
NULL
S2/0
192.168.0.1
R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
3.
Configure RIPv2 on Router D and Router E, and configure route redistribution from RIP to IS-IS on
Router D:
# Configure RIPv2 on Router D.
[RouterD] rip 1
[RouterD-rip-1] network 10.0.0.0
[RouterD-rip-1] version 2
[RouterD-rip-1] undo summary
# Configure RIPv2 on Router E.
[RouterE] rip 1
[RouterE-rip-1] network 10.0.0.0
[RouterE-rip-1] version 2
[RouterE-rip-1] undo summary
157
# Configure route redistribution from RIP to IS-IS on Router D.
[RouterD-rip-1] quit
[RouterD] isis 1
[RouterD–isis-1] import-route rip level-2
# Display IS-IS routing information on Router C.
[RouterC] display isis route
Route information for ISIS(1)
----------------------------ISIS(1) IPv4 Level-1 Forwarding Table
------------------------------------IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
ISIS(1) IPv4 Level-2 Forwarding Table
------------------------------------IPV4 Destination
IntCost
ExtCost ExitInterface
NextHop
Flags
-------------------------------------------------------------------------10.1.1.0/24
10
NULL
S2/1
Direct
D/L/-
10.1.2.0/24
10
NULL
S2/0
Direct
D/L/-
192.168.0.0/24
10
NULL
S2/2
Direct
D/L/-
10.1.4.0/24
10
NULL
S2/2
192.168.0.2
R/L/-
10.1.5.0/24
20
NULL
S2/2
192.168.0.2
R/L/-
10.1.6.0/24
20
NULL
S2/2
192.168.0.2
R/L/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
IS-IS GR configuration example
Network requirements
Router A, Router B, and Router C belong to the same IS-IS routing domain, as illustrated in Figure 45.
158
Figure 45 Network diagram
Configuration procedure
1.
Configure IP addresses of the interfaces on each router and configure IS-IS:
Follow Figure 45 to configure the IP address and subnet mask of each interface on the router.
(Details not shown.)
Configure IS-IS on the routers, ensuring that Router A, Router B, and Router C can communicate
with each other at Layer 3 and dynamic route update can be implemented among them with IS-IS.
(Details not shown.)
2.
Configure IS-IS Graceful Restart:
# Enable IS-IS Graceful Restart on Router A and configure the Graceful Restart interval.
<RouterA> system-view
[RouterA] isis 1
[RouterA-isis-1] graceful-restart
[RouterA-isis-1] graceful-restart interval 150
[RouterA-isis-1] return
The configurations for Router B and Router C are similar. (Details not shown.)
3.
Verify the configuration:
After Router A establishes adjacencies with Router B and Router C, they begin to exchange routing
information. Restart IS-IS on Router A, which enters the restart state and sends connection requests
to its neighbors through the Graceful Restart mechanism to synchronize the LSDB. Using the
display isis graceful-restart status command can display the IS-IS GR status on Router A.
# Restart the IS-IS process on Router A.
<RouterA> reset isis all 1
Warning : Reset ISIS process? [Y/N]:y
# Check the IS-IS Graceful Restart state on Router A.
<RouterA> display isis graceful-restart status
Restart information for IS-IS(1)
-------------------------------------------------------------------IS-IS(1) Level-1 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 140
159
T2 Timer Status:
Remaining Time: 59
IS-IS(1) Level-2 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 140
T2 Timer Status:
Remaining Time: 59
IS-IS authentication configuration example
Network requirements
As shown in Figure 46, Router A, Router B, Router C, and Router D reside in the same IS-IS routing
domain.
Router A, Router B, and Router C belong to Area 10, and Router D belongs to Area 20.
Configure neighbor relationship authentication between neighbors. Configure area authentication in
Area 10 to prevent untrusted routes from entering into the area. Configure routing domain authentication
on Router C and Router D to prevent untrusted routes from entering the routing domain.
Figure 46 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IS-IS basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] isis 1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] is-level level-1
160
[RouterA-isis-1] quit
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis enable 1
[RouterA-Ethernet1/1] quit
# Configure Router B.
<RouterB> system-view
[RouterB] isis 1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] quit
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] isis enable 1
[RouterB-Ethernet1/1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] isis enable 1
[RouterC-Ethernet1/1] quit
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] isis enable 1
[RouterC-Ethernet1/2] quit
[RouterC] interface ethernet 1/3
[RouterC-Ethernet1/3] isis enable 1
[RouterC-Ethernet1/3] quit
# Configure Router D.
<RouterD> system-view
[RouterD] isis 1
[RouterD-isis-1] network-entity 20.0000.0000.0001.00
[RouterD-isis-1] quit
[RouterD] interface ethernet 1/1
[RouterD-Ethernet1/1] isis enable 1
[RouterD-Ethernet1/1] quit
3.
Configure neighbor relationship authentication between neighbors:
# Specify the MD5 authentication mode and password eRq on Ethernet 1/1 of Router A and on
Ethernet 1/3 of Router C.
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis authentication-mode md5 eRg
[RouterA-Ethernet1/1] quit
[RouterC] interface ethernet 1/3
[RouterC-Ethernet1/3] isis authentication-mode md5 eRg
[RouterC-Ethernet1/3] quit
# Specify the MD5 authentication mode and password t5Hr on Ethernet 1/1 of Router B and on
Ethernet 1/1 of Router C.
[RouterB] interface ethernet 1/1
161
[RouterB-Ethernet1/1] isis authentication-mode md5 t5Hr
[RouterB-Ethernet1/1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] isis authentication-mode md5 t5Hr
[RouterC-Ethernet1/1] quit
# Specify the MD5 authentication mode and password hSec on Ethernet 1/1 of Router D and on
Ethernet 1/2 of Router C.
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] isis authentication-mode md5 hSec
[RouterC-Ethernet1/2] quit
[RouterD] interface ethernet 1/1
[RouterD-Ethernet1/1] isis authentication-mode md5 hSec
[RouterD-Ethernet1/1] quit
4.
Configure area authentication. Specify the MD5 authentication mode and password 10Sec on
Router A, Router B, and Router C:
[RouterA] isis 1
[RouterA-isis-1] area-authentication-mode md5 10Sec
[RouterA-isis-1] quit
[RouterB] isis 1
[RouterB-isis-1] area-authentication-mode md5 10Sec
[RouterB-isis-1] quit
[RouterC] isis 1
[RouterC-isis-1] area-authentication-mode md5 10Sec
[RouterC-isis-1] quit
5.
Configure routing domain authentication. Specify the MD5 authentication mode and password
1020Sec on Router C and Router D:
[RouterC] isis 1
[RouterC-isis-1] domain-authentication-mode md5 1020Sec
[RouterC-isis-1] quit
[RouterD] isis 1
[RouterD-isis-1] domain-authentication-mode md5 1020Sec
[RouterD-isis-1] isis 1
Configuring BFD for IS-IS
Network requirements
•
As shown in Figure 47, IS-IS is enabled on Router A, Router B and Router C that are reachable to
each other at the network layer.
•
After the link over which Router A and Router B communicate through the Layer-2 switch fails, BFD
can quickly detect the failure and notify IS-IS of the failure. Router A and Router B then communicate
through Router C.
162
Figure 47 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth1/1
192.168.0.102/24
Router B
Eth1/1
192.168.0.100/24
Eth1/2
10.1.1.102/24
Eth1/2
13.1.1.1/24
Router C
Eth1/1
10.1.1.100/24
Eth1/2
13.1.1.2/24
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IS-IS basic functions:
# Configure Router A.
<RouterA> system-view
[RouterA] isis
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis enable
[RouterA-Ethernet1/1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] isis enable
[RouterA-Ethernet1/2] quit
# Configure Router B.
<RouterB> system-view
[RouterB] isis
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] isis enable
[RouterB-Ethernet1/1] quit
[RouterB] interface ethernet 1/2
[RouterB-Ethernet1/2] isis enable
[RouterB-Ethernet1/2] quit
# Configure Router C.
<RouterC> system-view
[RouterC] isis
163
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] isis enable
[RouterC-Ethernet1/1] quit
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] isis enable
[RouterC-Ethernet1/2] quit
3.
Configure BFD functions:
# Enable BFD on Router A and configure BFD parameters.
[RouterA] bfd session init-mode active
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] isis bfd enable
[RouterA-Ethernet1/1] bfd min-receive-interval 500
[RouterA-Ethernet1/1] bfd min-transmit-interval 500
[RouterA-Ethernet1/1] bfd detect-multiplier 7
# Enable BFD on Router B and configure BFD parameters.
[RouterB] bfd session init-mode active
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] isis bfd enable
[RouterB-Ethernet1/1] bfd min-receive-interval 500
[RouterB-Ethernet1/1] bfd min-transmit-interval 500
[RouterB-Ethernet1/1] bfd detect-multiplier 8
4.
Verify the configuration:
The following configurations are made on Router A. Configurations for Router B are similar.
(Details not shown.)
# Display the BFD information of Router A.
<RouterA> display bfd session
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
LD/RD
SourceAddr
DestAddr
State Holdtime Interface
3/1
192.168.0.102
192.168.0.100
Up
1700ms
Eth1/1
# Display route 120.1.1.0/24 on Router A, and you can see that Router A and Router B
communicate through the Layer-2 switch.
<RouterA> display ip routing-table 120.1.1.0 verbose
Routing Table : Public
Summary Count : 2
Destination: 120.1.1.0/24
Protocol: ISIS
Process ID: 0
Preference: 0
IpPrecedence:
NextHop: 192.168.0.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
Cost: 2
QosLcId:
Interface: Ethernet1/1
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h58m10s
164
Tag: 0
Destination: 120.1.1.0/24
Protocol: ISIS
Process ID: 1
Preference: 10
IpPrecedence:
NextHop: 10.1.1.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
Cost: 4
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Invalid Adv
Age: 00h58m05s
Tag: 0
# Enable debugging on Router A.
<RouterA> debugging isis bfd-event
<RouterA> terminal debugging
# When the link between Router B and the Layer-2 switch fails, BFD can quickly detect the failure.
#Aug
8 14:54:05:362 2008 RouterA IFNET/4/INTERFACE UPDOWN:
Trap 1.3.6.1.6.3.1.1.5.3: Interface 983041 is Down, ifAdminStatus is 1, ifOperStatus
is 2
#Aug 8 14:54:05:363 2008 RouterA
ISIS/4/ADJ_CHANGE:TrapID(1.3.6.1.2.1.138.0.17<isisAdjacencyChange>), ISIS Level-2
Adjencency IN Circuit-983041 State Change.
#Aug 8 14:54:05:364 2008 RouterA
ISIS/4/ADJ_CHANGE:TrapID(1.3.6.1.2.1.138.0.17<isisAdjacencyChange>), ISIS Level-1
Adjencency IN Circuit-983041 State Change.
%Aug 8 14:54:05:365 2008 RouterA IFNET/4/LINK UPDOWN: Ethernet1/1 link status is DOWN
%Aug 8 14:54:05:366 2008 RouterA IFNET/4/UPDOWN: Line protocol on the interface
Ethernet1/1 is DOWN
%Aug 8 14:54:05:367 2008 RouterA ISIS/4/ADJLOG:ISIS-1-ADJCHANGE: Adjacency To
0000.0000.0002 (Eth1/1) DOWN, Level-2 Circuit Down.
%Aug 8 14:54:05:367 2008 RouterA ISIS/4/ADJLOG:ISIS-1-ADJCHANGE: Adjacency To
0000.0000.0002 (Eth1/1) DOWN, Level-2 Adjacency clear.
%Aug 8 14:54:05:368 2008 RouterA ISIS/4/ADJLOG:ISIS-1-ADJCHANGE: Adjacency To
0000.0000.0002 (Eth1/1) DOWN, Level-1 Circuit Down.
%Aug 8 14:54:05:369 2008 RouterA ISIS/4/ADJLOG:ISIS-1-ADJCHANGE: Adjacency To
0000.0000.0002 (Eth1/1) DOWN, Level-1 Adjacency clear.
*Aug
8 14:54:05:370 2008 RouterA ISIS/6/ISIS:
ISIS-1-BFD: Success to send msg. Msg type 1 delete session. IfPhyIndex: 5 ,DstIPAddr:
192.168.0.100 , SrcIPAddr:192.168.0.102. NeighborType:Level-2.
*Aug
8 14:54:05:370 2008 RouterA ISIS/6/ISIS:
ISIS-1-BFD: Success to send msg. Msg type 1 delete session. IfPhyIndex: 5 ,DstIPAddr:
192.168.0.100 , SrcIPAddr:192.168.0.102. NeighborType:Level-1.
# Display the BFD information of Router A. Router A has removed its neighbor relationship with
Router B, so no information is output.
<RouterA> display bfd session
# Display route 120.1.1.0/24 on Router A, and you can see that Router A and Router B
communicate through Router C.
<RouterA> display ip routing-table 120.1.1.0 verbose
165
Routing Table : Public
Summary Count : 2
Destination: 120.1.1.0/24
Protocol: ISIS
Process ID: 1
Preference: 10
IpPrecedence:
NextHop: 10.1.1.100
BkNextHop: 0.0.0.0
RelyNextHop: 0.0.0.0
Cost: 4
QosLcId:
Interface: Ethernet1/2
BkInterface:
Neighbor : 0.0.0.0
Tunnel ID: 0x0
Label: NULL
BKTunnel ID: 0x0
BKLabel: NULL
State: Active Adv
Age: 00h58m10s
Tag: 0
166
Configuring BGP
Overview
Border Gateway Protocol (BGP) is an exterior gateway protocol. It is called internal BGP (IBGP) when it
runs within an AS and called external BGP (EBGP) when it runs between ASs.
The current version in use is BGP-4 (RFC 4271). Unless otherwise stated, BGP refers to BGP-4 in this
document.
BGP has the following characteristics:
•
Focuses on route control and the selection rather than route discovery and calculation.
•
Uses TCP to enhance reliability.
•
Measures the distance of a route by using a list of ASs that the route must travel through to reach the
destination. Therefore, BGP is also called a path-vector protocol.
•
Supports classless inter-domain routing (CIDR).
•
Reduces bandwidth consumption by advertising only incremental updates. BGP is very suitable to
advertise large numbers of routes on the Internet.
•
Eliminates routing loops by adding AS path information to BGP route updates.
•
Uses policies to implement flexible route filtering and selection.
•
Offers good scalability.
BGP speaker and BGP peer
A router running BGP is a BGP speaker. A BGP speaker establishes peer relationships with other BGP
speakers to exchange routing information over TCP connections.
BGP peers include the following types:
•
IBGP peers—Reside in the same AS as the local router.
•
EBGP peers—Reside in different ASs from the local router.
BGP message types
BGP uses the following types of messages:
•
Open—After establishing a TCP connection, BGP sends an Open message to establish a session
with the peer.
•
Update—BGP sends update messages to exchange routing information between peers. Each
update message can advertise a group of feasible routes with identical attributes and multiple
withdrawn routes.
•
Keepalive—BGP sends Keepalive messages between peers to maintain connectivity.
•
Route-refresh—BGP sends a Route-refresh message to request the routing information of a specified
address family from a peer.
•
Notification—BGP sends a Notification message upon detecting an error and immediately closes
the connection.
167
BGP path attributes
BGP uses the following path attributes in update messages for route filtering and selection:
•
ORIGIN
The ORIGIN attribute identifies the origin of routing information (how a route became a BGP route).
This attribute has the following types:
{
IGP—Has the highest priority. Routes generated in the local AS have the IGP attribute.
{
EGP—Has the second highest priority. Routes obtained through EGP have the EGP attribute.
{
•
INCOMPLETE—Has the lowest priority. The source of routes with this attribute is unknown. The
routes redistributed from other routing protocols have the INCOMPLETE attribute.
AS_PATH
The AS_PATH attribute identifies the ASs through which a route has passed. Before advertising a
route to another AS, BGP adds the local AS number into the AS_PATH attribute, so the receiver can
determine ASs to route the message back.
The AS_PATH attribute has the following two types:
{
{
AS_SEQUENCE—Arranges AS numbers in sequence. As shown in Figure 48, the number of the
AS closest to the receiver's AS is the first one listed in the AS_PATH.
AS_SET—Arranges AS numbers randomly.
Figure 48 AS_PATH attribute
BGP uses the AS_PATH attribute to implement the following functions:
{
{
Avoid routing loops—A BGP router does not receive routes containing the local AS number to
avoid routing loops.
Affect route selection—BGP gives priority to the route with the shortest AS_PATH length if other
factors are the same. As shown in Figure 48, the BGP router in AS 50 gives priority to the route
passing AS 40 for sending data to the destination 8.0.0.0. In some applications, you can apply
a routing policy to control BGP route selection by modifying the AS_PATH length.
168
{
•
Filter routes—By configuring an AS path filtering list, you can filter routes based on AS numbers
contained in the AS_PATH attribute. For more information about routing policies and AS path
filtering lists, see "Configuring routing policies."
NEXT_HOP
The NEXT_HOP attribute is not necessarily the IP address of a directly-connected router. Its value
is determined as follows:
{
{
{
When a BGP speaker advertises a self-originated route to a BGP peer, it sets the address of the
sending interface as the NEXT_HOP.
When a BGP speaker sends a received route to an EBGP peer, it sets the address of the sending
interface as the NEXT_HOP.
When a BGP speaker sends a route received from an EBGP peer to an IBGP peer, it does not
modify the NEXT_HOP attribute. If load balancing is configured, BGP modifies the NEXT_HOP
attribute for the equal-cost routes. For information about load balancing, see "BGP load
balancing."
Figure 49 NEXT_HOP attribute
•
MED (Multi-Exit-Discriminator)
BGP advertises the MED attribute between two neighboring ASs, each of which does not advertise
the attribute to any other AS.
Similar to metrics used by IGP, MED is used to determine the best route for traffic going into an AS.
When a BGP router obtains multiple routes to the same destination but with different next hops
from different EBGP peers, it considers the route with the smallest MED value the best route given
that other conditions are the same. As shown in Figure 50, traffic from AS 10 to AS 20 travels
through Router B that is selected according to MED.
169
Figure 50 MED attribute
MED = 0
Router B
2.1.1.1
D = 9.0.0.0
Next_hop = 2.1.1.1
MED = 0
EBGP
IBGP
9.0.0.0
IBGP
Router A
D = 9.0.0.0
Next_hop = 3.1.1.1
MED = 100
AS 10
EBGP
Router D
IBGP
3.1.1.1
Router C
MED = 100
AS 20
Generally, BGP only compares MEDs of routes received from the same AS. You can also use the
compare-different-as-med command to force BGP to compare MED values of routes received from
different ASs.
•
LOCAL_PREF
The LOCAL_PREF attribute is exchanged between IBGP peers only, and is not advertised to any
other AS. It indicates the priority of a BGP router.
BGP uses LOCAL_PREF to determine the best route for traffic leaving the local AS. When a BGP
router obtains from several IBGP peers multiple routes to the same destination but with different
next hops, it considers the route with the highest LOCAL_PREF value as the best route. As shown
in Figure 51, traffic from AS 20 to AS 10 travels through Router C that is selected according to
LOCAL_PREF.
170
Figure 51 LOCAL_PREF attribute
•
COMMUNITY
The COMMUNITY attribute identifies the community of BGP routes. A BGP community is a group
of routes with the same characteristics. It has no geographical boundaries. Routes of different ASs
can belong to the same community.
A route can carry one or more COMMUNITY attribute values (each of which is represented by a
four-byte integer). A router uses the COMMUNITY attribute to determine whether to advertise the
route and the advertising scope without using complex filters, such as ACLs. This mechanism
simplifies routing policy configuration, management, and maintenance.
Well-known community attributes involve the following:
{
{
{
{
Internet—By default, all routes belong to the Internet community. Routes with this attribute can
be advertised to all BGP peers.
No_Export—Routes with this attribute cannot be advertised out of the local AS or out of the
local confederation, but can be advertised to other sub ASs in the confederation. For
confederation information, see "Settlements for problems in large-scale BGP networks."
No_Advertise—Routes with this attribute cannot be advertised to other BGP peers.
No_Export_Subconfed—Routes with this attribute cannot be advertised out of the local AS or
other sub ASs in the local confederation.
You can configure BGP community lists to filter BGP routes based on the BGP community attribute.
•
Extended community attribute
To meet new demands, BGP defines the extended community attribute. The extended community
attribute has the following advantages over the community attribute:
{
{
Provides more attribute values by extending the attribute length to eight bytes.
Allows for using different types of extended community attributes in different scenarios to
enhance route filtering and control and simplify configuration and management.
The device supports the Route-Target attribute for VPN and Source of Origin (SOO) attribute. For
more information, see MPLS Configuration Guide.
171
BGP route selection
BGP discards routes with unreachable NEXT_HOPs. If multiple routes to the same destination are
available, BGP selects the best route in the following sequence:
1.
Highest Preferred_value
2.
Highest LOCAL_PREF
3.
Summary route
4.
Shortest AS_PATH
5.
IGP, EGP, or INCOMPLETE route in turn
6.
Lowest MED value
7.
Learned from EBGP, confederation, or IBGP in turn
8.
Smallest next hop metric
9.
Shortest CLUSTER_LIST
10. Smallest ORIGINATOR_ID
11. Advertised by the router with the smallest router ID
12. Advertised by the peer with the lowest address
CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that contains its
own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing loops.
If load balancing is configured, the system selects available routes to implement load balancing.
BGP route advertisement rules
BGP follow these rules for route advertisement:
•
When multiple feasible routes to a destination exist, BGP advertises only the best route to its peers.
•
BGP advertises only routes that it uses.
•
BGP advertises routes learned from an EBGP peer to all BGP peers, including both EBGP and IBGP
peers.
•
A BGP speaker advertises routes learned from an IBGP peer to EBGP peer, rather than other IBGP
peers.
•
After establishing a session with a new BGP peer, BGP advertises all the routes matching the above
rules to the peer. After that, BGP advertises only incremental routes to the peer.
BGP load balancing
BGP implements load balancing through route recursion and route selection.
•
BGP load balancing through route recursion
The next hop of a BGP route might not be directly connected. One of the reasons is next hops in
routing information exchanged between IBGP peers are not modified. The BGP router must find the
directly-connected next hop through IGP. The matching route with the direct next hop is called the
"recursive route." The process of finding a recursive route is route recursion.
The system supports BGP load balancing based on route recursion. If multiple recursive routes to
the same destination are load balanced (suppose three direct next hop addresses), BGP generates
the same number of next hops to forward packets. BGP load balancing based on route recursion
is always enabled by the system rather than configured by using commands.
172
•
BGP load balancing through route selection
BGP differs from IGP in the implementation of load balancing in the following ways:
{
{
IGP routing protocols, such as RIP and OSPF, compute metrics of routes, and then implement
load balancing over routes with the same metric and to the same destination. The route
selection criterion is metric.
BGP has no route computation algorithm, so it cannot implement load balancing according to
metrics of routes. However, BGP has abundant route selection rules, through which, it selects
available routes for load balancing and adds load balancing to route selection rules.
BGP implements load balancing only on routes that have the same AS_PATH, ORIGIN,
LOCAL_PREF and MED, rather than using the route selection rules as described in "BGP route
selection."
Figure 52 Network diagram
As shown in Figure 52, Router A and Router B are IBGP peers of Router C. Router D and Router E both
advertise a route 9.0.0.0 to Router C. If load balancing with a maximum number of two routes is
configured on Router C, and the two routes have the same AS_PATH, ORIGIN, LOCAL_PREF, and MED,
Router C installs both the two routes to its routing table for load balancing. After that, Router C forwards
to Router A and Router B a single route that has NEXT_HOP changed to Router C without changing other
attributes.
NOTE:
BGP load balancing is applicable between EBGP peers, between IBGP peers, and between
confederations.
Settlements for problems in large-scale BGP networks
For easy management and route distribution efficiency, use the following methods on a large-scale BGP
network:
•
Route summarization
Route summarization can reduce the BGP routing table size by advertising summary routes rather
than more specific routes.
173
The system supports both manual and automatic route summarization. Manual route
summarization allows you to determine the attribute of a summary route and whether to advertise
more specific routes.
•
Route dampening
BGP route dampening solves the issue of route instability such as route flaps—a route comes up
and disappears in the routing table frequently.
When a route flap occurs, the routing protocol sends an update to its neighbor, and then the
neighbor recalculates routes and modifies the routing table. Frequent route flaps consume too
many resources and affect other operations.
In most cases, BGP runs in complex networks, where route changes are more frequent. To solve the
problem caused by route flapping, you can use BGP route dampening to suppress unstable routes.
BGP route dampening uses a penalty value to judge the stability of a route. The bigger the value,
the less stable the route. Each time a route flap occurs, BGP adds a penalty value (1000, which is
a fixed number and cannot be changed) to the route. When the penalty value of the route exceeds
the suppress value, the route is suppressed from being added into the BGP routing table or being
advertised to other BGP peers.
The penalty value of the suppressed route decreases to half of the suppress value after a period of
time. This period is called "Half-life." When the value decreases to the reusable threshold value,
the route is added into the BGP routing table and advertised to other BGP peers.
Figure 53 BGP route dampening
Penalty
value
Suppress
threshold
Reusable
threshold
Suppress time
Time
Half-life
•
Peer group
You can organize BGP peers with the same attributes into a group to simplify their configurations.
When a peer joins the peer group, the peer obtains the same configuration as the peer group. If
the configuration of the peer group is changed, the configuration of group members is changed.
•
Community
You can apply a community list or an extended community list to a routing policy for route control.
For more information, see "BGP path attributes."
•
Route reflector
174
IBGP peers must be fully meshed to maintain connectivity. If n routers exist in an AS, the number of
IBGP connections is n(n-1)/2. If a large number of IBGP peers exist, large amounts of network and
CPU resources are consumed to maintain sessions.
Using route reflectors can solve this issue. In an AS, a router acts as a route reflector, and other
routers act as clients connecting to the route reflector. The route reflector forwards the routing
information received from a client to other clients. In this way, all clients can receive routing
information from one another without establishing BGP sessions.
A router that is neither a route reflector nor a client is a non-client, which, as shown in Figure 54
must establish BGP sessions to the route reflector and other non-clients.
Figure 54 Network diagram for a route reflector
The route reflector and clients form a cluster. Typically a cluster has one route reflector. The ID of
the route reflector is the Cluster_ID. You can configure more than one route reflector in a cluster to
improve availability as shown in Figure 55. The configured route reflectors must have the same
Cluster_ID to avoid routing loops.
Figure 55 Network diagram for route reflectors
When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it
consumes more bandwidth resources. You can use commands to disable route reflection instead of
modifying network configuration or changing network topology.
After route reflection is disabled between clients, routes can still be reflected between a client and
a non-client.
175
•
Confederation
Confederation is another method to manage growing IBGP connections in an AS. It splits an AS
into multiple sub ASs. In each sub AS, IBGP peers are fully meshed. As shown in Figure 56,
intra-confederation EBGP connections are established between sub Ass in AS 200.
Figure 56 Confederation network diagram
A non-confederation BGP speaker does not need to know sub ASs in the confederation. It
considers the confederation as one AS, and the confederation ID as the AS number. In the above
figure, AS 200 is the confederation ID.
Confederation has a deficiency. When you change an AS into a confederation, you must
reconfigure your routers, and the topology will be changed.
In large-scale BGP networks, both route reflector and confederation can be used.
MP-BGP
BGP-4 transmits IPv4 unicast routes, but does not transmit routing information of other network layer
protocols, such as IPv6.
To support more network layer protocols, IETF extended BGP-4 by introducing Multiprotocol Extensions
for BGP-4 (MP-BGP). MP-BGP can transmit routing information of various network layer protocols, for
example, IPv4 multicasts, IPv6 unicasts, IPv6 multicasts, and VPNv4 routes.
Routers supporting MP-BGP can communicate with routers not supporting MP-BGP.
MP-BGP extended attributes
Prefixes and next hops are key routing information of network layer protocols. In BGP-4, each update
message can carry prefixes of feasible routes in the Network Layer Reachability Information (NLRI) field,
prefixes of unfeasible routes in the withdrawn routes field, and next hops in the NEXT_HOP attribute. The
NLRI field, withdrawn routes field, and NEXT_HOP attribute cannot be extended to carry information of
multiple network layer protocols.
To support multiple network layer protocols, MP-BGP defines the following path attributes:
•
MP_REACH_NLRI—Multiprotocol Reachable NLRI, for carrying prefixes of feasible routes and next
hops for multiple network layer protocols. Such routes can then be advertised.
176
•
MP_UNREACH_NLRI—Multiprotocol Unreachable NLRI, for carrying prefixes of unfeasible routes
for multiple network layer protocols. Such routes can then be withdrawn.
MP-BGP uses these attributes to advertise feasible and unfeasible routes of different network layer
protocols. BGP speakers not supporting MP-BGP ignore updates containing these attributes and do not
forward them to its peers.
The system supports multiple MP-BGP extensions, including VPN extension (see MPLS Configuration
Guide), IPv6 extension (see "Configuring IPv6 BGP"), and multicast extension (see IP Multicast
Configuration Guide).
Address family
MP-BGP uses address families and subsequent address families to differentiate network layer protocols of
routes contained in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. For example, an Address
Family Identifier (AFI) of 2 and Subsequent Address Family Identifier (SAFI) of 1 indicates IPv6 unicast
routing information carried in the MP_REACH_NLRI attribute. For address family values, see RFC 1700.
BGP configuration views
BGP uses different views to manage routing information for different address families and different VPN
instances. Most BGP commands are available in all BGP views. BGP supports multiple VPN instances by
establishing a separate routing table for each VPN instance.
This chapter describes only configurations in BGP and BGP-VPN views. For configurations in other views,
see relevant configuration guides.
Table 7 describes different BGP configuration views.
Table 7 BGP configuration views
View names
Ways to enter the views
<Sysname> system-view
BGP view
[Sysname] bgp 100
[Sysname-bgp]
Remarks
Configurations in this view apply to
all address families and routes in all
VPN instances (such as
confederation and GR), or apply to
IPv4 unicast routes on the public
network (such as local network
injection, IGP route redistribution,
route summarization, and BGP route
distribution/reception filtering
policies ).
<Sysname> system-view
[Sysname] bgp 100
BGP-VPN view
[Sysname-bgp] ipv4-family
vpn-instance vpn1
Configurations in this view apply to
IPv4 unicast routes in the specified
VPN instance.
[Sysname-bgp-ipv4-vpn1]
<Sysname> system-view
IPv6 address family view
[Sysname] bgp 100
[Sysname-bgp] ipv6-family
[Sysname-bgp-af-ipv6]
177
Configurations in this view apply to
IPv6 unicast routes in the public
network.
View names
Ways to enter the views
Remarks
<Sysname> system-view
[Sysname] bgp 100
IPv6 BGP-VPN instance view
[Sysname-bgp] ipv6-family
vpn-instance vpn1
Configurations in this view apply to
IPv6 unicast routes in the specified
VPN instance.
[Sysname-bgp-ipv6-vpn1]
<Sysname> system-view
[Sysname] bgp 100
BGP VPNv4 instance view
[Sysname-bgp] ipv4-family
vpnv4
Configurations in this view apply to
VPNv4 routes.
[Sysname-bgp-af-vpnv4]
<Sysname> system-view
[Sysname] bgp 100
BGP VPNv6 instance view
[Sysname-bgp] ipv6-family
vpnv6
Configurations in this view apply to
VPNv6 routes.
[Sysname-bgp-af-vpnv6]
<Sysname> system-view
[Sysname] bgp 100
MBGP address family view
[Sysname-bgp] ipv4-family
multicast
Configurations in this view apply to
IPv4 multicast routes.
[Sysname-bgp-af-mul]
<Sysname> system-view
[Sysname] bgp 100
IPv6 MBGP address family
view
[Sysname-bgp] ipv6-family
multicast
Configurations in this view apply to
IPv6 multicast routes.
[Sysname-bgp-af-ipv6-mul]
[Sysname-bgp-ipv4-vpn1]
<Sysname> system-view
BGP-L2VPN address family
view
[Sysname] bgp 100
[Sysname-bgp] l2vpn-family
[Sysname-bgp-af-l2vpn]
Protocols and standards
•
RFC 1700, ASSIGNED NUMBERS
•
RFC 1771, A Border Gateway Protocol 4 (BGP-4)
•
RFC 2858, Multiprotocol Extensions for BGP-4
•
RFC 3392, Capabilities Advertisement with BGP-4
•
RFC 2918, Route Refresh Capability for BGP-4
•
RFC 2439, BGP Route Flap Damping
•
RFC 1997, BGP Communities Attribute
•
RFC 2796, BGP Route Reflection
•
RFC 3065, Autonomous System Confederations for BGP
•
RFC 4271, A Border Gateway Protocol 4 (BGP-4)
•
RFC 4360, BGP Extended Communities Attribute
•
RFC 4724, Graceful Restart Mechanism for BGP
178
Configurations in this view apply to
routes in MPLS L2VPN instances.
•
RFC 4760, Multiprotocol Extensions for BGP-4
•
RFC 5291, Outbound Route Filtering Capability for BGP-4
•
RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4
BGP configuration task list
In a basic BGP network, you only need to perform the following configurations:
•
Enable BGP.
•
Configure BGP peers or peer groups.
•
Control BGP route generation.
To control BGP route distribution and path selection, you must perform other configurations.
If you configure a BGP setting for a peer group and a peer in the group, the last configuration takes
effect.
Complete the following tasks to configure BGP:
Task
Configuring basic BGP
Generating BGP routes
Remarks
Enabling BGP
Required.
Configuring a BGP peer
Required.
Configuring a BGP peer group
HP recommends
configuring BGP peer
groups on large scale BGP
networks for easy
configuration and
maintenance.
Specifying the source interface for TCP
connections
Optional.
Injecting a local network
Required.
Redistributing IGP routes
Use at least one method.
Configuring BGP route summarization
Advertising a default route to a peer or peer
group
Controlling route
distribution and reception
Configuring BGP route distribution/reception
filtering policies
Optional.
Enabling BGP and IGP route synchronization
Limiting prefixes received from a peer or peer
group
Configuring BGP route dampening
Controlling BGP path
selection
Specifying a preferred value for routes received
Optional.
Configuring preferences for BGP routes
Optional.
Configure the default local preference
Optional.
Configuring the MED attribute
Optional.
Configuring the NEXT_HOP attribute
Optional.
179
Task
Tuning and optimizing BGP
networks
Configuring a large scale
BGP network
Remarks
Configuring the AS_PATH attribute
Optional.
Configuring the BGP keepalive interval and
holdtime
Optional.
Configuring the interval for sending the same
update
Optional.
Allowing establishment of EBGP session to an
indirectly connected peer or peer group
Optional.
Enabling the BGP ORF capability
Optional.
Enabling 4-byte AS number suppression
Optional.
Enabling quick reestablishment of direct EBGP
session
Optional.
Enabling MD5 authentication for BGP peers
Optional.
Configuring BGP load balancing
Optional.
Forbidding session establishment with a peer or
peer group
Optional.
Configuring BGP soft-reset
Optional.
Configuring BGP community
Optional.
Configuring a BGP route reflector
Optional.
Configuring a BGP confederation
Optional.
Configuring BGP GR
Optional.
Enabling trap
Optional.
Enabling logging of session state changes
Optional.
Configuring BFD for BGP
Optional.
Configuring basic BGP
This section describes the tasks required for a BGP network to work.
Enabling BGP
A router ID is the unique identifier of a BGP router in an AS.
•
To ensure the uniqueness of a router ID and enhance availability, you can specify in BGP view the
IP address of a local loopback interface as the router ID.
•
If no router ID is specified in BGP view, the global router ID is used.
•
If the global router ID is used and then the interface that owns the router ID is removed, the router
selects a new router ID.
•
If you specify a router ID in BGP view and then remove the interface that owns the router ID, the
router does not select a new router ID. To select a new router ID, use the undo router-id command
in BGP view.
To enable BGP:
180
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Configure a global router ID.
3.
Enable BGP and enter BGP
view.
router id router-id
By default, no global router ID is
configured. BGP uses the highest
loopback interface IP address as the
router ID. If no loopback interface IP
address is available, BGP uses the
highest physical interface IP address
as the router ID regardless of the
interface status.
Not enabled by default.
bgp as-number
A router can reside in only one AS,
so the router can run only one BGP
process.
Optional.
4.
Specify a router ID.
router-id router-id
By default, the global router ID is
used.
Command
Remarks
system-view
N/A
Configuring a BGP peer
Step
1.
Enter system view.
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family
vpn-instance
vpn-instance-name
3.
Create a BGP peer and
specify its AS number.
4.
Enable the default use of IPv4
unicast address family for the
peers that are established
using the peer as-number
command.
default ipv4-unicast
5.
Enable a peer.
peer ip-address enable
6.
Configure a description for a
peer.
peer ip-address description
description-text
peer ip-address as-number
as-number
By default, no BGP peer is created.
Optional.
181
Enabled by default.
This command is not supported in
BGP-VPN instance view.
Optional.
Enabled by default.
Optional.
By default, no description is
configured for a peer.
Configuring a BGP peer group
In a large-scale network, grouping peers that use the same route selection policy simplifies overall
configuration. When you modify the policy of the group, the modification applies to all peers in the
group. However, if a peer group already contains peers, you cannot remove or change its AS number.
A peer group is an IBGP peer group if peers in it belong to the local AS, and is an EBGP peer group if
peers in it belong to different ASs.
Configuring an IBGP peer group
After you create an IBGP peer group and then add a peer into it, the system creates the peer in BGP view
and specifies the local AS number for the peer.
To configure an IBGP peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b.
Use either method.
ipv4 family vpn-instance
vpn-instance-name
By default, no peer exists in the
peer group.
3.
Create an IBGP peer group.
group group-name [ internal ]
4.
Add a peer into the IBGP peer
group.
peer ip-address group group-name
[ as-number as-number ]
5.
Enable a peer.
peer ip-address enable
6.
Configure a description for a
peer group.
peer group-name description
description-text
To use the as-number as-number
option, you must specify the local
AS number.
N/A
Optional.
Enabled by default.
Optional.
By default, no description is
configured for the peer group.
Configuring an EBGP peer group
If peers in an EBGP group belong to the same external AS, the EBGP peer group is a pure EBGP peer
group. If not, it is a mixed EBGP peer group.
Use one of the following methods to configure an EBGP peer group:
•
Method 1—Create an EBGP peer group, specify its AS number, and add peers into it. All the
added peers have the same AS number. You can specify an AS number for a peer before adding
it into the peer group. The AS number must be the same as that of the peer group. All peers in the
peer group have the same AS number as the peer group.
•
Method 2—Create an EBGP peer group, specify an AS number for a peer, and add the peer into
the peer group. Peers added in the group can have different AS numbers.
•
Method 3—Create an EBGP peer group and add a peer with an AS number into it. Peers added
in the group can have different AS numbers.
182
To configure an EBGP peer group by using Method 1:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Create an EBGP peer group.
group group-name external
By default, no EBGP peer group is
created.
4.
Specify the AS number for the
group.
peer group-name as-number
as-number
By default, no AS number is
specified.
By default, no peer exists in the
peer group.
5.
Add a peer into the EBGP
peer group.
peer ip-address group group-name
[ as-number as-number ]
6.
Enable a peer.
peer ip-address enable
7.
Configure a description for a
peer group.
peer group-name description
description-text
The as-number as-number option,
if used, must specify the same AS
number as the peer group-name
as-number as-number command.
Optional.
Enabled by default.
Optional.
By default, no description is
configured for the peer group.
To configure an EBGP peer group by using Method 2:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Create an EBGP peer group
group group-name external
N/A
4.
Create a BGP peer and
specify its AS number.
peer ip-address as-number
as-number
N/A
5.
Add a peer into the EBGP
peer group.
peer ip-address group group-name
[ as-number as-number ]
The as-number as-number option,
if used, must specify the same AS
number as the peer ip-address
as-number as-number command.
183
Step
Command
Enable the default use of IPv4
unicast address family for the
peers that are established
using the peer as-number
command.
default ipv4-unicast
7.
Enable a peer.
peer ip-address enable
8.
Configure a description for a
peer group.
peer group-name description
description-text
6.
Remarks
Optional.
Enabled by default.
This command is not supported in
BGP-VPN instance view.
Optional.
Enabled by default.
Optional.
By default, no description is
configured for the peer group.
To configure an EBGP peer group by using Method 3:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Create an EBGP peer group.
group group-name external
N/A
4.
Add a peer into the EBGP
peer group.
peer ip-address group group-name
as-number as-number
N/A
5.
Enable a peer.
peer ip-address enable
6.
Configure a description for a
peer group.
peer group-name description
description-text
Optional.
Enabled by default.
Optional.
By default, no description is
configured for the peer group.
Specifying the source interface for TCP connections
By default, BGP uses the output interface of the optimal route to a peer or peer group as the source
interface for establishing TCP connections to the peer or peer group, and it uses the primary IP address
of the output interface as the source IP address of TCP connections. You can change the source interface
(primary IP address) for TCP connections in the following scenarios:
•
If the peer's IP address belongs to an interface indirectly connected to the local router, you must
specify that interface as the source interface for TCP connections on the peer. For example, interface
A on the local end is directly connected to interface B on the peer. If you execute the peer x.x.x.x
as-number as-number command in which x.x.x.x is not the IP address of interface B on the local
end, you must use the peer connect-interface command on the peer to specify the interface whose
IP address is x.x.x.x as the source interface for establishing a TCP connection.
•
On a BGP router that has multiple links to a peer, if the source interface fails, BGP has to reestablish
TCP connections. To avoid this problem, use a loopback interface as the source interface.
184
To establish multiple BGP sessions between two routers, you must specify the source interface for
establishing TCP connections to each peer on the local router. Otherwise, the local BGP router
might fail to establish a TCP connection to a peer when using the outbound interface of the best
route to the peer as the source interface.
•
To specify the source interface for TCP connections:
Step
Command
Enter system view.
1.
system-view
Remarks
N/A
• Enter BGP view:
bgp as-number
Enter BGP view or BGP-VPN
instance view.
2.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Specify the source interface
for establishing TCP
connections to a peer or
peer group.
3.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
By default, BGP uses the outbound
interface of the best route to the BGP
peer or peer group as the source
interface for establishing a TCP
connection to the peer or peer
group.
Generating BGP routes
BGP can generate routes can be done in the following ways:
•
Advertise local networks.
•
Redistribute IGP routes.
Configuration prerequisites
Create and configure a routing policy. For more information, see "Configuring routing policies."
Injecting a local network
Perform this task to inject a network in the local routing table to the BGP routing table, so that BGP can
advertise the network to BGP peers. The origin attribute of BGP routes advertised in this way is IGP. You
can also use a routing policy to flexibly control route advertisement.
To inject a local network:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
185
Use either method.
Step
Command
Remarks
Optional.
3.
Inject a local network to the
BGP routing table.
network ip-address [ mask |
mask-length ] [ route-policy
route-policy-name ]
Not injected by default.
The network to be injected must be
available and active in the local IP
routing table.
Redistributing IGP routes
Perform this task to configure route redistribution from an IGP to BGP.
By default, BGP does not redistribute default IGP routes. You can use the default-route imported
command to redistribute default IGP routes into the BGP routing table.
The origin attribute of BGP routes redistributed from IGPs is INCOMPLETE.
Only active routes can be redistributed. You can use the display ip routing-table protocol command to
view route state information. For more information about the display ip routing-table protocol command,
see Layer 3—IP Routing Command Reference.
To configure BGP to redistribute IGP routes:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Not enabled by default.
3.
Enable route redistribution
from IGP into BGP.
import-route protocol [ { process-id
| all-processes } [ allow-direct |
med med-value | route-policy
route-policy-name ] * ]
The allow-direct keyword is
available only when the specified
routing protocol is OSPF.
4.
Enable default route
redistribution into BGP.
default-route imported
Not enabled by default.
Controlling route distribution and reception
Configuring BGP route summarization
To reduce the number of routes to be redistributed and the routing table size on medium and large BGP
networks, configure route summarization on BGP routers. BGP supports the following summarization
modes: automatic and manual. Manual summary routes have a higher priority than automatic ones.
Configuring automatic route summarization
After automatic route summarization is configured, BGP summarizes redistributed IGP subnets to
advertise only natural networks. Routes injected with the network command cannot be summarized.
186
To configure automatic route summarization:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure automatic route
summarization.
summary automatic
Not configured by default.
Configuring manual route summarization
By configuring manual route summarization, you can summarize both redistributed routes and routes
injected using the network command and determine the mask length for a summary route as needed.
The output interface of a BGP summary route is Null 0. With route summarization, BGP advertises fewer
routes to its peers. A summary route must not be optimal; otherwise, BGP will fail to forward the packets
matching the route. If a summarized specific route has the same mask as the summary route but has a
lower priority, the summary route becomes the optimal route. In this case, you must change the priority
of the summary or the specific route to make the specific route the optimal route.
To configure BGP manual route summarization:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure manual route
summarization.
aggregate ip-address { mask |
mask-length } [ as-set |
attribute-policy route-policy-name
| detail-suppressed | origin-policy
route-policy-name |
suppress-policy
route-policy-name ]*
Not configured by default.
Advertising a default route to a peer or peer group
Perform this task to advertise a default BGP route with the next hop being the advertising router to a peer
or peer group.
To advertise a default route to a peer or peer group:
187
Step
Enter system view.
1.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
Enter BGP view or BGP-VPN
instance view.
2.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Advertise a default route to a
peer or peer group.
3.
peer { group-name | ip-address }
default-route-advertise
[ route-policy route-policy-name ]
Not advertised by default.
Configuring BGP route distribution/reception filtering policies
Configuration prerequisites
You must configure the following filters as needed:
•
ACL
•
IP prefix list
•
Routing policy
•
AS-path ACL
For information about configuring an ACL, see ACL and QoS Configuration Guide.
For information about configuring an IP prefix list, routing policy, and AS-path ACL, see "Configuring
routing policies."
Configuring BGP route distribution filtering policies
You can use the following methods to configure BGP route distribution filtering policies:
•
Use ACL or IP prefix list to filter routing information advertised to all peers.
•
Use routing policy, ACL, AS-path ACL, or IP prefix list to filter routing information advertised to the
specified peer or peer group.
You can configure a filtering policy as needed. If several filtering policies are configured, they are
applied in the following sequence:
1.
filter-policy export
2.
peer filter-policy export
3.
peer as-path-acl export
4.
peer ip-prefix export
5.
peer route-policy export
Only routes passing the first policy can go to the next, and only routes passing all the configured policies
can be advertised.
To configure BGP route distribution filtering policies:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
188
Step
Command
Remarks
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
• Configure the filtering of
redistributed routes advertised to all
peers:
filter-policy { acl-number | ip-prefix
ip-prefix-name } export [ direct | isis
process-id | ospf process-id | rip
process-id | | static ]
• Reference a routing policy to filter
advertisements to a peer or peer
group:
peer { group-name | ip-address }
route-policy route-policy-name
export
3.
Configure BGP route
distribution filtering policies.
• Reference an ACL to filter
advertisements to a peer or peer
group:
peer { group-name | ip-address }
filter-policy acl-number export
Use at least one method.
Not configured by default.
• Reference an AS path ACL to filter
routing information sent to a peer or
peer group:
peer { group-name | ip-address }
as-path-acl as-path-acl-number
export
• Reference an IP prefix list to filter
routing information sent to a peer or
peer group:
peer { group-name | ip-address }
ip-prefix ip-prefix-name export
Configuring BGP route reception filtering policies
You can use the following methods to configure BGP route reception filtering policies:
•
Use ACL or IP prefix list to filter routing information received by all peers.
•
Use routing policy, ACL, AS-path ACL, or IP prefix list to filter routing information received by the
specified peer or peer group.
If several filtering policies are configured, they are applied in the following sequence:
1.
filter-policy import
2.
peer filter-policy import
3.
peer as-path-acl import
189
4.
peer ip-prefix import
5.
peer route-policy import
Only routes passing all the configured policies can be received.
To configure BGP route reception filtering policies:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
• Filter incoming routes from all peers
with an ACL or IP prefix list:
filter-policy { acl-number | ip-prefix
ip-prefix-name } import
• Reference a routing policy to filter
routing information from a peer or
peer group:
peer { group-name | ip-address }
route-policy route-policy-name
import
• Reference an ACL to filter routing
3.
Configure BGP route
reception filtering policies.
information from a peer or peer
group:
peer { group-name | ip-address }
filter-policy acl-number import
Use at least one method.
By default, no route reception
filtering is configured.
• Reference an AS path ACL to filter
routing information from a peer or
peer group:
peer { group-name | ip-address }
as-path-acl as-path-acl-number
import
• Reference an IP prefix list to filter
routing information from a peer or
peer group:
peer { group-name | ip-address }
ip-prefix ip-prefix-name import
Enabling BGP and IGP route synchronization
Routing information synchronization between IBGP and IGP avoids giving wrong directions to routers
outside of the local AS.
By default, upon receiving an IBGP route, a BGP router checks the route's next hop. If the next hop is
reachable, the BGP router advertises the route to EBGP peers. If a non-BGP router works in an AS, it can
190
discard a packet due to an unreachable destination. As shown in Figure 57, Router E has learned a route
of 8.0.0.0/8 from Router D through BGP. Router E then sends a packet to 8.0.0.0/8 through Router D,
which finds from its routing table that Router B is the next hop (configured using the peer next-hop-local
command). Because Router D has learned the route to Router B through IGP, Router D forwards the
packet to Router C through route recursion. Router C does not know the route 8.0.0.0/8, so it discards
the packet.
Figure 57 IBGP and IGP synchronization
For this example, if synchronization is enabled, and the route 8.0.0.0/24 received from Router B is
available in its IGP routing table, Router D advertises the IBGP route when the following conditions are
met:
•
The next hop of the route is reachable.
•
An active route with the same destination network segment is available in the IGP routing table (use
the display ip routing-table protocol command to check the IGP route state).
You can disable the synchronization feature in the following situations:
•
The local AS is not a transitive AS (AS 20 is a transitive AS in the above figure).
•
Routers in the local AS are IBGP fully meshed.
To enable BGP and IGP synchronization:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enable synchronization
between BGP and IGP.
synchronization
Not enabled by default.
Limiting prefixes received from a peer or peer group
This feature can prevent that send a large number of BGP routes to the router.
If the number of routes received from a peer or peer group exceeds the upper limit, the router takes one
of the following actions based on your configuration:
•
Tear down the BGP session to the peer or peer group.
•
Display an alarm message.
•
Tear down the BGP session to the peer or peer group and, after a specified period of time,
reestablishes a BGP session to the peer or peer group.
191
You can specify the threshold value for the router to display an alarm message. When the ratio of the
number of received routes to the maximum number reaches the percentage value, the router displays an
alarm message.
To configure the maximum number of prefixes allowed to be received from a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Specify the maximum number
of routes that a router can
receive from a peer or peer
group.
peer { group-name | ip-address }
route-limit prefix-number
[ { alert-only | reconnect
reconnect-time } |
percentage-value ] *
By default, the number of routes
that a router can receive from a
peer or peer group is not limited.
Configuring BGP route dampening
By configuring BGP route dampening, you can suppress unstable routes from being added to the local
routing table or from being advertised to BGP peers.
To configure BGP route dampening:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure BGP route
dampening.
dampening [ half-life-reachable
half-life-unreachable reuse suppress
ceiling | route-policy
route-policy-name ] *
Not configured by default.
Controlling BGP path selection
By configuring BGP path attributes, you can control BGP path selection.
Specifying a preferred value for routes received
This task allows you to modify the preferred value of a route to control BGP path selection.
192
Among multiple routes that have the same destination/mask and are learned from different peers, the
one with the greatest preferred value is selected as the route to the destination.
To specify a preferred value for routes from a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Specify a preferred value for
routes received from a peer or
peer group.
peer { group-name | ip-address }
preferred-value value
Optional.
By default, the preferred value is 0.
Configuring preferences for BGP routes
A router might run multiple routing protocols with each having a preference. If they find the same route,
the route found by the routing protocol with the highest preference is selected.
You can use the preference command to modify preferences for external, internal, and local BGP routes.
By default, the preference of an EBGP route is lower than a local route. If a device has an EBGP route and
a local route to reach a destination, the device does not select the EBGP route. You can use the network
shortcut command to configure an EBGP route as a shortcut route that has the same preference as a local
route. The EBGP route is then more likely to become the optimal route.
To configure preferences for BGP routes:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure preferences for
external, internal, local BGP
routes.
preference { external-preference
internal-preference
local-preference | route-policy
route-policy-name }
4.
Increase the preference of a
received EBGP route.
network ip-address [ mask |
mask-length ] short-cut
193
Optional.
The default preferences of external,
internal, and local BGP routes are
255, 255, and 130, respectively.
Optional.
By default, an EBGP route received
has a preference of 255.
Configure the default local preference
The local preference is used to determine the best route for traffic leaving the local AS. When a BGP
router obtains from several IBGP peers multiple routes to the same destination but with different next hops,
it considers the route with the highest local preference as the best route.
This task allows you to specify the default local preference for routes sent to IBGP peers.
To specify the default local preference:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure the default local
preference.
Optional.
default local-preference value
The default local preference is
100.
Configuring the MED attribute
MED is used to determine the best route for traffic going into an AS. When a BGP router obtains from
EBGP peers multiple routes to the same destination but with different next hops, it considers the route with
the smallest MED value as the best route if other conditions are the same.
Configuring the default MED value
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure the default MED
value.
default med med-value
Optional.
0 by default.
Enabling the comparison of MED of routes from different ASs
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
194
Step
Command
Remarks
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable the comparison of
MED of routes from different
ASs.
Not enabled by default.
compare-different-as-med
Enabling the comparison of MEDs for routes on a per-AS basis
Route learning sequence might affect optimal route selection.
Figure 58 Route selection based on MED
As shown in Figure 58, Router D learns network 10.0.0.0 from both Router A and Router B. Because
Router B has a smaller router ID, the route learned from it is optimal.
Network
*>i
10.0.0.0
* i
NextHop
MED
LocPrf
PrefVal Path/Ogn
2.2.2.2
50
0
300e
3.3.3.3
50
0
200e
When Router D learns network 10.0.0.0 from Router C, it compares the route with the optimal route in
its routing table. Because Router C and Router B reside in different ASs, BGP will not compare the MEDs
of the two routes. Router C has a smaller router ID than Router B, the route from Router C becomes
optimal.
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i
10.0.0.0
1.1.1.1
60
0
200e
* i
10.0.0.0
2.2.2.2
50
0
300e
3.3.3.3
50
0
200e
* i
However, Router C and Router A reside in the same AS, and Router C has a greater MED, so network
10.0.0.0 learned from Router C is not optimal.
195
To resolve this issue, configure the bestroute compare-med command on Router D. After that, Router D
puts routes received from the same AS into a group. Router D then selects the route with the lowest MED
from the same group, and compares routes from different groups.
The following output is the BGP routing table on Router D after the comparison of MED of routes from
each AS is enabled. Network 10.0.0.0 learned from Router B is the optimal route.
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i
10.0.0.0
2.2.2.2
50
0
300e
*>i
10.0.0.0
2.2.2.2
50
0
300e
1.1.1.1
60
0
200e
* i
BGP load balancing cannot be implemented because load balanced routes must have the same AS-path
attribute.
To enable the comparison of MED of routes from each AS:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable the comparison of
MEDs for routes on a per-AS
basis.
bestroute compare-med
Optional.
Not enabled by default.
Enabling the comparison of MED of routes from confederation peers
The MED attributes of routes from confederation peers are not compared if their AS-path attributes
contain AS numbers that do not belong to the confederation, such as these three routes: AS-path
attributes of them are 65006 65009, 65007 65009, and 65008 65009, and MED values of them are
2, 3, and 1. Because the third route contains an AS number that does not belong to the confederation,
the first route becomes the optimal route.
To enable the comparison of MED of routes from confederation peers:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable the comparison of
MED of routes from
confederation peers.
bestroute med-confederation
196
Optional.
Not enabled by default.
Configuring the NEXT_HOP attribute
By default, when advertising routes to an IBGP peer or peer group, a BGP router does not set itself as the
next hop. However, to ensure a BGP peer can find the correct next hop in some cases, you need to
configure the router as the next hop for routes sent to the peer.
For example, as shown in Figure 59, Router A and Router B establish an EBGP neighbor relationship, and
Router B and Router C establish an IBGP neighbor relationship. When Router B advertises a network
learned from Router A to Router C, if Router C has no route to IP address 1.1.1.1/24, you need to configure
Router B to set itself as the next hop (3.1.1.1/24) for the route to be sent to Router C.
Figure 59 Next hop attribute configuration
If a BGP router has two peers on a common broadcast network, it does not set itself as the next hop for
routes sent to an EBGP peer by default. As shown in Figure 60, Router A and Router B establish an EBGP
neighbor relationship, and Router B and Router C establish an IBGP neighbor relationship. They are on
the same broadcast network 1.1.1.0/24. When Router B sends EBGP routes to Router A, it does not set
itself as the next hop by default. However, you can configure Router B to set it as the next hop (1.1.1.2/24)
for routes sent to Router A by using the peer next-hop-local command as needed.
Figure 60 Next hop attribute configuration
IMPORTANT:
If you have configured BGP load balancing, the router sets itself as the next hop for routes sent to an IBGP
peer or peer group regardless of whether the peer next-hop-local command is configured.
To configure the NEXT_HOP attribute:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
197
Use either method.
Step
Command
Remarks
Optional.
3.
Specify the router as the next
hop of routes sent to a peer or
peer group.
peer { group-name | ip-address }
next-hop-local
By default, the router sets it as the
next hop for routes sent to an EBGP
peer or peer group, but does not
set it as the next hop for routes sent
to an IBGP peer or peer group.
Configuring the AS_PATH attribute
Permitting local AS number to appear in routes from a peer or peer group
In general, BGP checks whether the AS_PATH attribute of a route from a peer contains the local AS
number. If so, it discards the route to avoid routing loops.
However, in certain network environments (a Hub&Spoke network in MPLS L3VPN, for example), the
AS_PATH attribute of a route from a peer must be allowed to contain the local AS number; otherwise, the
route cannot be advertised correctly.
To permit local AS number to appear in routes from a peer or peer group and specify the appearance
times:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b.
3.
Permit local AS number to
appear in routes from a peer
or peer group and specify the
appearance times.
Use either method.
pv4-family vpn-instance
vpn-instance-name
Optional.
peer { group-name | ip-address }
allow-as-loop [ number ]
By default, the local AS number is
not allowed to appear in routes
from a peer or peer group.
Disabling BGP from considering AS_PATH during best route selection
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
198
Use either method.
Step
3.
Command
Disable BGP from considering
AS_PATH during best route
selection.
Remarks
Optional.
bestroute as-path-neglect
By default, BGP considers
AS_PATH during best route
selection.
Specifying a fake AS number for a peer or peer group
When Router A in AS 2 is moved to AS 3, you can configure Router A to specify a fake AS number of 2
for created connections to EBGP peers or peer groups. In this way, these EBGP peers still think Router A
is in AS 2 and need not change their configurations. This feature ensures uninterrupted BGP services.
To specify a fake AS number for a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Optional.
3.
Specify a fake AS number for
a peer or peer group.
peer { group-name | ip-address }
fake-as as-number
Not specified by default.
This command is only
applicable to an EBGP peer or
peer group.
Configuring AS number substitution
In MPLS L3VPN, if EBGP is used between PE and CE, sites in different geographical areas must have
different AS numbers assigned to ensure correct route advertisement. If CEs in different geographical
areas use the same AS number, you must configure the relevant PE to replace the AS number of the CE
as its own AS number. This feature is used for route advertisement only.
Figure 61 AS number substitution configuration
As shown in the above figure, CE 1 and CE 2 use the same AS number of 800. If AS number substitution
for CE 2 is configured on PE 2, and PE 2 receives a BGP update sent from CE 1, PE 2 replaces AS number
800 as its own AS number 100. Similar configuration must also be made on PE 1.
199
Use AS number substitution only in the specific scenario. Improper configuration can result in routing
loops.
To configure AS number substitution for a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Replace the AS number of a
peer or peer group in the
AS_PATH attribute as the local
AS number.
peer { group-name | ip-address }
substitute-as
Not configured by default.
Removing private AS numbers from updates to a peer or peer group
Private AS numbers are typically used in test networks, and need not be transmitted in public networks.
The range of private AS numbers is from 64512 to 65535.
To remove private AS numbers from updates to a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Configure BGP to remove
private AS numbers from the
AS_PATH attribute of updates
to a peer or peer group.
peer { group-name | ip-address }
public-as-only
By default, BGP updates carry
private AS numbers.
Ignoring the first AS number of EBGP route updates
Typically, BGP checks the AS_PATH attribute of a route update received from a peer. If the first AS number
is not that of the BGP peer, the BGP router discards the route update.
For some network applications, a BGP router does not add its own AS number to the AS_PATH attribute.
In this case, you must configure the ignore-first-as command on the EBGP peer to ignore the first AS
number of EBGP route updates.
To ignore the first AS number of EBGP route updates:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
200
Step
Command
Remarks
2.
Enter BGP view or BGP-VPN
instance view.
bgp as-number
N/A
3.
Configure BGP to ignore the
first AS number of EBGP route
updates.
ignore-first-as
By default, BGP checks the first AS
number of EBGP route updates.
Tuning and optimizing BGP networks
Configuring the BGP keepalive interval and holdtime
After establishing a BGP session, two routers send keepalive messages at the specified keepalive interval
to each other to keep the session.
If a router receives no keepalive or update message from the peer within the holdtime, it tears down the
session.
You can configure the keepalive interval and holdtime globally or for a specific peer or peer group. The
intervals configured for the specified peer or peer group takes higher priority. The actual keepalive
interval and holdtime depend on the following cases:
•
If the holdtime settings on the local and peer routers are different, the smaller one is used.
•
If the configured keepalive interval is 0 and the negotiated holdtime is not 0, the actual keepalive
interval equals one-third of the holdtime.
•
If the configured keepalive interval is not 0, the actual keepalive interval is the smaller one between
one third of the holdtime and the keepalive interval.
Follow these guidelines when you configure the BGP keepalive interval and holdtime:
•
The maximum keepalive interval should be one third of the holdtime and no less than one second.
The holdtime is no less than three seconds unless it is set to 0.
•
The intervals set with the peer timer command are preferred to those set with the timer command.
•
If the router has established a BGP session with a peer, you must reset the BGP session to validate
the new set timers.
•
The timer command takes effect for only new BGP sessions.
•
After you set new intervals with the peer timer command, the existing BGP session is closed at once,
and a new session to the peer is negotiated by using the configured holdtime.
To configure BGP keepalive interval and holdtime:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
201
Use either method.
Step
Command
Remarks
• Configure the global keepalive
interval and holdtime:
timer keepalive keepalive hold
holdtime
3.
Configure BGP keepalive interval
and holdtime.
• Configure the keepalive interval
and holdtime for a peer or peer
group:
peer { group-name |
ip-address } timer keepalive
keepalive hold holdtime
Optional.
By default, the keepalive
interval is 60 seconds, and
holdtime is 180 seconds.
Configuring the interval for sending the same update
A BGP router sends an update message to its peers when a route is changed. If the route changes
frequently, the BGP router sends a large number of updates for the route, which can cause route flaps.
This task allows you to configure the interval for sending the same update to a peer or peer group,
avoiding frequent update sending and route flaps.
To configure the interval for sending the same update to a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Optional.
3.
Configure the interval for
sending the same update to a
peer or peer group.
peer { group-name | ip-address }
route-update-interval interval
By default, the intervals for sending
the same update to an IBGP peer
and an EBGP peer are 15 seconds
and 30 seconds, respectively.
Allowing establishment of EBGP session to an indirectly
connected peer or peer group
Direct physical links must be available between EBGP peers. If not, use the peer ebgp-max-hop
command to establish an EBGP session over multiple hops between two peers.
To allow establishment of EBGP session to an indirectly connected peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
202
Step
Command
Remarks
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Allow the establishment of
EBGP session to an indirectly
connected peer or peer
group, and specify the
maximum hop count.
peer { group-name | ip-address }
ebgp-max-hop [ hop-count ]
By default, the EBGP session to an
indirectly connected peer or peer
group is not allowed to be
established.
Enabling the BGP ORF capability
The BGP Outbound Route Filtering (ORF) feature allows a BGP speaker to send its BGP peer a set of ORFs
through route-refresh messages. The peer then applies the ORFs—in addition to its local routing policies
(if any)—to filter updates to the BGP speaker, reducing the number of exchanged Update messages and
saving network resources.
After you enable the BGP ORF capability, the local BGP router negotiates the ORF capability with the
BGP peer through Open messages (determines whether to carry ORF information in messages, and if yes,
whether to carry non-standard ORF information in the packets). After completing the negotiation process
and establishing the BGP session, the BGP router and its BGP peer can exchange ORF information
through specific route-refresh messages.
For the parameters configured on both sides for ORF capability negotiation, see Table 8.
To enable the BGP ORF capability:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable BGP route refresh for a
peer or peer group.
peer { group-name | ip-address }
capability-advertise route-refresh
Enabled by default.
Optional.
4.
5.
Enable the non-standard ORF
capability for a BGP peer or
peer group.
peer { group-name | ip-address }
capability-advertise orf
non-standard
Enable the ORF capability for
a BGP peer or peer group.
peer { group-name | ip-address }
capability-advertise orf ip-prefix
{ both | receive | send }
203
By default, standard BGP ORF
capability defined in RFC 5291
and RFC 5292 is supported.
If the peer supports only
non-standard ORF, you need to
configure this command.
Disabled by default.
Table 8 Description of the both, send, and receive parameters and the negotiation result
Local parameter
Peer parameter
Negotiation result
send
• receive
• both
The local end can only send ORF information, and the peer
end can only receive ORF information.
receive
• send
• both
The local end can only receive ORF information, and the
peer end can only send ORF information.
both
both
Both the local and peer ends can send and receive ORF
information.
Enabling 4-byte AS number suppression
When a device that supports 4-byte AS numbers sends an Open message for session establishment, the
Optional parameters field of the message indicates that the AS number occupies four bytes—in the
range of 1 to 4294967295. If the peer device does not support 4-byte AS numbers (for examples, it
supports only 2-byte AS numbers), the session cannot be established.
After you enable the 4-byte AS number suppression function, the peer device can then process the Open
message even though it does not support 4-byte AS numbers, and the BGP session can be established.
If the peer device supports 4-byte AS numbers, do not enable the 4-byte AS number suppression function;
otherwise, the BGP peer relationship cannot be established.
To enable 4-byte AS number suppression:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable 4-byte AS number
suppression.
peer { group-name | ip-address }
capability-advertise
suppress-4-byte-as
Disabled by default.
Enabling quick reestablishment of direct EBGP session
When the link to a directly connected EBGP peer is down, the router, with quick EBGP session
reestablishment enabled, tears down the session to the peer, and then reestablishes a session
immediately. If the function is not enabled, the router does not tear down the session until the holdtime
times out. A route flap does not affect the EBGP session state when the quick EBGP session
reestablishment is disabled.
To enable quick reestablishment of direct EBGP session:
204
Step
Enter system view.
1.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
Enter BGP view or BGP-VPN
instance view.
2.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Enable quick reestablishment
of direct EBGP session.
3.
ebgp-interface-sensitive
Optional.
Not enabled by default.
Enabling MD5 authentication for BGP peers
You can enable MD5 authentication to enhance security in the following ways:
•
Perform MD5 authentication when establishing TCP connections. Only the two parties that have the
same password configured can establish TCP connections.
•
Perform MD5 calculation on TCP packets to avoid modification to the encapsulated BGP packets.
To enable MD5 authentication for BGP peers:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable MD5 authentication
for BGP peers.
peer { group-name | ip-address }
password { cipher | simple }
password
Not enabled by default.
Configuring BGP load balancing
If multiple BGP routes that have the same AS_PATH, ORIGIN, LOCAL_PREF, and MED attributes to a
destination exist, you can use the balance command to configure the maximum number of BGP routes for
load balancing to improve link utilization.
To configure BGP load balancing:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
205
Step
Command
Remarks
• Enter BGP view:
bgp as-number
Enter BGP view or BGP-VPN
instance view.
2.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
Configure the maximum
number of BGP routes for load
balancing.
3.
balance number
By default, load balancing is not
enabled.
Forbidding session establishment with a peer or peer group
This task allows you to temporarily tear down the BGP session to a specific peer or peer group. To recover
the session, execute the undo peer ignore command. In this way, you can implement network upgrade
and maintenance without deleting and then configuring the peer or peer group.
To forbid session establishment with a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Forbid session establishment
with a peer or peer group.
peer { group-name | ip-address }
ignore
Not forbidden by default.
Configuring BGP soft-reset
After modifying the route selection policy, you must reset BGP sessions to make the new policy take effect
and advertise new routes. The router then filters routing information by using the new policy.
The soft-reset feature allows you to refresh the BGP routing table and apply the new route selection policy
without tearing down BGP sessions.
The following soft-reset methods are available:
•
Automatic soft-reset—After a policy is modified, the router advertises a Route-refresh message to
the peers, which then resend their routing information to the router. After receiving the routing
information, the router filters the routing information by using the new policy.
This method requires that both the local router and the peer support route refresh.
•
Manual soft-reset—Use the peer keep-all-routes command to save all route updates from the peer.
After modifying the route selection policy, use the refresh bgp command to filter routing information
by using the new policy.
This method uses more memory resources to save routes and does not require that the local router
and the peer support route refresh.
206
Configuring automatic soft-reset
After route refresh is enabled for peers and a policy is modified, the router advertises a route-refresh
message to the peers, which then resend their routing information to the router. After receiving the routing
information, the router performs dynamic route update by using the new policy.
To enable BGP route refresh for a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable BGP route refresh for a
peer or peer group.
peer { group-name | ip-address }
capability-advertise route-refresh
Optional.
Enabled by default.
Configuring manual soft-reset
If a BGP peer does not support route-refresh, you must save updates from the peer on the local router by
using the peer keep-all-routes command, and use the refresh bgp command to refresh the BGP routing
table.
If the BGP peer does not support route-refresh and the peer keep-all-routes command is not configured
on the local end, you must decide whether to manually disconnect the session with the peer to learn
routes again according to the impact of the new policy.
To save all route updates from a peer or peer group:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
• Disable BGP route-refresh:
3.
Disable BGP route-refresh for
a peer or peer group.
undo peer { group-name |
ip-address } capability-advertise
route-refresh
• Disable multi-protocol extension
capability:
peer { group-name | ip-address }
capability-advertise conventional
4.
Save all route updates from a
peer or peer group.
peer { group-name | ip-address }
keep-all-routes
207
Use either method.
By default, BGP route-refresh
and multi-protocol extension
capability is enabled for a peer
or peer group.
The peer capability-advertise
conventional command is not
supported in BGP-VPN instance
view.
Not saved by default.
Step
Command
Remarks
5.
Return to user view.
return
N/A
6.
Perform manual soft-reset on
BGP sessions.
refresh bgp { all | ip-address | group
group-name | external | internal }
{ export | import }
N/A
Configuring a large scale BGP network
In a large-scale BGP network, configuration and maintenance might become difficult due to large
numbers of BGP peers. To facilitate configuration, you can configure peer group, community, route
reflector, or confederation as needed. For information about configuring a peer group, see "Configuring
a BGP peer group."
Configuration prerequisites
Peering nodes are accessible to each other at the network layer.
Configuring BGP community
By default, a router does not send the community or extended community attribute to its peers or peer
groups. When the router receives a route carrying the community or extended community attribute, it
removes the attribute before advertising the route to its peers or peer groups.
This task allows you to enable a router to advertise the community or extended community attribute to its
peers, so that you can implement route filtering and control. By using this configuration together with a
routing policy, you can add and modify the community or extended community attribute of a route. For
more information about routing policy, see "Configuring routing policies."
To configure BGP community:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
208
Use either method.
Step
Command
Remarks
• Advertise the community
3.
4.
Advertise the community
attribute or extended
community attribute to a peer
or peer group.
Apply a routing policy to
routes advertised to a peer or
peer group.
attribute to a peer or peer
group:
peer { group-name |
ip-address }
advertise-community
Use either method.
• Advertise the extended
Not configured by default.
peer { group-name | ip-address }
route-policy route-policy-name
export
Not configured by default.
community attribute to a peer or
peer group:
peer { group-name |
ip-address }
advertise-ext-community
Configuring a BGP route reflector
If an AS has many BGP routers, you can configure them as a cluster and configure one of them as a route
reflector and others as clients to reduce IBGP connections.
To enhance network reliability and prevent single point of failure, specify multiple route reflectors for a
cluster. The route reflectors in the cluster must have the same cluster ID to avoid routing loops.
In general, it is not required to make clients of a route reflector fully meshed. The route reflector forwards
routing information between clients. If clients are fully meshed, disable route reflection between clients to
reduce routing costs.
To configure a BGP route reflector:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
b. ipv4-family vpn-instance
vpn-instance-name
209
Use either method.
Step
Command
Remarks
Not configured by default.
3.
Configure the router as a route
reflector and specify a peer or
peer group as its client.
peer { group-name | ip-address }
reflect-client
4.
Enable route reflection
between clients.
reflect between-clients
Configure the cluster ID of the
route reflector.
5.
The peer reflect-client command
can be configured in both BGP
view and BGP-VPNv4 subaddress
family view. In BGP view, the
command enables the router to
reflect routes of the public network;
in BGP-VPNv4 subaddress family
view, the command enables the
router to reflect routes of the private
network. (You can enter
BGP-VPNv4 subaddress family
view by executing the ipv4-family
vpnv4 command in BGP view. For
more information about the
ipv4-family vpnv4 command, see
MPLS Command Reference.)
Optional.
Enabled by default.
Optional.
reflector cluster-id cluster-id
By default, a route reflector uses its
router ID as the cluster ID.
Configuring a BGP confederation
Configuring a BGP confederation is another way for reducing IBGP connections in an AS.
A confederation contains sub ASs. In each sub AS, IBGP peers are fully meshed. Between sub ASs, EBGP
connections are established.
If routers not compliant with RFC 3065 exist in the confederation, use the confederation nonstandard
command to make the local router compatible with these routers.
Configuring a BGP confederation
After you split an AS into multiple sub ASs, you can configure a router in a sub AS in the following way:
1.
Enable BGP and specify the AS number of the router. For more information, see "Enabling BGP."
2.
Specify the confederation ID. From an outsider's perspective, the sub ASs of the confederation is
a single AS, which is identified by the confederation ID.
3.
If the router needs to establish EBGP connections to other sub ASs, you must specify the peering
sub ASs in the confederation.
A confederation contains a maximum of 32 sub ASs. The AS number of a sub AS is effective only in the
confederation.
To configure a BGP confederation:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
210
Step
Command
Remarks
3.
Configure a confederation ID.
confederation id as-number
Not configured by default.
4.
Specify peering sub ASs in the
confederation.
confederation peer-as
as-number-list
Not configured by default.
Configuring confederation compatibility
If some other routers in the confederation do not comply with RFC 3065, you must enable confederation
compatibility to allow the router to work with those routers.
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enable compatibility with
routers not compliant with
RFC 3065 in the
confederation.
confederation nonstandard
Optional.
Not enabled by default.
Configuring BGP GR
Graceful Restart (GR) ensures the continuity of packet forwarding when BGP restarts or an
active/standby switchover occurs:
•
GR restarter—Graceful restarting router. It must be GR capable.
•
GR helper—A neighbor of the GR restarter. It helps the GR restarter to complete the GR process.
NOTE:
An MSR router can act as only a GR helper.
Following is a GR process:
1.
A BGP GR restarter and Helper exchange Open messages with GR capability. If both parties have
the GR capability, the session established between them is GR capable.
2.
When an active/standby switchover occurs on the GR restarter, the GR restarter does not remove
existing route entries; it still uses these routes for packet forwarding. The GR helper marks all routes
learned from the GR restarter as stale, instead of deleting them; it still uses these routes for packet
forwarding. During the GR process, packet forwarding is not interrupted.
3.
After the active/standby switchover is completed, the GR restarter reestablishes a GR session with
the GR helper. If no BGP session is established within the interval set with the graceful-restart timer
restart command, the GR helper removes the stale routes.
4.
If a BGP session is established, routing information is exchanged between them for the GR restarter
to retrieve route entries, and for the GR helper to recover stale routes. You can control the routing
information exchange interval by configuring the graceful-restart timer wait-for-rib command. If
routing information exchange is not completed within the time, the GR restarter does not receive
new routes; instead, it updates its routing table and forwarding table with the BGP routes already
learned to complete BGP routing convergence. The GR helper then removes the state routes.
Follow these guidelines when you configure BGP GR:
211
•
In general, the maximum time allowed for the peer to reestablish a BGP session must be less than
the Holdtime carried in the Open message.
•
The End-Of-RIB (End of Routing-Information-Base) indicates the end of route updates.
Perform the following configuration on the GR helper.
To configure BGP GR:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable BGP, and enter its view.
bgp as-number
N/A
3.
Enable GR Capability for BGP.
graceful-restart
Disabled by default.
4.
Configure the maximum time
allowed for the peer to
reestablish a BGP session.
graceful-restart timer restart
timer
Optional.
Configure the maximum time to
wait for the End-of-RIB marker.
graceful-restart timer
wait-for-rib timer
Optional.
5.
150 seconds by default.
180 seconds by default.
Enabling trap
After trap is enabled for BGP, BGP generates Level-4 traps to report important events. The generated
traps are sent to the information center of the device. The output rules of the traps (whether to output the
traps and the output direction) are determined according to the information center configuration. (For
information center configuration, see Network Management and Monitoring Configuration Guide.)
To enable trap:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable trap for BGP.
snmp-agent trap enable bgp
Optional.
Enabled by default.
Enabling logging of session state changes
This task allows you to enable BGP to log session establishment and disconnection events. You can use
the display bgp ipv4 peer log-info command to view the log information.
To enable the logging of session state changes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enable the logging of session
state changes globally.
log-peer-change
212
Optional.
Enabled by default.
Step
Command
Remarks
4.
Enter BGP-VPN instance view.
ipv4-family vpn-instance
vpn-instance-name
Optional.
5.
Enable the logging of session
state changes for a peer or
peer group.
peer { group-name | ip-address }
log-change
Optional.
N/A
Enabled by default.
Configuring BFD for BGP
BGP maintains neighbor relationships based on the keepalive timer and holdtime timer, which are set in
seconds. BGP defines that the holdtime interval must be at least three times the keepalive interval. This
mechanism makes link failure detection rather slow; once a failure occurs on a high-speed link, a large
quantity of packets are dropped. BFD resolves this issue by detecting links between neighbors quickly to
reduce convergence time upon link failures.
IMPORTANT:
• Before you configure BFD for BGP, you must enable BGP.
• After a link failure occurs, BFD might detect the failure before the system performs GR. As a result, GR
will fail. If GR capability is enabled for BGP, use BFD with caution. If GR and BFD are both enabled, do
not disable BFD during a GR process; otherwise, GR might fail.
For BFD configuration, see High Availability Configuration Guide.
To enable BFD for a BGP peer:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Enter BGP view:
bgp as-number
2.
Enter BGP view or BGP-VPN
instance view.
• Enter BGP-VPN instance view:
a. bgp as-number
Use either method.
b. ipv4-family vpn-instance
vpn-instance-name
3.
Enable BFD for the specified
BGP peer.
peer ip-address bfd
Not enabled for any BGP peer
by default.
Displaying and maintaining BGP
Displaying BGP
Task
Command
Remarks
Display peer group information.
display bgp group [ group-name ] [ | { begin | exclude
| include } regular-expression ]
Available in
any view.
Display advertised BGP routing
information.
display bgp network [ | { begin | exclude | include }
regular-expression ]
Available in
any view.
213
Task
Command
Remarks
Display AS path information.
display bgp paths [ as-regular-expression | | { begin |
exclude | include } regular-expression ]
Available in
any view.
Display BGP peer or peer group
information.
display bgp peer [ ip-address { log-info | verbose } |
group-name log-info | verbose ] [ | { begin | exclude
| include } regular-expression ]
Available in
any view.
Display the prefix information in
the ORF message from the
specified BGP peer.
display bgp peer ip-address received ip-prefix [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Display BGP routing information.
display bgp routing-table [ ip-address [ { mask |
mask-length } [ longer-prefixes ] ] ] [ | { begin |
exclude | include } regular-expression ]
Available in
any view.
Display routing information
matching the AS path ACL.
display bgp routing-table as-path-acl
as-path-acl-number [ | { begin | exclude | include }
regular-expression ]
Available in
any view.
Display BGP CIDR routing
information.
display bgp routing-table cidr [ | { begin | exclude |
include } regular-expression ]
Available in
any view.
Display BGP routing information
matching the specified BGP
community.
display bgp routing-table community
[ aa:nn&<1-13> ] [ no-advertise | no-export |
no-export-subconfed ] * [ whole-match ] [ | { begin |
exclude | include } regular-expression ]
Available in
any view.
Display routing information
matching a BGP community list.
display bgp routing-table community-list
{ { basic-community-list-number | comm-list-name }
[ whole-match ] | adv-community-list-number } [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Display BGP dampened routing
information.
display bgp routing-table dampened [ | { begin |
exclude | include } regular-expression ]
Available in
any view.
Display BGP dampening
parameter information.
display bgp routing-table dampening parameter [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Display BGP routing information
originating from different ASs.
display bgp routing-table different-origin-as [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Display BGP routing flap statistics.
display bgp routing-table flap-info
[ regular-expression as-regular-expression |
[ as-path-acl as-path-acl-number | ip-address [ { mask
| mask-length } [ longer-match ] ] ] [ | { begin |
exclude | include } regular-expression ] ]
Available in
any view.
Display labeled BGP routing
information.
display bgp routing-table label [ | { begin | exclude |
include } regular-expression ]
Available in
any view.
Display routing information to or
from a peer.
display bgp routing-table peer ip-address
{ advertised-routes | received-routes }
[ network-address [ mask | mask-length ] | statistic ] [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Display routing information
matching a regular expression.
display bgp routing-table regular-expression
as-regular-expression
Available in
any view.
Display BGP routing statistics.
display bgp routing-table statistic [ | { begin | exclude
| include } regular-expression ]
Available in
any view.
214
Task
Command
Remarks
Display the global router ID.
display router id [ | { begin | exclude | include }
regular-expression ]
Available in
any view.
Resetting BGP session
Task
Command
Remarks
Reset the specified BGP session.
reset bgp { as-number | ip-address | all |
external | group group-name | internal }
Available in user view.
Reset all IPv4 unicast BGP
sessions.
reset bgp ipv4 all
Available in any view.
Clearing BGP information
Task
Command
Remarks
Clear dampened BGP
routing information and
release suppressed routes.
reset bgp dampening [ ip-address [ mask |
mask-length ] ]
Available in user view.
Clear route flap information.
reset bgp flap-info [ ip-address
[ mask-length | mask ] | as-path-acl
as-path-acl-number | regexp
as-path-regular-expression ]
Available in user view.
reset bgp peer-ip-address flap-info
BGP configuration examples
BGP basic configuration
Network requirements
As shown in Figure 62, run EBGP between Router A and Router B, and run IBGP between Router B and
Router C so that Router C can access the network 8.1.1.0/24 connected to Router A.
Figure 62 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IBGP:
215
{
{
{
To prevent route flapping caused by port state changes, this example uses loopback interfaces
to establish IBGP connections.
Because loopback interfaces are virtual interfaces, you need to use the peer connect-interface
command to specify the loopback interface as the source interface for establishing BGP
connections.
Enable OSPF in AS 65009 to make sure that Router B can communicate with Router C through
loopback interfaces.
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.3.3.3 as-number 65009
[RouterB-bgp] peer 3.3.3.3 connect-interface loopback 0
[RouterB-bgp] quit
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] network 9.1.1.1 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 2.2.2.2 as-number 65009
[RouterC-bgp] peer 2.2.2.2 connect-interface loopback 0
[RouterC-bgp] quit
[RouterC] ospf 1
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0
[RouterC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
[RouterC] display bgp peer
BGP local router ID : 3.3.3.3
Local AS number : 65009
Total number of peers : 1
Peer
2.2.2.2
Peers in established state : 1
AS
MsgRcvd
65009
7
MsgSent OutQ PrefRcv Up/Down
10
0
State
0 00:06:09 Established
The output shows that Router C has established an IBGP peer relationship with Router B.
3.
Configure EBGP:
{
The EBGP peers, Router A and Router B (usually belong to different ISPs), are located in different
ASs. Typically, their loopback interfaces are not reachable to each other, so directly connected
interfaces are used for establishing BGP sessions.
216
To enable Router C to access the network 8.1.1.0/24 connected directly to Router A, inject
network 8.1.1.0/24 to the BGP routing table of Router A.
{
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] network 8.1.1.1 24
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] peer 3.1.1.2 as-number 65008
[RouterB-bgp] quit
# Display BGP peer information on Router B.
[RouterB] display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 65009
Total number of peers : 2
Peer
Peers in established state : 2
AS
MsgRcvd
MsgSent OutQ PrefRcv Up/Down
State
3.3.3.3
65009
12
10
0
3 00:09:16 Established
3.1.1.2
65008
3
3
0
1 00:00:08 Established
The output shows that Router B has established an IBGP peer relationship with Router C and an
EBGP peer relationship with Router A.
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
*>
Network
NextHop
MED
8.1.1.0/24
0.0.0.0
0
LocPrf
PrefVal Path/Ogn
0
# Display the BGP routing table on Router B.
[RouterB] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 2.2.2.2
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
217
i
Origin : i - IGP, e - EGP, ? - incomplete
*>
Network
NextHop
MED
8.1.1.0/24
3.1.1.2
0
LocPrf
PrefVal Path/Ogn
0
65008i
# Display the BGP routing table on Router C.
[RouterC] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
i 8.1.1.0/24
3.1.1.2
0
100
0
65008i
NOTE:
From the outputs, you can find Router A has learned no route to AS 65009, and Router C has learned
network 8.1.1.0 but the next hop 3.1.1.2 is unreachable, and thus the route is invalid.
4.
Redistribute direct routes:
Configure BGP to redistribute direct routes on Router B, so Router A can obtain the route to
9.1.1.0/24 and Router C can obtain the route to 3.1.1.0/24.
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] import-route direct
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 4
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? – incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
2.2.2.2/32
3.1.1.1
0
0
65009?
*
3.1.1.0/24
3.1.1.1
0
0
65009?
*>
8.1.1.0/24
0.0.0.0
0
0
i
*>
9.1.1.0/24
3.1.1.1
0
0
65009?
Two routes 2.2.2.2/32 and 9.1.1.0/24 have been added in the routing table of Router A.
# Display the BGP routing table on Router C.
218
[RouterC] display bgp routing-table
Total Number of Routes: 4
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
i 2.2.2.2/32
2.2.2.2
0
100
0
?
*>i 3.1.1.0/24
2.2.2.2
0
100
0
?
*>i 8.1.1.0/24
3.1.1.2
0
100
0
65008i
* i 9.1.1.0/24
2.2.2.2
0
100
0
?
The output shows that the route 8.1.1.0 becomes valid with the next hop as Router A.
Verifying the configuration
# Ping 8.1.1.1 on Router C.
[RouterC] ping 8.1.1.1
PING 8.1.1.1: 56
data bytes, press CTRL_C to break
Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=2 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=3 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=5 ttl=254 time=2 ms
--- 8.1.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/2 ms
BGP and IGP synchronization configuration
Network requirements
As shown in Figure 63, all devices of company A reside in AS 65008 while all devices of company B
reside in AS 65009. AS 65008 and AS 65009 are connected through Router A and Router B. It is
required that Router A can access network 9.1.2.0/24 in AS 65009, and Router C can access network
8.1.1.0/24 in AS 65008.
Figure 63 Network diagram
219
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF:
Enable OSPF in AS 65009, so that Router B can obtain the route to 9.1.2.0/24.
# Configure Router B.
<RouterB> system-view
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf 1
[RouterC-ospf-1] import-route direct
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
3.
Configure the EBGP connection:
Configure the EBGP connection and inject network 8.1.1.0/24 to the BGP routing table of Router
A, so that Router B can obtain the route to 8.1.1.0/24.
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] network 8.1.1.0 24
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.1.1.2 as-number 65008
4.
Configure BGP and IGP synchronization:
{
{
Configure BGP to redistribute routes from OSPF on Router B, so Router A can obtain the route to
9.1.2.0/24.
Configure OSPF to redistribute routes from BGP on Router B, so that Router C can obtain the
route to 8.1.1.0/24.
# Configure BGP to redistribute routes from OSPF on Router B.
[RouterB-bgp] import-route ospf 1
[RouterB-bgp] quit
[RouterB] ospf 1
[RouterB-ospf-1] import-route bgp
[RouterB-ospf-1] quit
220
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
3.3.3.3/32
3.1.1.1
1
0
65009?
*>
8.1.1.0/24
0.0.0.0
0
0
i
*>
9.1.2.0/24
3.1.1.1
1
0
65009?
# Display the routing table on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 9
Routes : 9
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
2.2.2.2/32
OSPF
10
1
9.1.1.1
S2/0
3.3.3.3/32
Direct 0
0
127.0.0.1
InLoop0
8.1.1.0/24
O_ASE
1
9.1.1.1
S2/0
9.1.1.0/24
Direct 0
0
9.1.1.2
S2/0
9.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
9.1.2.0/24
Direct 0
0
9.1.2.1
Eth1/1
9.1.2.1/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.1/32
Direct 0
0
127.0.0.1
InLoop0
150
Verifying the configuration
# Use ping for verification.
[RouterA] ping -a 8.1.1.1 9.1.2.1
PING 9.1.2.1: 56
data bytes, press CTRL_C to break
Reply from 9.1.2.1: bytes=56 Sequence=1 ttl=254 time=15 ms
Reply from 9.1.2.1: bytes=56 Sequence=2 ttl=254 time=31 ms
Reply from 9.1.2.1: bytes=56 Sequence=3 ttl=254 time=47 ms
Reply from 9.1.2.1: bytes=56 Sequence=4 ttl=254 time=46 ms
Reply from 9.1.2.1: bytes=56 Sequence=5 ttl=254 time=47 ms
--- 9.1.2.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 15/37/47 ms
[RouterC] ping -a 9.1.2.1 8.1.1.1
221
PING 8.1.1.1: 56
data bytes, press CTRL_C to break
Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=2 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=3 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=5 ttl=254 time=2 ms
--- 8.1.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/2 ms
BGP load balancing configuration
Network requirements
As shown in Figure 64, all routers run BGP, and Router A resides in AS 65008, and Router B and Router
C reside in AS 65009. EBGP runs between Router A and Router B, and between Router A and Router C.
IBGP runs between Router B and Router C. Configure two routes on Router A for load balancing.
Figure 64 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure BGP connections:
{
{
{
On Router A, establish EBGP connections with Router B and Router C, respectively; configure
BGP to advertise network 8.1.1.0/24 to Router B and Router C, so Router B and Router C can
access the internal network connected to Router A.
On Router B, establish an EBGP connection with Router A and an IBGP connection with Router
C; configure BGP to advertise network 9.1.1.0/24 to Router A, so Router A can access the
intranet through Router B; configure a static route to interface loopback 0 on Router C (or use a
routing protocol like OSPF) to establish the IBGP connection.
On Router C, establish an EBGP connection with Router A and an IBGP connection with Router
B; configure BGP to advertise network 9.1.1.0/24 to Router A, so Router A can access the
222
internal network through Router C; configure a static route to interface loopback 0 on Router B
(or use another protocol like OSPF) to establish the IBGP connection.
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] peer 3.1.2.1 as-number 65009
[RouterA-bgp] network 8.1.1.1 24
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.1.1.2 as-number 65008
[RouterB-bgp] peer 3.3.3.3 as-number 65009
[RouterB-bgp] peer 3.3.3.3 connect-interface loopback 0
[RouterB-bgp] network 9.1.1.0 24
[RouterB-bgp] quit
[RouterB] ip route-static 3.3.3.3 32 9.1.1.2
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 3.1.2.2 as-number 65008
[RouterC-bgp] peer 2.2.2.2 as-number 65009
[RouterC-bgp] peer 2.2.2.2 connect-interface loopback 0
[RouterC-bgp] network 9.1.1.0 24
[RouterC-bgp] quit
[RouterC] ip route-static 2.2.2.2 32 9.1.1.1
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? – incomplete
Network
NextHop
MED
*>
8.1.1.0/24
0.0.0.0
0
0
i
*>
9.1.1.0/24
3.1.1.1
0
0
65009i
3.1.2.1
0
0
65009i
*
223
LocPrf
PrefVal Path/Ogn
{
{
3.
The output shows two valid routes to destination 9.1.1.0/24: the route with next hop 3.1.1.1 is
marked with a greater-than sign (>), indicating it is the best route; the route with next hop 3.1.2.1
is marked with only an asterisk (*), indicating it is a valid route, but not the best.
By using the display ip routing-table command, you can find only one route to 9.1.1.0/24 with
next hop 3.1.1.1 and outbound interface S2/0.
Configure load balancing:
Because Router A has two routes to reach AS 65009, configuring load balancing over the two
BGP routes on Router A can improve link utilization.
# Configure Router A.
[RouterA] bgp 65008
[RouterA-bgp] balance 2
[RouterA-bgp] quit
Verifying the configuration
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
*>
*>
8.1.1.0/24
9.1.1.0/24
*>
NextHop
0.0.0.0
MED
LocPrf
0
PrefVal Path/Ogn
0
i
3.1.1.1
0
0
65009i
3.1.2.1
0
0
65009i
•
The output shows two valid routes to the destination 9.1.1.0/24, and both of them are marked with
a greater-than sign (>), indicating they are the best routes.
•
By using the display ip routing-table command, you can find two routes to 9.1.1.0/24: one with next
hop 3.1.1.1 and outbound interface S2/0, the other with next hop 3.1.2.1 and outbound interface
S2/1.
BGP route summarization configuration
Network requirements
As shown in Figure 65, run EBGP between Router C and Router D, so the internal network and external
network can communicate with each other.
In AS 65106, configure static routing between Router A and Router B, configure OSPF between Router B
and Router C, and configure OSPF to redistribute static routes, so devices in the internal network can
communicate with each other.
Configure route summarization on Router C so BGP advertises a summary route instead of the specific
networks 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 to Router D.
224
Figure 65 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure static routing between Router A and Router B:
# Configure a default route with the next hop 192.168.212.1 on Router A.
<RouterA> system-view
[RouterA] ip route-static 0.0.0.0 0 192.168.212.1
# Configure static routes to 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 with
the same next hop 192.168.212.161 on Router B.
<RouterB> system-view
[RouterB] ip route-static 192.168.64.0 24 192.168.212.161
[RouterB] ip route-static 192.168.74.0 24 192.168.212.161
[RouterB] ip route-static 192.168.99.0 24 192.168.212.161
3.
Configure OSPF between Router B and Router C, and configure OSPF on Router B to redistribute
static routes:
# Configure OSPF to advertise the local network, and enable OSPF to redistribute static routes on
Router B.
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 172.17.100.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] import-route static
[RouterB-ospf-1] quit
# Configure OSPF to advertise local networks on Router C.
[RouterC] ospf
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 172.17.100.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 10.220.2.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# Display the IP routing table on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
225
Destinations : 10
Destination/Mask
Proto
3.3.3.3/32
Routes : 10
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
10.220.2.0/24
Direct 0
0
10.220.2.16
S2/0
10.220.2.16/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.1/32
Direct 0
0
127.0.0.1
InLoop0
172.17.100.0/24
Direct 0
0
172.17.100.2
S2/1
172.17.100.2/32
Direct 0
0
127.0.0.1
InLoop0
192.168.64.0/24
O_ASE
150
1
172.17.100.1
S2/1
192.168.74.0/24
O_ASE
150
1
172.17.100.1
S2/1
192.168.99.0/24
O_ASE
150
1
172.17.100.1
S2/1
The output shows that Router C has learned routes to 192.168.64.0/24, 192.168.74.0/24, and
192.168.99.0/24 through OSPF.
4.
Configure BGP between Router C and Router D, and configure BGP on Router C to redistribute
OSPF routes:
# On Router C, enable BGP, specify Router D as an EBGP peer, and configure BGP to redistribute
OSPF routes.
[RouterC] bgp 65106
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 10.220.2.217 as-number 64631
[RouterC-bgp] import-route ospf
# Enable BGP, and configure Router C as an EBGP peer on Router D.
[RouterD] bgp 64631
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 10.220.2.16 as-number 65106
[RouterD-bgp] quit
# Display routing table information on Router D.
[RouterD] display ip routing-table
Routing Tables: Public
Destinations : 8
Destination/Mask
Proto
4.4.4.4/32
Routes : 8
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
10.220.2.0/24
Direct 0
0
10.220.2.217
S2/0
10.220.2.217/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.1/32
Direct 0
0
127.0.0.1
InLoop0
192.168.64.0/24
BGP
255
1
10.220.2.16
S2/0
192.168.74.0/24
BGP
255
1
10.220.2.16
S2/0
192.168.99.0/24
BGP
255
1
10.220.2.16
S2/0
The output shows that Router D has learned routes to 192.168.64.0/24, 192.168.74.0/24, and
192.168.99.0/24 through BGP.
226
After the above configurations, ping the hosts on networks 192.168.64.0/24,
192.168.74.0/24, and 192.168.99.0/24 from Router D. The ping operations succeed.
5.
Configure route summarization on Router C:
# Summarize 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 into a single route
192.168.64.0/18 on Router C and disable advertisement of the specific routes.
[RouterC-bgp] aggregate 192.168.64.0 18 detail-suppressed
[RouterC-bgp] quit
Verifying the configuration
# Display IP routing table information on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 11
Destination/Mask
Proto
3.3.3.3/32
Routes : 11
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
10.220.2.0/24
Direct 0
0
10.220.2.16
S2/0
10.220.2.16/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.1/32
Direct 0
0
127.0.0.1
InLoop0
172.17.100.0/24
Direct 0
0
172.17.100.2
S2/1
172.17.100.2/32
Direct 0
0
127.0.0.1
InLoop0
192.168.64.0/18
BGP
130
0
127.0.0.1
NULL0
192.168.64.0/24
O_ASE
150
1
172.17.100.1
S2/1
192.168.74.0/24
O_ASE
150
1
172.17.100.1
S2/1
192.168.99.0/24
O_ASE
150
1
172.17.100.1
S2/1
The output shows that Router C has a summary route 192.168.64.0/18 with the output interface null 0.
# Display the IP routing table information on Router D.
[RouterD] display ip routing-table
Routing Tables: Public
Destinations : 6
Destination/Mask
Proto
4.4.4.4/32
Routes : 6
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
10.220.2.0/24
Direct 0
0
10.220.2.217
S2/0
10.220.2.217/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.1/32
Direct 0
0
127.0.0.1
InLoop0
192.168.64.0/18
BGP
0
10.220.2.16
S2/0
255
The output shows that Router D has only one route 192.168.64.0/18 to AS 65106.
# Verify that Router D can ping the hosts on subnets 192.168.64.0/24, 192.168.74.0/24 and
192.168.99.0/24. (Details not shown.)
227
BGP community configuration
Network requirements
As shown in Figure 66, EBGP runs between Router B and Router A, and between Router B and Router C.
Configure No_Export community attribute on Router A to make routes from AS 10 not advertised by AS
20 to any other AS.
Figure 66 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure EBGP connections:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 10
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.2.2 as-number 20
[RouterA-bgp] network 9.1.1.0 255.255.255.0
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 20
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 200.1.2.1 as-number 10
[RouterB-bgp] peer 200.1.3.2 as-number 30
[RouterB-bgp] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 30
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 200.1.3.1 as-number 20
[RouterC-bgp] quit
# Display BGP routing table information on Router B.
[RouterB] display bgp routing-table 9.1.1.0
BGP local router ID : 2.2.2.2
228
Local AS number : 20
Paths:
1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:
From
: 200.1.2.1 (1.1.1.1)
Original nexthop: 200.1.2.1
AS-path
: 10
Origin
: igp
Attribute value : MED 0, pref-val 0, pre 255
State
: valid, external, best,
Advertised to such 1 peers:
200.1.3.2
Router B has advertised the route to Router C in AS 30.
# Display BGP routing table information on Router C.
[RouterC] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
*>
Network
NextHop
MED
9.1.1.0/24
200.1.3.1
0
LocPrf
PrefVal Path/Ogn
0
Router C has learned the route to the destination 9.1.1.0/24 from Router B.
3.
Configure BGP community attribute:
# Configure a routing policy.
[RouterA] route-policy comm_policy permit node 0
[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit
# Apply the routing policy.
[RouterA] bgp 10
[RouterA-bgp] peer 200.1.2.2 route-policy comm_policy export
[RouterA-bgp] peer 200.1.2.2 advertise-community
# Display BGP routing table information on Router B.
[RouterB] display bgp routing-table 9.1.1.0
BGP local router ID : 2.2.2.2
Local AS number : 20
Paths:
1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:
From
: 200.1.2.1 (1.1.1.1)
Original nexthop: 200.1.2.1
Community
: No-Export
AS-path
: 10
Origin
: igp
229
20 10i
Attribute value : MED 0, pref-val 0, pre 255
State
: valid, external, best,
Not advertised to any peers yet
The output shows that BGP has not learned any route.
BGP route reflector configuration
Network requirements
As shown in Figure 67, all routers run BGP.
•
EBGP runs between Router A and Router B. IBGP runs between Router C and Router B, and between
Router C and Router D.
•
Router C is a route reflector with clients Router B and D.
•
Router D can learn route 1.0.0.0/8 from Router C.
Figure 67 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure BGP connections:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 100
[RouterA-bgp] peer 192.1.1.2 as-number 200
# Inject network 1.0.0.0/8 to the BGP routing table.
[RouterA-bgp] network 1.0.0.0
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 200
[RouterB-bgp] peer 192.1.1.1 as-number 100
[RouterB-bgp] peer 193.1.1.1 as-number 200
[RouterB-bgp] peer 193.1.1.1 next-hop-local
[RouterB-bgp] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 200
230
[RouterC-bgp] peer 193.1.1.2 as-number 200
[RouterC-bgp] peer 194.1.1.2 as-number 200
[RouterC-bgp] quit
# Configure Router D.
<RouterD> system-view
[RouterD] bgp 200
[RouterD-bgp] peer 194.1.1.1 as-number 200
[RouterD-bgp] quit
Configure the route reflector:
3.
# Configure Router C as the route reflector.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.2 reflect-client
[RouterC-bgp] peer 194.1.1.2 reflect-client
[RouterC-bgp] quit
Verifying the configuration
# Display the BGP routing table on Router B.
[RouterB] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 200.1.2.2
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
*>
Network
NextHop
MED
1.0.0.0
192.1.1.1
0
LocPrf
PrefVal Path/Ogn
0
100i
# Display the BGP routing table on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 200.1.2.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
i 1.0.0.0
NextHop
MED
LocPrf
PrefVal Path/Ogn
193.1.1.2
0
100
0
100i
The output shows that Router D learned the route 1.0.0.0/8 from Router C.
BGP confederation configuration
Network requirements
As shown in Figure 68, to reduce IBGP connections in AS 200, split it into three sub-ASs: AS 65001, AS
65002, and AS 65003. Routers in AS 65001 are fully meshed.
231
Figure 68 Network diagram
Router C
Router B
Eth1/1
Eth1/1
Eth1/1 AS 65002
S2/0
AS 65003
Router F
Eth1/4
AS 100
Eth1/1
S2/1
Eth1/2
Eth1/2
Router A
Eth1/1
Eth1/3
Eth1/2
AS 200
Router D
AS 65001
Eth1/1
Router E
Device
Interface
IP address
Device
Interface
IP address
Router A
S2/1
200.1.1.1/24
Router D
Eth1/1
10.1.5.1/24
Eth1/1
10.1.2.1/24
Eth1/2
10.1.3.2/24
Eth1/2
10.1.3.1/24
Eth1/1
10.1.5.2/24
Eth1/3
10.1.4.1/24
Eth1/2
10.1.4.2/24
Eth1/4
10.1.1.1/24
Eth1/1
9.1.1.1/24
Router B
Eth1/1
10.1.1.2/24
S2/0
200.1.1.2/24
Router C
Eth1/1
10.1.2.2/24
Router E
Router F
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure the BGP confederation:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65001
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp] peer 10.1.1.2 as-number 65002
[RouterA-bgp] peer 10.1.1.2 next-hop-local
[RouterA-bgp] peer 10.1.2.2 as-number 65003
[RouterA-bgp] peer 10.1.2.2 next-hop-local
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65002
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] confederation id 200
[RouterB-bgp] confederation peer-as 65001 65003
[RouterB-bgp] peer 10.1.1.1 as-number 65001
[RouterB-bgp] quit
# Configure Router C.
232
<RouterC> system-view
[RouterC] bgp 65003
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001 65002
[RouterC-bgp] peer 10.1.2.1 as-number 65001
[RouterC-bgp] quit
3.
Configure IBGP connections in AS 65001:
# Configure Router A.
[RouterA] bgp 65001
[RouterA-bgp] peer 10.1.3.2 as-number 65001
[RouterA-bgp] peer 10.1.3.2 next-hop-local
[RouterA-bgp] peer 10.1.4.2 as-number 65001
[RouterA-bgp] peer 10.1.4.2 next-hop-local
[RouterA-bgp] quit
# Configure Router D.
<RouterD> system-view
[RouterD] bgp 65001
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] confederation id 200
[RouterD-bgp] peer 10.1.3.1 as-number 65001
[RouterD-bgp] peer 10.1.5.2 as-number 65001
[RouterD-bgp] quit
# Configure Router E.
<RouterE> system-view
[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] peer 10.1.5.1 as-number 65001
[RouterE-bgp] quit
4.
Configure the EBGP connection between AS 100 and AS 200:
# Configure Router A.
[RouterA] bgp 65001
[RouterA-bgp] peer 200.1.1.2 as-number 100
[RouterA-bgp] quit
# Configure Router F.
<RouterF> system-view
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] network 9.1.1.0 255.255.255.0
[RouterF-bgp] quit
Verifying the configuration
# Display BGP routing table information on Router B.
[RouterB] display bgp routing-table
233
Total Number of Routes: 1
BGP Local router ID is 2.2.2.2
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
*>i
NextHop
9.1.1.0/24
MED
LocPrf
0
100
10.1.1.1
PrefVal Path/Ogn
0
(65001) 100i
[RouterB] display bgp routing-table 9.1.1.0
BGP local router ID : 2.2.2.2
Local AS number : 65002
Paths:
1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:
From
: 10.1.1.1 (1.1.1.1)
Relay Nexthop
: 0.0.0.0
Original nexthop: 10.1.1.1
AS-path
: (65001) 100
Origin
: igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State
: valid, external-confed, best,
Not advertised to any peers yet
# Display BGP routing table information on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 4.4.4.4
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
*>i
NextHop
9.1.1.0/24
10.1.3.1
MED
0
LocPrf
100
[RouterD] display bgp routing-table 9.1.1.0
BGP local router ID : 4.4.4.4
Local AS number : 65001
Paths:
1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:
From
: 10.1.3.1 (1.1.1.1)
Relay Nexthop
: 0.0.0.0
Original nexthop: 10.1.3.1
AS-path
: 100
234
PrefVal Path/Ogn
0
100i
Origin
: igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State
: valid, internal, best,
Not advertised to any peers yet
The output shows the following:
•
Router F can send route information to Router B and Router C through the confederation by
establishing only an EBGP connection with Router A.
•
Router B and Router D are in the same confederation, but belong to different sub ASs. They obtain
external route information from Router A and generate the same BGP route entries; it seems like that
they reside in the same AS although they have no direct connection in between.
BGP path selection configuration
Network requirements
As shown in Figure 69, all routers run BGP. EBGP runs between Router A and Router B, and between
Router A and Router C. IBGP runs between Router B and Router D, and between Router D and Router C.
OSPF is the IGP protocol in AS 200.
Configure routing policies to make Router D give priority to the route 1.0.0.0/8 learned from Router C.
Figure 69 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Router A
Eth1/1
1.0.0.0/8
Router D
S2/0
195.1.1.1/24
S2/0
192.1.1.1/24
S2/1
194.1.1.1/24
S2/1
193.1.1.1/24
S2/0
195.1.1.2/24
S2/0
192.1.1.2/24
S2/1
193.1.1.2/24
S2/1
194.1.1.2/24
Router B
Router C
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF on routers B, C, and D:
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
235
[RouterB-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf] area 0
[RouterC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] ospf
[RouterD-ospf] area 0
[RouterD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
[RouterD-ospf-1] quit
3.
Configure BGP connections:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 100
[RouterA-bgp] peer 192.1.1.2 as-number 200
[RouterA-bgp] peer 193.1.1.2 as-number 200
# Inject network 1.0.0.0/8 into the BGP routing table of Router A.
[RouterA-bgp] network 1.0.0.0 8
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 200
[RouterB-bgp] peer 192.1.1.1 as-number 100
[RouterB-bgp] peer 194.1.1.1 as-number 200
[RouterB-bgp] quit
# Configure Router C.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.1 as-number 100
[RouterC-bgp] peer 195.1.1.1 as-number 200
[RouterC-bgp] quit
# Configure Router D.
[RouterD] bgp 200
[RouterD-bgp] peer 194.1.1.2 as-number 200
[RouterD-bgp] peer 195.1.1.2 as-number 200
[RouterD-bgp] quit
4.
Configure different attribute values for the route 1.0.0.0/8 to make Router D give priority to the
route learned from Router C:
236
{
Method 1: Specify a higher MED value for the route 1.0.0.0/8 advertised to 192.1.1.2 to make
Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterA-acl-basic-2000] quit
# Define routing policy apply_med_50 that sets the MED value of route 1.0.0.0/8 to 50, and
routing policy apply_med_100 that sets the MED value of route 1.0.0.0/8 to 100.
[RouterA] route-policy apply_med_50 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA-route-policy] quit
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
[RouterA-route-policy] quit
# Apply routing policy apply_med_50 to the route advertised to 193.1.1.2 (Router C), and
apply routing policy apply_med_100 to the route advertised to 192.1.1.2 (Router B).
[RouterA] bgp 100
[RouterA-bgp] peer 193.1.1.2 route-policy apply_med_50 export
[RouterA-bgp] peer 192.1.1.2 route-policy apply_med_100 export
[RouterA-bgp] quit
# Display the BGP routing table on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 2
BGP Local router ID is 194.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d – damped,
h – history,
i – internal, s – suppressed, S – Stale
Origin : i – IGP, e – EGP, ? – incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 1.0.0.0
193.1.1.1
50
100
0
100i
* i
192.1.1.1
100
100
0
100i
The route 1.0.0.0/8 learned from Router C is the optimal.
{
Method 2: Specify different local preferences for route 1.0.0.0/8 on Router B and C to make
Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8 on Router C.
[RouterC] acl number 2000
[RouterC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterC-acl-basic-2000] quit
# Define routing policy localpref on Router C to set the local preference of route 1.0.0.0/8 to
200 (the default is 100).
[RouterC] route-policy localpref permit node 10
[RouterC-route-policy] if-match acl 2000
[RouterC-route-policy] apply local-preference 200
237
[RouterC-route-policy] quit
# Apply the routing policy localpref to the route from the peer 193.1.1.1 on Router C.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.1 route-policy localpref import
[RouterC-bgp] quit
# Display the BGP routing table on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 2
BGP Local router ID is 194.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 1.0.0.0
193.1.1.1
0
200
0
100i
* i
192.1.1.1
0
100
0
100i
The route 1.0.0.0/8 learned from Router C is the optimal.
BGP GR configuration
Network requirements
As shown in Figure 70, all routers run BGP. EBGP runs between Router A and Router B. IBGP runs
between router B and Router C. Router A and Router C are MSR routers, and Router B is a GR restarter
of another router model. Enable GR capability for BGP so that the communication between Router A and
Router C cannot be affected when an active/standby switchover occurs on Router B.
Figure 70 Network diagram
Configuration procedure
1.
Configure Router A:
# Configure IP addresses for interfaces. (Details not shown.)
# Configure the EBGP connection.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# Inject network 8.0.0.0/8 to the BGP routing table.
[RouterA-bgp] network 8.0.0.0
238
# Enable GR capability for BGP.
[RouterA-bgp] graceful-restart
2.
Configure Router B:
# Configure IP addresses for interfaces. (Details not shown.)
# Configure the EBGP connection.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 200.1.1.2 as-number 65008
# Configure the IBGP connection.
[RouterB-bgp] peer 9.1.1.2 as-number 65009
# Inject networks 200.1.1.0/24 and 9.1.1.0/24 to the BGP routing table.
[RouterB-bgp] network 200.1.1.0 24
[RouterB-bgp] network 9.1.1.0 24
# Enable GR capability for BGP.
[RouterB-bgp] graceful-restart
3.
Configure Router C:
# Configure IP addresses for interfaces. (Details not shown.)
# Configure the IBGP connection.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 9.1.1.1 as-number 65009
# Enable GR capability for BGP.
[RouterC-bgp] graceful-restart
Verifying the configuration
# Ping Router C on Router A. Meanwhile, perform an active/standby switchover on Router B. The ping
operation is successful during the whole switchover process.
Configuring BFD for BGP
Network requirements
As shown in Figure 71,
•
Configure OSPF as the IGP in AS 200.
•
Establish two IBGP connections between Router A and Router C. When both links are working,
Router C adopts the link Router A<—>Router B<—>Router C to exchange packets with network
1.1.1.0/24. Configure BFD over the link. Then if the link fails, BFD can quickly detect the failure and
notify it to BGP. Then the link Router A<—>Router D<—>Router C takes effect immediately.
239
Figure 71 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure OSPF so that Router A and Router C are reachable to each other. (Details not shown.)
3.
Configure BGP on Router A:
# Establish two IBGP connections to Router C.
<RouterA> system-view
[RouterA] bgp 200
[RouterA-bgp] peer 3.0.2.2 as-number 200
[RouterA-bgp] peer 2.0.2.2 as-number 200
[RouterA-bgp] quit
# Create ACL 2000 to permit 1.1.1.0/24 to pass.
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 1.1.1.0 0.0.0.255
[RouterA-acl-basic-2000] quit
# Create two route policies, apply_med_50 and apply_med_100. Policy apply_med_50 sets the
MED for route 1.1.1.0/24 to 50. Policy apply_med_100 sets that to 100.
[RouterA] route-policy apply_med_50 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA-route-policy] quit
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
[RouterA-route-policy] quit
# Apply routing policy apply_med_50 to routes outgoing to peer 3.0.2.2, and apply routing
policy apply_med_100 to routes outgoing to peer 2.0.2.2.
[RouterA] bgp 200
[RouterA-bgp] peer 3.0.2.2 route-policy apply_med_50 export
[RouterA-bgp] peer 2.0.2.2 route-policy apply_med_100 export
# Enable BFD for peer 3.0.2.2.
[RouterA-bgp] peer 3.0.2.2 bfd
240
[RouterA-bgp] quit
4.
Configure BGP on Router C:
<RouterC> system-view
[RouterC] bgp 200
[RouterC-bgp] peer 3.0.1.1 as-number 200
[RouterC-bgp] peer 3.0.1.1 bfd
[RouterC-bgp] peer 2.0.1.1 as-number 200
[RouterC-bgp] quit
5.
Configure BFD parameters (you can use default BFD parameters instead):
# Configure Router A.
{
Configure active-mode BFD on Ethernet 1/2.
[RouterA] bfd session init-mode active
[RouterA] interface ethernet 1/2
{
Configure the minimum interval for transmitting BFD control packets as 500 milliseconds.
[RouterA-Ethernet1/2] bfd min-transmit-interval 500
{
Configure the minimum interval for receiving BFD control packets as 500 milliseconds.
[RouterA-Ethernet1/2] bfd min-receive-interval 500
{
Configure the detect multiplier as 7.
[RouterA-Ethernet1/2] bfd detect-multiplier 7
{
Configure the BFD authentication mode as plain-text authentication, and set the authentication
key to ibgpbfd.
[RouterA-Ethernet1/2] bfd authentication-mode simple 1 ibgpbfd
[RouterA-Ethernet1/2] quit
# Configure Router C.
[RouterC] bfd session init-mode active
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] bfd min-transmit-interval 500
[RouterC-Ethernet1/1] bfd min-receive-interval 500
[RouterC-Ethernet1/1] bfd detect-multiplier 7
[RouterC-Ethernet1/1] bfd authentication-mode simple 1 ibgpbfd
[RouterC-Ethernet1/1] return
Verifying the configuration
The following operations are made on Router C. Operations on Router A are similar.
# Display detailed BFD session information.
<RouterC> display bfd session verbose
Total Session Num: 1
Init Mode: Active
IP Session Working Under Ctrl Mode:
Local Discr: 17
Source IP: 3.0.2.2
Remote Discr: 13
Destination IP: 3.0.1.1
Session State: Up
Interface: Ethernet1/1
Min Trans Inter: 500ms
Act Trans Inter: 500ms
Min Recv Inter: 500ms
Act Detect Inter: 3500ms
241
Recv Pkt Num: 57
Send Pkt Num: 53
Hold Time: 2200ms
Connect Type: Indirect
Running Up for: 00:00:06
Auth mode: Simple
Protocol: BGP
Diag Info: No Diagnostic
The output shows that a BFD session is established between Ethernet 1/2 of Router A and Ethernet 1/1
of Router C and that BFD runs correctly.
# Display BGP peer information on Router C. The output shows that Router C has established two BGP
neighborships with Router A.
<RouterC> display bgp peer
BGP local router ID : 1.1.1.1
Local AS number : 200
Total number of peers : 2
Peer
Peers in established state : 2
AS
MsgRcvd
MsgSent OutQ PrefRcv Up/Down
State
2.0.1.1
200
7
10
0
0 00:01:05 Established
3.0.1.1
200
7
10
0
0 00:01:34 Established
# Display route 1.1.1.0/24 on Router C. The output shows that Router A and Router C communicate
through Router B.
<RouterC> display ip routing-table 1.1.1.0 24 verbose
Routing Table : Public
Summary Count : 2
Destination: 1.1.1.0/24
Protocol: BGP
Preference: 0
NextHop: 3.0.1.1
BkNextHop: 0.0.0.0
RelyNextHop: 3.0.2.1
Tunnel ID: 0x0
State: Active Adv
Process ID: 0
Cost: 50
Interface: Ethernet1/1
BkInterface:
Neighbor : 3.0.1.1
Label: NULL
Age: 00h08m54s
Tag: 0
Destination: 1.1.1.0/24
Protocol: BGP
Preference: 0
NextHop: 2.0.1.1
BkNextHop: 0.0.0.0
RelyNextHop: 2.0.2.1
Tunnel ID: 0x0
State: Invalid Adv
Process ID: 0
Cost: 100
Interface: Ethernet1/2
BkInterface:
Neighbor : 2.0.1.1
Label: NULL
Age: 00h08m54s
Tag: 0
The output shows that Router C has two routes to reach network 1.1.1.0/24: Router C<—>Router
B<—>Router A, which is the active route; Router C<—>Router D<—>Router A, which is the backup
route.
242
# Enable BFD debugging on Router C.
<RouterC> debugging bfd scm
<RouterC> debugging bfd event
<RouterC> debugging bgp bfd
<RouterC> terminal monitor
<RouterC> terminal debugging
# The following debugging information shows that: when the link between Router A and Router B fails,
Router C can quickly detect the link failure.
%Nov 5 11:42:24:172 2009 RouterC BFD/5/BFD_CHANGE_FSM:
Sess[3.0.2.2/3.0.1.1,13/17,Eth1/1,Ctrl], Sta: UP->DOWN, Diag: 1
%Nov 5 11:42:24:172 2009 RouterC BGP/5/BGP_STATE_CHANGED: 3.0.1.1 state is changed from
ESTABLISHED to IDLE.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Recv BFD DOWN msg, Src IP 3.0.2.2,
Dst IP 3.0.1.1, Instance ID 0.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Reset BGP session 3.0.1.1 for
BFD session down.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Send DELETE msg to BFD, Connection
type DIRECT, Src IP 3.0.2.2, Dst IP 3.0.1.1, Instance ID 0.
# Display route 1.1.1.0/24 on Router C. The output shows that Router A and Router C communicate
through Router D.
<RouterC> display ip routing-table 1.1.1.0 24 verbose
Routing Table : Public
Summary Count : 1
Destination: 1.1.1.0/24
Protocol: BGP
Process ID: 0
Preference: 0
Cost: 100
NextHop: 2.0.1.1
BkNextHop: 0.0.0.0
Interface: Ethernet1/2
BkInterface:
RelyNextHop: 2.0.2.1
Tunnel ID: 0x0
State: Active Adv
Neighbor : 2.0.1.1
Label: NULL
Age: 00h09m54s
Tag: 0
The output shows that Router C has one route to reach network 1.1.1.0/24. The route is Router
C<—>Router D<—>Router A.
Troubleshooting BGP
BGP peer relationship not established
Symptom
Display BGP peer information by using the display bgp peer command. The state of the connection to a
peer cannot become established.
Analysis
To become BGP peers, any two routers must establish a TCP session using port 179 and exchange Open
messages successfully.
243
Solution
1.
Use the display current-configuration command to verify that the peer's AS number is correct.
2.
Use the display bgp peer command to verify that the peer's IP address is correct.
3.
If a loopback interface is used, verify that the loopback interface is specified with the peer
connect-interface command.
4.
If the peer is a non-direct EBGP peer, verify that the peer ebgp-max-hop command is configured.
5.
If the peer ttl-security hops command is configured, verify that the command is configured on the
peer, and the hop-count values configured on them are greater than the number of hops between
them.
6.
Verify that a valid route to the peer is available.
7.
Use the ping command to verify the connectivity to the peer.
8.
Use the display tcp status command to verify the TCP connection.
9.
Verify that an ACL disabling TCP port 179 is configured.
244
Configuring routing policies
Routing policies control routing paths by filtering and modifying routing information. This chapter
describes both IPv4 and IPv6 routing policies.
Overview
Routing policies can filter advertised, received, and redistributed routes, and modify attributes for specific
routes.
To configure a routing policy:
1.
Configure filters based on route attributes, such as destination address and the advertising router's
address.
2.
Create a routing policy and apply filters to the routing policy.
Filters
The filters that routing protocols can use to filter routes include ACL, IP prefix list, AS path list, community
list, extended community list, and routing policy. These filters cannot work alone. They must be
referenced by specific commands to take effect. A routing policy can use all the other filters as its own
match criteria.
ACL
ACLs include IPv4 ACLs and IPv6 ACLs. An ACL can match the destination or next hop of routing
information.
For more information about ACL, see ACL and QoS Configuration Guide.
IP prefix list
IP prefix lists include IPv4 prefix lists and IPv6 prefix lists.
An IP prefix list matches the destination address of routing information. You can use the gateway option
to receive routing information only from specific routers. For gateway option information, see
"Configuring RIP" and "Configuring OSPF."
An IP prefix list, identified by name, can comprise multiple items. Each item, identified by an index
number, specifies a prefix range to match. An item with a smaller index number is matched first. A route
that matches one item matches the IP prefix list.
AS path list
An AS path list matches the AS-PATH attribute of BGP routing information.
For more information about AS path list, see "Configuring BGP."
Community list
A community list matches the community attribute of BGP routing information.
For more information about community list, see "Configuring BGP."
245
Extended community list
An extended community list matches the extended community attribute (Route-Target for VPN and Source
of Origin) of BGP routing information.
For more information about extended community list, see MPLS Configuration Guide.
Routing policy
A routing policy can comprise multiple nodes, which are in a logical OR relationship. A node with a
smaller number is matched first. A route that matches one node matches the routing policy.
A node can comprise a set of if-match, apply, and continue clauses.
•
The if-match clauses configure the match criteria that match the attributes of routing information. The
if-match clauses are in a logical AND relationship. A route must match all the if-match clauses to
match the node.
•
The apply clauses specify the actions to be taken on permitted routes, such as modifying a route
attribute.
•
The continue clause specifies the next node. A route that matches the current node must match the
specified next node in the same routing policy. The continue clause combines the if-match and
apply clauses of the two nodes to improve flexibility of the routing policy.
Follow these guidelines to configure if-match, apply, and continue clauses:
•
If you only want to filter routes, do not configure apply clauses.
•
If you do not configure any if-match clauses for a permit-mode node, the node will permit all routes.
•
Configure a permit-mode node containing no if-match or apply clauses behind multiple deny-mode
nodes to allow unmatched routes to pass.
Configuring filters
Configuration prerequisites
Determine the IP-prefix list name, matching address range, and community list number.
Configuring an IP-prefix list
Configuring an IPv4 prefix list
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure an IPv4
prefix list.
ip ip-prefix ip-prefix-name [ index index-number ]
{ deny | permit } ip-address mask-length
[ greater-equal min-mask-length ] [ less-equal
max-mask-length ]
Not configured by
default.
If all the items are set to deny mode, no routes can pass the IPv4 prefix list. Configure the permit 0.0.0.0
0 less-equal 32 item following multiple deny items to allow other IPv4 routing information to pass.
For example, the following configuration filters routes 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16, but
allows other routes to pass.
<Sysname> system-view
246
[Sysname] ip ip-prefix abc index 10 deny 10.1.0.0 16
[Sysname] ip ip-prefix abc index 20 deny 10.2.0.0 16
[Sysname] ip ip-prefix abc index 30 deny 10.3.0.0 16
[Sysname] ip ip-prefix abc index 40 permit 0.0.0.0 0 less-equal 32
Configuring an IPv6 prefix list
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure an IPv6
prefix list.
ip ipv6-prefix ipv6-prefix-name [ index index-number ]
{ deny | permit } ipv6-address prefix-length
[ greater-equal min-prefix-length ] [ less-equal
max-prefix-length ]
Not configured by
default.
If all items are set to deny mode, no routes can pass the IPv6 prefix list. Configure the permit :: 0
less-equal 128 item following multiple deny items to allow other IPv6 routing information to pass.
For example, the following configuration filters routes 2000:1::/48, 2000:2::/48, and 2000:3::/48,
but allows other routes to pass.
<Sysname> system-view
[Sysname] ip ipv6-prefix abc index 10 deny 2000:1:: 48
[Sysname] ip ipv6-prefix abc index 20 deny 2000:2:: 48
[Sysname] ip ipv6-prefix abc index 30 deny 2000:3:: 16
[Sysname] ip ipv6-prefix abc index 40 permit :: 0 less-equal 128
Configuring an AS path list
You can configure multiple items for an AS path list that is identified by number. The relationship between
items is logical OR. A route that matches one item matches the AS path list.
To configure an AS path list:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure an AS path
list.
ip as-path as-path-number { deny |
permit } regular-expression
Not configured by default.
Configuring a community list
You can configure multiple items for a community list that is identified by number. The relationship
between the items is logic OR. A route that matches one item matches the community list.
To configure a community list:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
247
Step
Command
Remarks
• Configure a basic community list:
Configure a community
list.
2.
ip community-list { basic-comm-list-num | basic
comm-list-name } { deny | permit }
[ community-number-list ] [ internet | no-advertise
| no-export | no-export-subconfed ] *
• Configure an advanced community list:
ip community-list { adv-comm-list-num | advanced
comm-list-name } { deny | permit }
regular-expression
Use either method.
Not configured by
default.
Configuring an extended community list
You can configure multiple items for an extended community list that is identified by number. The
relationship between items is logic OR. A route that matches one item matches the extended community
list.
To configure an extended community list:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure an extended
community list.
ip extcommunity-list ext-comm-list-number { deny |
permit } { rt route-target | soo
site-of-origin }&<1-16>
Not configured by
default.
Configuring a routing policy
Configuration prerequisites
Configure filters and routing protocols, and determine the routing policy name, node numbers, match
criteria, and the attributes to be modified.
Creating a routing policy
Follow these guidelines when you create a routing policy:
•
The routing information matching all the if-match clauses of a permit-mode node is handled by the
apply clauses of the node, without needing to match against the next node. The routing information
that does not match the node goes to the next node for a match.
•
The apply clauses of a deny-mode node are never executed. The routing information matching all
the if-match clauses of the node cannot pass the node, or go to the next node. The route information
that does not match node goes to the next node for a match.
•
For a routing policy that has more than one node, configure at least one permit-mode node. A route
that does not match any node cannot pass the routing policy. If all the nodes are in deny mode, no
routing information can pass the routing policy.
To create a routing policy:
248
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a routing policy and a node and
enter routing policy view.
route-policy
route-policy-name { deny |
permit } node node-number
By default, no routing policy
is created.
Configuring if-match clauses
Follow these guidelines when you configure if-match clauses:
•
The if-match clauses of a routing policy node have a logical AND relationship. A route must satisfy
all if-match clauses before it can be handled by the apply clauses of the node. If an if-match
command exceeds the maximum length, multiple identical if-match clauses are generated. These
clauses have a logical OR relationship. A route only needs to match one of them.
•
You can specify no or multiple if-match clauses for a routing policy node. If no if-match clause is
specified for a permit-mode node, all routing information can pass the node. If no if-match clause
is specified for a deny-mode node, no routing information can pass the node.
•
If the ACL referenced by an if-match clause does not exist, the clause is always satisfied; if no rules
of the referenced ACL are matched or the matching rule is inactive, the clause is not satisfied.
•
An ACL specified in an if-match clause must be a non-VPN ACL.
•
The if-match command for matching IPv4 destination, next hop, and source is different from the
if-match command for matching IPv6 ones.
•
BGP does not support criteria for matching against outbound interfaces of routing information.
To configure if-match clauses for a routing policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter routing policy view.
route-policy route-policy-name { deny |
permit } node node-number
N/A
• Match IPv4 routing information
specified in the ACL:
if-match acl acl-number
• Match IPv4 routing information
3.
Define match criteria for IPv4 routes.
specified in the IP prefix list:
if-match ip-prefix ip-prefix-name
• Match IPv4 routing information whose
next hop or source is specified in the
ACL or IP prefix list:
if-match ip { next-hop | route-source }
{ acl acl-number | ip-prefix
ip-prefix-name }
4.
5.
Match IPv6 routing information whose
next hop or source is specified in the
ACL or IP prefix list.
if-match ipv6 { address | next-hop |
route-source } { acl acl-number |
prefix-list ipv6-prefix-name }
Match BGP routing information whose
AS path attribute is specified in the AS
path lists.
if-match as-path
AS-PATH-number&<1-16>
249
Optional.
Not configured by
default.
Optional.
Not configured by
default.
Optional.
Not configured by
default.
Step
Command
Remarks
Match BGP routing information whose
community attribute is specified in the
community lists.
if-match community
{ { basic-community-list-number |
comm-list-name } [ whole-match ] |
adv-community-list-number }&<1-16>
Optional.
7.
Match routes having the specified
cost.
if-match cost value
8.
Match BGP routing information whose
extended community attribute is
specified in the extended community
lists.
if-match extcommunity
ext-comm-list-number&<1-16>
Match routing information having
specified outbound interfaces.
if-match interface { interface-type
interface-number }&<1-16>
6.
9.
Not configured by
default.
Optional.
Not configured by
default.
Optional.
Not configured by
default.
Optional.
Not configured by
default.
Optional.
10. Match routing information having
MPLS labels.
if-match mpls-label
11. Match routing information having the
specified route type.
if-match route-type { external-type1 |
external-type1or2 | external-type2 |
internal | is-is-level-1 | is-is-level-2 |
nssa-external-type1 |
nssa-external-type1or2 |
nssa-external-type2 } *
12. Match RIP, OSPF, and IS-IS routing
information having the specified tag
value
if-match tag value
Not configured by
default.
Optional.
Not configured by
default.
Optional.
Not configured by
default.
Configuring apply clauses
Follow these guidelines when you configure apply clauses:
•
The difference between IPv4 and IPv6 apply clauses is the command for setting the next hop for
routing information.
•
The apply ip-address next-hop and apply ipv6 next-hop commands do not apply to redistributed
IPv4 and IPv6 routes.
To configure apply clauses for a routing policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter routing policy view.
route-policy route-policy-name
{ deny | permit } node node-number
Not created by default.
3.
Set the AS-PATH attribute for
BGP routes.
apply as-path as-number&<1-10>
[ replace ]
Optional.
Delete the community attribute
of BGP routing information
using the community list.
apply comm-list { comm-list-number |
comm-list-name } delete
Optional.
4.
250
Not set by default.
Not configured by default.
Step
5.
6.
7.
8.
Command
Remarks
Set the community attribute for
BGP routes.
apply community { none | additive |
{ community-number&<1-16> |
aa:nn&<1-16> | internet |
no-advertise | no-export |
no-export-subconfed } * [ additive ] }
Set a cost for routing
information.
apply cost [ + | - ] value
Set a cost type for routing
information.
apply cost-type [ external | internal
| type-1 | type-2 ]
Optional.
Set the extended community
attribute for BGP routes.
apply extcommunity { { rt
route-target }&<1-16> [ additive ] |
soo site-of-origin additive }
Optional.
Optional.
Not set by default.
Optional.
Not set by default.
Not set by default.
Not set by default.
• Set the next hop for IPv4 routes:
9.
Set the next hop.
apply ip-address next-hop
ip-address
Optional.
• Set the next hop for IPv6 routes:
Not set by default.
10. Inject routing information to a
specified ISIS level.
apply isis { level-1 | level-1-2 |
level-2 }
Optional.
11. Set the local preference for
BGP routing information.
apply local-preference preference
12. Set MPLS label.
apply mpls-label
13. Set the origin attribute for BGP
routes.
apply origin { egp as-number | igp |
incomplete }
14. Set the preference for the
routing protocol.
apply preference preference
15. Set a preferred value for BGP
routes.
apply preferred-value
preferred-value
16. Set a tag value for RIP, OSPF or
IS-IS route.
apply tag value
apply ipv6 next-hop
ipv6-address
Not configured by default.
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
Not set by default.
Configuring a continue clause
Follow these guidelines when you configure a continue clause:
•
If you configure the same apply clause that set different values (including the apply community and
apply extcommunity clauses with the additive keyword) on nodes that are combined by the
continue clause, the apply clause configured on the last matching node takes effect.
251
If you configure the apply community clause for multiple nodes that are combined by the continue
clause, the apply comm-list delete clause configured on the current node cannot delete the
community attributes set by preceding nodes.
•
To configure a continue clause for a routing policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a routing policy and
enter routing policy view.
route-policy route-policy-name
{ deny | permit } node node-number
Not created by default.
Optional.
3.
Specify the next node to be
matched.
Not configured by default.
continue [ node-number ]
The specified next node must
have a larger number than the
current node.
Displaying and maintaining the routing policy
Task
Command
Display BGP AS path list
information.
display ip as-path [ as-path-number ] [ | { begin |
exclude | include } regular-expression ]
Display BGP community list
information.
display ip community-list
[ basic-community-list-number |
adv-community-list-number | comm-list-name ] [ |
{ begin | exclude | include } regular-expression ]
Display BGP extended community
list information.
display ip extcommunity-list
[ ext-comm-list-number ] [ | { begin | exclude |
include } regular-expression ]
Display IPv4 prefix list statistics.
display ip ip-prefix [ ip-prefix-name ] [ | { begin |
exclude | include } regular-expression ]
Display IPv6 prefix list statistics.
display ip ipv6-prefix [ ipv6-prefix-name ] [ |
{ begin | exclude | include } regular-expression ]
Display routing policy information.
display route-policy [ route-policy-name ] [ | { begin
| exclude | include } regular-expression ]
Clear IPv4 prefix list statistics.
reset ip ip-prefix [ ip-prefix-name ]
Clear IPv6 prefix list statistics.
reset ip ipv6-prefix [ ipv6-prefix-name ]
Remarks
Available in any
view.
Available in user
view.
Routing policy configuration examples
Applying a routing policy to IPv4 route redistribution
Network requirements
In Figure 72, Router B exchanges routing information with Router A using OSPF, and with Router C using
IS-IS.
252
Configure Router B to redistribute IS-IS routes into OSPF, and use a routing policy to set the cost of route
172.17.1.0/24 to 100 and the tag of route 172.17.2.0/24 to 20.
Figure 72 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure IS-IS:
# Configure Router C.
<RouterC> system-view
[RouterC] isis
[RouterC-isis-1] is-level level-2
[RouterC-isis-1] network-entity 10.0000.0000.0001.00
[RouterC-isis-1] quit
[RouterC] interface serial 2/1
[RouterC-Serial2/1] isis enable
[RouterC-Serial2/1] quit
[RouterC] interface ethernet 1/1
[RouterC-Ethernet1/1] isis enable
[RouterC-Ethernet1/1] quit
[RouterC] interface ethernet 1/2
[RouterC-Ethernet1/2] isis enable
[RouterC-Ethernet1/2] quit
[RouterC] interface ethernet 1/3
[RouterC-Ethernet1/3] isis enable
[RouterC-Ethernet1/3] quit
# Configure Router B.
[RouterB] isis
[RouterB-isis-1] is-level level-2
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB] interface serial 2/1
[RouterB-Serial2/1] isis enable
[RouterB-Serial2/1] quit
3.
Configure OSPF and route redistribution:
# Configure OSPF on Router A.
253
<RouterA> system-view
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
# On Router B, configure OSPF and enable route redistribution from IS-IS.
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] import-route isis 1
[RouterB-ospf-1] quit
# Display the OSPF routing table on Router A. The redistributed routes are available.
[RouterA] display ospf routing
OSPF Process 1 with Router ID 192.168.1.1
Routing Tables
Routing for Network
Destination
Cost
192.168.1.0/24
Type
1
NextHop
Transit
AdvRouter
192.168.1.1
Area
192.168.1.1
0.0.0.0
Routing for ASEs
Destination
Cost
Type
Tag
NextHop
AdvRouter
172.17.1.0/24
1
Type2
1
192.168.1.2
192.168.2.2
172.17.2.0/24
1
Type2
1
192.168.1.2
192.168.2.2
172.17.3.0/24
1
Type2
1
192.168.1.2
192.168.2.2
192.168.2.0/24
1
Type2
1
192.168.1.2
192.168.2.2
Total Nets: 5
Intra Area: 1
4.
Inter Area: 0
ASE: 4
NSSA: 0
Configure filtering lists on Router B:
# Configure ACL 2002 to allow route 172.17.2.0/24 to pass.
[RouterB] acl number 2002
[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
[RouterB-acl-basic-2002] quit
# Configure IP prefix list prefix-a to allow route 172.17.1.0/24 to pass.
[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
5.
Configure a routing policy on Router B:
[RouterB] route-policy isis2ospf permit node 10
[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] apply cost 100
[RouterB-route-policy] quit
[RouterB] route-policy isis2ospf permit node 20
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
254
[RouterB-route-policy] quit
[RouterB] route-policy isis2ospf permit node 30
[RouterB-route-policy] quit
6.
Apply the routing policy to route redistribution on Router B:
# On Router B, enable route redistribution from IS-IS and apply the routing policy.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
[RouterB-ospf-1] quit
# Display OSPF routing table information on Router A. The cost of route 172.17.1.0/24 is 100,
and the tag of route 172.17.2.0/24 is 20.
[RouterA] display ospf routing
OSPF Process 1 with Router ID 192.168.1.1
Routing Tables
Routing for Network
Destination
Cost
192.168.1.0/24
Type
1
NextHop
Transit
AdvRouter
192.168.1.1
Area
192.168.1.1
0.0.0.0
Routing for ASEs
Destination
Cost
Type
Tag
NextHop
AdvRouter
172.17.1.0/24
100
Type2
1
192.168.1.2
192.168.2.2
172.17.2.0/24
1
Type2
20
192.168.1.2
192.168.2.2
172.17.3.0/24
1
Type2
1
192.168.1.2
192.168.2.2
192.168.2.0/24
1
Type2
1
192.168.1.2
192.168.2.2
Total Nets: 5
Intra Area: 1
Inter Area: 0
ASE: 4
NSSA: 0
Applying a routing policy to IPv6 route redistribution
Network requirements
•
In Figure 73, enable RIPng on Router A and Router B.
•
Configure three static routes on Router A
•
On Router A, enable static route redistribution into RIPng and apply a routing policy to permit routes
20::/32 and 40::/32 and deny route 30::/32.
Figure 73 Network diagram
Configuration procedure
1.
Configure Router A:
255
# Configure IPv6 addresses for interfaces Ethernet 1/1 and Ethernet 1/2.
<RouterA> system-view
[RouterA] ipv6
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ipv6 address 10::1 32
[RouterA-Ethernet1/1] quit
[RouterA] interface ethernet 1/2
[RouterA-Ethernet1/2] ipv6 address 11::1 32
[RouterA-Ethernet1/2] quit
# Enable RIPng on Ethernet 1/1.
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ripng 1 enable
[RouterA-Ethernet1/1] quit
# Configure three static routes with next hop 11::2, and make sure that the static routes are active.
[RouterA] ipv6 route-static 20:: 32 11::2
[RouterA] ipv6 route-static 30:: 32 11::2
[RouterA] ipv6 route-static 40:: 32 11::2
# Configure a routing policy.
[RouterA] ip ipv6-prefix a index 10 permit 30:: 32
[RouterA] route-policy static2ripng deny node 0
[RouterA-route-policy] if-match ipv6 address prefix-list a
[RouterA-route-policy] quit
[RouterA] route-policy static2ripng permit node 10
[RouterA-route-policy] quit
# Enable RIPng and apply routing policy static2ripng to filter redistributed static routes on Router
A.
[RouterA] ripng
[RouterA-ripng-1] import-route static route-policy static2ripng
2.
Configure Router B:
# Configure the IPv6 address of Ethernet 1/1
<RouterB> system-view
[RouterB] ipv6
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] ipv6 address 10::2 32
# Enable RIPng on the interface.
[RouterB-Ethernet1/1] ripng 1 enable
[RouterB-Ethernet1/1] quit
# Enable RIPng.
[RouterB] ripng
# Display RIPng routing table information.
[RouterB-ripng-1] display ripng 1 route
Route Flags: A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::7D58:0:CA03:1
on Ethernet1/1
Dest 10::/32,
256
via FE80::7D58:0:CA03:1, cost
1, tag 0, A, 18 Sec
Dest 20::/32,
via FE80::7D58:0:CA03:1, cost
1, tag 0, A, 8 Sec
Dest 40::/32,
via FE80::7D58:0:CA03:1, cost
1, tag 0, A, 3 Sec
Applying a routing policy to filter received BGP routes
Network requirements
•
All the routers in Figure 74 run BGP. Router C establishes EBGP connections with other routers.
•
Configure a routing policy on Router D to reject routes from AS 200.
Figure 74 Network diagram
Configuration procedure
1.
Configure IP addresses for interfaces. (Details not shown.)
2.
Configure BGP:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 100
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 1.1.1.2 as-number 300
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 200
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 1.1.2.2 as-number 300
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 300
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 1.1.1.1 as-number 100
[RouterC-bgp] peer 1.1.2.1 as-number 200
257
[RouterC-bgp] peer 1.1.3.2 as-number 400
# Configure Router D.
<RouterD> system-view
[RouterD] bgp 400
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 1.1.3.1 as-number 300
[RouterD-bgp] quit
# Inject routes 4.4.4.4/24, 5.5.5.5/24, and 6.6.6.6/24 on Router A.
[RouterA-bgp] network 4.4.4.4 24
[RouterA-bgp] network 5.5.5.5 24
[RouterA-bgp] network 6.6.6.6 24
# Inject routes 7.7.7.7/24, 8.8.8.8/24, and 9.9.9.9/24 on Router B.
[RouterB-bgp] network 7.7.7.7 24
[RouterB-bgp] network 8.8.8.8 24
[RouterB-bgp] network 9.9.9.9 24
# Display the BGP routing table information of Router D.
[RouterD-bgp] display bgp routing-table
Total Number of Routes: 6
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
4.4.4.0/24
1.1.3.1
0
300 100i
*>
5.5.5.0/24
1.1.3.1
0
300 100i
*>
6.6.6.0/24
1.1.3.1
0
300 100i
*>
7.7.7.0/24
1.1.3.1
0
300 200i
*>
8.8.8.0/24
1.1.3.1
0
300 200i
*>
9.9.9.0/24
1.1.3.1
0
300 200i
The output shows that Router D has learned routes 4.4.4.0/24, 5.5.5.0/24, and 6.6.6.0/24
from AS 100 and 7.7.7.0/24, 8.8.8.0/24, and 9.9.9.0/24 from AS 200.
3.
Configure Router D to reject the routes from AS 200:
# Configure AS path list 1.
[RouterD] ip as-path 1 permit .*200.*
# Create routing policy rt1 with node 1, and specify the match mode as deny to deny routes from
AS 200.
[RouterD] route-policy rt1 deny node 1
[RouterD-route-policy] if-match as-path 1
[RouterD-route-policy] quit
# Create routing policy rt1 with node 10, and specify the match mode as permit to permit routes
from other ASs.
[RouterD] route-policy rt1 permit node 10
[RouterD-route-policy] quit
258
# On Router D, specify routing policy rt1 to filter routes received from peer 1.1.3.1.
[RouterD] bgp 400
[RouterD-bgp] peer 1.1.3.1 route-policy rt1 import
# Display the BGP routing table information of Router D.
[RouterD-bgp] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
4.4.4.0/24
1.1.3.1
0
300 100i
*>
5.5.5.0/24
1.1.3.1
0
300 100i
*>
6.6.6.0/24
1.1.3.1
0
300 100i
The output shows that Router D has learned only routes 4.4.4.0/24, 5.5.5.0/24, and
6.6.6.0/24 from AS 100.
Troubleshooting routing policy configuration
IPv4 routing information filtering failure
Symptom
The routing protocol is running correctly, but filtering routing information failed.
Analysis
At least one item of the IP prefix list must be configured as permit mode, and at least one node in the
routing policy must be configured as permit mode.
Solution
1.
Use the display ip ip-prefix command to display IP prefix list information.
2.
Use the display route-policy command to display routing policy information.
IPv6 routing information filtering failure
Symptom
The routing protocol is running correctly, but filtering routing information failed.
Analysis
At least one item of the IPv6 prefix list must be configured as permit mode, and at least one node of the
routing policy must be configured as permit mode.
Solution
1.
Use the display ip ipv6-prefix command to display IP prefix list information.
2.
Use the display route-policy command to display routing policy information.
259
Configuring PBR
Overview
Different from destination-based routing, policy-based routing (PBR) uses user-defined policies to route
packets based on the source address, packet length, and other criteria. A policy can specify the output
interface, next hop, default output interface, default next hop, and other parameters for packets that
match specific criteria such as ACLs or have specific lengths.
A device uses PBR to forward matching packets and uses the routing table to forward other packets. If
PBR is not configured, a device uses the routing table to forward packets.
PBR includes local PBR and interface PBR:
•
Local PBR guides the forwarding of locally generated packets, such as the ICMP packets generated
by using the ping command.
•
Interface PBR guides the forwarding of packets received on an interface only.
Policy
A policy comprises match criteria and actions to be taken on the matching packets. A policy can
comprise one or multiple nodes. The following describes information about nodes:
•
Each node is identified by a node number. A smaller node number has a higher priority.
•
A node comprises if-match and apply clauses. An if-match clause specifies a match criterion, and
an apply clause specifies an action.
•
A node has a match mode of permit or deny.
A policy matches nodes in priority order against packets. If a packet satisfies the match criteria on a node,
it is processed by the action on the node. Otherwise, it goes to the next node for a match. If the packet
does not match the criteria on any node, it is forwarded according to the routing table.
if-match clause
PBR supports the following types of if-match clauses:
•
if-match acl—Sets an ACL match criteria.
•
if-match packet-length—Sets a packet length match criterion.
You can specify multiple if-match clauses for a node, but only one if-match clause can be specified for
each type at most. To match a node, a packet must satisfy all the if-match clauses of the node.
apply clause
PBR supports the following types of apply clauses, as shown in Table 9. You can specify multiple apply
clauses for a node, but some of them might not be executed.
260
Table 9 Priorities and meanings of apply clauses
Clause
Meaning
Priority
apply ip-df zero
Sets the DF (Don't Fragment)
bit in the IP header to 0,
which means the packet can
be fragmented.
This clause is always executed.
If this clause is configured, other apply clauses, except
the apply ip-df zero clause, are not executed.
apply access-vpn
vpn-instance
Sets VPN instances.
apply ip-precedence
Sets an IP precedence.
If configured for public network forwarding, that is, the
apply access-vpn vpn-instance clause is not
configured, this clause is always executed.
apply
output-interface and
apply ip-address
next-hop
Sets the output interface and
sets the next hop.
The apply ip-address next-hop clause takes
precedence over the apply output-interface clause.
Only the apply ip-address next-hop clause is executed
when both are configured.
apply
output-interface
ip-address next-hop
dhcpc
apply default
output-interface and
apply ip-address
default next-hop
If a packet matches a forwarding entry of a specified
VPN instance, it is forwarded in the VPN instance. If it
does not match any entry in all VPN instances
specified, it is discarded.
Sets the output interface and
next hop (the next hop
address is the gateway
address learned through
DHCP).
Sets the default output
interface and sets the default
next hop.
For a point to point (P2P) link, the next hop address is
the peer address, so you only need to specify the output
interface by using the apply output-interface
command.
For a non-P2P link, specify both the output interface and
the next hop. If the output interface obtains an IP
address through DHCP, you can use the apply
output-interface ip-address next-hop dhcpc command
to specify the gateway address learned through DHCP
as the next hop.
The apply ip-address default next-hop clause takes
precedence over the apply default output-interface
clause. Only the apply ip-address default next-hop
clause is executed when both are configured.
They take effect only in the following situations:
• No output interface or next hop is set.
• The output interface and next hop are invalid.
• The packet does not match any route, except for the
default route, in the routing table.
Relationship between the match mode and clauses on a node
Does a packet match all the
if-match clauses on the
node?
Match mode
permit
deny
Yes
PBR executes the apply clause on the
node.
The packet is forwarded according
to the routing table.
No
PBR matches the packet against the
next node.
PBR matches the packet against the
next node.
261
All packets can match a node where no if-match clauses are configured.
If a permit-mode node has no apply clause, packets matching all the if-match clauses of the node are
forwarded according to the routing table.
If a node has no if-match or apply clauses configured, all packets can match the node and are
forwarded according to the routing table.
PBR and Track
You can use Track to monitor the output interface, default output interface, next hop, and default next hop
for PBR so that PBR can discover link failures faster. PBR takes effect when the status of the associated
track entry is positive or invalid.
For more information about Track-PBR collaboration, see High Availability Configuration Guide.
PBR configuration task list
Task
Remarks
Creating a node
Configuring a policy
Configuring match criteria for a node
Required.
Configuring actions for a node
Configuring PBR
Configuring local PBR
Required.
Configuring interface PBR
Perform one of the tasks.
Configuring a policy
Creating a node
Step
Command
1.
Enter system view.
system-view
2.
Create a node for a policy and enter policy
node view.
policy-based-route policy-name [ deny | permit ] node
node-number
Configuring match criteria for a node
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter policy node view.
policy-based-route policy-name [ deny |
permit ] node node-number
N/A
3.
Configure an ACL match
criterion.
if-match acl acl-number
Optional.
4.
Configure a packet length
match criterion.
if-match packet-length min-len max-len
Optional.
262
NOTE:
An ACL match criterion uses the specified ACL to match packets if the match mode is configured as permit. If the
specified ACL does not exist or the match mode is configured as deny, no packet can match the criterion.
Configuring actions for a node
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter policy node view.
policy-based-route policy-name
[ deny | permit ] node
node-number
N/A
3.
Set the DF bit in the IP header
to 0, which means the packet
can be fragmented.
apply ip-df zero
Optional.
4.
Set VPN instances.
apply access-vpn vpn-instance
vpn-instance-name&<1-6>
Optional.
5.
Set an IP precedence.
apply ip-precedence value
Optional.
6.
Set output interfaces.
apply output-interface
interface-type interface-number
[ track track-entry-number ]
[ interface-type interface-number
[ track track-entry-number ] ]
7.
Set the output interface and
next hop (the next hop
address is the gateway
address learned through
DHCP).
apply output-interface
interface-type interface-number
ip-address next-hop dhcpc
Set next hops.
apply ip-address next-hop
[ vpn-instance vpn-instance-name ]
ip-address [ direct ] [ track
track-entry-number ] [ ip-address
[ direct ] [ track
track-entry-number ] ]
Set default output interfaces.
apply default output-interface
interface-type interface-number
[ track track-entry-number ]
[ interface-type interface-number
[ track track-entry-number ] ]
8.
9.
10. Set default next hops.
apply ip-address default next-hop
[ vpn-instance vpn-instance-name ]
ip-address [ track
track-entry-number ] [ ip-address
[ track track-entry-number ] ]
263
Optional.
You can specify up to two output
interfaces to achieve load sharing.
Optional.
Optional.
You can specify up to two next
hops to achieve load sharing.
Optional.
You can specify up to two default
output interfaces to achieve load
sharing.
Optional.
You can specify up to two default
next hops to achieve load sharing.
Configuring PBR
Configuring local PBR
Configure PBR by applying a policy locally. PBR uses the policy to guide the forwarding of locally
generated packets.
You can apply only one policy locally. If you perform the ip local policy-based-route command multiple
times, only the last specified policy takes effect.
If the specified policy does not exist, the local PBR configuration succeeds, but it does not take effect until
the policy is created.
Do not configure local PBR unless required.
To configure local PBR:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Apply a policy locally.
ip local policy-based-route
policy-name
Not applied by default.
Configuring interface PBR
Configure PBR by applying a policy on an interface. PBR uses the policy to guide the forwarding of
packets received on the interface.
You can apply only one policy to an interface. If you perform the ip policy-based-route command
multiple times, only the last specified policy takes effect.
If the specified policy does not exist, the interface PBR configuration succeeds, but it does not take effect
until the policy is created.
You can apply the same policy on multiple interfaces.
To configure interface PBR:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Apply a policy on the
interface.
ip policy-based-route policy-name
Not applied by default.
Displaying and maintaining PBR
Task
Command
Remarks
Display PBR configuration for a
policy.
display policy-based-route [ policy-name ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
264
Task
Command
Remarks
Display information about local
PBR and interface PBR.
display ip policy-based-route [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display PBR configuration.
display ip policy-based-route setup
{ interface interface-type interface-number |
local | policy-name } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display PBR statistics.
display ip policy-based-route statistics
{ interface interface-type interface-number |
local } [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Clear PBR statistics.
reset policy-based-route statistics
[ policy-name ]
Available in user view.
PBR configuration examples
Configuring local PBR based on packet type
Network requirements
As shown in Figure 75, configure local PBR on Router A to forward all locally generated TCP packets
through Serial 2/0. Router A forwards other packets according to the routing table.
Figure 75 Network diagram
Configuration procedure
1.
Configure Router A:
# Configure ACL 3101 to match TCP packets.
<RouterA> system-view
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit tcp
[RouterA-acl-adv-3101] quit
# Configure Node 5 for policy aaa to forward TCP packets through Serial 2/0.
[RouterA] policy-based-route aaa permit node 5
[RouterA-pbr-aaa-5] if-match acl 3101
[RouterA-pbr-aaa-5] apply output-interface serial 2/0
[RouterA-pbr-aaa-5] quit
# Configure local PBR by applying policy aaa on Router A.
[RouterA] ip local policy-based-route aaa
# Configure the IP addresses of the serial interfaces.
265
[RouterA] interface serial 2/0
[RouterA-Serial2/0] ip address 1.1.2.1 255.255.255.0
[RouterA-Serial2/0] quit
[RouterA] interface serial 2/1
[RouterA-Serial2/1] ip address 1.1.3.1 255.255.255.0
2.
Configure Router B:
# Configure the IP address of the serial interface.
<RouterB> system-view
[RouterB] interface serial 2/0
[RouterB-Serial2/0] ip address 1.1.2.2 255.255.255.0
3.
Configure Router C:
# Configure the IP address of the serial interface.
<RouterC> system-view
[RouterC] interface serial 2/1
[RouterC-Serial2/1] ip address 1.1.3.2 255.255.255.0
[RouterC-Serial2/1] quit
4.
Verify the configuration:
# Telnet to Router B (1.1.2.2/24) from Router A. The operation succeeds.
# Telnet to Router C (1.1.3.2/24) from Router A. The operation fails.
# Ping Router C (1.1.3.2/24) from Router A. The operation succeeds.
Telnet uses TCP, and ping uses ICMP. The preceding results show that all TCP packets of Router A
are forwarded through Serial 2/0, and other packets are forwarded through Serial 2/1. The local
PBR configuration is effective.
Configuring interface PBR based on packet type
Network requirements
As shown in Figure 76, configure interface PBR on Router A to forward all TCP packets received on
Ethernet 1/1 through Serial 2/0. Router A forwards other packets according to the routing table.
266
Figure 76 Network diagram
Router B
Router C
S2/0
1.1.2.2/24
S2/1
1.1.3.2/24
S2/0
1.1.2.1/24
Router A
S2/1
1.1.3.1/24
Eth1/1
10.110.0.10/24
Subnet
10.110.0.0/24
Host A
Host B
10.110.0.20/24
Gateway: 10.110.0.10
Configuration procedure
NOTE:
In this example, static routes are configured to ensure the reachability among devices.
1.
Configure Router A:
# Configure ACL 3101 to match TCP packets.
<RouterA> system-view
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit tcp
[RouterA-acl-adv-3101] quit
# Configure Node 5 for policy aaa to forward TCP packets through Serial 2/0.
[RouterA] policy-based-route aaa permit node 5
[RouterA-pbr-aaa-5] if-match acl 3101
[RouterA-pbr-aaa-5] apply output-interface serial 2/0
[RouterA-pbr-aaa-5] quit
# Configure interface PBR by applying the policy aaa on Ethernet 1/1.
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ip address 10.110.0.10 255.255.255.0
[RouterA-Ethernet1/1] ip policy-based-route aaa
[RouterA-Ethernet1/1] quit
# Configure the IP addresses of the serial interfaces.
[RouterA] interface serial 2/0
[RouterA-Serial2/0] ip address 1.1.2.1 255.255.255.0
[RouterA-Serial2/0] quit
[RouterA] interface serial 2/1
[RouterA-Serial2/1] ip address 1.1.3.1 255.255.255.0
267
2.
Configure Router B:
# Configure a static route to subnet 10.110.0.0/24.
<RouterB> system-view
[RouterB] ip route-static 10.110.0.0 24 1.1.2.1
# Configure the IP address of the serial interface.
[RouterB] interface serial 2/0
[RouterB-Serial2/0] ip address 1.1.2.2 255.255.255.0
3.
Configure Router C:
# Configure a static route to subnet 10.110.0.0/24.
<RouterC> system-view
[RouterC] ip route-static 10.110.0.0 24 1.1.3.1
# Configure the IP address of the serial interface.
[RouterC] interface serial 2/1
[RouterC-Serial2/1] ip address 1.1.3.2 255.255.255.0
4.
Verify the configuration:
Configure the IP address 10.110.0.20/24 for Host A, and specify its gateway address as
10.110.0.10.
On Host A, Telnet to Router B that is directly connected to Router A. The operation succeeds.
On Host A, Telnet to Router C that is directly connected to Router A. The operation fails.
Ping Router C from Host A. The operation succeeds.
Telnet uses TCP, and ping uses ICMP. The preceding results show that all TCP packets received on
Ethernet 1/1 of Router A are forwarded through Serial 2/0, and other packets are forwarded
through Serial 2/1. The interface PBR configuration is effective.
Configuring interface PBR based on packet length
Network requirements
As shown in Figure 77, configure interface PBR to guide the forwarding of packets received on Ethernet
1/1 of Router A as follows:
•
Forwards packets with a length of 64 to 100 bytes to the next hop 150.1.1.2/24.
•
Forwards packets with a length of 101 to 1000 to the next hop 151.1.1.2/24.
All other packets are forwarded according to the routing table.
Figure 77 Network diagram
268
Configuration procedure
1.
Configure Router A:
# Configure RIP.
<RouterA> system-view
[RouterA] rip
[RouterA-rip-1] network 192.1.1.0
[RouterA-rip-1] network 150.1.0.0
[RouterA-rip-1] network 151.1.0.0
[RouterA-rip-1] quit
# Configure Node 10 for policy lab1 to forward packets with a length of 64 to 100 bytes to the
next hop 150.1.1.2, and packets with a length of 101 to 1000 bytes to the next hop 151.1.1.2.
[RouterA] policy-based-route lab1 permit node 10
[RouterA-pbr-lab1-10] if-match packet-length 64 100
[RouterA-pbr-lab1-10] apply ip-address next-hop 150.1.1.2
[RouterA-pbr-lab1-10] quit
[RouterA] policy-based-route lab1 permit node 20
[RouterA-pbr-lab1-20] if-match packet-length 101 1000
[RouterA-pbr-lab1-20] apply ip-address next-hop 151.1.1.2
[RouterA-pbr-lab1-20] quit
# Configure interface PBR by applying policy lab1 to Ethernet 1/1.
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ip address 192.1.1.1 255.255.255.0
[RouterA-Ethernet1/1] ip policy-based-route lab1
[RouterA-Ethernet1/1] quit
# Configure the IP addresses of the serial interfaces.
[RouterA] interface serial 2/0
[RouterA-Serial2/0] ip address 150.1.1.1 255.255.255.0
[RouterA-Serial2/0] quit
[RouterA] interface serial 2/1
[RouterA-Serial2/1] ip address 151.1.1.1 255.255.255.0
[RouterA-Serial2/1] return
2.
Configure Router B:
# Configure RIP.
<RouterB> system-view
[RouterB] rip
[RouterB-rip-1] network 10.0.0.0
[RouterB-rip-1] network 150.1.0.0
[RouterB-rip-1] network 151.1.0.0
# Configure the IP addresses of the serial interfaces.
[RouterB] interface serial 2/0
[RouterB-Serial2/0] ip address 150.1.1.2 255.255.255.0
[RouterB-Serial2/0] quit
[RouterB] interface serial 2/1
[RouterB-Serial2/1] ip address 151.1.1.2 255.255.255.0
[RouterB-Serial2/1] quit
# Configure the loopback interface address.
269
[RouterB] interface loopback 0
[RouterB-LoopBack0] ip address 10.1.1.1 32
3.
Verify the configuration:
# Run the debugging ip policy-based-route command on Router A.
<RouterA> debugging ip policy-based-route
<RouterA> terminal debugging
<RouterA> terminal monitor
# Ping Loopback 0 of Router B from Host A, and set the data length to 80 bytes.
C:\>ping -l 80 10.1.1.1
Pinging 10.1.1.1 with 80 bytes of data:
Reply from 10.1.1.1: bytes=80 time<1ms TTL=255
Reply from 10.1.1.1: bytes=80 time<1ms TTL=255
Reply from 10.1.1.1: bytes=80 time<1ms TTL=255
Reply from 10.1.1.1: bytes=80 time<1ms TTL=255
Ping statistics for 10.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
The debugging information about PBR displayed on Router A is as follows:
<RouterA>
*Jun
7 12:04:33:519 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 10, next-hop : 150.1.1.2
*Jun
7 12:04:34:518 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 10, next-hop : 150.1.1.2
*Jun
7 12:04:35:518 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 10, next-hop : 150.1.1.2
*Jun
7 12:04:36:518 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 10, next-hop : 150.1.1.2
The preceding information shows that Router A sets the next hop for the received packets to
150.1.1.2 according to PBR. The packets are forwarded through Serial 2/0.
# Ping Loopback 0 of Router B from Host A, and set the data length to 200 bytes.
C:\>ping -l 200 10.1.1.1
Pinging 10.1.1.1 with 200 bytes of data:
Reply from 10.1.1.1: bytes=200 time<1ms TTL=255
Reply from 10.1.1.1: bytes=200 time<1ms TTL=255
Reply from 10.1.1.1: bytes=200 time<1ms TTL=255
Reply from 10.1.1.1: bytes=200 time<1ms TTL=255
Ping statistics for 10.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
270
The debugging information about PBR displayed on Router A is as follows:
<RouterA>
*Jun
7 12:06:47:631 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 20, next-hop : 151.1.1.2
*Jun
7 12:06:48:630 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 20, next-hop : 151.1.1.2
*Jun
7 12:06:49:627 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 20, next-hop : 151.1.1.2
*Jun
7 12:06:50:627 2009 RouterA PBR/7/POLICY-ROUTING: IP policy based routing
success : POLICY_ROUTEMAP : lab1, Node : 20, next-hop : 151.1.1.2
The preceding information shows that Router A sets the next hop for the received packets to
151.1.1.2 according to PBR. The packets are forwarded through Serial 2/1.
Configuring local PBR to specify output interface and next hop
Network requirements
As shown in Figure 78:
•
The downlink port of the router is connected to the hosts, and its uplink port Ethernet1/1 is
connected to the Internet.
•
The subinterface Ethernet 1/1.1 obtains its IP address through DHCP.
Configure local PBR so that the router forward SNMP packets and SNMP traps through the subinterface
Ethernet 1/1.1.
Figure 78 Network diagram
Configuration procedure
# Configure the subinterface Ethernet1/1.1 to obtain its IP address through DHCP.
<Router> system-view
[Router] interface ethernet 1/1.1
[Router-Ethernet1/1.1] ip address dhcp-alloc
[Router-Ethernet1/1.1] vlan-type dot1q vid 1
[Router-Ethernet1/1.1] quit
# Configure ACL 3000 to match SNMP packets and SNMP traps.
[Router] acl number 3000
[Router-acl-adv-3000] rule 0 permit udp source-port eq snmp
[Router-acl-adv-3000] rule 5 permit udp destination-port eq snmptrap
[Router-acl-adv-3000] quit
271
# Configure Node 1 for policy management to forward management packets through Ethernet1/1.1.
(Because Ethernet1/1.1 obtains its IP address through DHCP and the next hop address is unknown,
specify the gateway address learned through DHCP as the next hop address.)
[Router] policy-based-route management permit node 1
[Router-pbr-management-1] if-match acl 3000
[Router-pbr-management-1] apply output-interface ethernet 1/1.1 ip-address next-hop dhcpc
[Router-pbr-management-1] quit
# Configure local PBR by applying policy management on Router A.
[Router] ip local policy-based-route management
272
Configuring IPv6 static routing
Overview
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 has to modify the static routes manually.
Similar to IPv4 static routes, IPv6 static routes work well in simple IPv6 network environments.
Configuring IPv6 static routing
Before you configure an IPv6 static route, complete the following tasks:
•
Configure parameters for the related interfaces.
•
Configure link layer attributes for the related interfaces.
•
Enable IPv6 packet forwarding.
•
Make sure that the neighboring nodes can reach each other.
To configure an IPv6 static route:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Method 1:
ipv6 route-static ipv6-address prefix-length
{ interface-type interface-number
[ next-hop-address ] | next-hop-address |
vpn-instance d-vpn-instance-name
next-hop-address } [ preference
preference-value ]
2.
Configure an IPv6 static route.
• Method 2:
ipv6 route-static vpn-instance
s-vpn-instance-name&<1-6> ipv6-address
prefix-length { interface-type
interface-number [ next-hop-address ] |
next-hop-address [ public ] | vpn-instance
d-vpn-instance-name next-hop-address }
[ preference preference-value ]
Use either method.
By default, no IPv6
static route is
configured.
Optional.
3.
Delete all IPv6 static routes,
including the default route.
delete ipv6 [ vpn-instance vpn-instance-name ]
static-routes all
273
The undo ipv6
route-static command
deletes one IPv6 static
route.
Displaying and maintaining IPv6 static routes
Task
Command
Remarks
Display IPv6 static route
information.
display ipv6 routing-table protocol
static [ inactive | verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
For more information about the display ipv6 routing-table protocol static [ inactive | verbose ] [ | { begin
| exclude | include } regular-expression ] command, see Layer 3—IP Routing Command Reference.
IPv6 static routing configuration example
Network requirements
As shown in Figure 79, configure IPv6 static routes so that hosts can reach one another.
Figure 79 Network diagram
Configuration procedure
1.
Configure IPv6 addresses for all interfaces. (Details not shown.)
2.
Configure IPv6 static routes:
# Enable IPv6 and configure the IPv6 default route on Router A.
<RouterA> system-view
[RouterA] ipv6
[RouterA] ipv6 route-static :: 0 4::2
# Enable IPv6 and configure two IPv6 static routes on Router B.
<RouterB> system-view
[RouterB] ipv6
[RouterB] ipv6 route-static 1:: 64 4::1
[RouterB] ipv6 route-static 3:: 64 5::1
# Enable IPv6 and configure the IPv6 default route on Router C.
<RouterC> system-view
[RouterC] ipv6
[RouterC] ipv6 route-static :: 0 5::2
274
3.
Configure the IPv6 addresses of hosts and gateways:
Configure the IPv6 addresses of all the hosts based on the network diagram, and configure the
default gateway of Host A as 1::1, Host B as 2::1, and Host C as 3::1.
4.
Verify the configuration:
# Display the IPv6 routing table on Router A.
[RouterA] display ipv6 routing-table
Routing Table : Public
Destinations : 5
Routes : 5
Destination
: ::
Protocol
: Static
NextHop
: 4::2
Preference
: 60
Interface
: S2/0
Cost
: 0
Destination
: ::1/128
Protocol
: Direct
NextHop
: ::1
Preference
: 0
Interface
: InLoop0
Cost
: 0
Destination
: 1::/64
Protocol
: Direct
NextHop
: 1::1
Preference
: 0
Interface
: Eth1/1
Cost
: 0
Destination
: 1::1/128
Protocol
: Direct
NextHop
: ::1
Preference
: 0
Interface
: InLoop0
Cost
: 0
Destination
: FE80::/10
Protocol
: Direct
NextHop
: ::
Preference
: 0
Interface
: NULL0
Cost
: 0
# Ping Host C on Router A to verify the reachability.
[RouterA] ping ipv6 3::2
PING 3::2 : 56
data bytes, press CTRL_C to break
Reply from 3::2
bytes=56 Sequence=1 hop limit=62
time = 63 ms
Reply from 3::2
bytes=56 Sequence=2 hop limit=62
time = 62 ms
Reply from 3::2
bytes=56 Sequence=3 hop limit=62
time = 62 ms
Reply from 3::2
bytes=56 Sequence=4 hop limit=62
time = 63 ms
Reply from 3::2
bytes=56 Sequence=5 hop limit=62
time = 63 ms
--- 3::2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 62/62/63 ms
275
Configuring an IPv6 default route
An IPv6 default route is used to forward packets that match no entry in the routing table.
An IPv6 default route can be configured in either of the following ways:
•
The network administrator can configure a default route with a destination prefix of ::/0. For more
information, see "Configuring IPv6 static routing."
•
Some dynamic routing protocols, such as OSPFv3, RIPng, and IPv6 IS-IS, can generate an IPv6
default route. For example, an upstream router running OSPFv3 can generate an IPv6 default route
and advertise it to other routers, which install the IPv6 default route with the next hop being the
upstream router. For more information, see the configuration guides of relevant routing protocols.
276
Configuring RIPng
Overview
RIP next generation (RIPng) is an extension of RIP-2 for IPv4. Most RIP concepts are applicable in RIPng.
RIPng for IPv6 has the following basic differences from RIP:
•
UDP port number—RIPng uses UDP port 521 for sending and receiving routing information.
•
Multicast address—RIPng uses FF02::9 as the link-local-router multicast address.
•
Destination Prefix—128-bit destination address prefix.
•
Next hop—128-bit IPv6 address.
•
Source address—RIPng uses FE80::/10 as the link-local source address.
RIPng working mechanism
RIPng is a routing protocol based on the distance vector (D-V) algorithm. RIPng uses UDP packets to
exchange routing information through port 521.
RIPng uses a hop count to measure the distance to a destination. The hop count is the metric or cost. The
hop count from a router to a directly connected network is 0. The hop count between two directly
connected routers is 1. When the hop count is greater than or equal to 16, the destination network or host
is unreachable.
By default, the routing update is sent every 30 seconds. If the router receives no routing updates from a
neighbor within 180 seconds, the routes learned from the neighbor are considered unreachable. If no
routing update is received within another 240 seconds, the router removes these routes from the routing
table.
RIPng supports split horizon and poison reverse to prevent routing loops and route redistribution.
Each RIPng router maintains a routing database, which includes route entries of all reachable
destinations. A route entry contains the following information:
•
Destination address—IPv6 address of a host or a network.
•
Next hop address—IPv6 address of a neighbor along the path to the destination.
•
Egress interface—Outbound interface that forwards IPv6 packets.
•
Metric—Cost from the local router to the destination.
•
Route time—Time elapsed since a route entry was last changed. Each time a route entry is modified,
the routing time is set to 0.
•
Route tag—Identifies the route used in a routing policy to control routing information. For more
information about routing policy, see "Configuring routing policies."
RIPng packet format
Basic format
A RIPng packet consists of a header and multiple route table entries (RTEs). The maximum number of RTEs
in a packet depends on the IPv6 MTU of the sending interface.
277
Figure 80 RIPng basic packet fo