IP Routing—Configuring RIP, OSPF, BGP, and PBR · 15-152 IP Routing—Configuring RIP, OSPF, BGP, and PBR Troubleshooting Routing Enter **, which clears all routes, or enter the

15

IP Routing—Configuring RIP, OSPF, BGP, and PBR

Contents

Troubleshooting Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-148

Monitoring the Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-148

Monitoring Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-151

Clearing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-151

Troubleshooting RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-153

Router Not Receiving Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-153

Other Routers Not Receiving Routes to the Local Router’s Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-154

Troubleshooting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-155

Troubleshooting an Internal Router . . . . . . . . . . . . . . . . . . . . . 15-158

Troubleshooting an ABR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-162

Troubleshooting BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-164

Strategies and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-164

Troubleshooting a Prefix List . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-172

Troubleshooting a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . 15-173

Other Common BGP Problems . . . . . . . . . . . . . . . . . . . . . . . . . 15-174

Monitoring and Troubleshooting PBR . . . . . . . . . . . . . . . . . . . . . . . 15-175

15-1

IP Routing—Configuring RIP, OSPF, BGP, and PBRTroubleshooting Routing

Configure the route map as follows:

ProCurve(config)# route-map RealTime 10ProCurve(config-route-map)# match ip precedence 5ProCurve(config-route-map)# set interface ppp 1ProCurve(config-route-map)# set ip dscp efProCurve(config-route-map)# set ip dfProCurve(config-route-map)# exitProCurve(config)# interface eth 0/1ProCurve(config-eth 0/1)# ip policy route-map RealTime

Troubleshooting Routing

When you receive reports that traffic is not reaching its destination, first attempt to ping the destination from the router to verify that a host or other network node is not the root of the problem. If the ping confirms that the router cannot reach the destination, next view the routing table. It should have an entry for the destination. If it does not, then you will have to troubleshoot your routing method.

Remember that in order for a ping to be successful, the remote endpoint must know a route back to the source. If the routing table does include a route to the destination, the problem could be that the local router is not advertising correct routing information to other routers.

N o t e The show and debug commands described in the following sections are enable mode commands. However, you can also enter the commands from configuration mode contexts by adding the do option.

Monitoring the Routing Table

To view the routing table, enter this enable mode command:

ProCurve# show ip route

15-148


The screen displays the destinations to which the router can route traffic. (See Figure 15-33.) For each destination, the routing table also records:

■ the method the router used to discover the route

• B—BGP

• C—directly connected

• O—OSPF

• R—RIP

• S—entered manually (static)

■ the administrative distance—the trustworthiness of the route

■ the metric—the cost for the route

■ the next-hop address

■ the forwarding interface

Figure 15-33. Routing Table

You can also view specific portions of the routing table. Use the commands in Table 15-20.

ProCurve#show ip routeCodes: C - connected, S - static, R - RIP, O - OSPF, B - BGP IA - OSPF inter area, N1 - OSPF NSSA external type 1 N2 - OSPF NSSA external type 2, E1 - OSPF external type 1 E2 - OSPF external type 2

Gateway of last resort 192.168.128.1

C 10.1.1.0/30 is directly connected, ppp 1C 10.1.1.1/32 is directly connected, ppp 1C 10.2.2.0/30 is directly connected, ppp 2C 10.2.2.1/32 is directly connected, ppp 2R 172.16.1.0/24 [120/1] via 10.1.1.1, ppp 1R 172.16.3.0/24 [120/1] via 10.1.1.1, ppp 1R 172.16.4.0/24 [120/1] via 10.1.1.1, ppp 1O 192.168.65.0/24 [110/51] via 10.2.2.1, ppp 2

O 192.168.72.0/24 [110/51] via 10.2.2.1, ppp 2O 192.168.100.0/24 [110/51] via 10.2.2.1, ppp 2C 192.168.128.0/24 is directly connected, eth 0/1C 192.168.129.0/24 is directly connected, eth 0/2

OSPF route Administrative distance

Next-hop and forwarding interface

Cost

15-149


Table 15-20. Viewing the Routing Table

If the destination in question has a static route, you should double-check that the route has been entered correctly.

If the table does not include a route for the destination, you must either add a static route, if you are using that method, or troubleshoot your network’s routing protocol.

Refer to the show and debug commands listed in Table 15-21 as you trouble-shoot routing.

Table 15-21. Routing show and debug Commands

Portion of the Table Command Syntax

directly connected routes show ip route connected

statically entered routes show ip route static

BGP show ip route bgp

RIP show ip route rip

OSPF show ip route ospf

summary show ip route table

View Command Syntax

all RIP debug messages debug ip rip

RIP events debug ip rip events

routing configurations for RIP show running-config router rip

all OSPF events debug ip ospf

OSPF interfaces show ip ospf interface

OSPF neighbors show ip ospf neighbor

routing configurations for OSPF show running-config router ospf

BGP messages debug ip bgp

BGP routes show ip bgp

statistics for path to BGP neighbors

show ip bgp summary

routing configurations for BGP show running-config router bgp

15-150


Monitoring Routes

You can monitor the route that packets actually take through the network by using the traceroute command. Enter the command follow by the destination address for the route you want to trace:

Syntax: traceroute <A.B.C.D>

The router sends out a series of pings with steadily incrementing TTLs, so that each successive ping reaches one hop closer to the destination. The router records the addresses of the routers that return the pings, thus building up a list of every hop between itself and the destination. (See Figure 15-34.)

Figure 15-34. traceroute Command

Tracing routes allows you to monitor actual traffic flow (although in a neces-sarily limited fashion). When traffic does not reach its destination, you can determine which network node cannot forward it. You can then troubleshoot the device with the problem.

