To pass the BSCI exam, earn your CCNP certification, and become an outstanding networker, you've got to master the many details of BGP - and trust me, there are a lot of details to master! Before you get into the more advanced features of BGP, you should have the fundamentals down cold, and one of those fundamentals is knowing the BGP adjacency states. This will allow you to successfully analyze and troubleshoot BGP peer relationships.
In the following example, a BGP peering is being created between R1 and R3.
R1(config-router)#neighbor 172.12.123.3 remote-as 200
BGP speakers do not have to be in the same AS to become peers. To verify that the remote BGP speaker has become a peer, run show ip bgp neighbor.
R1#show ip bgp neighbor
BGP neighbor is 172.12.123.3, remote AS 200, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:01:39, hold time is 180, keepalive interval is 60 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between advertisement runs is 30 seconds
The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means that a BGP peer connection does not yet exist with the prospective neighbor. Before we continue with this example, let’s look at the different BGP states:
Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
Connect is the next state. If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.
Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You’ll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.
OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.
In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.
So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that’s not as good as it sounds. Of course, the reason the peer relationship hasn’t been established is that we haven’t configured R3 yet!
R3(config)#router bgp 200
R3(config-router)#neighbor 172.12.123.1 remote-as 100
Verify the peer establishment with show ip bgp neighbor:
R3#show ip bgp neighbor
BGP neighbor is 172.12.123.1, remote AS 100, external link
BGP version 4, remote router ID 172.12.123.1
BGP state = Established, up for 00:01:18
Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Received 5 messages, 0 notifications, 0 in queue
Sent 5 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between advertisement runs is 30 seconds
Local host: 172.12.123.3, Local port: 179 (BGP uses TCP Port 179)
Foreign host: 172.12.123.1, Foreign port: 11007
The peer relationship between R1 and R3 has been established!
Showing posts with label active. Show all posts
Showing posts with label active. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BCMSN Exam Tutorial: Changing The Active Router In HSRP
To pass the BCMSN exam and earn your CCNP certification, you've got to know HSRP inside and out. While the operation and basic commands of HSRP are pretty simple, there are some important details that are easily overlooked but are vital in getting HSRP to work the way you want it to. Let's take a look at using the priority command correctly on both the exam and in production networks.
A key value in the show standby command is the priority. The default is 100, and the router with the highest priority will be the primary HSRP router. We'll raise the default priority on R2 and see the results. R3 is currently the Active router and R2 the standby, so let's raise the priority on R2 and see what happens.
R2(config)#interface ethernet0
R2(config-if)#standby 5 priority 150
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 0.896
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 8.072
Standby router is local
1 state changes, last state change 00:14:24
R2 now has a higher priority, but R3 is still the active router. R2 will not take over as the HSRP primary until R3 goes down - OR the preempt option is configured on R2.
R2(config-if)#standby 5 priority 150 preempt
1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active
R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 1.844
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:00:13
In just a few seconds, a message appears that the local state has changed from standby to active. Show standby confirms that R2, the local router, is now the active router - the primary. R3 is now the standby. So if anyone tells you that you have to take a router down to change the Active router, they're wrong - you just have to use the preempt option on the standby priority command.
Another vital part of HSRP configurations is knowing how to change the MAC address of the virtual router, as well as interface tracking. We'll look at those features in the next part of my HSRP tutorial!
A key value in the show standby command is the priority. The default is 100, and the router with the highest priority will be the primary HSRP router. We'll raise the default priority on R2 and see the results. R3 is currently the Active router and R2 the standby, so let's raise the priority on R2 and see what happens.
R2(config)#interface ethernet0
R2(config-if)#standby 5 priority 150
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 0.896
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 8.072
Standby router is local
1 state changes, last state change 00:14:24
R2 now has a higher priority, but R3 is still the active router. R2 will not take over as the HSRP primary until R3 goes down - OR the preempt option is configured on R2.
R2(config-if)#standby 5 priority 150 preempt
1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active
R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 1.844
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:00:13
In just a few seconds, a message appears that the local state has changed from standby to active. Show standby confirms that R2, the local router, is now the active router - the primary. R3 is now the standby. So if anyone tells you that you have to take a router down to change the Active router, they're wrong - you just have to use the preempt option on the standby priority command.
Another vital part of HSRP configurations is knowing how to change the MAC address of the virtual router, as well as interface tracking. We'll look at those features in the next part of my HSRP tutorial!
Monday, December 22, 2008
CCNP Certification / BSCI Exam Tutorial: EIGRP Stuck-In-Active Routes
Passing the BSCI exam and earning your CCNP is all about knowing the details, and when it comes to EIGRP SIA routes, there are plenty of details to know. A quick check in a search engine for "troubleshoot SIA" will bring up quite a few matches. Troubleshooting SIA routes is very challengin in that there's no one reason they occur.
View the EIGRP topology table with the show ip eigrp topology command, and you'll see a code next to every successor and feasible successor. A popular misconception is that we want these routes to have an "A" next to them - so they're active. That's what we want, right? Active routes sound good, right?
Well, they sound good, but they're not. If a route shows as Active in the EIGRP topology table, that means that DUAL is currently calculating that route, and it's currently unusable. When a route is Passive ("P), that means it's not being recalculated and it's a usable route.
Generally, a route shown as Active is going to be there for a very short period of time by the time you repeat the command, hopefully that Active route has gone Passive. Sometimes that doesn't happen, though, and the route becomes SIA - Stuck In Active.
A route becomes SIA when a query goes unanswered for so long that the neighbor relationship is reset. From experience, I can tell you that troubleshooting SIA routes is more of an art form than a science, but there are four main reasons a route becomes SIA:
The link is unidirectional, so the query can't possibly be answered.
The queried router's resources are unavailable, generally due to high CPU utilization.
The queried router's memory is corrupt or otherwise unable to allow the router to answer the query.
The link between the two routers is of low quality, allowing just enough packets through to keep the neighbor relationship intact, but not good enough to allow the replies through.
To sum it up, routes generally become SIA when a neighbor either doesn't answer a query, or either the query or reply took a wrong turn somewhere. I told you it wasn't the easiest thing to troubleshoot!
View the EIGRP topology table with the show ip eigrp topology command, and you'll see a code next to every successor and feasible successor. A popular misconception is that we want these routes to have an "A" next to them - so they're active. That's what we want, right? Active routes sound good, right?
Well, they sound good, but they're not. If a route shows as Active in the EIGRP topology table, that means that DUAL is currently calculating that route, and it's currently unusable. When a route is Passive ("P), that means it's not being recalculated and it's a usable route.
Generally, a route shown as Active is going to be there for a very short period of time by the time you repeat the command, hopefully that Active route has gone Passive. Sometimes that doesn't happen, though, and the route becomes SIA - Stuck In Active.
A route becomes SIA when a query goes unanswered for so long that the neighbor relationship is reset. From experience, I can tell you that troubleshooting SIA routes is more of an art form than a science, but there are four main reasons a route becomes SIA:
The link is unidirectional, so the query can't possibly be answered.
The queried router's resources are unavailable, generally due to high CPU utilization.
The queried router's memory is corrupt or otherwise unable to allow the router to answer the query.
The link between the two routers is of low quality, allowing just enough packets through to keep the neighbor relationship intact, but not good enough to allow the replies through.
To sum it up, routes generally become SIA when a neighbor either doesn't answer a query, or either the query or reply took a wrong turn somewhere. I told you it wasn't the easiest thing to troubleshoot!
Subscribe to:
Posts (Atom)
