Trouble Ticket Solutions
These solutions are not always the only way to perform these tasks. Compare your results.
Trouble Ticket 1 Solution
First connect the physical cable between r5 and the frame switch. Then configure the frame switch to handle the new PVC, and then r1 and r5 as in Example 8-33.
Example 8-33. Configuring the Frame Switch, r1, and r5
!!!frame switch configuration for new PVC frame-switch#configure terminal frame-switch(config)#interface s0/3 frame-switch(config-if)#bandwidth 64 frame-switch(config-if)#clock rate 64000 frame-switch(config-if)#encap frame frame-switch(config-if)#frame-relay intf-type dce frame-switch(config-if)#frame route 101 interface s0/0 105 frame-switch(config-if)#no shut frame-switch(config-if)#end frame-switch#copy running-config startup-config !!!r1 configuration for point-to-point PVC 105 r1#configure terminal r1(config)#interface s0.105 p r1(config-subif)#bandwidth 64 r1(config-subif)#ip address 172.16.8.5 255.255.255.252 r1(config-subif)#frame-relay interface-dlci 105 r1(config-fr-dlci)#no shut r1(config-if)#end r1#copy running-config startup-config !!!r5 configuration for point-to-point PVC 101 Router#configure terminal Router(config)#hostname r5 r5(config)#interface s0 r5(config-if)#encap frame r5(config-if)#interface s0.101 p r5(config-subif)#bandwidth 64 r5(config-subif)#ip address 172.16.8.6 255.255.255.252 r5(config-subif)#frame-relay interface-dlci 101 r5(config-fr-dlci)#exit r5(config-if)#no shut r5(config-if)#end |
Then ping to test the new configuration. Because ping should be unsuccessful at this point, I do not show the output. Continue your testing as in Example 8-34.
Example 8-34. Checking the Interfaces for r5 and r1
r5#show ip interface brief Interface IP-Address OK? Method Status Protocol BRI0 unassigned YES unset administratively down down BRI0:1 unassigned YES unset administratively down down BRI0:2 unassigned YES unset administratively down down Ethernet0 unassigned YES unset administratively down down Serial0 unassigned YES unset administratively down down Serial0.101 172.16.8.6 YES manual down down Serial1 unassigned YES unset administratively down down r5#clock set 6:38:00 Dec 13 2002 r5#configure terminal r5(config)#service timestamps debug datetime localtime msec r5(config)#service timestamps log datetime localtime msec r5(config)#enable secret donna r5(config)#line vty 0 4 r5(config-line)#password donna r5(config-line)#exit r5(config)#line console 0 r5(config-line)#logging synchronous r5(config-line)#exit r5(config)#interface s0 r5(config-if)#no shut r5(config-if)#end r5#copy running-config startup-config r1#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset administratively down down Ethernet1 unassigned YES unset administratively down down Serial0 unassigned YES unset up up Serial0.100 192.168.8.1 YES manual up up Serial0.105 172.16.8.5 YES manual down down Serial1 unassigned YES unset administratively down down r1#configure terminal r1(config)#interface s0 r1(config-if)#no shut Dec 13 18:40:51.930: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.105, changed state to up Dec 13 18:40:51.938: %FR-5-DLCICHANGE: Interface Serial0 - DLCI 105 state changed to ACTIVE Dec 13 18:41:01.346: %FR-5-DLCICHANGE: Interface Serial0 - DLCI 105 state changed to DELETED Dec 13 18:41:01.346: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.105, changed state to down r1(config-if)#end r1#copy running-config startup-config |
Although you brought the administratively down interface up, the DLCI is still in a deleted state. Look at the routers and the frame switch in Example 8-35 to determine the problem.
Example 8-35. Troubleshooting r1, r5, and the Frame Switch
r1#show run interface s0.105 ... interface Serial0.105 point-to-point bandwidth 64 ip address 172.16.8.5 255.255.255.252 no ip directed-broadcast frame-relay interface-dlci 105 end r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (down): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status deleted r5#show frame-relay map Serial0.101 (down): point-to-point dlci, dlci 101(0x65,0x1850), broadcast status defined, inactive frameswitch>show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0/0 102 Serial0/1 101 active Serial0/0 104 Serial0/2 101 active Serial0/1 101 Serial0/0 102 active Serial0/2 101 Serial0/0 104 active Serial0/3 101 Serial0/0 105 inactive |
Hopefully, you see that you have a missing route statement from the frame switch, but how did you know what to look for? Instead of looking at the running configuration, you can check statuses: A good indication of this issue is the deleted status for DLCI 105 as well as the other end of the PVC being inactive. Fix these issues as in Example 8-36.
Example 8-36. Adding the Missing Frame Route Statement
frame-switch#configure terminal frame-switch(config)#interface s0/0 frame-switch(config-if)#frame route 105 interface s0/3 101 frame-switch(config-if)#no shut frame-switch(config-if)# 4d05h: %FR-5-DLCICHANGE: Interface Serial0/0 - DLCI 105 state changed to ACTIVE 4d05h: %FR-5-DLCICHANGE: Interface Serial0/3 - DLCI 101 state changed to ACTIVE frame-switch(config-if)#end frame-switch#copy running-config startup-config |
Now that everything appears to be configured properly, show the Inverse ARP tables on each device and verify connectivity as in Example 8-37.
Example 8-37. Testing the New PVC
r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (up): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, active r2#show frame-relay map Serial0.101 (up): ip 192.168.8.1 dlci 101(0x65,0x1850), dynamic, broadcast,, status defined, active frame-switch#show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0/0 102 Serial0/1 101 active Serial0/0 104 Serial0/2 101 active Serial0/0 105 Serial0/3 101 active Serial0/1 101 Serial0/0 102 active Serial0/2 101 Serial0/0 104 active Serial0/3 101 Serial0/0 105 active r4#show frame-relay map Serial0/0.101 (up): ip 192.168.8.1 dlci 101(0x65,0x1850), dynamic, broadcast,, status defined, active r5#show frame-relay map Serial0.101 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast status defined, active |
Active is the status you wanted to begin with on the frame switch and all the routers. Compare the findings in the preceding example to your drawing.
Save your configurations and move up the stack to work on the routing protocol. Configure BGP as in Example 8-38. r1 should advertise the 192.168.8.0 network to the other AS. r2 and r4 should be configured such that they use r1 to get to r5.
Example 8-38. Configuring BGP over Frame Relay
r1(config)#router bgp 65520 r1(config-router)#network 192.168.8.0 r1(config-router)#neighbor 192.168.8.2 remote-as 65520 r1(config-router)#neighbor 192.168.8.4 remote-as 65520 r1(config-router)#neighbor 172.16.8.6 remote-as 65525 r1(config-router)#neighbor 192.168.8.2 next-hop-self r1(config-router)#neighbor 192.168.8.4 next-hop-self r1(config-router)#no synchronization r1(config-router)#end r1#copy running-config startup-config r2#configure terminal r2(config)#router bgp 65520 r2(config-router)#neighbor 192.168.8.1 remote-as 65520 r2(config-router)#end r2#copy running-config startup-config r4#configure terminal r4(config)#router bgp 6520 r4(config-router)#router bgp 65520 BGP is already running; AS is 6520 !!!oops I made a typo r4(config)#no router bgp 6520 r4(config)#router bgp 65520 r4(config-router)#neighbor 192.168.8.1 remote-as 65520 r4(config-router)#end r4#copy running-config startup-config r5#configure terminal r5(config)#router bgp 65525 r5(config-router)#neighbor 172.16.8.5 remote-as 65520 r5(config-router)#end r5#copy running-config startup-config |
While setting up the BGP process, I made a typo. Actually it is a good way to prove that that while other routing protocols (such as OSPF and EIGRP) will run multiple processes, BGP will only run a single process. It is fine to advertise the 192.168.8.0 network without the mask statement because it is on the class boundary, and the manual neighbor statements are necessary because absolutely nothing in BGP is automatic. In looking at Figure 8-13, r1 has two IBGP peers (neighbors) and one EBGP peer (neighbor). The next-hop-self statement is needed for the IBGP peer to use r1 to get to the other AS because r1 has an interface in both autonomous systems. On the spoke routers, only the BGP process and neighbor statements are configured.
Perform the neighbor testing in Example 8-39. What TCP or BGP state are the neighbors in? Are they receiving prefixes?
Example 8-39. Identifying BGP Neighbors
r1#show ip bgp summary
BGP router identifier 192.168.8.1, local AS number 65520
BGP table version is 2, main routing table version 2
1 network entries and 1 paths using 121 bytes of memory
1 BGP path attribute entries using 96 bytes of memory
BGP activity 1/0 prefixes, 1/0 paths
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.8.6 4 65525 5 6 2 0 0 00:02:49 0
192.168.8.2 4 65520 7 8 2 0 0 00:04:19 0
192.168.8.4 4 65520 6 7 2 0 0 00:03:42 0
|
The show ip bgp summary command is an excellent way to BGP statistics and your neighbors. Any number, including 0 in the State/PfxRcd column, indicates that the neighbors are ready to receive prefixes. Thus they have completed both the TCP and BGP sessions. Investigate the TCP and BGP sessions a little further in Example 8-40.
Example 8-40. Displaying the TCP and BGP Sessions
r1#debug ip bgp events BGP events debugging is on r1#configure terminal r1(config)#interface s0 r1(config-if)#shut r1(config-if)#no shut Dec 13 20:01:06.813: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.100, changed state to down Dec 13 20:01:06.817: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.105, changed state to down Dec 13 20:01:07.065: BGP: 172.16.8.6 reset requested Dec 13 20:01:07.065: BGP: 172.16.8.6 reset due to Interface flap Dec 13 20:01:07.069: BGP: 172.16.8.6 went from Established to Idle Dec 13 20:01:08.305: BGP: 192.168.8.2 computing updates, neighbor version 2, table version 3, starting at 0.0.0.0 Dec 13 20:01:08.309: BGP: 192.168.8.2 update run completed, ran for 0ms, neighbor version 2, start version 3, throttled to 3, check point net 0.0.0.0 Dec 13 20:01:08.313: BGP: 192.168.8.4 computing updates, neighbor version 2, table version 3, starting at 0.0.0.0 Dec 13 20:01:08.317: BGP: 192.168.8.4 update run completed, ran for 0ms, neighbor version 2, start version 3, throttled to 3, check point net 0.0.0.0 Dec 13 20:01:08.809: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.100, changed state to up Dec 13 20:01:08.813: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.105, changed state to up Dec 13 20:01:12.837: BGP: 192.168.8.4 computing updates, neighbor version 3, table version 4, starting at 0.0.0.0 Dec 13 20:01:12.841: BGP: 192.168.8.4 update run completed, ran for 0ms, neighbor version 3, start version 4, throttled to 4, check point net 0.0.0.0 Dec 13 20:01:13.945: BGP: 192.168.8.2 computing updates, neighbor version 3, table version 4, starting at 0.0.0.0 Dec 13 20:01:13.949: BGP: 192.168.8.2 update run completed, ran for 0ms, neighbor version 3, start version 4, throttled to 4, check point net 0.0.0.0 Dec 13 20:01:27.845: BGP: 172.16.8.6 went from Idle to Active Dec 13 20:01:40.749: BGP: scanning routing tables Dec 13 20:01:55.969: BGP: 172.16.8.6 went from Active to OpenSent Dec 13 20:01:56.581: BGP: 172.16.8.6 went from OpenSent to OpenConfirm Dec 13 20:01:56.817: BGP: 172.16.8.6 went from OpenConfirm to Established Dec 13 20:01:56.921: BGP: 172.16.8.6 computing updates, neighbor version 0, table version 4, starting at 0.0.0.0 Dec 13 20:01:56.925: BGP: 172.16.8.6 update run completed, ran for 0ms, neighbor version 0, start version 4, throttled to 4, check point net 0.0.0.0 r1(config-if)#end r1#undebug all r1#copy running-config startup-config |
Although there are other commands, I find show ip bgp summary to be a very valuable tool. It not only enables you to see the neighbor relationship, if there are problems it shows the actual TCP or BGP state you are in with each neighbor. The first three states are TCP connections and the last three are BGP connections with established being the Promised Land.
NOTE
Active sounds good—and it is, when you are talking DLCIs in Frame Relay—but in BGP routing, it means the TCP session is not yet established, as in “actively trying.”
You can very quickly look at the State/PfxRcd column to check BGP neighbor issues. Numbers mean you are receiving prefixes; words mean you are stuck in another state for some reason. If you do everything right the first time, it is hard to learn from your mistakes, but the debug ip bgp events command clearly shows you the steps a neighbor goes through. The show ip bgp neighbor command gives you specifics about the neighbor and displays the established state. It also tells you whether the neighbor is internal or external. Compare the output of show ip bgp summary in Example 8-39 to show ip bgp neighbors in Example 8-41.
Example 8-41. Viewing Your BGP Neighbors on r1
r1#show ip bgp neighbors BGP neighbor is 172.16.8.6, remote AS 65525, external link Index 2, Offset 0, Mask 0x4 BGP version 4, remote router ID 172.16.8.6 BGP state = Established, table version = 4, up for 00:15:16 Last read 00:00:16, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 31 messages, 0 notifications, 0 in queue Sent 33 messages, 0 notifications, 0 in queue Prefix advertised 2, suppressed 0, withdrawn 0 Connections established 2; dropped 1 Last reset 00:16:06, due to Interface flap 0 accepted prefixes consume 0 bytes 0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 172.16.8.5, Local port: 11005 Foreign host: 172.16.8.6, Foreign port: 179 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0xC4A3DA8): Timer Starts Wakeups Next Retrans 20 0 0x0 TimeWait 0 0 0x0 AckHold 18 13 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3426000199 snduna: 3426000604 sndnxt: 3426000604 sndwnd: 15980 irs: 2443213131 rcvnxt: 2443213484 rcvwnd: 16032 delrcvwnd: 352 SRTT: 487 ms, RTTO: 3830 ms, RTV: 1428 ms, KRTT: 0 ms minRTT: 40 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, nagle Datagrams (max data segment is 1460 bytes): Rcvd: 25 (out of order: 0), with data: 18, total data bytes: 352 Sent: 34 (retransmit: 0), with data: 19, total data bytes: 404 !!!The rest of the neighbors are IBGP peers BGP neighbor is 192.168.8.2, remote AS 65520, internal link Index 1, Offset 0, Mask 0x2 NEXT_HOP is always this router BGP version 4, remote router ID 192.168.8.2 BGP state = Established, table version = 4, up for 00:27:58 Last read 00:00:59, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 5 seconds Received 30 messages, 0 notifications, 0 in queue Sent 33 messages, 0 notifications, 0 in queue Prefix advertised 2, suppressed 0, withdrawn 1 Connections established 1; dropped 0 Last reset never 0 accepted prefixes consume 0 bytes 0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 192.168.8.1, Local port: 179 Foreign host: 192.168.8.2, Foreign port: 11000 ... BGP neighbor is 192.168.8.4, remote AS 65520, internal link Index 3, Offset 0, Mask 0x8 NEXT_HOP is always this router BGP version 4, remote router ID 192.168.8.4 BGP state = Established, table version = 4, up for 00:27:26 ... |
Note that the output of show ip bgp neighbors presents you with much more detail than show ip bgp summary. For example, it clearly shows the neighbor is in the established state and whether the peer is IBGP (internal) or EBGP (external). Continue to verify your neighbors from the spoke perspective in Example 8-42.
Example 8-42. Viewing Your BGP Neighbors on r2, r4, and r5
r2#show ip bgp summary BGP router identifier 192.168.8.2, local AS number 65520 BGP table version is 4, main routing table version 4 1 network entries and 1 paths using 121 bytes of memory 1 BGP path attribute entries using 96 bytes of memory BGP activity 1/0 prefixes, 2/1 paths Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.8.1 4 65520 43 40 4 0 0 00:37:21 1 r4#show ip bgp summary BGP table version is 6, main routing table version 6 1 network entries (1/3 paths) using 208 bytes of memory 1 BGP path attribute entries using 104 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.8.1 4 65520 43 40 6 0 0 00:37:07 1 !!!the following shortcut works too r5#sh ip bgp sum BGP router identifier 172.16.8.6, local AS number 65525 BGP table version is 4, main routing table version 4 1 network entries and 1 paths using 121 bytes of memory 1 BGP path attribute entries using 144 bytes of memory BGP activity 2/1 prefixes, 2/1 paths Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.8.5 4 65520 43 41 4 0 0 00:25:21 1 |
If there would have been any neighbor issues, I would have backed up to make sure I had physical connectivity and had manually configured the neighbors. Now that you have verified the BGP neighbors, confirm the BGP tables and the routing tables as in Example 8-43.
Example 8-43. Confirming the BGP and Routing Tables
r1#show ip bgp BGP table version is 4, local router ID is 192.168.8.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.8.0 0.0.0.0 0 32768 i r1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.8.0/24 is directly connected, Serial0.100 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.105 r2#show ip bgp BGP table version is 4, local router ID is 192.168.8.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i192.168.8.0 192.168.8.1 0 100 0 i r2#show ip route ... C 192.168.8.0/24 is directly connected, Serial0.101 r4#show ip bgp BGP table version is 6, local router ID is 192.168.8.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i192.168.8.0 192.168.8.1 0 100 0 i r4#show ip route ... C 192.168.8.0/24 is directly connected, Serial0/0.101 r5#show ip bgp BGP table version is 4, local router ID is 172.16.8.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.8.0 172.16.8.5 0 0 65520 i r5#show ip route ... B 192.168.8.0/24 [20/0] via 172.16.8.5, 00:33:30 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.101 |
The only routing table that has BGP routes is r5. Many times routes are in the BGP table but just can't make it to the routing table, particularly with IBGP. As discussed earlier, when all routers in an AS are running BGP you can safely turn off synchronization. Do that now for r1, r2, and r4 as in Example 8-44. Then reset the BGP table.
Example 8-44. No Synchronization
r1(config)#router bgp 65520 r1(config-router)#no synchronization r1(config-router)#end r1#copy running-config startup-config !!!no synch is short for no synchronization r2(config)#router bgp 65520 r2(config-router)#no synch r2(config-router)#end r2#copy running-config startup-config r4(config)#router bgp 65520 r4(config-router)#no synch r4(config-router)#end r4#copy running-config startup-config r1#clear ip bgp * |
A word of caution before you perform more testing: For an IBGP peer to propagate routes to another IBGP peer, or EBGP peer for that matter, full-mesh connectivity is required. That is not too scalable in the practical service provider world, so they tend to use route reflectors or confederations for this purpose. Route reflectors allow routes to bounce or reflect from one IBGP peer to another. You can think of them as rubber routers if you like. Confederations are like mini-autonomous systems to make all neighbors appear as if they are EBGP so that there are no IBGP issues.
Instead of having every router peer with every router for a full-mesh topology, set up r1 as a route reflector to clients r2 and r4 (IBGP peers) as in Example 8-45. This time reset BGP for only the affected peers.
Example 8-45. Configuring r1 as a Route Reflector
r1(config)#router bgp 65520 r1(config-router)#neighbor 192.168.8.2 route-reflector-client r1(config-router)#neighbor 192.168.8.4 route-reflector-client r1(config-router)#end r1#clear ip bgp 192.168.8.2 r1#clear ip bgp 192.168.8.4 r1#copy running-config startup-config |
Test your hybrid point-to-point multipoint hub-and-spoke topology in Example 8-46.
Example 8-46. Testing the Hub and Spokes
!!!r1 pings r2 r1#ping 192.168.8.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms !!!r1 pings r4 r1#p 192.168.8.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms !!!r2 pings r1 r2>p 192.168.8.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms !!!r2 pings r4 r2>p 192.168.8.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) !!!r2 pings r5 r2#p 172.16.8.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.8.6, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) |
NOTE
On many devices, p is a shortcut for ping.
Compare the output of the last couple of examples to Figure 8-13 to determine the problems. Recall back in Example 8-43 that there were no BGP learned routes in r1, r2, and r4. Even after you turn synchronization off in Example 8-44, these routes do not appear in either the BGP or routing table because the 172.16.8.4/30 prefix has not been advertised. That is a very likely reason as to why r2 can't ping r5 in Example 8-46. Fix this in Example 8-47.
Example 8-47. Advertising the 172.16.8.4 Network
r1(config)#router bgp 65520 r1(config-router)#network 172.16.8.4 mask 255.255.255.252 r1(config-router)#end r1#copy running-config startup-config r1#clear ip bgp * r1#show ip bgp r1#show ip bgp r1#show ip bgp |
Note that in the preceding example the mask had to be typed in for the network statement because it differs from the classful mask. It is easy to forget to type the word mask, but in the Cisco software you can always rely on the question mark (?) for help.
NOTE
You must have patience to support BGP. Everything is manual in operation, and although convergence is relatively fast, sometimes things just take a little more time to appear than what you would expect. That is why you see an empty BGP table in Example 8-47; get used to the Up Arrow key to repeat the last command.
It is important to not configure the network statement on each and every router like you are used to with an IGP routing protocol. Remember that BGP is an EGP. You manually configure your neighbors and don't need a network statement for adjacency to occur. In an example like Figure 8-13, however, it was pretty important to advertise the 192.168.8.0 network out to the other AS and vice versa. Static and default routes would probably have been more appropriate if you were running another IGP inside AS 65520 or if you had multiple networks involved.
Advertising the 172.16.8.4 network into AS 65520 should allow r2 and r4 to be able to ping r5 in the remote AS. First look at the BGP table on r1 in Example 8-48, then look at the BGP and routing tables on r2 to see whether this is in fact possible. Verify with ping.
Example 8-48. Testing the Network Advertisement
r1>show ip bgp BGP table version is 3, local router ID is 192.168.8.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.8.4/30 0.0.0.0 0 32768 i *> 192.168.8.0 0.0.0.0 0 32768 i r2>show ip bgp BGP table version is 13, local router ID is 192.168.8.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i172.16.8.4/30 192.168.8.1 0 100 0 i *>i192.168.8.0 192.168.8.1 0 100 0 i r2>show ip route ... C 192.168.8.0/24 is directly connected, Serial0.101 172.16.0.0/30 is subnetted, 1 subnets B 172.16.8.4 [200/0] via 192.168.8.1, 00:06:15 !!!r2 pings r5 via EBGP r2>ping 172.16.8.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.8.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/120 ms !!!r2 pings r4 via IBGP r2>ping 192.168.8.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) |
Example 8-48 shows how r2 can now reach r5 via EBGP, yet it can't reach r4 via IBGP. The remaining issue is that the spoke routers can reach the hub (r1) but not each other. Do not be so quick to blame this one on BGP, although it appears that everything is working except the route reflectors. By definition the IBGP routes from r2 should bounce off of r1 to r4 and vice versa. That is not happening here; the ping fails from r2 to r4. Review the examples throughout this Trouble Ticket and Figure 8-13 for some hints.
This is a Frame Relay issue because now you want DC to talk to VA and VA to talk to DC through HQ. This was not a requirement in any of the chapter scenarios or Trouble Tickets thus far. Currently, there are no physical or logical connections between DC and VA. Program your spoke routers in Example 8-49 so that the remote sites can talk to one another.
Example 8-49. Configuring Static Maps for the Spoke Routers
r2#show frame-relay map Serial0.101 (up): ip 192.168.8.1 dlci 101(0x65,0x1850), dynamic, broadcast,, status defined, active r2#configure terminal r2(config)#interface s0.101 r2(config-subif)#frame map ip 192.168.8.1 101 broadcast r2(config-subif)#frame map ip 192.168.8.4 101 broadcast r2(config-subif)#end !!!remove any extraneous dynamic mappings r2#clear frame-relay-inarp r2#copy running-config startup-config r4#configure terminal r4(config)#interface s0/0.101 r4(config-subif)#frame map ip 192.168.8.1 101 broadcast r4(config-subif)#frame map ip 192.168.8.2 101 broadcast r4(config-subif)#end !!!the next command is short for clear frame-relay-inarp r4#clear frame r4#copy running-config startup-config |
Look at the Inverse ARP table on r2 and r4. Verify connectivity as in Example 8-50.
Example 8-50. Testing the Spoke Routers
r2#show frame-relay map Serial0.101 (up): ip 192.168.8.1 dlci 101(0x65,0x1850), static, broadcast, CISCO, status defined, active Serial0.101 (up): ip 192.168.8.4 dlci 101(0x65,0x1850), static, broadcast, CISCO, status defined, active r2#ping 192.168.8.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/118/128 ms r4#ping 192.168.8.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.8.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/116/124 ms r2#show ip bgp sum BGP router identifier 192.168.8.2, local AS number 65520 BGP table version is 3, main routing table version 3 2 network entries and 2 paths using 242 bytes of memory 1 BGP path attribute entries using 96 bytes of memory BGP activity 2/0 prefixes, 2/0 paths Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.8.1 4 65520 23 21 3 0 0 00:18:37 2 |
Having a route to get to your destination and the physical transport, too, is obviously pretty important. Originally you set up your Frame Relay connection with a PVC from HQ to DC and VA as well as another from HQ to the other AS using multipoint subinterfaces. However, you were relying on Inverse ARP to get you through r1 to the other IBGP peer. Instead you needed not only the route reflector configuration but static map statements, too.
NOTE
Patience is the answer for BGP any way you configure it. I am not undermining it by any means, but from a support standpoint, take time for a cup of tea and check your configurations again. Always remember to use clear ip bgp with a specific address where possible every time you make a change. On the other hand, check those layers.
Now that things are working all the way up the stack, glimpse at the BGP updates as in Example 8-51 so that you see what is going on when you issue clear ip bgp *. Feel free to show the clock periodically to see the timing of things or just look at the time and date stamps from the service timestamps debug output that you previously configured.
Example 8-51. BGP Routing Updates
r1#debug ip bgp updates BGP updates debugging is on r1#show clock 22:08:39.825 UTC Fri Dec 13 2002 r1#clear ip bgp * Dec 13 22:09:08.113: BGP: 192.168.8.2 computing updates, neighbor version 0, table version 1, starting at 0.0.0.0 Dec 13 22:09:08.117: BGP: 192.168.8.2 update run completed, ran for 0ms, neighbor version 0, start version 1, throttled to 1, check point net 0.0.0.0 Dec 13 22:09:08.121: BGP: 192.168.8.4 computing updates, neighbor version 0, table version 1, starting at 0.0.0.0 Dec 13 22:09:08.125: BGP: 192.168.8.4 update run completed, ran for 0ms, neighbor version 0, start version 1, throttled to 1, check point net 0.0.0.0 Dec 13 22:09:29.681: BGP: 172.16.8.6 computing updates, neighbor version 0, table version 1, starting at 0.0.0.0 Dec 13 22:09:29.685: BGP: 172.16.8.6 update run completed, ran for 0ms, neighbor version 0, start version 1, throttled to 1, check point net 0.0.0.0 Dec 13 22:09:57.957: BGP: nettable_walker 172.16.8.4/30 route sourced locally Dec 13 22:09:57.961: BGP: nettable_walker 192.168.8.0/24 route sourced locally Dec 13 22:09:57.961: BGP: 192.168.8.2 computing updates, neighbor version 1, table version 3, starting at 0.0.0.0 Dec 13 22:09:57.965: BGP: 192.168.8.2 send UPDATE 172.16.8.4/30, next 192.168.8.1, metric 0, path Dec 13 22:09:57.969: BGP: 192.168.8.2 send UPDATE 192.168.8.0/24 (chgflags: 0x8), next 192.168.8.1, path (before routemap/aspath update) Dec 13 22:09:57.977: BGP: 192.168.8.2 1 updates enqueued (average=60, maximum=60) Dec 13 22:09:57.977: BGP: 192.168.8.2 update run completed, ran for 12ms, neighbor version 1, start version 3, throttled to 3, check point net 0.0.0.0 Dec 13 22:09:57.981: BGP: 192.168.8.4 computing updates, neighbor version 1, table version 3, starting at 0.0.0.0 Dec 13 22:09:57.985: BGP: 192.168.8.4 send UPDATE 172.16.8.4/30, next 192.168.8.1, metric 0, path Dec 13 22:09:57.993: BGP: 192.168.8.4 send UPDATE 192.168.8.0/24 (chgflags: 0x8), next 192.168.8.1, path (before routemap/aspath update) Dec 13 22:09:57.997: BGP: 192.168.8.4 1 updates enqueued (average=60, maximum=60) Dec 13 22:09:58.001: BGP: 192.168.8.4 update run completed, ran for 12ms, neighbor version 1, start version 3, throttled to 3, check point net 0.0.0.0 Dec 13 22:09:59.101: BGP: 172.16.8.6 computing updates, neighbor version 1, table version 3, starting at 0.0.0.0 Dec 13 22:09:59.105: BGP: 172.16.8.6 send UPDATE 172.16.8.4/30, next 172.16.8.5, metric 0, path 65520 Dec 13 22:09:59.109: BGP: 172.16.8.6 send UPDATE 192.168.8.0/24 (chgflags: 0x8), next 172.16.8.5, path (before routemap/aspath update) Dec 13 22:09:59.117: BGP: 172.16.8.6 1 updates enqueued (average=57, maximum=57) Dec 13 22:09:59.117: BGP: 172.16.8.6 update run completed, ran for 12ms, neighbor version 1, start version 3, throttled to 3, check point net 0.0.0.0 r1#undebug all |
After you have watched the BGP routing update process for a few minutes, you should have a couple of occurrences of the nettable walker process. It runs about every minute to populate the routing table from the BGP table. Save your configurations to a file named tt1 bgp configs.
Congratulations. You have successfully configured BGP over Frame Relay NBMA.
Trouble Ticket 2 Solution
Assuming you are continuing from the preceding Trouble Ticket, first remove BGP and configure the loopbacks in Example 8-52.
Example 8-52. Removing BGP and Configuring Loopback Addresses
r1(config)#no router bgp 65520 r1(config)#interface loopback 8 r1(config-if)#ip address 1.1.1.1 255.255.255.0 r1(config-if)#no shut r1(config-if)#end r1#show ip protocols r2(config)#no router bgp 65520 !!!lo8 is short for loopback 8 r2(config)#interface lo8 r2(config-if)#ip address 2.2.2.2 255.255.255.0 r2(config-if)#no shut r2(config-if)#end r2#show ip protocols r4(config)#no router bgp 65520 r4(config)#interface lo8 r4(config-if)#ip address 4.4.4.4 255.255.255.0 r4(config-if)#no shut r4(config-if)#end r4#show ip protocols r5(config)#no router bgp 65525 r5(config)#interface lo8 r5(config-if)#ip address 5.5.5.5 255.255.255.0 r5(config-if)#no shut r5(config-if)#end r5#show ip protocols |
Now that you have completely removed BGP and verified that with the old-faithful show ip protocols command, configure OSPF, including the loopbacks, as in Example 8-53.
Example 8-53. Configuring OSPF
r1(config)#router ospf 1 r1(config-router)#network 192.168.8.0 0.0.0.255 area 8 r1(config-router)#network 1.1.1.0 0.0.0.255 area 8 r1(config-router)#end r1#copy running-config startup-config r2(config)#router ospf 1 r2(config-router)#network 192.168.8.0 0.0.0.255 area 8 r2(config-router)#network 2.2.2.0 0.0.0.255 area 8 r2(config-router)#end r2#copy running-config startup-config r4(config)#router ospf 1 r4(config-router)#network 192.168.8.0 0.0.0.255 area 8 r4(config-router)#network 4.4.4.0 0.0.0.255 area 8 r4(config-router)#end r4#copy running-config startup-config |
Verify OSPF connectivity between the routers in network 192.168.8.0 as in Example 8-54.
Example 8-54. Verifying OSPF
r1#show ip ospf neighbor r1#!!!no neighbors so no sense in looking for routes r1#show ip ospf interface s0 r1#!!!appears that opsf not configured on int s0 r1#show run ... interface Loopback8 ip address 1.1.1.1 255.255.255.0 no ip directed-broadcast ... router ospf 1 network 1.1.1.0 0.0.0.255 area 8 network 192.168.8.0 0.0.0.255 area 8 end r1#clear ip ospf process Reset ALL OSPF processes? [no]: y r1#show ip ospf interface Loopback8 is up, line protocol is up Internet Address 1.1.1.1/24, Area 8 Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host Serial0.100 is up, line protocol is up Internet Address 192.168.8.1/24, Area 8 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 1562 Transmit Delay is 1 sec, State WAITING, Priority 1 No designated router on this network No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:18 Wait time before Designated router selection 00:01:39 Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) r1# |
For better or worse, I assume Layer 2 is alright because you just finished the preceding Trouble Ticket. Like Example 8-54 illustrates, the next step is to see whether you have any OSPF neighbors and if not, why not. Next I checked to make sure OSPF was configured on the interface with the show ip ospf interface command, but actually I just looked at s0. Alternatively, you could use show run. It looks like things are configured properly, so I issued a clear ip ospf process and, sure enough, that did the trick. Well, almost. Look back at the output of show ip ospf interface to find the real issue and fix it as in Example 8-55.
Example 8-55. OSPF Neighbors
r1#show ip ospf neighbor r1#configure terminal r1(config)#router ospf 1 r1(config-router)#neighbor 192.168.8.2 ? cost OSPF cost for point-to-multipoint neighbor database-filter Filter OSPF LSA during synchronization and flooding for point-to-multipoint neighbor poll-interval OSPF dead-router polling interval priority OSPF priority of non-broadcast neighbor <cr> r1(config-router)#neighbor 192.168.8.2 r1(config-router)#neighbor 192.168.8.4 r1(config-router)#end r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface N/A 0 ATTEMPT/DROTHER 00:01:48 192.168.8.4 Serial0.100 N/A 0 ATTEMPT/DROTHER 00:01:46 192.168.8.2 Serial0.100 r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface N/A 0 ATTEMPT/DROTHER 00:01:44 192.168.8.4 Serial0.100 2.2.2.2 1 FULL/DR 00:01:58 192.168.8.2 Serial0.100 r1#!!!things are starting to happen now r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface N/A 0 ATTEMPT/DROTHER 00:01:40 192.168.8.4 Serial0.100 2.2.2.2 1 FULL/DR 00:01:59 192.168.8.2 Serial0.100 r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 1 FULL/DR 00:01:59 192.168.8.4 Serial0.100 2.2.2.2 1 FULL/DROTHER 00:01:56 192.168.8.2 Serial0.100 r1#show ip ospf neighbor detail Neighbor 4.4.4.4, interface address 192.168.8.4 In the area 8 via interface Serial0.100 Neighbor priority is 1, State is FULL, 7 state changes DR is 192.168.8.4 BDR is 192.168.8.1 Poll interval 60 Options 2 Dead timer due in 00:01:32 Neighbor 2.2.2.2, interface address 192.168.8.2 In the area 8 via interface Serial0.100 Neighbor priority is 1, State is FULL, 7 state changes DR is 192.168.8.2 BDR is 192.168.8.1 Poll interval 60 Options 2 Dead timer due in 00:01:54 |
Yes, there are issues with running OSPF over Frame Relay NBMA, as mentioned earlier in the chapter. Personally, I would rather just configure point-to-point subinterfaces and be done with it, but there are workarounds. One method is to manually specify the neighbor statements. Notice that I only configured the neighbor statement on one end. However, it is a much better practice to configure the neighbor statements on both ends so as not to leave anything to chance. Speaking of leaving anything to chance, you do not have a full-mesh configuration here, so it is pretty important that the hub router be the DR. Force r1 to be the DR for the serial interfaces by making the other routers ineligible to become the DR as in Example 8-56. Configure the other neighbor statements while you are at it. Watch the election process on r4.
Example 8-56. Forcing r1 to Become the DR
r2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 00:01:45 192.168.8.1 Serial0.101 r2#configure terminal r2(config)#router ospf 1 r2(config-router)#neighbor 192.168.8.1 r2(config-router)#interface s0.101 r2(config-subif)#ip ospf priority 0 r2(config-subif)#end r4#configure terminal r4(config)#router ospf 1 r4(config-router)#neighbor 192.168.8.1 r4(config-router)#interface s0/0.101 r4(config-subif)#ip ospf priority 0 r4(config-subif)#end r4#debug ip ospf adj OSPF adjacency events debugging is on Dec 13 23:37:18.150: OSPF: Rcv hello from 1.1.1.1 area 8 from Serial0/0.101 192.168.8.1 Dec 13 23:37:18.150: OSPF: Neighbor change Event on interface Serial0/0.101 Dec 13 23:37:18.154: OSPF: DR/BDR election on Serial0/0.101 Dec 13 23:37:18.154: OSPF: Elect BDR 1.1.1.1 Dec 13 23:37:18.154: OSPF: Elect DR 1.1.1.1 Dec 13 23:37:18.154: DR: 1.1.1.1 (Id) BDR: 1.1.1.1 (Id) Dec 13 23:37:18.154: OSPF: Send DBD to 1.1.1.1 on Serial0/0.101 seq 0xFDD opt 0x2 flag 0x7 len 32 Dec 13 23:37:18.154: OSPF: End of hello processing Dec 13 23:37:18.190: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0.101 seq 0xDB6 opt 0x2 flag 0x7 len 32 state EXSTART Dec 13 23:37:18.190: OSPF: First DBD and we are not SLAVE Dec 13 23:37:18.654: OSPF: Build router LSA for area 8, router ID 4.4.4.4 Dec 13 23:37:23.154: OSPF: Retransmitting DBD to 1.1.1.1 on Serial0/0.101 Dec 13 23:37:23.154: OSPF: Send DBD to 1.1.1.1 on Serial0/0.101 seq 0xFDD opt 0x2 flag 0x7 len 32 Dec 13 23:37:23.190: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0.101 seq 0xDB6 opt 0x2 flag 0x7 len 32 state EXSTART Dec 13 23:37:23.190: OSPF: First DBD and we are not SLAVE Dec 13 23:37:23.222: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0.101 seq 0xFDD opt 0x2 flag 0x2 len 132 state EXSTART Dec 13 23:37:23.222: OSPF: NBR Negotiation Done. We are the MASTER Dec 13 23:37:23.222: OSPF: Send DBD to 1.1.1.1 on Serial0/0.101 seq 0xFDE opt 0x2 flag 0x3 len 132 Dec 13 23:37:23.286: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0.101 seq 0xFDE opt 0x2 flag 0x0 len 32 state EXCHANGE Dec 13 23:37:23.286: OSPF: Send DBD to 1.1.1.1 on Serial0/0.101 seq 0xFDF opt 0x2 flag 0x1 len 32 Dec 13 23:37:23.322: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0.101 seq 0xFDF opt 0x2 flag 0x0 len 32 state EXCHANGE Dec 13 23:37:23.326: OSPF: Exchange Done with 1.1.1.1 on Serial0/0.101 Dec 13 23:37:23.326: OSPF: Synchronized with 1.1.1.1 on Serial0/0.101, state FULL Dec 13 23:37:23.654: OSPF: Build router LSA for area 8, router ID 4.4.4.4 Dec 13 23:37:28.654: OSPF: Build router LSA for area 8, router ID 4.4.4.4 r4#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DR 00:01:46 192.168.8.1 Serial0/0.101 Dec 13 23:37:48.270: OSPF: Rcv hello from 1.1.1.1 area 8 from Serial0/0.101 192.168.8.1 Dec 13 23:37:48.270: OSPF: Neighbor change Event on interface Serial0/0.101 Dec 13 23:37:48.270: OSPF: DR/BDR election on Serial0/0.101 Dec 13 23:37:48.270: OSPF: Elect BDR 0.0.0.0 Dec 13 23:37:48.274: OSPF: Elect DR 1.1.1.1 Dec 13 23:37:48.274: DR: 1.1.1.1 (Id) BDR: none Dec 13 23:37:48.274: OSPF: End of hello processing Dec 13 23:37:48.774: OSPF: Build router LSA for area 8, router ID 4.4.4.4 r4#undebug all r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 0 FULL/DROTHER 00:01:46 192.168.8.4 Serial0.100 2.2.2.2 0 FULL/DROTHER 00:01:38 192.168.8.2 Serial0.100 |
Observe the preceding output of show ip ospf neighbor on each of the routers to note that both r2 and r4 are in a full state with the DR (r1). Likewise, from r1's perspective it is in a full state with the DRothers. The clear ip ospf process command was not necessary here because changing the priority to 0 forced the election to occur. Had you set r1 with a higher priority, clearing the OSPF process or bouncing the interface would have been an effective way to trigger the election. However, on r4 the version of code doesn't support the clear ip ospf command anyway. The debug ip ospf adj command enabled you to watch the stages of the election process.
I find it more helpful for troubleshooting to manually configure the router ID (RID). In the preceding example, the loopbacks should take precedence unless OSPF was configured before you created them. The problem with making changes to the RID is that it normally doesn't take effect until you reload the router (or restart the OSPF process). I can get away with that in a test environment, but that is not always a choice in a practical environment. Example 8-57 illustrates how to hard code the RIDs.
Example 8-57. Hard Coding the RIDs
r1(config)#router ospf 1 r1(config-router)#router-id ? A.B.C.D OSPF router-id in IP address format r1(config-router)#router-id 1.1.1.1 Reload or use "clear ip ospf process" command, for this to take effect r1(config-router)#end r1#copy running-config startup-config r2(config)#router ospf 1 r2(config-router)#router-id 2.2.2.2 Reload or use "clear ip ospf process" command, for this to take effect r2(config-router)#end r2#copy running-config startup-config r4(config)#router ospf 1 r4(config-router)#router-id 4.4.4.4 ^ % Invalid input detected at '^' marker. r4(config-router)#end r4#show ver Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3620-D-M), Version 11.3(9)T, RELEASE SOFTWARE (fc1) r4#!!!ios version issue |
After hard coding the RID in Example 8-57, the IOS told you to reload or clear the OSPF process for the new RID to take effect. Alternatively, you could try a no router ospf 1 instead in cases where the IOS version does not support the clear ip ospf process command. Review your neighbors and OSPF tables in Example 8-58 after your OSPF processes reset.
Example 8-58. Viewing OSPF Neighbors, Processes, and Databases
r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 0 FULL/DROTHER 00:01:44 192.168.8.4 Serial0.100 2.2.2.2 0 FULL/DROTHER 00:01:48 192.168.8.2 Serial0.100 r2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DR 00:01:57 192.168.8.1 Serial0.101 r4#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DR 00:01:52 192.168.8.1 Serial0/0.101 r4#show ip ospf neighbor detail Neighbor 1.1.1.1, interface address 192.168.8.1 In the area 8 via interface Serial0/0.101 Neighbor priority is 1, State is FULL DR is 192.168.8.1 BDR is 0.0.0.0 Poll interval 60 Options 2 Dead timer due in 00:01:48 r4> r1#show ip ospf Routing Process "ospf 1" with ID 1.1.1.1 Supports only single TOS(TOS0) routes SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x0 Number of DCbitless external LSA 0 Number of DoNotAge external LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Area 8 Number of interfaces in this area is 2 Area has no authentication SPF algorithm executed 4 times Area ranges are Number of LSA 7. Checksum Sum 0x30C32 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 r1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 8) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 711 0x80000002 0x1FF1 2 2.2.2.2 2.2.2.2 706 0x80000008 0x3FA 2 4.4.4.4 4.4.4.4 195 0x8000000A 0xDE03 2 Net Link States (Area 8) Link ID ADV Router Age Seq# Checksum 192.168.8.1 1.1.1.1 711 0x80000001 0xE4BE |
The first shaded output shows the new RID in the Neighbor ID column, then the neighbor priority, the DR state, the timers, and the actual neighbor interface address is listed in the Address column with the corresponding neighbor interface to the right. After I analyzed the neighbors, I looked at how OSPF was configured with show ip ospf and the link-state database with show ip ospf database. With serial interfaces, each interface is considered a link rather than just the wire between them, which is why you see two links in the database for each address. When supporting OSPF, you must have neighbors and link states before you get any OSPF routes in your routing table.
Next configure a default route in Example 8-59 on r1 to get to the outside world (meaning the other AS). Have OSPF advertise a default route to r2 and r4 as in Example 8-58, but do not configure a default route on r2 and r4 themselves.
Example 8-59. Configuring a Default Route on r1
r1#configure terminal r1(config)#ip route 0.0.0.0 0.0.0.0 s0.105 r1(config)#end r1#copy running-config startup-config r1#show ip route ... Gateway of last resort is 0.0.0.0 to network 0.0.0.0 1.0.0.0/24 is subnetted, 1 subnets C 1.1.1.0 is directly connected, Loopback8 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1563] via 192.168.8.2, 00:12:22, Serial0.100 C 192.168.8.0/24 is directly connected, Serial0.100 4.0.0.0/32 is subnetted, 1 subnets O 4.4.4.4 [110/1563] via 192.168.8.4, 00:12:22, Serial0.100 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.105 S* 0.0.0.0/0 is directly connected, Serial0.105 |
You configured the default route on r1 to send all unknown packets out interface s0.105. This resulted in setting the gateway of last resort and the S* entry in the routing table. Although r1 now has a route to get to the other networks, the remote devices do not have a return route. Now have r1 advertise a default route via OSPF into the spoke routers r2 and r4 in Example 8-60.
Example 8-60. Advertising Default Routes into the Spoke Routers
r1#configure terminal r1(config)#router ospf 1 r1(config-router)#default-information originate ? always Always advertise default route metric OSPF default metric metric-type OSPF metric type for default routes route-map Route-map reference <cr> r1(config-router)#default-information originate always r1(config-router)#end r1#copy running-config startup-config r1#clear ip ospf process Reset ALL OSPF processes? [no]: y |
View the OSPF external routes (E2) in the routing tables of r2 and r4, as in Example 8-61.
Example 8-61. Advertising Default Routes into the Spoke Routers
r2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is 192.168.8.1 to network 0.0.0.0 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/1563] via 192.168.8.1, 00:00:15, Serial0.101 2.0.0.0/24 is subnetted, 1 subnets C 2.2.2.0 is directly connected, Loopback8 C 192.168.8.0/24 is directly connected, Serial0.101 4.0.0.0/32 is subnetted, 1 subnets O 4.4.4.4 [110/1563] via 192.168.8.4, 00:00:15, Serial0.101 O*E2 0.0.0.0/0 [110/1] via 192.168.8.1, 00:00:15, Serial0.101 r4#show ip route ... Gateway of last resort is 192.168.8.1 to network 0.0.0.0 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/1563] via 192.168.8.1, 00:02:07, Serial0/0.101 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1563] via 192.168.8.2, 00:02:07, Serial0/0.101 C 192.168.8.0/24 is directly connected, Serial0/0.101 4.0.0.0/24 is subnetted, 1 subnets C 4.4.4.0 is directly connected, Loopback8 O*E2 0.0.0.0/0 [110/1] via 192.168.8.1, 00:02:07, Serial0/0.101 |
Now that the spoke routers have learned a default route via OSPF, they should be able to ping outside of the specific networks in their routing tables. Ping is a two-way street, however, and you need to make sure the echo replies can return. Therefore, in Example 8-62 configure a static route on r5 to get to the 192.168.8.0 network using r1 as the next hop before you start your ping testing.
Example 8-62. Configuring a Static Route on r5
r5#configure terminal r5(config)#ip route 192.168.8.0 255.255.255.0 172.16.8.5 r5(config)#end r5#show ip route ... Gateway of last resort is not set S 192.168.8.0/24 [1/0] via 172.16.8.5 5.0.0.0/24 is subnetted, 1 subnets C 5.5.5.0 is directly connected, Loopback8 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.101 |
Fix any other issues, save your configurations, and test things out using the loopbacks as in Example 8-63.
Example 8-63. Testing the OSPF Configurations
r1#copy running-config startup-config r1#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms r1#ping 4.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/60 ms r1#p 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/60 ms r2#copy running-config startup-config r2#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms r2#ping 4.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/118/128 ms r2#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/116 ms r4#copy running-config startup-config r4#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/60 ms r4#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/118/128 ms r4#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/116 ms r5#copy running-config startup-config r5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) |
Looks like everything is fine until you get to r5. Analyze the routing table, fix the problem, and continue testing in Example 8-64.
Example 8-64. Analyzing, Fixing, and Testing r5
r5#show ip route Gateway of last resort is not set S 192.168.8.0/24 [1/0] via 172.16.8.5 5.0.0.0/24 is subnetted, 1 subnets C 5.5.5.0 is directly connected, Loopback8 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.101 r5#configure terminal r5(config)#ip route 0.0.0.0 0.0.0.0 s0.101 r5(config)#end r5#show ip route Gateway of last resort is 0.0.0.0 to network 0.0.0.0 S 192.168.8.0/24 [1/0] via 172.16.8.5 5.0.0.0/24 is subnetted, 1 subnets C 5.5.5.0 is directly connected, Loopback8 172.16.0.0/30 is subnetted, 1 subnets C 172.16.8.4 is directly connected, Serial0.101 S* 0.0.0.0/0 is directly connected, Serial0.101 r5#show ip protocols r5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms r5#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/120 ms r5#ping 4.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/113/116 ms |
You would have been successful had you used the 192.168.8.0 network for your ping tests. Remember that r5 is not running a routing protocol at all and is relying on static and default routes to get to the couple of networks it needs to communicate with. In Example 8-65, perform a traceroute from r5 to r4 to see once again how the frame switch is transparent to routing.
Example 8-65. Trace from r5 to r4
r5#trace 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
1 172.16.8.5 28 msec 28 msec 28 msec
2 192.168.8.4 56 msec 56 msec *
|
Save your configurations to a file named tt2 ospf configs.
Congratulations. You have successfully configured OSPF over Frame Relay NBMA using static neighbor statements.
Trouble Ticket 3 Solution
Instead of using static neighbor statements in the preceding Trouble Ticket, you could have configured the ip ospf network type as in Example 8-66.
Example 8-66. Configuring the ip ospf network Type
r1(config)#router ospf 1 r1(config-router)#no neighbor 192.168.8.2 r1(config-router)#no neighbor 192.168.8.4 r1(config)#end r1#configure terminal r1(config)#interface s0.100 r1(config-subif)#ip ospf network ? broadcast Specify OSPF broadcast multi-access network non-broadcast Specify OSPF NBMA network point-to-multipoint Specify OSPF point-to-multipoint network point-to-point Specify OSPF point-to-point network r1(config-subif)#ip ospf network point-to-multipoint r1(config-subif)#end r1#copy running-config startup-config r2#configure terminal r2(config)#router ospf 1 r2(config-router)#no neighbor 192.168.8.1 r2#configure terminal r2(config)#interface s0.101 r2(config-subif)#ip ospf network point-to-multipoint r2(config-subif)#end r2#copy running-config startup-config r4#configure terminal r4(config)#router ospf 1 r4(config-router)#no neighbor 192.168.8.1 r4#configure terminal r4(config)#interface s0/0.101 r4(config-subif)#ip ospf network point-to-multipoint r4(config-subif)#end r4#copy running-config startup-config |
First I removed the static neighbor statements and then added the ip ospf network point-to-point command to r1, r2, and r4. This is not necessary on r5 because it has a point-to-point subinterface rather than multipoint. Verify your OSPF neighbors and ensure your pings still work as in Example 8-67.
Example 8-67. Verifying OSPF Neighbors
r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 0 FULL/ - 00:01:59 192.168.8.2 Serial0.100 4.4.4.4 0 FULL/ - 00:01:59 192.168.8.4 Serial0.100 |
Using this method does not require manual neighbor statements or a DR/BDR election. All ping tests should succeed. During this Trouble Ticket, I made a mistake and created an extraneous subinterface. Remove it in Example 8-68.
Example 8-68. Deleting a Subinterface
r1#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset administratively down down Ethernet1 unassigned YES unset administratively down down Loopback8 1.1.1.1 YES NVRAM up up Serial0 unassigned YES unset up up Serial0.100 192.168.8.1 YES NVRAM up up Serial0.101 unassigned YES unset up up Serial0.105 172.16.8.5 YES NVRAM up up Serial1 unassigned YES unset administratively down down r1#configure terminal r1(config-if)#no interface s0.101 % Not all config may be removed and may reappear after reactivating the sub-interface r1(config)#end r1#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset administratively down down Ethernet1 unassigned YES unset administratively down down Loopback8 1.1.1.1 YES NVRAM up up Serial0 unassigned YES unset up up Serial0.100 192.168.8.1 YES NVRAM up up Serial0.101 unassigned YES unset deleted down Serial0.105 172.16.8.5 YES NVRAM up up Serial1 unassigned YES unset administratively down down r1#copy running-config startup-config r1#reload Proceed with reload? [confirm] 01:09:21: %SYS-5-RELOAD: Reload requested ... r1>show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset administratively down down Ethernet1 unassigned YES unset administratively down down Loopback8 1.1.1.1 YES NVRAM up up Serial0 unassigned YES unset up up Serial0.100 192.168.8.1 YES NVRAM up up Serial0.105 172.16.8.5 YES NVRAM up up Serial1 unassigned YES unset administratively down down |
The moral of this story is that you have to reload the router to completely get rid of the unwanted subinterface. Save your configurations to a file named tt3 ospf configs.
Trouble Ticket 4 Solution
Example 8-69 starts by making sure all DLCIs are active before any changes are made. Shut down the serial interfaces on r3 (the frame switch) and observe the results.
Example 8-69. Observing Service Provider Issues with the Frame Switch Shut Down
r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (up): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, active frameswitch#configure terminal frameswitch(config)#interface s0/0 frameswitch(config-if)#shut frameswitch(config-if)#interface s0/1 frameswitch(config-if)#shut frameswitch(config-if)#interface s0/2 frameswitch(config-if)#shut frameswitch(config-if)#interface s0/3 frameswitch(config-if)#shut r1#show frame-relay map Serial0.100 (down): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status deleted Serial0.100 (down): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status deleted Serial0.105 (down): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status deleted r2#show frame-relay map Serial0.101 (down): ip 192.168.8.1 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted Serial0.101 (down): ip 192.168.8.4 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted |
Notice how I tested to make sure things worked to begin with before I started experimenting. The key word here is deleted. This is a service provider issue. The DLCIs were once there but no longer are or perhaps they were never configured. Bring only the s0/0 interface up and observe the results in Example 8-70.
Example 8-70. Observing Service Provider Issues with s0/0 Up
frame-switch(config)#interface s0/0 frame-switch(config-if)#no shut frame-switch(config-if)#end !!!first look at the r1 end for dlci 102 r1#show frame-relay map Serial0.100 (down): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, inactive Serial0.100 (down): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, inactive Serial0.105 (down): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, inactive !!!then look at the r2 end for the same pvc r2#show frame-relay map Serial0.101 (down): ip 192.168.8.1 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted Serial0.101 (down): ip 192.168.8.4 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted |
The effect of bringing up the s0/0 interface on the frame switch changed the DLCI to an inactive state on the local r1 side. However, the other end of the PVC on r2 is still deleted. Make sure you bring all the interfaces up again before you start the next Trouble Ticket.
Trouble Ticket 5 Solution
First you should play the role of the service provider and mix up the DLCIs as in Example 8-71. Remove the correct route statement and then route what comes in the r3 interface s0/1 as DLCI 102 out the s0/0 interface as DLCI 101.
Example 8-71. Misconfiguring the DLCIs
frame-switch#configure terminal frame-switch(config)#interface s0/1 frame-switch(config-if)#no frame route 101 interface s0/0 102 frame-switch(config-if)#frame route 102 interface s0/0 101 !!!first look at the frame switch for dlci 102 frame-switch#show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0/0 102 Serial0/1 101 inactive Serial0/0 104 Serial0/2 101 active Serial0/0 105 Serial0/3 101 active Serial0/1 102 Serial0/0 101 inactive Serial0/2 101 Serial0/0 104 active Serial0/3 101 Serial0/0 105 active !!!now look at the r1 end for dlci 102 r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, inactive Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (up): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, active r1#show frame-relay pvc 102 PVC Statistics for interface Serial0 (Frame Relay DTE) DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0.100 input pkts 49 output pkts 45 in bytes 4108 out bytes 3944 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 pvc create time 00:13:55, last time pvc status changed 00:01:15 !!!now look at the r2 end for dlci 102 r2#show frame-relay map Serial0.101 (down): ip 192.168.8.1 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted Serial0.101 (down): ip 192.168.8.4 dlci 101(0x65,0x1850), static, broadcast, CISCO, status deleted |
The frame switch shows inactive frame routes for PVC 102. r1 shows an inactive state, too. However, r2 is more local to the problem in the cloud and shows a deleted state for DLCI 102. You know it was once there because you configured it, but something mysteriously happened in the cloud. Fix the service provider issues in Example 8-72.
Example 8-72. Fixing the Frame Route Statement in the Cloud
frame-switch(config)#interface s0/1 frame-switch(config-if)#frame route 101 interface s0/0 102 frameswitch(config-if)#no frame route 102 interface s0/0 101 frameswitch(config-if)#end r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (up): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, active r2#show frame-relay map Serial0.101 (up): ip 192.168.8.1 dlci 101(0x65,0x1850), static, broadcast, CISCO, status defined, active Serial0.101 (up): ip 192.168.8.4 dlci 101(0x65,0x1850), static, broadcast, CISCO, status defined, active |
Trouble Ticket 6 Solution
Turn on Frame Relay compression on r1 as in Example 8-73.
Example 8-73. Frame Relay Compression on r1
r1(config)#interface s0.105 r1(config-subif)#frame-relay payload-compression packet-by-packet r1(config-subif)#end r1#show frame-relay map Serial0.100 (up): ip 192.168.8.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active Serial0.100 (up): ip 192.168.8.4 dlci 104(0x68,0x1880), static, broadcast, CISCO, status defined, active Serial0.105 (up): point-to-point dlci, dlci 105(0x69,0x1890), broadcast status defined, active r1#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) r5#show frame-relay map Serial0.101 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast status defined, active r5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) |
The frame maps look fine, but mismatched compression types do not enable you to communicate. Turn compression on for r5, the other end of the PVC, as in Example 8-74.
Example 8-74. Frame Relay Compression on Both Ends of the PVC
r5#configure terminal r5(config)#interface s0.101 r5(config-subif)#frame-relay payload-compression packet-by-packet r5(config-subif)#end r5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms |
Now that things are successful, turn frame compression off as in Example 8-75.
Example 8-75. Removing Frame Relay Compression on Both Ends
r5#configure terminal r5(config)#interface s0.101 r5(config-subif)#no frame-relay payload-compression packet-by-packet r5(config-subif)#end r1#configure terminal r1(config)#interface s0.105 r1(config-subif)#no frame-relay payload-compression packet-by-packet r1(config-subif)#end !!!making sure you can ping r1#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms |
Compression works if configured the same on both ends, but many times it works best not configured at all.