Showing posts with label link. Show all posts
Showing posts with label link. Show all posts

Mar 12, 2013

Lesson 38 - OSPF Fundamentals Part1 - Terminology



Open Shortest Path First is the dynamic routing protocol based a link-state algorithm. In the upcoming few posts I will attempt to explain the basics of OSPF operation. Cisco CCNA level of expertise assumes that the candidates know how to implement it in a single area. In my OSPF related posts I will go a bit beyond CCNA requirements but not too much, just enough to help you appreciate this fascinating solution and put OSPF into practice.

Link-state algorithm is faster and more accurate in selecting the best path compared to distance vector approach. The latter algorithm allows routers to know how far the destinations are (distance) and the next-hop router(s) the packets should be sent to (vector). Thus, the routers do not know the topology of the network.

Routers using link-state algorithm create "a map" of the network which allows them to choose paths more accurately. Even though they are more demanding hardware-wise (CPU and RAM memory) they supersede distance vector based solutions.

OSPF Basic Operation
OSPF is a very complex routing protocol but its fundamental operation is quite simple. The steps of operation might be pictured as follows:
  1. Each router sends so called hello packets out of all OSPF-enabled interfaces. This way, the OSPF-enabled router discovers directly connected routers which also run OSPF. If certain parameters in the hello packets match between the neighboring routers, they form the relationship called the adjacency. It is a sort of virtual communication between them. 
  2. Then, each router exchanges special packets called Link State Advertisements (LSAs) with its neighbors (adjacent routers). In OSPF terminology the word link is the same as the interface. LSAs contain details such as: addresses/network masks configured on the links (interfaces running OSPF of course), the metric, the state of the link (which is its relation to the rest of the network), list of neighbors connected to the link.
  3. Each router stores the LSAs in its Link State Database (LSDB). These LSAs are then flooded (advertised) to all OSPF neighbors. As a result of the LSA flooding, all routers in the area have identical LSDBs. An analogy would be having the same road map of a given country which all drivers use. Their journey's starting point is different but the map is still the same.
  4. Each router runs Dijkstra's algorithm to select the best path from this topological database (LSDB). This way, each router creates loop free graph indicating the shortest (best) path to each network/subnet advertised. The best paths end up in the routing table.
OSPF Network Types
OSPF distinguishes between two major types of networks:
  • Transit Networks - Networks which have two or more attached routers. The packets might be originated or passing through this type of network.
  • Stub Networks - Networks which have only one router attached (one exit point). Packets are either originated or destined to these types of networks. A loopback interface is a type of stub network as well. The loopbacks are by default advertised as /32 prefixes (255.255.255.255). If you want to advertise loopbacks with their real network mask length, you must change the OSPF mode of operation to point-to-point (presented in the upcoming posts).
More specifically OSPF defines five different types of networks it can operate on. These are:
  • Broadcast - such as Ethernet, Token-Ring
  • Non Broadcast Multiple Access (NBMA) - such as Frame-Relay, ATM, X.25 (they may but do not have to be fully meshed)
  • Point-To-Multipoint - such as Frame-Relay but treated as point-to-point links (Hub and Spoke)
  • Point-to-Point - such as using PPP, HDLC protocols
  • Virtual Links - used in special situations if the OSPF area 0 (backbone area) is partitioned or if an OSPF area cannot be connected to the area 0 directly
There are some differences in OSPF operation, depending on what type of network it runs on. I will explain the relevant details in the upcoming posts. 

OSPF routers will go through multiple states with their neighbors before they are ready to route the packets. Some of them will be used on all type of the networks but others only on specific types of networks listed above. 

OSPF Neighbor State Machine
All possible states between the neighbors are shown in pic. 1. They are also referred to as Neighbor State Machine.

Pic. 1 - OSPF Neighbor States.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

Down
In this state, a router has not heard a hello packet from any OSPF neighbor yet.

Attempt
This state is applied only on NBMA networks in which the neighbors are not discovered dynamically but must be configured manually ('neighbor' statement in the config-router context).

