In my last ISIS tutorial, I mentioned that while ISIS and OSPF are both link state protocols, their actual operation differs greatly. To pass the BSCI exam and earn your CCNP, you'll need to know these differences! Today, we'll take a look at ISIS Hello types and the adjacency types that form through the use of these Hellos.
Hello packets have been mentioned several times with ISIS, and with good reason. Hello packets are the heartbeat of OSPF and ISIS when heartbeats are no longer heard from a neighbor, that adjacency will be dropped. A major difference between OSPF and ISIS is that OSPF has one type of Hello packet, where ISIS actually has three!
An ES Hello (ESH) is send by all End Systems, and all IS devices listen for this Hello. This is how a router (IS) discovers a host (ES).
An IS Hello (ISH) announces the presence of an IS. An IS Hello is sent by all IS devices, and End Systems listen for these hellos.
An IS-to-IS Hello (IIH) is used by an IS to discover other ISes and to form adjacencies with them.
An interesting side note: A router will send an IIH to another router on the link to form or maintain an adjacency, but it will still send an ISH as well in case there are end systems located on that segment.
ISIS and OSPF both create and maintain adjacencies with the Hello packet. Let's take a look at the rules regarding ISIS adjacencies as well as the adjacency types.
L1 and L2 Hellos are different messages, so an L1 router must exchange Hellos with another L1 router to form an adjacency, just as L2 routers form adjacencies with L2 routers. L1 routers can only form an adjacency with an L2 router if one of the two routers involved is actually an L1/L2 router.
L1 routers must be in the same area in order to form an adjacency. The Hello timers, as well as the MTU, must match between the interfaces used to form the adjacency.
That's a lot of L1, L2, and L1/L2, isn't it? Let's review the adjacencies each router type can form:
L1: Can form adjacency with any L1 in the same area and any L1/L2 in the same area.
L2: Can form adjacency with any L2 in any area, and with an L1/L2 in any area.
L1/L2: Can form adjacency with any L1 in the same area, L1/L2 in any area, and L2 in any area.
Knowing the similarities and differences regarding ISIS and OSPF is vital for CCNP exam success. Take your time, master the fundamentals, and before long the magic letters “CCNP” are behind your name and on your resume!
Showing posts with label adjacency. Show all posts
Showing posts with label adjacency. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BSCI Exam Tutorial: ISIS Router Types
To pass the BSCI exam and earn your CCNP, you've got to know ISIS inside and out. There are many similarities between ISIS and OSPF, but one major difference is that ISIS has three different types of routers - Level 1 (L1), Level 2 (L2), and L1/L2.
L1 routers are contained in a single area, and are connected to other areas by an L1/L2 router. The L1 uses the L1/L2 router as a default gateway to reach destinations contained in other areas, much like an OSPF stub router uses the ABR as a default gateway.
L1 routers have no specific routing table entries regarding any destination outside their own area; they will use an L1/L2 router as a default gateway to reach any external networks. ISIS L1 routers in the same area must synchronize their databases with each other.
Just as we have L1 routers, we also have L2 routers. Anytime we're routing between areas (inter-area routing), an L2 or L1/L2 router must be involved. All L2 routers will have synchronized databases as well.
Both L1 and L2 routers send out their own hellos. As with OSPF, hello packets allow ISIS routers to form adjacencies. The key difference here is that L1 routers send out L1 hellos, and L2 routers send out L2 hellos. If you have an L1 router and an L2 router on the same link, they will not form an adjacency.
An ISIS router can act as an L1 and an L2 router at the same time; these routers are L1/L2 routers. An L1/L2 router can have neighbors in separate ISIS areas. The L1/L2 router will have two separate databases, though - one for L1 routes and another for L2 routes. L1/L2 is the default setting for Cisco routers running ISIS. The L1/L2 router is the router that makes it possible for an L1 router to send data to another area.
In the next part of my ISIS tutorial, we'll take a more detailed look at those ISIS hellos!
L1 routers are contained in a single area, and are connected to other areas by an L1/L2 router. The L1 uses the L1/L2 router as a default gateway to reach destinations contained in other areas, much like an OSPF stub router uses the ABR as a default gateway.
L1 routers have no specific routing table entries regarding any destination outside their own area; they will use an L1/L2 router as a default gateway to reach any external networks. ISIS L1 routers in the same area must synchronize their databases with each other.
Just as we have L1 routers, we also have L2 routers. Anytime we're routing between areas (inter-area routing), an L2 or L1/L2 router must be involved. All L2 routers will have synchronized databases as well.
Both L1 and L2 routers send out their own hellos. As with OSPF, hello packets allow ISIS routers to form adjacencies. The key difference here is that L1 routers send out L1 hellos, and L2 routers send out L2 hellos. If you have an L1 router and an L2 router on the same link, they will not form an adjacency.
An ISIS router can act as an L1 and an L2 router at the same time; these routers are L1/L2 routers. An L1/L2 router can have neighbors in separate ISIS areas. The L1/L2 router will have two separate databases, though - one for L1 routes and another for L2 routes. L1/L2 is the default setting for Cisco routers running ISIS. The L1/L2 router is the router that makes it possible for an L1 router to send data to another area.
In the next part of my ISIS tutorial, we'll take a more detailed look at those ISIS hellos!
Cisco CCNP / BSCI Exam Tutorial: BGP Adjacency States
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!
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!
Cisco CCNP / BSCI Exam Tutorial: 10 ISIS Details You Must Know!
Earning your CCNP certification and passing the BSCI exam depends on knowing the details of many Cisco technologies, ISIS chief among them. To help you prepare for exam success, here's a list of ISIS terminology and basic concepts that will help you pass this tough exam. Enjoy!
ISIS Terms:
Domain: section of the network under common administrative control
Area: logical segment of the network composed of contiguous routers and their data links
Intermediate System: A router.
End System: A host device.
The four levels of ISIS routing:
Level 0: ES-IS routing in the same subnet.
Level 1: IS-IS routing in the same area.
Level 2: IS-IS routing in the same domain.
Level 3: Inter-domain routing performed by InterDomain Routing Protocol (IDRP).
ISIS Adjacency Possibilities:
L1: Can form adjacency with any L1 in the same area and any L1/L2 in the same area.
L2: Can form adjacency with any L2 in any area, and with an L1/L2 in any area.
L1/L2: Can form adjacency with any L1 in the same area, L1/L2 in any area, and L2 in any area.
A router interface’s SNPA (Subnetwork Point Of Attachment) is its highest DLCI number if it’s on a Frame network, and its MAC address if the interface is on an Ethernet segment.
ISIS Hello Types:
ESH: ES Hello – Sent by End Systems to discover a router.
ISH: IS Hello – Send by Intermediate Systems to announce their presence. End Systems listen for these.
IIH: IS-to-IS Hello – Send by one IS to be heard by another IS. These hellos makes IS-IS adjacencies possible.
Best of luck on your CCNP exams!
ISIS Terms:
Domain: section of the network under common administrative control
Area: logical segment of the network composed of contiguous routers and their data links
Intermediate System: A router.
End System: A host device.
The four levels of ISIS routing:
Level 0: ES-IS routing in the same subnet.
Level 1: IS-IS routing in the same area.
Level 2: IS-IS routing in the same domain.
Level 3: Inter-domain routing performed by InterDomain Routing Protocol (IDRP).
ISIS Adjacency Possibilities:
L1: Can form adjacency with any L1 in the same area and any L1/L2 in the same area.
L2: Can form adjacency with any L2 in any area, and with an L1/L2 in any area.
L1/L2: Can form adjacency with any L1 in the same area, L1/L2 in any area, and L2 in any area.
A router interface’s SNPA (Subnetwork Point Of Attachment) is its highest DLCI number if it’s on a Frame network, and its MAC address if the interface is on an Ethernet segment.
ISIS Hello Types:
ESH: ES Hello – Sent by End Systems to discover a router.
ISH: IS Hello – Send by Intermediate Systems to announce their presence. End Systems listen for these.
IIH: IS-to-IS Hello – Send by one IS to be heard by another IS. These hellos makes IS-IS adjacencies possible.
Best of luck on your CCNP exams!
Cisco CCNA Exam Tutorial: Five OSPF Hub-And-Spoke Details You Must Know!
CCNA exam success depends greatly on knowing the details, and if there's one protocol that has a lot of details, it's OSPF! This is true particularly of hub-and-spoke networks, so in this CCNA OSPF tutorial we'll take a look at some of the more important hub-and-spoke OSPF details. This will help you in working with real-world networks as well, since this OSPF network type is one of the more typical network topologies.
In OSPF, the hub must become the designated router (DR). The DR election's deciding value is the OSPF interface priority, and the default value is 1. It's not enough to set the hub's OSPF interface to 2, however, since the spoke routers must not become the DR or BDR. You must set the spoke interfaces to an OSPF priority of zero.
R2(config)#int s0
R2(config-if)#ip ospf priority 0
This ensures that the spokes will not become the DR or BDR if the hub goes down.
The hub does require a bit more configuration, though. The neighbor command must be used on the hub to indicate the IP address of the potential neighbors.
R1(config)#router ospf 1
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
It's common to have an ISDN link as a backup in an OSPF network, and when that ISDN link comes up the hello packets must be able to cross the link. What you don't want is to have the hellos keep the link up! By configuring the ISDN link as an OSPF demand circuit, the link will drop in the absence of interesting traffic, but the OSPF adjacency that formed across the ISDN link will be assumed by the router to still be up. (You usually see this command configured on both sides of the ISDN link, but it's only needed on one side. It doesn't hurt anything to put it on both sides, though.)
R2(config)#int bri0
R2(config-if)#ip ospf demand-circuit
A final detail of OSPF hub-and-spoke and demand circuits actually takes place at Layer 2. For the OSPF hello packets to successfully be transmitted across an ISDN link or a frame relay network, the broadcast option must be enabled in the appropriate frame and dialer map statements. Failure to enable this option can lead to a situation where pings will be successful, but OSPF adjacencies will not form.
R2(config-if)#dialer map ip 172.12.21.1 name R1 broadcast 5551111
R2(config-if)#frame map ip 172.12.123.1 221 broadcast
When you're troubleshooting OSPF in a production network or your CCNA / CCNP home lab, don't just look at Layer 3 - because everything's got to be right at the physical and data link layers in order for the network layer to function correctly!
In OSPF, the hub must become the designated router (DR). The DR election's deciding value is the OSPF interface priority, and the default value is 1. It's not enough to set the hub's OSPF interface to 2, however, since the spoke routers must not become the DR or BDR. You must set the spoke interfaces to an OSPF priority of zero.
R2(config)#int s0
R2(config-if)#ip ospf priority 0
This ensures that the spokes will not become the DR or BDR if the hub goes down.
The hub does require a bit more configuration, though. The neighbor command must be used on the hub to indicate the IP address of the potential neighbors.
R1(config)#router ospf 1
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
It's common to have an ISDN link as a backup in an OSPF network, and when that ISDN link comes up the hello packets must be able to cross the link. What you don't want is to have the hellos keep the link up! By configuring the ISDN link as an OSPF demand circuit, the link will drop in the absence of interesting traffic, but the OSPF adjacency that formed across the ISDN link will be assumed by the router to still be up. (You usually see this command configured on both sides of the ISDN link, but it's only needed on one side. It doesn't hurt anything to put it on both sides, though.)
R2(config)#int bri0
R2(config-if)#ip ospf demand-circuit
A final detail of OSPF hub-and-spoke and demand circuits actually takes place at Layer 2. For the OSPF hello packets to successfully be transmitted across an ISDN link or a frame relay network, the broadcast option must be enabled in the appropriate frame and dialer map statements. Failure to enable this option can lead to a situation where pings will be successful, but OSPF adjacencies will not form.
R2(config-if)#dialer map ip 172.12.21.1 name R1 broadcast 5551111
R2(config-if)#frame map ip 172.12.123.1 221 broadcast
When you're troubleshooting OSPF in a production network or your CCNA / CCNP home lab, don't just look at Layer 3 - because everything's got to be right at the physical and data link layers in order for the network layer to function correctly!
Subscribe to:
Posts (Atom)