When traffic can take more than one route through a network, you can use the traceroute command to discover which path routers have selected. If you determine that routers are using high-cost paths unnecessarily, you can make adjustments accordingly. For example, you can assign a higher cost to an OSPF interface.

Clearing Routes

You can clear all routes that the router has discovered using a routing protocol. This can be useful when the network is having trouble converging, or if the router has learned unreliable routes. Enter:

Syntax: clear ip route [** | <A.B.C.D> <subnet mask | /prefix length>

ProCurveSR7102dl#traceroute 192.168.100.2Type CTRL+C to abort.Tracing route to 192.168.100.2 over a maximum of 30 hops

1 2ms 2ms 2ms 10.1.1.2 2 4ms 4ms 4ms 10.2.2.1 3 4ms 5ms 4ms 192.168.100.2

Next hop—directly connected neighbor

Destination

15-151


Enter **, which clears all routes, or enter the destination for the specific route you want to remove.

The clear command only removes learned routes. To clear a static route, you must enter the no form of the global configuration mode command you used to enter it:

Syntax: no ip route <A.B.C.D> <subnet mask | /prefix length> <next hop A.B.C.D | forwarding interface ID>

Figure 15-35. Clearing Routes

For example, your router has the routes in the routing table shown in Figure 15-35. The routes to 192.168.65.0 /24 and 172.168.0.0 /16 are faulty and you want to clear them. The first is a learned route, so you enter:

ProCurve# clear ip route 192.168.65.0 /24

The second is a static route, so you move to the global configuration mode context and enter:

ProCurve(config)# no ip route 172.168.0.0 /16 ppp 1


Gateway of last resort 192.168.128.1

C 10.1.1.0/30 is directly connected, ppp 1C 10.1.1.1/32 is directly connected, ppp 1C 10.2.2.0/30 is directly connected, ppp 2C 10.2.2.1/32 is directly connected, ppp 2S 172.16.0.0/16 [1/0] via 10.1.1.1, ppp 1R 172.16.3.0/24 [120/1] via 10.1.1.1, ppp 1R 172.16.4.0/24 [120/1] via 10.1.1.1, ppp 1O 192.168.65.0/24 [110/51] via 10.2.2.1, ppp 2

C 192.168.128.0/24 is directly connected, eth 0/1C 192.168.129.0/24 is directly connected, eth 0/2

Faulty route

Misconfigured route

15-152


Troubleshooting RIP

You can scan RIP events to determine the problem by entering the debug commands shown in Table 15-21 on page 15-150. For example, enter:

ProCurve# debug ip rip

Examine Table 15-22 to learn about the messages associated with particular problems. The following sections will give general tips on how to troubleshoot these problems.

Table 15-22. RIP Debug Messages

C a u t i o n RIP debug messages can be processor-intensive.

Router Not Receiving Routes

A router may not receive routes because:

■ an interface has not been enabled to participate in RIP

■ an interface is listening for the incorrect RIP version

■ remote sites are separated by a non-multicast network

Message Possible Problem Next Best Step

discard packet from <A.B.C.D> (source Address not in RIP network)

A RIP interface directly connects to an interface with an address on a different network.

The peer should not be on a different network.However, you can add the peer’s network from the RIP configuration mode context:network <peer A.B.C.D> <subnet mask>

ignored [v1 | v2] packet from <A.B.C.D> (illegal version)

RIP versions are incompatible. • Determine whether the local or remote peer is configured for the wrong version.

• If the local router, determine whether the global version or a particular interface is misconfigured.

you do NOT see:[v1 | v2] sent <number> route

• LANs are not participating in RIP.

• RIP interfaces are passive.

• Add the LAN to RIP.• If the LAN should not be

running RIP, redistribute connected routes.

• Remove the passive-interface configuration.

15-153


An interface only participates in RIP when the network on which it has its primary address has been added to RIP. You can see which interfaces are running RIP by viewing the running-config.

The interface may not participate in RIP if the subnet mask for its address has been entered incorrectly. Make sure that you have entered a subnet mask, not wildcard bits.

A common problem with RIP is routers using incompatible versions. The ProCurve Secure Router does not support RIP v2 compatibility mode. This means that RIP v2 interfaces multicast routing updates. RIP v1 interfaces do listen for and send multicasts, so the interfaces running different versions do not receive the routes that they should.

You can also view the RIP version by entering show running-config

router rip.

A particular interface may be configured to override the global version and send or listen for a different version. View the portion of the running-config for a particular interface (for example, do show running-config interface

ppp 1) to see what RIP versions it is using. If it is listening for a different type than that implemented on its network, change it by entering:

ProCurve(config-ppp 1)# ip rip receive version [1 | 2]

If the peer is sending the wrong version type to the local router, you can view the debug messages (see Table 15-22) to determine which peer is doing so. However, debug messages can be very processor intensive. You can try pinpointing the faulty device by the routes the local router is not receiving. Then, troubleshoot that device.

Routers at remote sites may be separated by a transit network that does not support multicasts. For example, your organization has established a VPN through the Internet. In this situation, you must configure a GRE tunnel to encapsulate routing updates and then tunnel them through the Internet. See Chapter 11: Configuring a Tunnel with Generic Routing Encapsulation to learn how to configure this tunnel.

Other Routers Not Receiving Routes to the Local Router’s Subnets

A remote router may not receive routes from the local router because:

■ the local router is sending the wrong version of RIP messages

■ the local router interface has been configured as a passive interface

■ connected routes have not been redistributed

■ the remote router has some problem

15-154


View the running-config for the interface that connects to the peer that is not receiving routes. If the send version does not match that implemented by the peer, you must change it:

ProCurve(config-ppp 1)# ip rip send version [1 | 2]

If the interface is not transmitting any RIP messages, it may be configured as a passive interface: it listens for updates but does not send them. View the running-config and look for this RIP configuration:

passive-interface <interface ID>

If the interface should be sending RIP updates, use the no form of the command to remove the configuration. From the RIP configuration mode context, enter:

Syntax: no passive-interface <interface ID>

Sometimes you do not want to enable RIP on a network; however, other routers still need to reach that network. In this case, make sure that you have redistributed connected routes into RIP.

If you cannot find any of these problems on the local router, troubleshoot the remote router.

Troubleshooting OSPF

When an OSPF router does not receive the correct LSAs, it cannot route traffic correctly.

Because you can configure various routers to send and receive various LSAs, depending on their role in the network, it is easy to inadvertently prevent a router from receiving the LSAs it should.

You can use the enable mode debug commands to monitor OSPF activity in detail and to view the LSAs that the router’s interfaces send and receive. (See Table 15-23.)

C a u t i o n OSPF is a chatty protocol and the debug messages can be very processor-intensive.

15-155


Table 15-23. Viewing OSPF Debug Messages

As you troubleshoot, you may also want to view information about OSPF interfaces, networks, and areas. Use the show commands shown in Table 15-24.

Message Command Syntax

all events debug ip ospf

OSPF packets debug ip ospf packet

adjacency events debug ip ospf adj

hello debug ip ospf hello

LSA generation debug ip ospf lsa-generation

SPF generation debug ip ospf spf

database tree debug ip ospf tree

flood debug ip ospf flood

retransmission debug ip ospf retransmission

timer for the database tree debug ip ospf database-timer

15-156


Table 15-24. Viewing OSPF Information

View Command Syntax

• router ID• the number of areas configured on a router• areas’ types:

– normal– stub– NSSA

• the number of interfaces in each area• the number of external LSAs received

show ip ospf

the interfaces running OSPF:• line status• line protocol• IP address• area ID• router ID• network type• transit delay and timers• DR and BDR in a multi-access network• neighbors

show ip ospf interface

OSPF information on a particular interface show ip ospf interface <interface ID>

OSPF neighbors:• router ID• state• local forwarding interface

show ip ospf neighbor

detailed information on OSPF neighbors:• router ID• area• priority• state• state changes• timers

show ip ospf neighbor detail

detailed information on OSPF neighbors for a particular interface

show ip ospf neighbor <interface ID>

route summaries (ASBRs) show ip ospf summary-address

15-157


If your network runs OSPF routing over a VPN, you must configure a GRE tunnel to encapsulate routing updates. The Internet cannot support unencap-sulated multicast traffic. See Chapter 11: Configuring a Tunnel with Generic

Routing Encapsulation to learn how to configure such a tunnel.

Troubleshooting an Internal Router

Common problems include a router being unable to route traffic or sending incorrect routes to its neighbors. Follow the troubleshooting tips for your problem.

The Router Is Unable to Route Traffic. In a stub area, an internal router should be able to route intra-area traffic on its own. It should also be able to route inter-area traffic to an ABR (which then routes it to its final destination) with a default route, with inter-area routes, or with both. If the private network connects to an external network, the router should be able to route it with the default route.

OSPF database:• complete (no keyword)• external LSAs• router LSAs• network LSAs• summary LSAs

show ip ospf database [external | router | network | summary]

summary of the OSPF database show ip ospf database database-summary

particular entry in an OSPF database:• external LSA• router LSA• network LSA• summary LSA

show ip ospf database [external | router | network | summary] <LSA ID>

OSPF database from a specific router:• complete (no keyword)• external LSAs• router LSAs• network LSAs• summary LSAs

show ip ospf database [external | router | network | summary] adv-router <A.B.C.D> <LSA ID>

View Command Syntax

15-158


Figure 15-36. Example OSPF Stub Router’s Table

When the router is not properly performing these functions, follow these steps:

1. View the routing table:

ProCurve# show ip route

The table should include routes to all other subnets in the router’s area. Unless this is a total stub area, it should also contain route(s) to an ABR(s) for inter-area traffic and a default route for external traffic.

Make a list of the destinations for which the table should have an entry, but does not.

Figure 15-36 displays an example of a stub router’s routing table.

2. If the router only lacks routes for networks in other areas, move to step 7. If the router also lacks routes to networks in its own area, it is not fully synchronizing its database with other routers in its area. This could be because:

• OSPF has not been enabled on one or more of its interfaces

• an interface has been placed in the wrong area

• the MTU on the interface does not match its neighbor’s

• an interface has not been configured with the correct authentication information

• connecting routers are not running OSPF as they should


Gateway of last resort is 10.2.2.2 to network 0.0.0.0

O IA 0.0.0.0/0 [110/50] via 10.2.2.2, ppp 1C 10.2.2.0/30 is directly connected, ppp 1C 10.2.2.2/32 is directly connected, ppp 1C 192.168.64.0/24 is directly connected, eth 0/1C 192.168.65.0/24 is directly connected, eth 0/2O 192.168.100.0/24 [110/1], via 192.168.64.1, eth 0/1O IA 192.168.128.0/18 [110/51] via 10.2.2.2, ppp 1

Inter-area route

Intra-area route

Default route

15-159


3. View the OSPF interfaces (show ip ospf interface) and verify that all interfaces that should be running OSPF are listed. Also make sure that the interfaces are up and active.

If an interface that should be running OSPF is not, you have found your problem. Move to the OSPF configuration mode context and enable OSPF on the interface’s network. For example:

ProCurve(config-ospf)# network 192.168.3.0 0.0.0.255 area 1

Take care to place the network in the correct area. Remember that the network for the interface’s primary address must run OSPF.

If an interface is down, troubleshoot it as described in the Basic Manage-

ment and Configuration Guide, Chapter 6: Configuring the Data Link

Layer Protocol for E1, T1, and Serial Interfaces.

4. Verify that the area for the interface in question is correct. If an interface is in the wrong area, it will not establish full adjacency with neighboring routers. If this is an internal router, all networks should be in the same area. If necessary, remove and re-add an incorrectly defined network:

ProCurve(config-ospf)# no network 192.168.3.0 0.0.0.255 area 10 ProCurve(config-ospf)# network 192.168.3.0 0.0.0.255 area 1

5. Next, check the OSPF neighbors (show ip ospf neighbor). The router should have established full adjacency with all connected OSPF routers. For point-to-point links, the neighbor state should be “FULL/PPTP.”

If the state remains in EXSTART or EXCHANGE, one router cannot receive the other router’s database. This problem could be caused by:

• Incompatible MTU—The router with the smaller MTU will reject over-size packets from its neighbor and so may not receive the neighbor’s database. It will stay in the EXSTART state. The neighbor with the larger MTU will continue sending packets and remain in the EXCHANGE state. If you are troubleshooting an inactive network and can view debug messages, enter debug ip ospf and look for messages such as those shown in Figure 15-37. Set the MTU on the interfaces to the same value. You might need to reset the OSPF process.

15-160


Figure 15-37. Incompatible MTU

• Both routers have the same router ID—If both routers have the same ID, check for a misconfigured IP address in the loopback interface. An OSPF router takes its router ID from the highest IP address on a loopback interface. If the router does not have a loopback interface, it takes its ID from the highest address on any interface. However, once the router takes an ID, it does not change it simply because a new interface is configured. (This is one reason why it is important to completely configure OSPF before connecting the router to the network.) If you need to change the router’s ID, you must reset OSPF.

6. Incorrect authentication settings can also prevent a router from establish-ing full adjacency with its neighbors. All networks in the area should be using the same authentication type. Determine what type this is, and if necessary configure it on each OSPF interface. (See “Configuring OSPF Authentication” on page 15-62.)

Remember that different networks can use different passwords, so you might need to configure different passwords on various interfaces on the router.

OSPF: Update LSA: id=192.168.3.1 rtid=192.168.3.1 area=0.0.0.2 type=1b09:46:01:Receiving OSPF packet from 10.20.20.1 to 224.0.0.5 on tunnel 1 CurrentTime=5641597. Database Description Packet from Router ID:192.168.100.1; Ver:2 Length:32 Area ID:0.0.0.2 Checksum:0x305d; Using Null Authentication:0:0 MTU:1472 Options:0x0 Sequence Number:104111321 Router is the Master; 0 LSA Headers:09:46:01: OSPF: Processing database description packet from nbr 192.168.100.1 (seq=104111321)09:46:01: OSPF: Neighbor 192.168.100.1 packet's MTU (1472) does not match ours (0)09:46:01: OSPF: Sending database description packet to 192.168.100.1 with sequence 0e763dfc on tunnel 109:46:01:Sending OSPF packet to 224.0.0.5 from 10.20.20.2 on tunnel 1 CurrentTime=5641601. Database Description Packet from Router ID:192.168.3.1; Ver:2 Length:32 Area ID:0.0.0.2 Checksum:0xedb8; Using Null Authentication:0:0 MTU:0 Options:0x0 Sequence Number:242630140 Router is the Master; 0 LSA Headers:

Local interface’s MTU

MTU must match

Neighbor’s MTU

15-161


7. If the router has established full adjacency with its neighbors, but it still lacks routes to destinations in the area, other routers may be the source of the problem. Troubleshoot these routers as you would a router not sending the correct routes. (See “The Router Is Not Sending the Correct Routes” on page 15-162.)

8. An internal router should also receive IA routes so that it can forward inter-area traffic. Several problems with inter-area routing can arise:

• The area was configured to not receive route summaries on the local router—Enter show running-config and look for an area <area

ID> stub no-summary setting.

• An ABR incorrectly classifies the local area as a total stub area.

• The ABR does not generate route summaries or generates them incorrectly—In this case, the router might have a route for inter-area traffic, but the traffic is misrouted when it reaches area 0.

If the router has received a default route but no inter-area route summa-ries, it has probably been defined as a total stub area on either the local router or its ABR. Enter area <area ID> stub without the no-summary

option from the OSPF configuration mode context to solve the problem on a local router. If the problem seems to be on the ABR’s end, use the tips for troubleshooting an ABR. (See “Troubleshooting an ABR” on page 15-162.)

The Router Is Not Sending the Correct Routes. View the OSPF inter-faces (show ip ospf int). It is possible that OSPF has not been enabled on the correct networks in the correct area. Troubleshoot as described above in steps 3 through 6.

Sometimes a router has interfaces that should not run OSPF, but which make connections that OSPF routers should take into account when generating a network topology. In this case, you should redistribute connected routes into OSPF. (See “Redistributing Routes Discovered by Other Protocols (ASBRs)” on page 15-58.)

Troubleshooting an ABR

An ABR should be able to route traffic it receives from a stub area through the network backbone to the destination area. It should also be able to route intra-area traffic in area 0.

If the ABR is only routing intra-area traffic incorrectly, troubleshoot it as you would an internal router.

15-162


Other problems with an ABR include:

■ not sending route summaries to the areas that need them

■ misrouting inter-area traffic

An ABR That Does Not Send Route Summaries. The area that is not receiving summaries may be defined as a total stub area. Such areas do not receive route summaries.

View the running-config and look for this OSPF configuration for the area in question:

area <area ID> stub no-summary

If the area should be receiving summaries, move to the OSPF configuration mode context and re-enter the command without the no-summary option:

ProCurve(config-ospf)# area <area ID> stub

The ABR might also be prohibited from advertising a route summary. View the running-config and look for this option for the area that cannot be reached:

area <area ID> range <network A.B.C.D> <subnet mask> not-advertise

Remove this configuration and re-enter the command with the advertise option instead.

An ABR Misrouting Inter-Area Traffic. When an ABR generates incor-rect route summaries, it can both misroute traffic itself and cause connected stub routers to misroute traffic. Misconfigurations often involve entering the wrong subnet mask for an area’s IP address range.

You can view the summaries the router is sending by entering show ip ospf

database summary from the enable mode context.

In a network with variable-length subnets, you must be very careful to specify subnet masks that correspond with the correct CIDR prefix length. Remem-ber, for example, that the network address 172.16.0.0 /16 (255.255.0.0) is different from the network address, 172.16.0.0 /20 (255.255.240.0). The first refers to all addresses between 172.16.0.1 through 172.16.255.255; the second only refers to addresses up to 172.16.15.255.

When the router summarizes routes to a range of subnets, you must alter the subnet mask that corresponds with the subnet’s bit length, which can lead to errors. The simplest way is to summarize a range of subnets up to the classful network boundary.

15-163


However, different areas often use subnets from the same classful network, and the range should only apply to the one area. You must then calculate exactly which network bits the range of subnets have in common.

For example, if area 1 includes subnets 172.16.0.0 /20 and 172.16.16.0 /20, and area 2 includes 172.16.32.0 /20 and 172.16.48.0 /20, the IP address range for area 1 is not 172.16.0.0 /16. That summary would include subnets in the other area. Rather, the address range for area 1 is 172.16.0.0 /19 (255.255.224.0). One bit is removed from the prefix length to match both /20 networks. Similarly, the address range for area 2 is 172.16.32.0 /19 (255.255.224.0).

See “Route Summarization (ABRs): Advertising a Link to One Area to Routers in Another Area” on page 15-47 to review how to specify the range of addresses in an area.

Troubleshooting BGP

BGP allows you a great deal of flexibility in setting a policy for exchanging routes. However, these policies can be complicated to configure. The follow-ing sections contain general tips for solving common problems.

Strategies and Tools

A BGP router might not send or receive the routes that it should for several reasons:

■ It cannot communicate with a neighbor.

■ It is not authorized to transmit, or to accept, the routes in question.

View BGP neighbors to make certain the neighbor exists. (Enter show ip bgp

neighbor from the enable mode context).

If the router seems to be able to communicate with the neighbor, but it is not receiving the routes that it should, you should examine BGP filters.

The clear, show, and debug commands will help you as you troubleshoot BGP.

show and debug Commands. Use the debug commands shown in Table 15-25 and the show commands shown in Table 15-26 as you troubleshoot the router.

15-164


Table 15-25. Viewing BGP Debug Messages

N o t e Remember that the debug commands can be draining on the processor.

Table 15-26. Viewing BGP Information

Message Command Syntax

updates:• new route• withdrawn routes

debug ip bgp updates

events, such as a change in the neighbor’s status

debug ip bgp events

all BGP messages except keepalives:• all (do not enter an option keyword) • received (in)• transmitted (out)

debug ip bgp [in | out]

keepalives debug ip bgp keepalives

View Command Syntax

• BGP table, which for each route includes:– origin– destination– next hop– AS in path– whether selected as best

• Local router ID and AS

show ip bgp

• BGP table with only the routes advertised to a specific neighbor

show ip bgp neighbors <A.B.C.D> advertised-routes

• BGP table with only the routes received from a specific neighbor

show ip bgp neighbors <A.B.C.D> received-routes

• BGP table with only the routes actually added to the routing table

show ip bgp neighbors <A.B.C.D> routes

Specific route:– advertising router IP address– advertising router ID– neighbors to which the route is

advertised

show ip bgp <A.B.C.D> <subnet mask>

15-165


clear Commands. You must clear BGP sessions in order for BGP policy changes, such as alterations to the prefix-list filters, to take effect. Enter this enable mode command:

Syntax: clear ip bgp [* | <AS> | <A.B.C.D>] [in | out | soft]

You must specify which neighbors the router will clear. If you enter *, the router will clear all neighbors. If you enter an AS number, the router clears all neighbors in that AS. You can also enter the neighbor’s IP address to clear only the session with that neighbor.

You can specify a hard reset or a soft reset.

BGP neighbors:• neighbor IP address• neighbor ID• remote AS• settings for BGP intervals• connection status• number of messages:

– opens– notifications– updates– keepalives

• local BGP interface IP address

show ip bgp neighbors

specific BGP neighbor show ip bgp neighbors <A.B.C.D>

summary of BGP information:• local ID• local AS• paths received• neighbors:

– remote IP address– remote AS– messages in and out

show ip bgp summary

all routes known by the router that are part of a community

show ip bgp community [internet | local-as | no-advertise | no-export | <1-4294967295>]

all routes known by the router that pass through a specific expected AS

show ip bgp regexp <AS number>

community lists show ip bgp community-list <listname>

View Command Syntax

15-166


N o t e Typically, you should use soft resets because hard resets can disrupt the network.

A hard reset terminates the TCP connection to the neighbor, causing all routes to flap. If you enter only the identifier for the neighbor (*, AS number, or IP address), the router automatically institutes a hard reset. For example, to initiate a hard reset with all neighbors in AS 1, enter:

ProCurve# clear ip bgp 1

A soft inbound reset simply prompts the neighbor to resend routes, and a soft outbound reset causes the router to resend routes to the neighbor.

You specify a soft inbound reset with the in keyword and a soft outbound reset with the out keyword. For example, you can configure a soft outbound reset and have the router resend routes to all neighbors:

ProCurve# clear ip bgp * out

You can set a soft inbound and outbound reset at the same time with the soft keyword. For example:

ProCurve# clear ip bgp 1 soft

Removing Filters. IBGP allows you to configure policies to filter the routes that router accepts from and advertises to neighbors. You configure these policies in prefix lists and route maps. Because the policies can be quite complicated, they open room for errors.

One of the first steps that you can take when troubleshooting BGP is to remove any inbound or outbound filters from the neighbor. If the router begins to receive or advertise the routes that it should, then you know that the filters are causing the problem. You can troubleshoot the filters and reapply them. (See “Troubleshooting a Prefix List” on page 15-172 and “Troubleshooting a Route Map” on page 15-173.)

To remove filters, move to the BGP neighbor configuration mode context. If you have applied a prefix list to the neighbor, enter:

Syntax: no prefix-list <listname> [in | out]

If you have applied a route map to the neighbor, remove the map:

Syntax: no route-map <mapname> [in | out]

15-167


Clear the neighbor with a soft reset and see if the router begins to receive routes. If it does, you have confirmed that the filter is the problem. Reconfigure the prefix list or route map, keeping in mind that the router processes entries in order by sequence number and stops as soon as it finds a match.

You can also monitor how a prefix list or route map is affecting traffic by viewing the list or map and checking the number of packets the router has matched to it. (See “Troubleshooting a Prefix List” on page 15-172 and “Trou-bleshooting a Route Map” on page 15-173.)

If you are using a prefix list with a route map, then you may want to determine whether it is the prefix list or the route map configuration that has the error. You can configure an entry in the prefix list that permits all routes:

ProCurve(config)# ip prefix-list NeighborIn seq 100 permit 0.0.0.0/0 le 32

You can then reapply the route map to the neighbor. If the router begins to receive routes, then you will know that you must reconfigure the prefix list.

A BGP Interface Cannot Communicate with a Neighbor. Unlike other routing protocols, BGP interfaces do not automatically search for and exchange routes with connected routers. You must manually configure autho-rized neighbors.

View the BGP neighbor and double-check its IP address:

ProCurve# show ip bgp neighbors

Ping the neighbor to check connectivity.

If the ping is successful, but the router does not seem to be exchanging BGP messages, you might need to configure eBGP multihop. External neighbors are supposed to be directly connected to the BGP interface. If they are not, you must specify the number of hops it is to the neighbor. For example:

ProCurve(config-bgp-neighbor)# ebgp-multihop 4

Remember that a loopback interface adds a hop to the route. Even if the external neighbor is directly connected, you must enable eBGP multihop if you are using the loopback interface as the source BGP interface.

You should also check the configurations shown in Table 15-27 and make sure they match those you have agreed upon with the entity that controls the external AS.

15-168


Table 15-27. Checking BGP Configurations

See Figure 15-38 for an example of how you can find some of this information.

Figure 15-38. Viewing Local ID and Local AS

When the BGP interface cannot reach the configured neighbor, you receive the follow debug messages:

BGP EVT 1.1.1.1[1]: IDLE->CONNECTBGP EVT 1.1.1.1[1]: CONNECT->IDLEBGP OUT 1.1.1.1[1]: TCP error 0 connecting to peer (events:connect)

In this example, the interface is attempting to connect to a peer through the peer’s loopback address (1.1.1.1), which the router does not consider to be directly connected.

When you configure the BGP neighbor, you should always identify it by the IP address for the connecting interface, even if the remote router uses a different router ID. For example, Figure 15-39 displays information about a local router’s BGP neighbor. The neighbor uses a loopback interface address (1.1.1.1) for its router ID. However, the remote IP address is 10.1.1.1, and this is the IP address you would enter when configuring the neighbor.

Configuration How to View Your Setting

local AS show ip bgp [summary]

local router ID show ip bgp [summary]

local router IP address show ip bgp neighbor

neighbor router ID show ip bgp neighbor

neighbor IP address show ip bgp neighbor

remote AS show ip bgp neighbor

ProCurve#show ip bgp summaryBGP router identifier 4.4.4.4, local AS number 21 network entries, 1 paths, and 2 BGP path attribute entries

Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State/PfxRcd10.1.1.1 4 1 12 11 0 0 00:08:37 3

Local AS

Local ID

Remote IP address

15-169


Figure 15-39. Viewing a BGP Neighbor

A BGP Interface Will Not Accept Routes. If you suspect that the filters are keeping the router from receiving routes, try comparing the routes that the BGP interface receives from a neighbor to those it actually accepts. Enter:

Syntax: show ip bgp neighbor <A.B.C.D> received-routesSyntax: show ip bgp neighbor <A.B.C.D> routes

Note any routes that display when you enter the first command that do not display when you enter the second. These routes are being filtered out. (See Figure 15-40.) You can also determine that the filter is rejecting a route, when the route does not have an asterisk (*) in front of the network address.

If the router should accept the rejected route, then the inbound filter has been misconfigured.

ProCurve#show ip bgp neighborBGP neighbor is 10.1.1.1, remote AS 1, external linkConfigured hold time is 180, keepalive interval is 60 secondsDefault minimum time between advertisement runs is 30 secondsConnections established 1; dropped 0Last reset: Never Connection ID: 2 BGP version 4, remote router ID 1.1.1.1 BGP state is Established, for 00:08:20 Negotiated hold time is 180, keepalive interval is 60 seconds Message statistics: InQ depth is 0, OutQ depth is 0 Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 1 3 Keepalives: 8 8 Unknown: 0 0 Total: 10 12 Local host: 10.2.2.1, Local port: 1096 Foreign host: 10.1.1.1, foreign port: 179 Flags: active open

Neighbor IP addressNeighbor AS

Neighbor ID

Local IP address

Neighbor IP address

15-170


Figure 15-40. Comparing Accepted Routes to All Routes Received

Try removing filters from the neighbor. (See “Removing Filters” on page 15-167.) If the filter is the problem, then troubleshoot it as described in “Troubleshooting a Prefix List” on page 15-172 and “Troubleshooting a Route Map” on page 15-173.

The router also will not accept a route if the AS path includes the local AS number. If this is the problem, verify that the local AS is correct.

A BGP Interface Will Not Send Routes to a Neighbor. When remote hosts cannot reach the local network, the BGP interface may not be sending it the correct routes. View the routes the router is advertising to the neighbor by entering show ip bgp neighbor <A.B.C.D> advertised-routes.

Verify that you have configured BGP to advertise the network by viewing the running-config. Also, check outbound filters (both prefix lists and route maps) as you would inbound filters.

ProCurveSR7102dl#show ip bgp neighbor 10.1.1.1 routesBGP local router ID is 192.168.140.1, local AS is 1.Status codes: * valid, > best, i - internal, o - localOrigin codes: i - IGP, e - EGP, ? - incomplete

Network NextHop Metric LocPrf PathTotal RIB entries = 1

ProCurveSR7102dl#show ip bgp neighbor 10.1.1.1 received-routesBGP local router ID is 192.168.140.1, local AS is 1.Status codes: * valid, > best, i - internal, o - localOrigin codes: i - IGP, e - EGP, ? - incomplete

Network NextHop Metric LocPrf Path 10.0.0.0/8 10.1.1.1 2 iTotal RIB entries = 1

The router is not accepting any routes from the neighbor

The router is filtering out the route to 10.0.0.0 /8

No * indicates that the router considers the route invalid.

15-171


If you want a router to advertise routes it receives from one BGP neighbor to another, you must configure the AS it should add to the AS path. You configure this setting from the configuration mode context of the BGP neighbor from which the router receives the route. Enter:

Syntax: local-as <AS>

If the router still cannot send or receive routes, then it is probably having trouble connecting to the neighbor. (See “A BGP Interface Cannot Communi-cate with a Neighbor” on page 15-168.)

Troubleshooting a Prefix List

Use the following enable mode command to view a prefix list:

Syntax: show ip prefix-list [detail | summary] <listname>

The detail and summary keywords are optional and mutually exclusive. If you enter only the listname, then you can view the permit and deny statements, listed by sequence number. If you use the summary keyword, then you will see only the number of statements, their sequence numbers, and the number of these statements that include a range of valid prefixes.

Entering the detail keyword produces all the information shown by the other two commands, as well as the number of packets the router has matched to each statement. Looking for a statement that has had no hits can point you towards the statement with the misconfiguration.

If the entire list has no hits, then you may have forgotten to apply the list to the neighbor. (If you are applying the list to a route map, make sure that the map has been applied to the neighbor.) You should also verify that the list is correctly applied to either inbound or outbound data.

Figure 15-41 shows the output of a detailed command.

Figure 15-41. Viewing a Prefix List

ProCurve# show ip prefix-list detail MyListip prefix-list MyList count: 2, range entries 1, sequence 10-20 (total hit count: 50)

seq 10, deny 10.1.3.0/24 (hit count: 10)seq 20, permit 10.1.0.0/16 ge 24 le 24 (hit count: 40)

Number of statements in the list.

Number of statements that filter a range of routes. Number of routes

filtered by this statement.

15-172


Keep these tips in mind as you search a prefix list for misconfigurations:

■ If a statement does not include a range of prefixes, then a route must match the statement exactly in order to be selected. Make sure that the prefix length is correct.

■ Sequence numbers are important. The router stops processing the list after it finds a match. In Figure 15-41, the deny statement must have a lower sequence number than the permit statement because the route specified in the deny statement also matches the permit statement.

■ The ge and le keywords match prefixes equal to length specified, as well as those greater or lesser than the specified length. That is, the statement permit 0.0.0.0/0 le 17 will allow /17 routes.

Troubleshooting a Route Map

Enter the following enable mode command to view a route map:

Syntax: show route-map [<mapname>]

Include a name to view only that route map. If you want to see all route maps configured on the router, do not enter a mapname.

Figure 15-42. Viewing BGP Policies in a Route Map

You can view how many routes have been matches to the route map. (See Figure 15-42.) If the router does not seem to be filtering any routes, verify that you have applied the route map to the correct neighbor and as the correct policy (inbound or outbound).

ProCurve# show route-maproute-map ISP1, permit, sequence 10 Match clauses: ip address (prefix-lists): LAN1 Set clauses: community no-export metric 200 BGP Filtering matches: 5 routes Policy routing matches: 0 packets, 0 bytesroute-map ISP1, permit, sequence 20 Match clauses: ip address (prefix-lists): LAN2 Set clauses: metric 160 BGP Filtering matches: 4 routes Policy routing matches: 0 packets, 0 bytes

Criteria for selecting routes

Number of routes matches by this map entry.

Policies applied to routes

15-173


When examining the route map for misconfigurations keep these tips in mind:

■ If you want to apply attributes to routes filtered by an inbound route map, you must enter the set command for the attributes in the same route map entry in which you enter the match command to select permitted routes.

■ If an entry does not include a match clause, then the policy in that entry will be applied to all routes.

■ If you are using an entry to place a route in one or more communities (the set clause will read community <community>), then you should enter the send-community standard command in the BGP neighbor configu-ration mode context.

Other Common BGP Problems

Once a BGP has opened a session and exchanged routes with neighbors, two problems may arise:

■ An ISP refuses to accept the local router’s routes.

■ Your network is flooded with external traffic.

■ Routes are not being defined in the correct communities.

An ISP Router Refuses Local Routes. You should verify that your ISP allows you to advertise private routes. The ISP must support VRF.

Network Flooded with External Traffic. One of the most common uses for BGP is BGP multihoming. BGP allows you to connect to two ISPs and advertise certain routes to one and certain routes to the other.

An unintended consequence of multihoming is that the ISPs can advertise routes to each other through your local network. Your private network becomes a transit network for external traffic.

To prevent this from happening, you should configure a prefix list that adver-tises only local subnets.

Routes in Incorrect Communities. Several causes could prevent a remote neighbor from applying the correct policies to routes that you have defined as members of particular communities:

■ You did not enable the router to send community attributes to this neighbor.

Enter the send-community standard command from the BGP neighbor configuration mode context.

15-174


■ The BGP neighbor defines different policies for the community. Or the BGP neighbor does not accept community attributes in customer routes.

You should consult with your ISP about what communities it supports.

You may also have problems with the local policy that you have configured for communities on your router.

View route maps and examine entries that include a match clause for a community list. Then verify that the set clauses implement the correct policies for communities in this list.

You can view a community list using this enable mode command:

Syntax: show ip community-list [<listname>]

You can enter show ip bgp community-list <listname> to view the routes that match the community list.

You can monitor the communities of routes that the router receives by entering this enable mode command:

Syntax: show ip bgp community [internet | local-as | no-advertise | no-export | <1-4294967295>]

The CLI displays all routes in the specified community. Enter the command without a keyword for the community to see all routes known by the router that have a community attribute.

Monitoring and Troubleshooting PBR

After configuring PBR, you should view the policies and verify that the traffic is being sent over the correct connections.

You can view the policies applied to router interfaces with this enable mode command:

ProCurve# show ip policy

This enable mode command displays the policy applied to router traffic (if any):

ProCurve# show ip local policy

You can view the actual configured policies by viewing the route maps. Enter this enable mode command:

ProCurve# show route-map [<mapname>]

15-175


Figure 15-43. Viewing PBR Policies in a Route Map

The display lists entries in the route map by sequence number. The entries are further divided into match clauses, which show the criteria the map uses to select packets, and set clauses, which show the next hop address or forward-ing interface for the PBR route. (See Figure 15-43.)

You can verify that traffic can reach its destination by applying the route map to router traffic with this global configuration mode context command:

Syntax: ip local policy route-map <mapname>

First clear the route map statistics so that you can later verify that the router is matching the traffic to the route map. Enter:

ProCurve# clear route-map counters

Then send a ping to the desired destination using the extended commands so that the ping matches the criteria specified in the route map.

For example, route map entry PBR 10 (shown in Figure 15-43) selects traffic for which the Layer 3 packet size is between 150 and 200 bytes. You could enter this command from the enable mode context:

ProCurve# ping size 150

Router# show route-map

route-map PBR, permit, sequence 10 Match clauses: length 150 200 Set clauses: ip next-hop 10.10.10.254 BGP Filtering matches: 0 packets, 0 bytes Policy routing matches: 4 packets, 600 bytesroute-map PBR, permit, sequence 20 Match clauses: ip address (access-lists): 101 Set clauses: ip next-hop 10.10.10.14 BGP Filtering matches: 0 packets, 0 bytes Policy routing matches: 144 packets, 15190 bytes

Criteria for selecting traffic

Number of routes matches by this map entry

Route for selected traffic

15-176


You can also select a source address for ping so that you can simulate the traffic for source-based PBR. If the ping is not successful, then you should look for misconfigurations in the set clauses. Verify that specified interfaces are up and that the router’s routing table includes a route to the next-hop address.

Simply because a ping is successful does not mean that traffic used the correct interface.

View the route map by entering show route-map and verify that the pings have generated “Policy routing matches.” (See Figure 15-43.)

If the router is not matching any packets to the entries, then you should verify that the route map has been applied to the correct interface. Route maps for PBR apply to traffic received on the interface.

You should also look for misconfigurations in the match clauses. One common problem is a misconfigured ACL. See Chapter 5: Applying Access Control to

Router Interfaces for tips for troubleshooting an ACL.

Remember also that if you specify more than one type of criteria in an entry, traffic must match each specification. For example, you enter:

ProCurve(route-map)# match length 150 200ProCurve(route-map)# match ip precedence 5

This route map entry only selects packets that are both the correct size and have the correct IP precedence value.

If you are using source-based PBR only, you can use this traceroute command to determine the path the traffic is taking:

Syntax: traceroute <destination A.B.C.D> source <A.B.C.D>

Another common problem with PBR is traffic that should be routed normally is being sent over the policy-based route. In this situation, you consider whether the route map’s set commands should use the default keyword so that it only applies to traffic without another explicit route. Often this is the case when you are using the route map to route and load balance external traffic. You should also check the route map’s match clauses for misconfigu-rations. If an entry does not include a match clause, then it will select all traffic.

15-177

Documents

IP Routing—Configuring RIP, OSPF, BGP, and PBR · 15-152 IP Routing—Configuring RIP, OSPF, BGP, and PBR Troubleshooting Routing Enter **, which clears all routes, or enter the