Init
A router has heard a hello packet from its neighbor(s), which among other parameters the Router IDs of all the neighbors are listed  (look at hello packet structure in the next post).

2-Way
A router has seen its own Router ID in the hello packet from the neighbor(s). This means that bidirectional communication has been established between the routers.

ExStart
In this state the master/slave relationship is established necessary to exchange Database Description Packets. Since all the packets have their sequence number allowing routers to detect more recent information, initial numbers are negotiated in this state. The router with the highest Router ID becomes the master.

Exchange
The routers will send Database Description packets (description of the LDSB). Link State Request packets to request more recent LSAs are also sent in this state.

Loading
The Link State Request packets are sent to neighbors in the loading state. They request more recent LSAs discovered in the Exchange state. Link State Updates are sent in response to LSRs.

Full
OSPF neighbors are fully adjacent. All information about networks/subnets have been exchanged and acknowledged. 

OSPF Packet Types
In the Neighbor State Machine description, a few types of OSPF packets were mentioned. OSPF uses five types of packets for communication. Take a look at them (pic. 2):

Pic. 2 - OSPF Packet Types.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

Type 1 - Hello
This packet type is used to discover neighbors and maintain the adjacencies between them. More details regarding a hello packet will be presented in the next post.

Type 2 - Database Description
It is used to describe the LSAs so that the receiving router (neighbor) can determine if all LSAs have been synchronized between them (all routers in the area must have the same LSDB). It is accomplished by exchanging the headers of LSAs (Database Description packets aka DD packets) with the neighbor(s). The receiving router will check if it has a match for all LSAs in its local database. If not, LSR packets are sent to retrieve the missing LSAs.

Type 3 - Link State Request
During the exchange state the router creates a list of all missing or older LSAs in the so called Link State Request List. Then, it sends one or more LSR packets asking the neighbor for the copy of all these LSAs.

Type 4 - Link State Update
It is the response to LSR packets. Contains one or more LSAs which are sent to the neighbor which sent LSR. Upon receiving them the router is flooding them to all its neighbors in order to maintain the same LSDB within the OSPF area.

Type 5 - Link State Acknowledgment
Each LSA the router receives must be acknowledged in order to synchronize the LSDB with neighbors reliably. This packet is used to acknowledge the reception of all LSAs.

This lesson's terminology should make it easier for you to understand some details of OSPF operation presented in the upcoming lessons.

In my next post, I will focus in on the process of building adjacency between OSPF routers.

Lesson 33 - Static Routing


In the previous post I attempted to explain how a router selects the best route if there are multiple paths available. In this lesson, I'm going to show you how you can use static routes effectively in two different topologies (the second one uses backup links). You'll see how basic knowledge on route selection can come in handy if you plan on using primary and backup connections.

All Cisco routers have the routing capability turned ON by default. The command responsible for this is:

router(config)#ip routing

This allows a router to create and use the routing table the moment we enable and configure at least two interfaces.


NOTICE!
Some subnets and networks are simulated by means of creating and configuring virtual interfaces (Loopback) in my topology.



Pic. 1 - Routing Topology 1

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Directly Connected Networks
In the topology used (pic. 1), the routers have been assigned IP addresses and the interfaces are up. Since the routing process is enabled (ip routing) the directly connected subnets/networks show in the routing table immediately. Look at R1's routing table:

Pic. 2 - Directly Connected Networks.

The problem is with the destinations that are NOT connected directly to a router (remote). A router does not know anything about these by default. There are two ways of "teaching" a router about remote networks or subnets:
  1. Applying static routing (manual method)
  2. Applying dynamic routing (a routing protocol that distributes information automatically)
Static Routing
There are pros and cons of using manual method. In complex scenarios (with redundant connections), more often than not, we use dynamic routing protocols. But there are situations in which static routing is good or perhaps the best solution.

