Difference between revisions of "CCNP TSHOOT Learning Guide/Chapter 5"
m (→Debug ip routing) |
m (→Troubleshooting OSPF) |
||
(13 intermediate revisions by the same user not shown) | |||
Line 18: | Line 18: | ||
|- | |- | ||
|} | |} | ||
+ | == Redistribute from OSPF to EIGRP == | ||
+ | Example | ||
+ | <source lang=cli> | ||
+ | router eigrp 1 | ||
+ | redistribute ospf 100 metric 64 10000 255 1 1500 | ||
+ | </source> | ||
=IOS Commands to verify Routing Functions= | =IOS Commands to verify Routing Functions= | ||
Line 27: | Line 33: | ||
R1#<input>clear ip eigrp 1 neighbors</input> | R1#<input>clear ip eigrp 1 neighbors</input> | ||
R1# | R1# | ||
− | Jun 18 12:45:44 | + | Jun 18 12:45:44: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: <notice>Nei 10.1.2.1 (Fa0/1) is down: manually cleared</notice> |
− | Jun 18 12:45:44 | + | Jun 18 12:45:44: RT: delete route to 10.1.10.0 via 10.1.2.1, eigrp metric [90/28416] |
− | Jun 18 12:45:44 | + | Jun 18 12:45:44: RT: no routes to 10.1.10.0 |
− | Jun 18 12:45:44 | + | Jun 18 12:45:44: RT: NET-RED 10.1.10.0/24 |
<notice>...OUTPUT OMITTED...</notice> | <notice>...OUTPUT OMITTED...</notice> | ||
− | Jun 18 12:45:44 | + | Jun 18 12:45:44: RT: NET-RED 10.1.200.0/24 |
− | Jun 18 12:45:46 | + | Jun 18 12:45:46: RT: NET-RED 0.0.0.0/0 |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: <notice>Nei 10.1.2.1 (Fa0/1) is up: new adjacency</notice> |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: network 10.0.0.0 is now variably masked |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: add 10.1.10.0/24 via 10.1.2.1, eigrp metric [90/28416] |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: NET-RED 10.1.10.0/24 |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: add 10.1.20.0/24 via 10.1.2.1, eigrp metric [90/28416] |
<notice>...OUTPUT OMITTED...</notice> | <notice>...OUTPUT OMITTED...</notice> | ||
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: add 10.1.203.1/32 via 10.1.2.1, eigrp metric [90/158976] |
− | Jun 18 12:45:47 | + | Jun 18 12:45:47: RT: NET-RED 10.1.203.1/32 |
R1#<input>no debug ip routing</input> | R1#<input>no debug ip routing</input> | ||
IP routing debugging is off | IP routing debugging is off | ||
Line 63: | Line 69: | ||
3 0 0 0 0 0 | 3 0 0 0 0 0 | ||
4 0 0 0 0 0 | 4 0 0 0 0 0 | ||
− | + | <notice>...OUTPUT OMITTED...</notice> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
3905 0 0 0 0 0 | 3905 0 0 0 0 0 | ||
7030 0 0 0 0 0 | 7030 0 0 0 0 0 | ||
Line 98: | Line 81: | ||
==show ip cef== | ==show ip cef== | ||
<source lang=cli> | <source lang=cli> | ||
− | SW1#show ip cef exact-route 172.16.4.16 192.168.22.73 | + | SW1#<input>show ip cef exact-route 172.16.4.16 192.168.22.73</input> |
172.16.4.16 -> 192.168.22.73 => IP adj out of Vlan1, addr 172.16.4.16 | 172.16.4.16 -> 192.168.22.73 => IP adj out of Vlan1, addr 172.16.4.16 | ||
</source> | </source> | ||
− | + | ||
− | |||
==Route-maps== | ==Route-maps== | ||
+ | Example | ||
+ | <source lang=cli> | ||
+ | ip access-list extended ISP-CON1 | ||
+ | remark Internally used nets denied. They should be routed by the FIB | ||
+ | deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255 | ||
+ | deny ip 192.168.1.0 0.0.0.255 192.168.0.0 0.127.255.255 | ||
+ | permit ip 192.168.1.0 0.0.0.255 any | ||
+ | ! | ||
+ | ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0 | ||
+ | ! | ||
+ | route-map HETH permit 5 | ||
+ | match ip address ISP-CON1 | ||
+ | set ip next-hop 10.0.0.30 | ||
+ | ! | ||
+ | route-map HETH permit 10 | ||
+ | match ip address prefix-list DEFAULT | ||
+ | set ip next-hop 10.0.0.34 | ||
+ | </source> | ||
+ | |||
==prefix lists== | ==prefix lists== | ||
+ | Example | ||
+ | Prefix-lists are numbered. In this example "secret net" are not announced. | ||
+ | *'''Note:''' As with [[Access-list Cisco IOS|access-lists]] there are an implicit ''deny'' in the end. | ||
+ | <source lang=cli> | ||
+ | ip prefix-list SECRET-NET seq 10 deny 172.16.0.0/16 | ||
+ | ip prefix-list SECRET-NET seq 20 deny 192.168.22.0/24 | ||
+ | ip prefix-list SECRET-NET seq 30 permit 0.0.0.0/0 le 32 !Permit all other nets | ||
+ | ! | ||
+ | router bgp 100 | ||
+ | neighbor 10.1.2.3 remote-as 200 | ||
+ | neighbor 10.1.2.3 prefix-list SECRET-NET out | ||
+ | </source> | ||
+ | |||
+ | |||
{{Source cli}} | {{Source cli}} | ||
+ | |||
=Troubleshooting EIGRP= | =Troubleshooting EIGRP= | ||
EIGRP uses three tables | EIGRP uses three tables | ||
Line 114: | Line 130: | ||
! Table !! Description | ! Table !! Description | ||
|- | |- | ||
− | | Interface || Contains list of all interfaces that have been enabled for processing of EIGRP packets. Passive interfaces are ''not'' listed in this table. | + | | Interface || Contains list of all interfaces that have been enabled for processing of EIGRP packets. Passive interfaces are '''''not''''' listed in this table. |
|- | |- | ||
| Neighbor || Keeps track of all active EIGRP neighbors. Neighbours are added on the reception of hello packet and are removed when the hold-time expires or when the associated interface goes down or removed from the Interface table. This table also keeps track on status on Routing information exchanged. | | Neighbor || Keeps track of all active EIGRP neighbors. Neighbours are added on the reception of hello packet and are removed when the hold-time expires or when the associated interface goes down or removed from the Interface table. This table also keeps track on status on Routing information exchanged. | ||
Line 189: | Line 205: | ||
! Table !! Description | ! Table !! Description | ||
|- | |- | ||
− | | Interface table || List all interfaces enabled for OSPF. The directly connected subnets are included in the TYPE-1 Router LSA the Router injects into the OSPF link-state database. Passive-interfaces ''' | + | | Interface table || List all interfaces enabled for OSPF. The directly connected subnets are included in the TYPE-1 Router LSA the Router injects into the OSPF link-state database. Passive-interfaces '''''are''''' listed in the tables |
|- | |- | ||
|Neighbor table || Used to keep track of all OSPF neighbors. Neighbors are added on the reception of a hello packet and removed when the dead-time expires or when the associated interface goes down. | |Neighbor table || Used to keep track of all OSPF neighbors. Neighbors are added on the reception of a hello packet and removed when the dead-time expires or when the associated interface goes down. | ||
Line 196: | Line 212: | ||
|- | |- | ||
|Routing Information Base ||Contains results from the SPF algorithm. OSPF offers the contents of the RIB to the Routing Table. | |Routing Information Base ||Contains results from the SPF algorithm. OSPF offers the contents of the RIB to the Routing Table. | ||
+ | |} | ||
+ | == Neighbor states == | ||
+ | {|border=1 ;style="margin: 0 auto; text-align: center;cellpadding="5" cellspacing="0" | ||
+ | |+ OSPF Neighbor states | ||
+ | |- bgcolor=lightgrey | ||
+ | ! State !! Description | ||
+ | |- | ||
+ | |Attempt | ||
+ | |This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval. | ||
+ | |- | ||
+ | |Init | ||
+ | |This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet. | ||
+ | |- | ||
+ | |2-Way | ||
+ | |This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers. | ||
+ | |||
+ | At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election. | ||
+ | |||
+ | Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state. | ||
+ | |- | ||
+ | |Exstart | ||
+ | |Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR. | ||
+ | |||
+ | In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis. | ||
+ | |- | ||
+ | |Exchange | ||
+ | |In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor. | ||
+ | |- | ||
+ | |Loading | ||
+ | |In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged. | ||
+ | |- | ||
+ | |Full | ||
+ | |In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized. | ||
+ | |||
+ | Full is the normal state for an OSPF router. If a router is stuck in another state, it's an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the full state with their DR and BDR only. Neighbors always see each other as 2-way. | ||
|} | |} | ||
==INSERT TABLE 5.2 and FIGURE 5.3 from page 168 == | ==INSERT TABLE 5.2 and FIGURE 5.3 from page 168 == | ||
Line 211: | Line 262: | ||
=Troubleshooting BGP= | =Troubleshooting BGP= | ||
− | + | BGP has two maintables | |
+ | {|border=1 ;style="margin: 0 auto; text-align: center;cellpadding="5" cellspacing="0" | ||
+ | |+ BGP Tables | ||
+ | |- bgcolor=lightgrey | ||
+ | ! Table !! Description | ||
+ | |- | ||
+ | |Neighbor table|| List all neighbors configured on the router. Contains AS, state, time up/down, and how many prefixes exchanged | ||
+ | |- | ||
+ | |BGP table || Also called BGP RIB stores all locally injected routes and all routes received from neighbors/peers and routing info such as Nexthop, AS, MED, metric origin etc. | ||
+ | |} | ||
+ | ==Troubleshooting commands== | ||
+ | ===show commands=== | ||
+ | *'''show ip bgp summary''' | ||
+ | *'''show ip bgp neighbors [''ip-address'']''' | ||
+ | *'''show ip bgp ''[prefix'']''' | ||
+ | ===debug commands=== | ||
+ | *'''debug ip bgp''' | ||
+ | *'''debug ip bgp updates''' | ||
[[Category:CCNPv6]][[Category:CCNPv6 TSHOOT]] | [[Category:CCNPv6]][[Category:CCNPv6 TSHOOT]] |
Latest revision as of 11:50, 23 June 2010
Maintaining and Troubleshooting Routing Solutions
Contents
Redistributiuon
Protocol | Default Seed Metric |
---|---|
RIP | Infinity |
IGRP/EIGRP | Infinity |
OSPF | 20 except from BGP then 1 |
ISIS | 0 |
BGP | IGP |
Redistribute from OSPF to EIGRP
Example
router eigrp 1
redistribute ospf 100 metric 64 10000 255 1 1500
IOS Commands to verify Routing Functions
Verifying and Troubleshooting Route Propagation
Debug ip routing
R1#<input>debug ip routing</input>
IP routing debugging is on
R1#<input>clear ip eigrp 1 neighbors</input>
R1#
Jun 18 12:45:44: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: <notice>Nei 10.1.2.1 (Fa0/1) is down: manually cleared</notice>
Jun 18 12:45:44: RT: delete route to 10.1.10.0 via 10.1.2.1, eigrp metric [90/28416]
Jun 18 12:45:44: RT: no routes to 10.1.10.0
Jun 18 12:45:44: RT: NET-RED 10.1.10.0/24
<notice>...OUTPUT OMITTED...</notice>
Jun 18 12:45:44: RT: NET-RED 10.1.200.0/24
Jun 18 12:45:46: RT: NET-RED 0.0.0.0/0
Jun 18 12:45:47: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: <notice>Nei 10.1.2.1 (Fa0/1) is up: new adjacency</notice>
Jun 18 12:45:47: RT: network 10.0.0.0 is now variably masked
Jun 18 12:45:47: RT: add 10.1.10.0/24 via 10.1.2.1, eigrp metric [90/28416]
Jun 18 12:45:47: RT: NET-RED 10.1.10.0/24
Jun 18 12:45:47: RT: add 10.1.20.0/24 via 10.1.2.1, eigrp metric [90/28416]
<notice>...OUTPUT OMITTED...</notice>
Jun 18 12:45:47: RT: add 10.1.203.1/32 via 10.1.2.1, eigrp metric [90/158976]
Jun 18 12:45:47: RT: NET-RED 10.1.203.1/32
R1#<input>no debug ip routing</input>
IP routing debugging is off
Route Profiling
R1(config)#<input>ip route profile</input>
R1(config)#<input>^Z</input>
Jun 18 12:46:41.803: %SYS-5-CONFIG_I: Configured from console by console
R1#<input>sh ip route profile</input>
IP routing table change statistics:
Frequency of changes in a 5 second sampling interval
-------------------------------------------------------------
Change/ Fwd-path Prefix Nexthop Pathcount Prefix
interval change add change change refresh
-------------------------------------------------------------
0 2 2 2 2 1
1 0 0 0 0 1
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
<notice>...OUTPUT OMITTED...</notice>
3905 0 0 0 0 0
7030 0 0 0 0 0
10155 0 0 0 0 0
13280 0 0 0 0 0
Overflow 0 0 0 0 0
R1#<input>conf t</input>
R1(config)#<input>no ip route profile</input>
show ip cef
SW1#<input>show ip cef exact-route 172.16.4.16 192.168.22.73</input>
172.16.4.16 -> 192.168.22.73 => IP adj out of Vlan1, addr 172.16.4.16
Route-maps
Example
ip access-list extended ISP-CON1
remark Internally used nets denied. They should be routed by the FIB
deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 192.168.1.0 0.0.0.255 192.168.0.0 0.127.255.255
permit ip 192.168.1.0 0.0.0.255 any
!
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
route-map HETH permit 5
match ip address ISP-CON1
set ip next-hop 10.0.0.30
!
route-map HETH permit 10
match ip address prefix-list DEFAULT
set ip next-hop 10.0.0.34
prefix lists
Example Prefix-lists are numbered. In this example "secret net" are not announced.
- Note: As with access-lists there are an implicit deny in the end.
ip prefix-list SECRET-NET seq 10 deny 172.16.0.0/16
ip prefix-list SECRET-NET seq 20 deny 192.168.22.0/24
ip prefix-list SECRET-NET seq 30 permit 0.0.0.0/0 le 32 !Permit all other nets
!
router bgp 100
neighbor 10.1.2.3 remote-as 200
neighbor 10.1.2.3 prefix-list SECRET-NET out
Troubleshooting EIGRP
EIGRP uses three tables
- interface table:
Table | Description |
---|---|
Interface | Contains list of all interfaces that have been enabled for processing of EIGRP packets. Passive interfaces are not listed in this table. |
Neighbor | Keeps track of all active EIGRP neighbors. Neighbours are added on the reception of hello packet and are removed when the hold-time expires or when the associated interface goes down or removed from the Interface table. This table also keeps track on status on Routing information exchanged. |
Topology | Holds all Routes received from neighbors, locally injected or redistributed into EIGRP. EIGRP selects the best routes from this table based on the DUAL algorithm. |
Monitoring EIGRP
show commands
- show ip eigrp interface
- show ip eigrp neighbors
- show ip eigrp topology
debug commands
- debug ip routing
- debug eigrp packets - Many options here (terse - except hello packets)
- debug ip eigrp neighbor as-number network mask
- debug ip eigrp as-number network mask - limit info. from debug eigrp packets
Examples
R1#<input>sh ip protocols</input>
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: static, eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.1.2.0/30
192.168.1.1/32
Passive Interface(s):
FastEthernet0/0
Service-Engine0/1
Serial0/0/0
Serial0/0/1
ATM0/3/0
NVI0
Loopback0
Passive Interface(s):
VoIP-Null0
Routing Information Sources:
Gateway Distance Last Update
10.1.2.1 90 00:07:33
Distance: internal 90 external 170
Many options debugging eigrp
R1#<input>debug eigrp packets ?</input>
SIAquery EIGRP SIA-Query packets
SIAreply EIGRP SIA-Reply packets
ack EIGRP ack packets
hello EIGRP hello packets
ipxsap EIGRP ipxsap packets
probe EIGRP probe packets
query EIGRP query packets
reply EIGRP reply packets
request EIGRP request packets
retry EIGRP retransmissions
stub EIGRP stub packets
terse Display all EIGRP packets except Hellos
update EIGRP update packets
verbose Display all EIGRP packets
<cr>
Troubleshooting OSPF
Table | Description |
---|---|
Interface table | List all interfaces enabled for OSPF. The directly connected subnets are included in the TYPE-1 Router LSA the Router injects into the OSPF link-state database. Passive-interfaces are listed in the tables |
Neighbor table | Used to keep track of all OSPF neighbors. Neighbors are added on the reception of a hello packet and removed when the dead-time expires or when the associated interface goes down. |
Link State database | Main data structure containing all network topology information for the OSPF process. |
Routing Information Base | Contains results from the SPF algorithm. OSPF offers the contents of the RIB to the Routing Table. |
Neighbor states
State | Description |
---|---|
Attempt | This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval. |
Init | This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet. |
2-Way | This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers.
At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election. Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state. |
Exstart | Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.
In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis. |
Exchange | In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor. |
Loading | In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged. |
Full | In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.
Full is the normal state for an OSPF router. If a router is stuck in another state, it's an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the full state with their DR and BDR only. Neighbors always see each other as 2-way. |
INSERT TABLE 5.2 and FIGURE 5.3 from page 168
Cisco IOS OSPF commands
Show commands
- show ip ospf interface
- show ip ospf neighbor
- show ip ospf datatbase
- show ip ospf statistics
debug commands
- debug ip routing
- debug ip ospf packet
- debug ip ospf adj
- debug ip ospf monitor
Troubleshooting BGP
BGP has two maintables
Table | Description |
---|---|
Neighbor table | List all neighbors configured on the router. Contains AS, state, time up/down, and how many prefixes exchanged |
BGP table | Also called BGP RIB stores all locally injected routes and all routes received from neighbors/peers and routing info such as Nexthop, AS, MED, metric origin etc. |
Troubleshooting commands
show commands
- show ip bgp summary
- show ip bgp neighbors [ip-address]
- show ip bgp [prefix]
debug commands
- debug ip bgp
- debug ip bgp updates