Showing posts with label chris. Show all posts
Showing posts with label chris. Show all posts
Cisco CCNA CCNP Certification How And Why To Build An Etherchannel
Tuesday, 1 September 2009Posted by
Best-Product
0 Comments
CCNA and CCNP candidates are well-versed in Spanning-Tree Protocol
and one of the great things about STP is that it works well with little or no additional configuration. There is one situation where STP works against us just a bit while it prevents switching loops
and that is the situation where two switches have multiple physical connections.
You would think that if you have two separate physical connections between two switches
twice as much data could be sent from one switch to the other than if there was only one connection. STP doesn't allow this by default
however in an effort to prevent switching loops from forming
one of the paths will be blocked.
SW1 and SW2 are connected via two separate physical connections
on ports fast0/11 and fast 0/12. As we can see here on SW1
only port 0/11 is actually forwarding traffic. STP has put the other port into blocking mode (BLK).
SW1#show spanning vlan 10
(some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Fa0/11 Root FWD 19 128.11 P2p
Fa0/12 Altn BLK 19 128.12 P2p
While STP is helping us by preventing switching loops
STP is also hurting us by preventing us from using a perfectly valid path between SW1 and SW2. We could literally double the bandwidth available between the two switches if we could use that path that is currently being blocked.
The secret to using the currently blocked path is configuring an Etherchannel. An Etherchannel is simply a logical bundling of 2 - 8 physical connections between two Cisco switches.
Configuring an Etherchannel is actually quite simple. Use the command "channel-group 1 mode on" on every port you want to be placed into the Etherchannel. Of course
this must be done on both switches if you configure an Etherchannel on one switch and don't do so on the correct ports on the other switch
the line protocol will go down and stay there.
The beauty of an Etherchannel is that STP sees the Etherchannel as one connection. If any of the physical connections inside the Etherchannel go down
STP does not see this
and STP will not recalculate. While traffic flow between the two switches will obviously be slowed
the delay in transmission caused by an STP recalculation is avoided. An Etherchannel also allows us to use multiple physical connections at one time.
Here's how to put these ports into an Etherchannel:
SW1#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW1(config)#interface fast 0/11
SW1(config-if)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1
SW1(config-if)#interface fast 0/12
SW1(config-if)#channel-group 1 mode on
SW2#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#channel-group 1 mode on
SW2(config-if)#int fast 0/12
SW2(config-if)#channel-group 1 mode on
The command "show interface trunk" and "show spanning-tree vlan 10" will be used to verify the Etherchannel configuration.
SW2#show interface trunk (some output removed for clarity)
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
SW2#show spanning vlan 10 (some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 12 128.65 P2p
Before configuring the Etherchannel
we saw individual ports here. Now we see "Po1"
which stands for the interface "port-channel1". This is the logical interface created when an Etherchannel is built. We are now using both physical paths between the two switches at one time!
That's one major benefit in action let's see another. Ordinarily
if the single open path between two trunking switches goes down
there is a significant delay while another valid path is opened - close to a minute in some situations. We will now shut down port 0/11 on SW2 and see the effect on the etherchannel.
SW2#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#shutdown
3w0d: %LINK-5-CHANGED: Interface FastEthernet0/11
changed
state to administratively down
SW2#show spanning vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 19 128.65 P2p
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
The Etherchannel did not go down! STP sees the Etherchannel as a single link therefore
as far as STP is concerned
nothing happened.
Building an Etherchannel and knowing how it can benefit your network is an essential skill for CCNA and CCNP success
and it comes in very handy on the job as well. Make sure you are comfortable with building one before taking Cisco's exams!
Read More “Cisco CCNA CCNP Certification How And Why To Build An Etherchannel”
and one of the great things about STP is that it works well with little or no additional configuration. There is one situation where STP works against us just a bit while it prevents switching loops
and that is the situation where two switches have multiple physical connections.
You would think that if you have two separate physical connections between two switches
twice as much data could be sent from one switch to the other than if there was only one connection. STP doesn't allow this by default
however in an effort to prevent switching loops from forming
one of the paths will be blocked.
SW1 and SW2 are connected via two separate physical connections
on ports fast0/11 and fast 0/12. As we can see here on SW1
only port 0/11 is actually forwarding traffic. STP has put the other port into blocking mode (BLK).
SW1#show spanning vlan 10
(some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Fa0/11 Root FWD 19 128.11 P2p
Fa0/12 Altn BLK 19 128.12 P2p
While STP is helping us by preventing switching loops
STP is also hurting us by preventing us from using a perfectly valid path between SW1 and SW2. We could literally double the bandwidth available between the two switches if we could use that path that is currently being blocked.
The secret to using the currently blocked path is configuring an Etherchannel. An Etherchannel is simply a logical bundling of 2 - 8 physical connections between two Cisco switches.
Configuring an Etherchannel is actually quite simple. Use the command "channel-group 1 mode on" on every port you want to be placed into the Etherchannel. Of course
this must be done on both switches if you configure an Etherchannel on one switch and don't do so on the correct ports on the other switch
the line protocol will go down and stay there.
The beauty of an Etherchannel is that STP sees the Etherchannel as one connection. If any of the physical connections inside the Etherchannel go down
STP does not see this
and STP will not recalculate. While traffic flow between the two switches will obviously be slowed
the delay in transmission caused by an STP recalculation is avoided. An Etherchannel also allows us to use multiple physical connections at one time.
Here's how to put these ports into an Etherchannel:
SW1#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW1(config)#interface fast 0/11
SW1(config-if)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1
SW1(config-if)#interface fast 0/12
SW1(config-if)#channel-group 1 mode on
SW2#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#channel-group 1 mode on
SW2(config-if)#int fast 0/12
SW2(config-if)#channel-group 1 mode on
The command "show interface trunk" and "show spanning-tree vlan 10" will be used to verify the Etherchannel configuration.
SW2#show interface trunk (some output removed for clarity)
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
SW2#show spanning vlan 10 (some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 12 128.65 P2p
Before configuring the Etherchannel
we saw individual ports here. Now we see "Po1"
which stands for the interface "port-channel1". This is the logical interface created when an Etherchannel is built. We are now using both physical paths between the two switches at one time!
That's one major benefit in action let's see another. Ordinarily
if the single open path between two trunking switches goes down
there is a significant delay while another valid path is opened - close to a minute in some situations. We will now shut down port 0/11 on SW2 and see the effect on the etherchannel.
SW2#conf t
Enter configuration commands
one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#shutdown
3w0d: %LINK-5-CHANGED: Interface FastEthernet0/11
changed
state to administratively down
SW2#show spanning vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 19 128.65 P2p
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
The Etherchannel did not go down! STP sees the Etherchannel as a single link therefore
as far as STP is concerned
nothing happened.
Building an Etherchannel and knowing how it can benefit your network is an essential skill for CCNA and CCNP success
and it comes in very handy on the job as well. Make sure you are comfortable with building one before taking Cisco's exams!
CCNP Certification BSCI Exam Tutorial The BGP Neighbor Process
Tuesday, 18 August 2009Posted by
Best-Product
Like TCP
BGP is connection-oriented. An underlying connection between two BGP speakers is established before any routing information is exchanged. This connection takes place on TCP port 179. As with EIGRP and OSPF
keepalive messages are sent out by the BGP speakers in order to keep this relationship alive.
Once the connection is established
the BGP speakers exchange routes and synchronize their tables. After this initial exchange
a BGP speaker will only send further updates upon a change in the network topology.
The IGP protocols that use Autonomous Systems
IGRP and EIGRP
require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. The BGP neighbors do not have to be directly connected
and often are not
but do need to be able to reach the IP addresses they use in their neighbor statements.
A BGP peer that is in the same AS is referred to as an Internal BGP (iBGP) Peer
where a BGP peer in another AS is an External BGP (eBGP) Peer.
A sample iBGP configuration:
Router bgp 100
Neighbor 10.1.1.2 remote-as 100
A sample eBGP configuration:
Router bgp 100
Neighbor 10.1.1.2 remote-as 200
Cisco recommends that eBGP peers be directly connected
where iBGP peers generally will not be.
Before we get too much farther into BGP theory
let’s get a configuration started. You’ll use the router bgp command to configure a router as a BGP speaker. Right after that
the neighbor command will be used to identify this BGP speaker’s potential neighbors. (The terms "peer" and "neighbor" are interchangeable in BGP
but it's the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.)
R1(config-router)#neighbor 172.12.123.3 remote-as 200
While almost all of the neighbor options are just that -- optional -- you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. Remember
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.
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
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.
Now that you know how the neighbor relationship itself is built
you need to start learning the many options of the neighbor command. You’ll have to master these to become a CCNP and CCIE!
Read More “CCNP Certification BSCI Exam Tutorial The BGP Neighbor Process”
BGP is connection-oriented. An underlying connection between two BGP speakers is established before any routing information is exchanged. This connection takes place on TCP port 179. As with EIGRP and OSPF
keepalive messages are sent out by the BGP speakers in order to keep this relationship alive.
Once the connection is established
the BGP speakers exchange routes and synchronize their tables. After this initial exchange
a BGP speaker will only send further updates upon a change in the network topology.
The IGP protocols that use Autonomous Systems
IGRP and EIGRP
require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. The BGP neighbors do not have to be directly connected
and often are not
but do need to be able to reach the IP addresses they use in their neighbor statements.
A BGP peer that is in the same AS is referred to as an Internal BGP (iBGP) Peer
where a BGP peer in another AS is an External BGP (eBGP) Peer.
A sample iBGP configuration:
Router bgp 100
Neighbor 10.1.1.2 remote-as 100
A sample eBGP configuration:
Router bgp 100
Neighbor 10.1.1.2 remote-as 200
Cisco recommends that eBGP peers be directly connected
where iBGP peers generally will not be.
Before we get too much farther into BGP theory
let’s get a configuration started. You’ll use the router bgp command to configure a router as a BGP speaker. Right after that
the neighbor command will be used to identify this BGP speaker’s potential neighbors. (The terms "peer" and "neighbor" are interchangeable in BGP
but it's the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.)
R1(config-router)#neighbor 172.12.123.3 remote-as 200
While almost all of the neighbor options are just that -- optional -- you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. Remember
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.
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
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.
Now that you know how the neighbor relationship itself is built
you need to start learning the many options of the neighbor command. You’ll have to master these to become a CCNP and CCIE!
CCNA CCNP Home Lab Tutorial The VLAN.DAT File
Sunday, 16 August 2009Posted by
Best-Product
CCNA and CCNP candidates who have their own Cisco home labs often email me about an odd situation that occurs when they erase a switch's configuration. Their startup configuration is gone
as they expect
but the VLAN and VTP information is still there!
Sounds strange
doesn't it? Let's look at an example. On SW1
we run show vlan brief and see in this abbreviated output that there are three additional vlans in use:
SW1#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
We want to totally erase the router's startup configuration
so we use the write erase command
confirm it
and reload without saving the running config:
SW1#write erase
Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]
[OK]
Erase of nvram: complete
00:06:00: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvram
SW1#reload
System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
The router reloads
and after exiting setup mode
we run show vlan brief again. And even though the startup configuration was erased
the vlans are still there!
Switch#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
The reason is that this vlan and VTP information is actually kept in the VLAN.DAT file in Flash memory
and the contents of Flash are kept on a reload. The file has to be deleted manually.
There's a little trick to deleting this file. The switch will prompt you twice to ask if you really want to get rid of this file. Don't type "y" or "yes"; just accept the defaults by hitting the return key. If you type "y"
the router attempts to delete a file named "y"
as shown here:
Switch#delete vlan.dat
Delete filename [vlan.dat]? y
Delete flash:y? [confirm]
%Error deleting flash:y (No such file or directory)
Switch#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
Switch#
The best way to prepare for CCNA and CCNP exam success is by working on real Cisco equipment
and by performing lab tasks over and over. Repetition is the mother of skill
and by truly erasing your VLAN and VTP information by deleting the vlan.dat file from Flash
you'll be building your Cisco skills to the point where your CCNA and CCNP exam success is a certainty.
Read More “CCNA CCNP Home Lab Tutorial The VLAN.DAT File”
as they expect
but the VLAN and VTP information is still there!
Sounds strange
doesn't it? Let's look at an example. On SW1
we run show vlan brief and see in this abbreviated output that there are three additional vlans in use:
SW1#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
We want to totally erase the router's startup configuration
so we use the write erase command
confirm it
and reload without saving the running config:
SW1#write erase
Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]
[OK]
Erase of nvram: complete
00:06:00: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvram
SW1#reload
System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
The router reloads
and after exiting setup mode
we run show vlan brief again. And even though the startup configuration was erased
the vlans are still there!
Switch#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
The reason is that this vlan and VTP information is actually kept in the VLAN.DAT file in Flash memory
and the contents of Flash are kept on a reload. The file has to be deleted manually.
There's a little trick to deleting this file. The switch will prompt you twice to ask if you really want to get rid of this file. Don't type "y" or "yes"; just accept the defaults by hitting the return key. If you type "y"
the router attempts to delete a file named "y"
as shown here:
Switch#delete vlan.dat
Delete filename [vlan.dat]? y
Delete flash:y? [confirm]
%Error deleting flash:y (No such file or directory)
Switch#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
Switch#
The best way to prepare for CCNA and CCNP exam success is by working on real Cisco equipment
and by performing lab tasks over and over. Repetition is the mother of skill
and by truly erasing your VLAN and VTP information by deleting the vlan.dat file from Flash
you'll be building your Cisco skills to the point where your CCNA and CCNP exam success is a certainty.
Subscribe to:
Posts (Atom)
Blog Archive
-
▼
2009
(36)
-
▼
September
(17)
- Cisco CCNA CCNP Exam Tutorial Testing ISDN Link...
- Cisco CCNA CCNP Exam Tutorial Testing ISDN Link...
- Cisco CCNA CCNP Exam Tutorial Five Debugs You ...
- Cisco CCNA CCNP Certification Tutorial Frame R...
- Cisco CCNA CCNP Certification Exam Tutorial Dia...
- Cisco CCNA CCNP Certification Exam Tutorial Con...
- Cisco CCNA CCNP Certification Exam Tutorial IS...
- Cisco CCNA CCNP Certification Exam Review Prot...
- Cisco CCNA CCNP Certification Exam Lab Frame Re...
- Cisco CCNA CCNP Certification Exam Frame Relay ...
- Cisco CCNA CCNP Certification Exam Creating A S...
- Cisco CCNA CCNP Certification Exam Troubleshoo...
- Cisco CCNA CCNP Certification Exam Same Comman...
- Cisco CCNA CCNP Certification Exam Frame Relay...
- Cisco CCNA CCNP Certification Exam Caller ID S...
- Cisco CCNA CCNP Certification Exam Cabling You...
- Cisco CCNA CCNP Certification How And Why To Bu...
-
▼
September
(17)