Consider our example. R4 and R5 are connected to so called stub networks. A stub network hasonly one way in and out (one path). Some routers used in such designs are relatively cheap and may not even have enough hardware resources to run a dynamic routing protocol (such as OSPF or EIGRP). Then, installing static routes is the only option possible. Also, imagine your broadband router (your home network is also the stub-like if you're connected to one ISP). This router does not have the paths to each and every destination on the Internet. It uses a form of static route instead known as: default route. More on the default route later in the post.

Let's look at the syntax which allows us to instruct a router about remote networks and subnets manually.
Pic. 3 - Static Route Command Version 1.
Let's read what this command does. 
"IP route towards class C network 192.168.1.0/24 can be reached by sending packets to a next-hop router out the serial0/2 interface."

The last parameter used shows the router which interface should be used to send the packets out. If you configure the outbound interface instead of the IP address of the next-hop router in the path, this connection must be point-to-point (not multiaccess).

In case, the router's egress (outbound) interface is multiaccess link (Ethernet, Frame-Relay, ATM etc.), we must NEVER use local interface but IP address of the next-hop router instead. If you do not follow this recommendation, the router will try to resolve the layer 3 to layer 2 address for every destination out that interface. This leads to serious inefficiency and shows little understanding of routing operation of a person who used it.

If the router must send the packet to the next router in order to get to the destination (egress interface is multiaccess), the 'ip route' command should look like the example below (pic. 4).

Pic. 4 - Static Route Command Version 2.
Let's configure our routers so they can reach all networks int the topology used (pic. 1).

NOTICE!
The routing works in both directions. This means that the router receiving packet to its directly connected network/subnet must know the returning path to the sender of the packet (source).



Configuration on R1

Step 1
Reachability towards 172.31.2.0/24. The next-hop router is R2. The outbound interface is multiaccess link (F1/0). The order of statements does not matter. Configuring the remaining routers I will use a more logical approach than on R1.

R1#configure terminal
R1(config)#ip route 172.31.2.0 255.255.255.0 172.31.123.2
R1(config)#

Step 2
Reachability towards 172.31.3.0/28 and 172.31.16.0/28. The same egress interface (F1/0).

R1(config)#ip route 172.31.3.0 255.255.255.240 172.31.123.3
R1(config)#ip route 172.31.3.16 255.255.255.240 172.31.123.3
R1(config)#

Step 3
Reachability towards 192.168.4.0/24. The egress interface is point-to-point (S0/2 running HDLC protocol). I can use either the next-hop IP address or the local interface s0/2.

R1(config)#ip route 192.168.4.0 255.255.255.0 s0/2
R1(config)#

Step 4
In order to reach Branch2 network 192.168.5.0/24, R1 must use R2 as the gateway. Even though R2does not know how to get there now, I will configure it and then configure R2 to reach all networks and subnets (including 192.168.5.0/24).

R1(config)#ip route 192.168.5.0 255.255.255.0 172.31.123.2
R1(config)#

Step 5
Reachability to the point-to-point subnet between R2 and R5 (172.31.25.0/24).

R1(config)#ip route 172.31.25.0 255.255.255.0 172.31.123.2
R1(config)#


Now, let's see what the routing table reveals:

Pic. 5 - Routing Table of R1.
 

Before I proceed with the configuration of the other routers let's consider a few things.

Look at the R1's routing table and the topology carefully, and try to answer the following questions before you test the reachability using 'ping'. If you have problems answering the questions 1, the remaining ones (2-4) should give you a few hints.

Question 1
How many IP addresses presented in the topology (pic. 1) will respond to ping from R1 after you have configured static routes so far (only R1 is configured with static routes; all other routers have IP addresses and interfaces enabled)?

Question 2
R1 sends ping (echo request) towards 192.168.4.1. What is going to be the source IP address of this request?

Question 3
R1 sends ping (echo request) towards 172.31.25.2. Is R1 going to receive reply (echo reply)? Why?

Question 4
R1 sends ping (echo request) towards 172.31.25.5. Is R1 going to receive reply (echo reply)? Why?

If you have answered them, check if you were right. The answers are as follows.

Answer 1
There are 11 IP addresses to respond to the ping sent by R1. These are:

  • 172.31.1.1 - reason: directly connected subnet (Loopback 1).
  • 172.31.123.1 through 3 - reason: directly connected subnet (F1/0).
  • 172.31.3.1 and 172.31.3.17 - reason: source IP address is the 172.31.123.1. It's the egress interface to reach these two addresses (via F1/0). R3 knows how to get back toR1's F1/0 interface (R3's F1/0 is connected to 172.31.123.0/24 too).
  • 172.31.2.1 and 172.31.25.2 - reason: R1 will use F1/0 (egress interface) to reach these IP addresses according to our 'ip route' statements. The source IP address is going to be the address of F1/0. R2 knows its way back to 172.31.123.0/24 subnet (directly connected to F1/0).
  • 172.31.14.1172.31.14.4 and 192.168.4.1 - reason: R4 knows how to get back to the source IP address R1 uses for these destination. R1 uses 172.31.14.1 as the source IP address. This source (subnet 172.31.14.0/24) is shared between R1 and R4 on their Serial0/2 interfaces.
The reason I ask this question is to draw your attention to two important facts:
  • A router is going to find the best match in the routing table for each destination. If not found, of course the packet is dropped. If found though, a router will not change the source and destination addresses in packets TRAVERSING it. If the packet isORIGINATED by the router (here: ping), the source of IP address used is going to be the address of its egress (outbound) interface by default.
  • Sending a packet out is one job, but the destination will try to send a response back to the source. The remote router which is going to respond, must know how to reach the source of the transmission as well (valid path back to the source in its routing table).
Answer 2
Ping from R1 towards 192.168.4.1 is going to use 172.31.14.1 as its source address since according to the routing table Serial0/2 is the outbound interface.

Destination 192.168.4.1 shows the following detailed output on R1:

Pic. 6 - R1's Route Towards 192.168.4.1.

The route shows that the longest match for 192.168.4.1 is: 192.168.4.0/24. This routing table entry points to Serial0/2 as an egress interface.

Answer 3
R1 sends the ping (echo request) packet towards 172.31.25.2. Like explained in the answer 2, the source IP address for this echo request is going to be the address of the outbound interface (FastEthernet1/0). R2 knows how to reply back to 172.31.123.1 since R2 is directly connected to the subnet 172.31.123.0/24 with its FastEthernet1/0 interface.

Answer 4
R1 sends the ping (echo request) packet towards 172.31.25.5. It is NOT going to get the reply fromR5. The reason is that R5 does not know how to reply back to the source (172.31.123.1). It has not been configured to reach remote subnets and networks yet.

I hope you have found this little quiz entertaining and informative enough.

Would you know how to configure R2 and R3 using R1's configuration as an example? Give it a try. If you can't do it yet, just follow the configuration presented below.

Configuration on R2

Step 1
Reachability to networks/subnets via R1.

R2#configure terminal
R2(config)#ip route 172.31.1.0 255.255.255.0 172.31.123.1
R2(config)#ip route 172.31.14.0 255.255.255.0 172.31.123.1
R2(config)#ip route 192.168.4.0 255.255.255.0 172.31.123.1
R2(config)#

Step 2
Reachability to networks/subnets via R3.

R2(config)#ip route 172.31.3.0 255.255.255.240 172.31.123.3
R2(config)#ip route 172.31.3.16 255.255.255.240 172.31.123.3
R2(config)#

Step 3
Reachability to network via R5.

R2(config)#ip route 192.168.5.0 255.255.255.0 s0/2
R2(config)#

Configuration on R3

Step 1
Reachability to networks/subnets via R1.

R3#configure terminal
R3(config)#ip route 172.31.1.0 255.255.255.0 172.31.123.1
R3(config)#ip route 172.31.14.0 255.255.255.0 172.31.123.1
R3(config)#ip route 192.168.4.0 255.255.255.0 172.31.123.1

Step 2
Reachability to networks/subnets via R2.

R3(config)#ip route 172.31.2.0 255.255.255.0 172.31.123.2
R3(config)#ip route 172.31.25.0 255.255.255.0 172.31.123.2
R3(config)#ip route 192.168.5.0 255.255.255.0 172.31.123.2
R3(config)#


As for the routers R4 and R5 they connect stub networks. In order to simplify the configuration on these and reduce the number of entries on them, I am going to use a special type of static route called: the default route.

Pic. 7 - Default Route Example.

The destination IP address 0.0.0.0 (unknown) represents all destination which cannot be found in the routing table. This address uses the network mask of all zeros (0.0.0.0). As long as the router does not have the best match in the routing table for a given destination ('subnet not in table') the default route is going to be used instead. It is the 'gateway of last resort'. Like previously explained, on point-to-point links you can use the outbound interface instead of the address of the next-hop router.

Applying default routes is going to be easy.

Configuration on R4
Step 1
Packets for all unknown destinations send via R1.

R4(config)#ip route 0.0.0.0 0.0.0.0 s0/2
R4(config)#

Configuration on R5
Step 1
Packets for all unknown destinations send via R2.

R5(config)#ip route 0.0.0.0 0.0.0.0 s0/2
R5(config)#

Simple test will prove the default route operation:

Pic. 8 - Default Route Test.

Even though the routing table does not have the route towards 192.168.5.1, the packets are delivered using the default route (via R1 which knows how to get there).

Look what the routing table shows when default route has been added (pic. 9).

Pic. 9 - Routing Table with Default Route.


Static Routing with Primary and Backup Links
In order to spice things up, I am going to configure two additional connections from HQ to our branches using Frame-Relay. These redundant paths must be used as the backup links. They should be used in the case of losing main path via Serial0/2 interfaces (down).

Pic. 10 - Routing Topology with Redundant Paths.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Please, disregard my configuration of Frame-Relay links for now. I'm going to address WAN protocols in the upcoming posts. I only need the extra connectivity to show you how to handle the primary and backup scenario using static routing.

Frame-Relay Configuration is going to look like this in order to reflect the topology in the pic. 10.

Circuit Between R1 and R5

R1 Configuration:

R1(config)#interface serial0/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#ip address 172.31.15.1 255.255.255.0
R1(config-if)#frame-relay map ip 172.31.15.5 105 broadcast
R1(config-if)#no shutdown
R1(config-if)#

R5 Configuration:

R5(config)#interface serial0/0
R5(config-if)#encapsulation frame-relay
R5(config-if)#no frame-relay inverse-arp
R5(config-if)#ip address 172.31.15.5 255.255.255.0
R5(config-if)#frame-relay map ip 172.31.15.1 501 broadcast
R5(config-if)#no shutdown
R5(config-if)#

Circuit Between R2 and R4

R2 Configuration:

R2(config)#interface serial0/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#no frame-relay inverse-arp
R2(config-if)#ip address 172.31.24.2 255.255.255.0
R2(config-if)#frame-relay map ip 172.31.24.4 204 broadcast
R2(config-if)#no shutdown
R2(config-if)#

R4 Configuration:

R4(config)#interface serial0/0
R4(config-if)#encapsulation frame-relay
R4(config-if)#no frame-relay inverse-arp
R4(config-if)#ip address 172.31.24.4 255.255.255.0
R4(config-if)#frame-relay map ip 172.31.24.2 402 broadcast
R4(config-if)#no shutdown
R4(config-if)#

Now let's get back to the business. If I add two static route entries using the newly created paths, the metric of each of them is going to be identical with the metric used by the primary link (Serial0/2). This way, load balancing (traffic sharing) is going to be used since two equal cost paths exist. Our design stipulates that Frame-Relay circuits should be used as the backup links only (Serial0/2 down).

In order to accomplish this, I should change either the metric or administrative distance of the backup path. Unfortunately, we cannot change the metric (no command available) on static routes, but we can easily increase the value of administrative distance to make the backup path less preferred. The default AD for static routes is 1, so I will make the backup route less trusted by using the value of, say, 3.

Backup Link Between R1 and R5

R1 Configuration:

R1(config)#ip route 192.168.5.0 255.255.255.0 172.31.15.5 3
R1(config)#

R5 Configuration:

R5(config)#ip route 0.0.0.0 0.0.0.0 172.31.15.1 3
R5(config)#
  
Backup Link Between R2 and  R4

R2 Configuration:

R2(config)#ip route 192.168.4.0 255.255.255.0 172.31.24.4 3
R2(config)#

R4 Configuration:

R4(config)#ip route 0.0.0.0 0.0.0.0 172.31.24.2 3
R4(config)#

This way, the primary link (via Serial0/2) is preferred due to the lower administrative distance (AD=1). Look at R4 now:

Pic. 11 - R4's Routing Table with Primary Link UP.

In case the primary link goes down, the extra ip route (using Frame-Relay link) kicks in like shown in the pic. 12.
Pic. 12. - R4's Routing Table with Primary Link DOWN.



In the few upcoming posts, I will focus in on dynamic routing protocols.

Lesson 24 - Layer 2 Etherchannel



There are two more things I would like to cover in this Cisco fundamentals series that relates to switches: the etherchannel technology and switch port security. Then we move on to layer 3 stuff.

Layer 2 Etherchannel

When you're designing your network one of the factors you always consider is resiliency. Redundant connections are part of a good design. Consider picture 1 below. A rule of thumb says that if all the devices connected to SW3 (access switch on first floor) were transmitting at full speed towards distribution switches (here towards SW1) the traffic is allowed to exceed the capacity of F0/2 port onSW1 20 times. In other words, the link between access layer could oversubscribe 20:1 the link on the distribution switch. Well, it is true in most cases. Remember this is just a rule for an average network.

Pic. 1 - 2-tier network design (access+distribution layer).
Icons designed by: Andrzej Szoblik - http://www.newo.pl

In reality, the situation in which all computers begin to transmit at full speed at the same time never happens. The studies show, that the link between access and distribution switch is utilized in 7% on the average (unless some worm has been planted on your computers). In order to live up to this rule (oversubscription 20:1) you might consider access-to-distribution connection using multiple links that form a virtual connection called: etherchannel. Ports that are members of the etherchannel are represented by a virtual interface called: port-channel.

Etherchannel Advantages
Etherchannel is often used between the switches in order to increase the capacity of the connection between them by performing a load balancing of the frames traversing the channel. Load sharing (balancing) is based either on source or destination MAC address of the transmitting computers when layer 2 etherchannel is used. In case of an active link failure (the port in the channel that transmits the frames), the next link is going to transmit the packets with almost no delay. Keep in mind that the word: etherchannel, is a Cisco term. The industry standard name is link aggregation(IEEE 802.3ad).

Enough of the terminology and reasons for using the technology. Let's get practical.


Cisco offers you three ways of configuring the etherchannel ( three modes of operation):

  1. Dynamic channel negotiation using Link Aggregation Control Protocol (LACP) which is the industry standard implementation.
  2. Dynamic channel negotiation using Port Aggregation Protocol (PAgP) which is Cisco proprietary implementation.
  3. Manual channel configuration without using any form of negotiation.
Etherchannel is a very picky technology. For the channel to be formed correctly (without STP loops etc.), there are a lot of link parameters that must match between switches. Even though I'm not a big fan of "automatic", "I-think-for-you" methods, using either LACP or PAgP seems to be a good idea here. If the channel cannot be formed we have a better reporting as to what went wrong and better protection against the loops that might form between switches on mis-configured channels. But if you use switches from different vendors and dynamic methods fails, even though all parameters, are correct, you can always resort to a manual method.

If I decided to use etherchannel in the topology presented in Pic. 1, I could use the following setup using at least two connections between, each forming a single connection like shown below:

Pic. 2 - Redundant Topology with Etherchannels.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

For the argument sake I will use a simple network topology below (pic. 3). Now, let's see the configuration options.

Pic. 3 - Topology
Icons designed by: Andrzej Szoblik - http://www.newo.pl

Etherchannel using LACP
If you want to configure an etherchannel using a dynamic exchange of packets that is compliant with an industry standard method, the IOS offers you two mode options:

  • active - in this mode the ports are actively sending negotiation frames to the other switch checking if the required parameters match and the channel can be safely formed.
  • passive - in this mode the ports are waiting for the negotiation frames from the other switch in order to form a channel. The ports in the passive mode do NOT initiate any negotiation, but they will reply to negotiation frames received from a neighbor.
In pic. 3, if the parameters between ports F0/13 and F0/14 on SW1 and SW2 are correct (speed, duplex, trunking, vlans allowed etc.), the following channel modes will succeed in forming the etherchannel:
  • SW1 active - SW2 active
  • SW1 active - SW2 passive
  • SW1 passive - SW2 active

NOTICE!
In case, when both use channel mode passive, the etherchannel will not form since no switch is going to start negotiation.

NOTICE!
It is imperative that you check all the settings of the ports first (all ports must have identical configuration). Candidate ports must be in the shutdown mode. This precaution is used to avoid loops and other issues while establishing the etherchannel.



Etherchannel using PAgP
Port Aggregation Protocol is Cisco proprietory protocol helping establish a virtual link between devices using dynamic negotiation (PAgP frames). Similarly to LACP, it has two modes of operation.

  • desirable - in this mode, ports initiate negotiation frames and check if ports on a neighboring switch have proper settings to establish the etherchannel. 
  • auto - in this mode, ports cannot initiate negotiation but will respond to the negotiation frames sent by a neighboring switch.
Similarly, assuming that all the port parameters are identical, the following pairs will work in the topology presented above (pic. 3):
  • SW1 desirable - SW2 desirable
  • SW1 desirable - SW2 auto
  • SW1 auto - SW2 desirable

Etherchannel manual
This mode does not exchange any negotiation frames. Be cautious using this method, as switches won't check if port parameters match. Loops can be formed more easily than with the other two methods.

It's time to get our hands dirty!

The configuration assumes that all port parameters are IDENTICAL!

METHOD 1 - LACP (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14
SW(config-if-range)#channel-group 1 mode active
SW(config-if-range)#end
SW#

Verification (here on SW1):

Pic. 4 -  "show etherchannel summary" command.

Pic. 5 - "show etherchannel 1 detail" command.
In the above picture (pic. 5), part of the output has been truncated for a clarity.

METHOD 2 - PAgP (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14
SW(config-if-range)#channel-group 1 mode desirable
SW(config-if-range)#end
SW#

Verification (here on SW1):

Pic. 6 - "show etherchannel summary" command.


Pic. 7 - "show etherchannel 1 detail" output.
 
In the above picture (pic. 7), part of the output has been truncated for a clarity.


METHOD 3 - Manual (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14
SW(config-if-range)#channel-group 1 mode on
SW(config-if-range)#end
SW#

Verification (here on SW1):

Pic. 8 - "show etherchannel summary" command.



Pic. 9 - "show etherchannel 1 detail" command.
In the above picture (pic. 9), part of the output has been truncated for a clarity.


All configurations that do NOT relate to physical aspects of the ports that are member of the etherchannel must be configured on the port-channel interface now. For instance, if you want to change the channel member ports to a trunk or access mode, the configuration must be done as follows:

SW(config)#interface port-channel 1
SW(config-if)#switchport trunk encapsulation dot1q
SW(config-if)#switchport mode trunk 


I hope this will help you get started. For more information on etherchannel, please refer to Cisco documentation.

In my next post I am going to present switch port security. After that, get ready for layer 3 stuff.