Network Analyst: 03/10/10

Cisco EtherChannel

Introduction

Etherchannel (also referred to as "Fast Etherchannel" or simply "trunking") is a scheme to trunk together multiple 10/100 Mb/s Ethernet links to form a single, fat pipe in order to:

load-balance traffic over the physical links; and
recover from link failures.

Etherchannel was originally proposed by Sun and picked up by Cisco. Cisco and Sun (and host of switch vendors) currently support Etherchannel in their products. Etherchannel is typically used in LAN backbones for switch-switch, router-switch or server-switch/router connectivity.
In what follows, the terms "Etherchannel" and "trunking" are used interchangeably.
Why Etherchannel?

Etherchannel provides a fat pipe by linking together multiple 10/100 BaseT links.
Etherchannel provides load-balancing of traffic over the physical links.
Etherchannel provides recovery from link failures.
Etherchannel uses 10/100BaseT technology as its core. This leverages investments in existing network infrastructure (UTP wiring, 10/100 switches, etc.). The only thing required is a software upgrade on switches, routers and servers.
Even though Gigabit Ethernet products are shipping, products that enable Gigabit Ethernet over copper (4 pairs of UTP cabling) are not going to be shipped for a several years. Etherchannel gives customers reluctant to switch to fiber in the LAN backbones an alternative to Gigabit Ethernet.

What is Etherchannel?

As mentioned above, the basic idea in Etherchannel is really simple. The idea is to take some (small number) of Ethernet links and trunk them together. Most switches/routers provide trunking of 2 to 4 links. This trunk looks like a single network pipe to the upper layers (and is administered as a single network pipe). Load balancing is achieved by distributing traffic out onto the physical links. The distribution of outgoing traffic over the links forming the trunk is described below. Furthermore, a trunk with N links can recover from failure of any (N - 1) links by distributing traffic over the remaining links.
Basically, there are two parts to Etherchannel. The first deals with how the links are configured to form a trunk. The second deals with how traffic flowing out on the trunk is load-balanced over the physical links.

Let's proceed further and we will see how to configure a Layer 3 Ether channel using the PAgp Protocol (Port Aggregation Protocol) in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 3 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

ITKESW01#config t

ITKESW01(config)# interface port-channel 1

ITKESW01(config-if)# no switchport

ITKESW01(config-if)# no shutdown

ITKESW01(config-if)# ip address 192.168.1.1 255.255.255.0

ITKESW01(config-if)# end

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)# no switchport

ITKESW01(config-if-range)# no ip address

ITKESW01(config-if-range)# channel-group 1 mode desirable

ITKESW01(config-if-range)#end

Note: This example shows how to configure Gigabit Ethernet ports 0/45 – 0/48   into port channel 1 with PAgP mode desirable

Note: The "no switchport" command is required to change interface from layer2 to layer3 mode.

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#config t

ITKESW02(config)# interface port-channel 1

ITKESW02(config-if)# no switchport

ITKESW02(config-if)# no shutdown

ITKESW02(config-if)# ip address 192.168.1.2 255.255.255.0

ITKESW02(config-if)# end

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)# no switchport

ITKESW02(config-if-range)# no ip address

ITKESW02(config-if-range)# channel-group 1 mode auto

ITKESW02(config-if-range)#end

Note: This example shows how to configure Gigabit Ethernet ports 0/1 – 0/4   into port channel 1 with PAgP mode auto

Note: The "no switchport" command is required to change interface from layer2 to layer3 mode.

Do use "show etherchannel" command to display port-channel information after configuration and remember to save the configuration.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 7

Now it's the time to proceed further and we will see how to configure a Layer 2 Etherchannel using the LACP Protocol (Link Aggregation Protocol) in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 2 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are trunk ports and they are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/4 (also trunk ports in desirable mode) in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

First run the command "Show interfaces trunk

ITKESW01#sho interfaces trunk

Port        Mode             Encapsulation Status       Native vlan

Gi0/45      desirable                n-isl         trunking            1

Gi0/46      desirable               n-isl         trunking            1

Gi0/47      desirable                n-isl         trunking            1

Gi0/48      desirable                n-isl         trunking            1

Port        Vlans allowed on trunk

Gi0/45        1-4094

Gi0/46        1-4094

Gi0/47        1-4094

Gi0/48       1-4094

Port        Vlans allowed and active in management domain

Gi0/45        1

Gi0/46       1

Gi0/47       1

Gi0/48        1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/45      1

Gi0/46       1

Gi0/47       1

Gi0/48       1

ITKESW01#

Second Step configure the Giga Ethernet ports 0/45 to 0/48 in the Etherchannel

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)# channel-protocol lacp

Note: LACP protocol is configured to be used in this channel

ITKESW01 (config-if-range)# channel-group 1 mode active

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode active to be used in LACP

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/1      desirable            n-isl         trunking            1

Gi0/2      desirable            n-isl         trunking            1

Gi0/3      desirable            n-isl         trunking            1

Gi0/4      desirable            n-isl         trunking            1

Port        Vlans allowed on trunk

Gi0/1        1-4094

Gi0/2        1-4094

Gi0/3        1-4094

Gi0/4        1-4094

Port        Vlans allowed and active in management domain

Gi0/1        1

Gi0/2        1

Gi0/3        1

Gi0/4        1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1       1

Gi0/2       1

Gi0/3       1

Gi0/4       1

ITKESW02#

Second Step configure the Giga Ethernet ports 0/1 to 0/4 in the Etherchannel

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)#channel-protocol lacp

Note: LACP protocol is configured to be used in this channel

ITKESW02 (config-if-range)# channel-group 1 mode active

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode active to be used in LACP

Now run show command to display the Etherchannel configurations on the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02

ITKESW01#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          LACP      Gi0/45 (P)   Gi0/46 (P)  Gi0/47 (P)  Gi0/48 (P)

ITKESW01#

ITKESW02#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          LACP     Gi0/1 (P)   Gi0/2 (P)  Gi0/3 (P)  Gi0/4 (P)

ITKESW02#

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 6

An Etherchannel in a Cisco IOS can be defined as Layer 2 Etherchannel or a Layer 3 Etherchannel.

For a Layer 2 Etherchannel, physical ports are placed into an Etherchannel group.

For a Layer 3 Etherchannel, layer 3 SVI (Switch Virtual Interface) is created, and then the physical ports are placed into an Etherchannel group which is bound to the L3 SVI.

Now let's see how to configure a Configure a Layer 2 Etherchannel in a Cisco Catalyst Switch using a PAGP (port aggregation protocol) Protocol. In my previous posts I did discussed about the PAGP protocol, it's a Cisco proprietary protocol, can be applied only in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 2 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are trunk ports and they are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/4 (also trunk ports) in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

First run the command "Show interfaces trunk

ITKESW01#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/45      on                        802.1q         trunking            1

Gi0/46      on                        802.1q         trunking            1

Gi0/47      on                        802.1q         trunking            1

Gi0/48      on                        802.1q         trunking            1

Port        Vlans allowed on trunk

Gi0/45       1-4094

Gi0/46        1-4094

Gi0/47        1-4094

Gi0/48        1-4094

Port        Vlans allowed and active in management domain

Gi0/45       1

Gi0/46       1

Gi0/47       1

Gi0/48       1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/45      1

Gi0/46      1

Gi0/47      1

Gi0/48      1

ITKESW01#

Second Step configure the Giga Ethernet ports 0/45 to 0/48 in the Etherchannel

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)#channel-protocol pagp

Note: PAgP protocol is configured to be used in this channel

ITKESW01 (config-if-range)# channel-group 1 mode desirable

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode desirable to be used in PAgP

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/1      on                        802.1q         trunking            1

Gi0/2      on                        802.1q         trunking            1

Gi0/3      on                        802.1q         trunking            1

Gi0/4      on                        802.1q         trunking            1

Port        Vlans allowed on trunk

Gi0/1       1-4094

Gi0/2        1-4094

Gi0/3        1-4094

Gi0/4        1-4094

Port        Vlans allowed and active in management domain

Gi0/1       1

Gi0/2       1

Gi0/3       1

Gi0/4       1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1      1

Gi0/2      1

Gi0/3      1

Gi0/4      1

ITKESW02#

Second Step configure the Giga Ethernet ports 0/1 to 0/4 in the Etherchannel

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)#channel-protocol pagp

Note: PAgP protocol is configured to be used in this channel

ITKESW02 (config-if-range)# channel-group 1 mode auto

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode auto to be used in PAgP

Now run show command to display the Etherchannel configurations on the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02

ITKESW01#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          PAgP      Gi0/45 (P)   Gi0/46 (P)  Gi0/47 (P)  Gi0/48 (P)

ITKESW01#

ITKESW02#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          PAgP      Gi0/1 (P)   Gi0/2 (P)  Gi0/3 (P)  Gi0/4 (P)

ITKESW02#

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 5

Now let's see what options are available for load balancing in an Etherchannel bundle. How does the Cisco Catalyst Switch determines which physical link in the Etherchannel bundle to use to forward the data?

The answer is the Cisco Catalyst Switch uses a polymorphic algorithm taking key fields from the header of the packet to generate a hash to a physical link in the Etherchannel group.

Data sent across an Etherchannel is not load-balanced equally between all interfaces. Etherchannel utilizes a load-balancing algorithm, which can be based on several forms of criteria, including:

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 4

The automate creation of an Etherchannels group can occur only when the Cisco Switches are running same Etherchannel protocols. Using different Etherchannel protocols at each end will not work. One more important criterion for the automated creation of the Etherchannel is the links must share the similar physical characteristics.

Configuration of ports into an Etherchannel are based on pre defined Etherchannel modes that are assigned as a default or modified via user configuration to an Ethernet port. There are five Etherchannel modes, which can be used for automated creation of an Etherchannel .

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 3

Basically there are two types of protocols are available, which can be used to bundled the automated creation of an Etherchannel in the Cisco Catalyst Switches.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 2

·         An Etherchannel Group Number must be in the range of 1 to 256.
·         All ports in the target Etherchannel group MUST be in the same VLAN.
·         If one physical link in the Etherchannel group is a TRUNK, then all other ports must be configured as trunks carrying the same VLAN information.
·         Any defined broadcast limits must be the same across all ports in an Etherchannel.
·         An LACP Etherchannel group cannot support any physical links in half duplex mode.
·         No port in the Etherchannel group can be defined as a SPAN port.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 1

An Etherchannel combines multiple physical links into a single logical link that provides aggregate bandwidth of 800 MBPS (fast Etherchannel, full duplex) , 8 GBPS (Giga Etherchannel) or 80 Gbps (10 Giga Ethernet) . Ideal for load sharing or link redundancy – can be used by both layer 2 and Layer 3 subsystems and Etherchannel can provide network managers with a reliable, high-speed solution for the campus network backbone. EtherChannel technology was invented by Kalpana in the early 1990s. They were later acquired by Cisco Systems in 1994. In 2000 the IEEE passed 802.3ad which is an open standard version of EtherChannel.

I would like to explain some key points about Etherchannel using graphical diagrams so that it's easy understand and to remember.

Etherchannel can be configured defined on Ethernet, Fast Ethernet, Giga Ethernet or 10 Giga Ethernet ports

Scenario : Verifying BGP Operation

Scenario : Verifying BGP Operation

This final scenario looks at Cisco IOS mechanisms for monitoring and verifying BGP routing within a Cisco router network.

The BGP topology to see how to use some common show commands to verify that BGP is operating correctly.

Show and debug commands can be valuable, not only in the real-life networks you come across, but also during your certification exams.

This scenario covers the following commands:

show ip bgp
summary— Displays BGP neighbors in summary mode
show ip bgp— Displays the BGP topology table
clear ip bgp *— Clears all BGP TCP sessions
show tcp brief— Displays all TCP sessions (BGP uses TCP)
debug ip bgp events— Displays any BGP events, such as neighbor state changes

Example 6-73 displays a sample output taken from R1 using the IOS show ip bgp summary command.

Example 6-73. show ip bgp summary on R1

R1#show ip bgp summary

BGP router identifier 131.108.255.13, local AS number 1

BGP table version is 11, main routing table version 11

6 network entries and 10 paths using 854 bytes of memory

3 BGP path attribute entries using 280 bytes of memory

BGP activity 50/44 prefixes, 73/63 paths

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

131.108.1.2 4 1 194 195 11 0 0 00:03:22 2

131.108.255.6 4 1 84 83 11 0 0 00:03:23 3

131.108.255.14 4 1 152 152 11 0 0 00:03:23 3

141.199.1.1 4 1001 0 0 0 0 0 never Idle

Example 6-73 displays a lot of useful information, including the local router identifier 131.108.255.13, the local AS of 1, and the BGP table version of 11. (An increasing version number indicates a network change is occurring; if no changes occur, this number remains the same.) It also shows six network paths on R1, using 854 bytes of memory.

Memory is important in BGP because in a large network, such as the Internet, memory can be a limiting factor. As more BGP entries populate the IP routing table, more memory is required. Example 6-73 displays four configured remote peers: the first three are IBGP (because the AS is 1 and the same as the local AS) and one remote peer that has never been active. (The output indicates an idle session, and the up/down time displays this connection was never established.)

The BGP table is one that confuses most people. Most engineers are familiar with a standard Cisco IOS IP routing table and mistakenly apply the same principles to the BGP table. The BGP table is not an IP routing table. The BGP table displays information, such as remote and local network entries, BGP attributes, and selected paths. Entries are then inserted into the IP routing table.

Example 6-74 displays the BGP table on R1. Notice the show ip bgp command can be performed in executive mode.

Example 6-74. show ip bgp

R1>show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2 0 100 1000 i

* i 131.108.255.14 0 100 1000 i

*> 131.108.255.4/30 0.0.0.0 0 32768 i

* i 131.108.255.6 0 100 1000 i

*>i131.108.255.8/30 131.108.1.2 0 100 1000 i

* i 131.108.255.6 0 100 1000 i

*> 131.108.255.12/30 0.0.0.0 0 32768 i

* i 131.108.255.14 0 100 1000 i

*>i141.108.1.0/24 131.108.255.6 0 100 1000 i

*>i151.108.1.0/24 131.108.255.14 0 100 1000 i

Again, the BGP table version is displayed as 11 and the local router ID is 131.108.255.13. The various networks are listed along with the next hop address, metric (MED), local preference (Locpref), weight, and the path. The i on the left side (part of the status codes) indicates an internal BGP route and the i on the right side of Example 6-74 indicates the origin. (i is for IGP, part of the origin codes.)

If a BGP configuration change is completed on Cisco IOS routers, the BGP peer session must be cleared. The command to clear all sessions is clear ip bgp *. To clear a single peer router, use the clear ip bgp
peer-ip-address command.

Example 6-75 clears all BGP sessions on R1 after a configuration change to set all IBGP peer localpref attributes to 1000, instead of the default value of 100.

Example 6-75 displays the BGP table after the change is configured and you clear all BGP peers sessions on R1.

Example 6-75. clear ip bgp * and show ip bgp on R1

R1#clear ip bgp ?

* Clear all connections

<1-65535> AS number of the peers

A.B.C.D BGP neighbor address to clear

dampening Clear route flap dampening information

flap-statistics Clear route flap statistics

peer-group Clear BGP connections of peer-group

R1#clear ip bgp *

R1#show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2 0 1000 1000 i

* i 131.108.255.14 0 1000 1000 i

*> 131.108.255.4/30 0.0.0.0 0 32768 i

* i 131.108.255.6 0 1000 1000 i

*>i131.108.255.8/30 131.108.1.2 0 1000 1000 i

* i 131.108.255.6 0 1000 1000 i

*> 131.108.255.12/30 0.0.0.0 0 32768 i

* i 131.108.255.14 0 1000 1000 i

*>i141.108.1.0/24 131.108.255.6 0 1000 1000 i

*>i151.108.1.0/24 131.108.255.14 0 100 1000 i

The ? tool displays a number of options, including clearing BGP sessions based on AS numbers or remote peer address. On Cisco IOS routers, you must clear the BGP sessions if you want a change to take place because BGP does not update changes after a BGP session is established. You can, however, configure soft configurations with the neighbor
peer address
soft-reconfiguration inbound command, which enables you to make changes and not have to clear the TCP peer, resulting in no downtime.

Example 6-76 displays the output from the show tcp brief command on R1.

Example 6-76. show tcp brief

R1#show tcp brief

TCB Local Address Foreign Address (state)

812CC228 131.108.255.5.11040 131.108.255.6.179 ESTAB

812CF508 131.108.1.1.11039 131.108.1.2.179 ESTAB

812D0054 131.108.255.13.11041 131.108.255.14.179 ESTAB

Router R1, as displayed in Example 6-76, has three TCP sessions in an established state. The TCP port numbers are also listed. This command is useful because you need to be certain that TCP is active at Layer 4 of the OSI model when troubleshooting to discover why two BGP peers are not sending updates, for example. The foreign addresses list the TCP port as 179, and the local address is a number TCP generates. This tells you that R1 has three TCP sessions active, and you can expect BGP to send updates and keepalives across each TCP session.

Debugging BGP is useful. The most widely used tool when establishing why BGP is or is not peering is the debug ip bgp events command. Next, clear all BGP sessions on R1 with this debug command turned on to discover the session you activated.

Example 6-77 displays the sample output taken from R1 when the BGP sessions are cleared for demonstration purposes. You would never use this command during normal working hours, because BGP loses peering to any remote peers. Also, notice that the clear and debug commands are performed in privileged mode.

Example 6-77. debug ip bgp events and clear ip bgp *on R1

R1#debug ip bgp events

BGP events debugging is on

R1#clear ip bgp *

4d01h: BGP: reset all neighbors due to User reset

4d01h: BGP: 131.108.1.2 went from Established to Idle

4d01h: BGP: 131.108.255.6 went from Established to Idle

4d01h: BGP: 131.108.255.14 went from Established to Idle

4d01h: BGP: 131.108.1.2 went from Idle to Active

4d01h: BGP: 131.108.255.6 went from Idle to Active

4d01h: BGP: 131.108.255.14 went from Idle to Active

4d01h: BGP: 131.108.255.6 went from Active to OpenSent

4d01h: BGP: 131.108.255.6 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.255.6 went from OpenConfirm to Established

4d01h: BGP: 131.108.255.6 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.255.14 went from Active to OpenSent

4d01h: BGP: 131.108.255.14 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.255.14 went from OpenConfirm to Established

4d01h: BGP: 131.108.255.14 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.14 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.1.2 went from Active to OpenSent

4d01h: BGP: 131.108.1.2 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.1.2 went from OpenConfirm to Established

4d01h: BGP: 131.108.1.2 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.1.2 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.255.6 computing updates, neighbor version 1, table version 9,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 1,

start version 9, throttled to 9, check point net 0.0.0.0

4d01h: BGP: scanning routing tables

The sample output from Example 6-77 displays the BGP session's teardown state (reset by user) and the re-establishing of TCP sessions to the three peers: 131.108.255.14, 131.108.255.14, and 131.108.1.2. After the sessions are active, only changes are sent across the TCP peers. You can view keepalives with the debug ip bgp keepalives command. Example 6-78 displays a sample output taken from R1 after the TCP peers are established.

Example 6-78. debug ip bgp keepalives on R1

R1#debug ip bgp keepalives

BGP keepalives debugging is on

4d01h: BGP: 131.108.255.6 sending KEEPALIVE

4d01h: BGP: 131.108.255.6 KEEPALIVE rcvd

4d01h: BGP: 131.108.255.14 sending KEEPALIVE

4d01h: BGP: 131.108.255.14 KEEPALIVE rcvd

4d01h: BGP: 131.108.1.2 sending KEEPALIVE

4d01h: BGP: 131.108.1.2 KEEPALIVE rcvd

R1 is sending and receiving keepalives to the three remote peers to ensure that the remote routers are still active. Assume that R1 is reloaded.

If you display the TCP sessions now, you will discover three TCP sessions using a new local TCP port number because the sessions have been re-established and a new random local TCP port number has been chosen by TCP.

Example 6-79 displays the TCP sessions on R1.

Example 6-79. show tcp brief on R1

R1#sh tcp brief

TCB Local Address Foreign Address (state)

812CF984 131.108.255.5.11042 131.108.255.6.179 ESTAB

812CCB20 131.108.1.1.11044 131.108.1.2.179 ESTAB

812CC6A4 131.108.255.13.11043 131.108.255.14.179 ESTAB

BGP Configuration Scenario : BGP with Communities and Peer Groups

BGP Configuration Scenario : BGP with Communities and Peer Groups

BGP deals with large BGP peers by using many different scalable solutions, such as the community attribute and peer groups. In this scenario, you discover how BGP uses the community attribute along with a peer group to ensure that IBGP is scalable in a large network environment. A community is a group of routers sharing the same property. A peer group is a group of BGP neighbors sharing the same update policies.

In this scenario, you configure a well-known BGP community and discover the advantages of peer groups.

Note

The community attribute is a number defined in the range 1 to 4,294,967,200. The IOS set community
community-number [additive] command is used to define a value. Some well-known community attributes, such as no-export (do not advertise to EBGP peers) and no-advertise (do not advertise this route to any peer), can substitute for community-number.

The no export community attribute advises a BGP router carrying this attribute that the route advertised should not be advertised to any peers outside the AS.

The no advertise community attribute advises a BGP router carrying this attribute that the route advertised should not be advertised to any peers.

To apply the community attribute to a remote BGP neighbor, use the neighbor command:

neighbor {ip address | peer group} send-community

Figure 6-5 displays a simple four-router topology, including an Internet connection on R1 and R2. R1 peers to an EBGP peer with the IP address 141.199.1.1 (Remote AS 1001), and R2 peers to an EBGP peer with the IP address 151.100.1.1 (Remote AS 1002). Typically, large companies have more than one Internet connection, so to ensure that R1 and R2 are not the transit paths for any ISP-based traffic, you set the community attribute (well-known) no-export on R1 and R2.

Figure 6-5

Example 6-61 displays the community attribute setting on R1.

Example 6-61. BGP Configuration on R1

R1(config)#router bgp 1

R1(config-router)#neighbor 141.199.1.1 remote-as 1001

R1(config-router)#neighbor 141.199.1.1 send-community

R1(config-router)#neighbor 141.199.1.1 route-map setcommunity ?

in Apply map to incoming routes

out Apply map to outbound routes

R1(config-router)#neighbor 141.199.1.1 route-map setcommunity out

R1 is configured for EBGP and IBGP. The EBGP connection to the remote peer address, 141.199.1.1, is the Internet gateway. Therefore, you must send the 6community to the remote peer and apply an outbound route map, so the Internet routers do not use R1 as a transit path. You have yet to apply the route map named setcommunity (arbitrary name). Example 6-62 displays the route map configuration on R1. Apply the well-known community no-export, which informs the neighboring router not to use R1 for any traffic not destined for the network 131.108.0.0/16.

Example 6-62. Route Map Configuration on R1

R1(config)#route-map setcommunity

R1(config-route-map)#set community ?

<1-4294967295> community number

aa:nn community number in aa:nn format

additive Add to the existing community

local-AS Do not send outside local AS (well-known community)

no-advertise Do not advertise to any peer (well-known community)

no-export Do not export to next AS (well-known community)

none No community attribute

<cr>

R1(config-route-map)#set community no-export

Notice that the ? tool displays all the community variations, including a community number and the two other well-known community values: local-AS and no-advertise.

You must ensure that the ISP connected to R2 does not use R2 as a transit path. Example 6-63 configures R2 to ensure that the ISP is not using the network of Routers R1–R4 as a transit path.

Example 6-63. Community Configuration on R2

R2(config)#router bgp 1

R2(config-router)#neighbor 151.100.1.1 remote-as 1002

R2(config-router)#neighbor 151.100.1.1 se

R2(config-router)#neighbor 151.100.1.1 send-community

R2(config-router)#neighbor 151.100.1.1 route-map setcommunity out

R2(config-router)#exit

R2(config)#route-mapsetcommunity

R2(config-route-map)#set community no-export

The route map name is the same as the name used on R1 because route map names are locally significant on Cisco routers.

Next, configure the four routers, R1–R4, for IBGP, and set the same policies on all four routers. Assume the network designer has asked you to ensure that R1 does not receive any default routes from R2, R3, or R4. Also set the next-hop-self attribute on all IBGP peer sessions. Ensure that R1 sets the community to the value 2000.

For a small network such as this, the configuration on R1 can grow quite large. Take advantage of peer groups and configure one policy, and apply that policy on R1 to all three remote routers (R2, R3, and R4).

First, to demonstrate the power of peer groups, configure IBGP on R1.

Example 6-64 configures R1 for IBGP to R2 only, sets the next-hop-self attribute (no defaults routes permitted), sends the community value of 2000, and sets the weight to 1000.

Example 6-64. R1's IBGP Configuration to R2

R1(config-router)#neighbor 131.108.1.2 route-map setattributes in

R1(config-router)#neighbor 131.108.1.2 next-hop-self

R1(config-router)#neighbor 131.108.1.2 distribute-list 1 in

R1(config-router)#neighbor 131.108.1.2 send-community

R1(config-router)#neighbor 131.108.1.2 weight 1000

R1(config)#route-map setattributes

R1(config-route-map)#set community 2000

R1(config)#access-list 1 deny 0.0.0.0

To configure R1 to set the same attributes and conditions to R3 and R4, you need to complete the same set of IOS commands (seven IOS commands in total) and have different route maps and access lists. Clearly with a large network, this is not scalable.

To create a BGP peer group, use the neighbor peer-group command, beginning in router configuration mode. Example 6-65 creates a peer group on R1 named internal; again, the name is an arbitrary name.

Example 6-65. Peer Group Command on R1

R1(config)#router bgp 1

R1(config-router)#neighbor internal peer-group

You must then assign the options, such as the weight and community value, to the peer groups. Example 6-66 displays all the available options you can assign to a peer group.

Example 6-66. Peer Groups Options

R1(config-router)#neighbor internal ?

advertise-map specify route-map for conditional advertisement

advertisement-interval Minimum interval between sending EBGP routing updates

default-originate Originate default route to this neighbor

description Neighbor specific description

distribute-list Filter updates to/from this neighbor

ebgp-multihop Allow EBGP neighbors not on directly connected

networks

filter-list Establish BGP filters

maximum-prefix Maximum number of prefix accept from this peer

next-hop-self Disable the next hop calculation for this neighbor

password Set a password

peer-group Configure peer-group

prefix-list Filter updates to/from this neighbor

remote-as Specify a BGP neighbor

remove-private-AS Remove private AS number from outbound updates

route-map Apply route map to neighbor

route-reflector-client Configure a neighbor as Route Reflector client

send-community Send Community attribute to this neighbor

shutdown Administratively shut down this neighbor

soft-reconfiguration Per neighbor soft reconfiguration

timers BGP per neighbor timers

unsuppress-map Route-map to selectively unsuppress suppressed routes

The shaded sections in Example 6-66 contain the options you set. Example 6-67 displays the setting of a distribution list to stop a default route from being accepted on R1, advertising the next-hop-self attribute, setting the remote AS number to 1 (same on all IBGP peers), and ensuring that community 2000 is sent to R2, R3, and R4.

Example 6-67. Peer Group Definitions

R1(config-router)#neighbor internal distribute-list 1 in

R1(config-router)#neighbor internal next-hop-self

R1(config-router)#neighbor internal remote-as 1

R1(config-router)#neighbor internal route-map setattributes in

Finally, apply these settings to all the remote peers. Example 6-68 shows how to make R2, R3, and R4 members of the peer group called internal.

Example 6-68. Making R2, R3, and R4 Members of the Peer Group Internal

router bgp 1

neighbor 131.108.1.2 peer-group internal

neighbor 131.108.255.6 peer-group internal

neighbor 131.108.255.14 peer-group internal

R1 has defined three remote IBGP peers with one statement that sets all the parameters defined by the peer group internal. You can configure BGP peers to override configuration options if required. The beauty of using peer groups is that you can add more BGP peers by using only one command. This scales much better than configuring a multitude of IOS commands on several routers. Chapter 7 describes two other main methods used in BGP networks to scale in large networks, namely route reflectors (you might notice this network is fully meshed, that is, every BGP routers has a peer to each other) and confederations.

Example 6-69 displays the full working configuration on R1. Take note of the shaded sections that configure R1 to set local-based policies to all three IBGP peers. Peer groups can also be applied to EBGP peers and are commonly used in large ISP networks in which many thousands of customers might have Internet connections.

Example 6-69. R1's Full Working Configuration

hostname R1

enable password cisco

interface Ethernet0/0

ip address 131.108.1.1 255.255.255.0

interface Serial1/0

ip address 131.108.255.5 255.255.255.252

clockrate 128000

interface Serial1/1

Description Link to Internet

ip address 141.199.2.1 255.255.255.252

interface Serial1/2

ip address 131.108.255.13 255.255.255.252

no ip directed-broadcast

router bgp 1

no synchronization

network 131.108.255.4 mask 255.255.255.252

network 131.108.255.12 mask 255.255.255.252

neighbor internal peer-group

neighbor internal remote-as 1

neighbor internal distribute-list 1 in

neighbor internal route-map setattributes in

neighbor 131.108.1.2 peer-group internal

neighbor 131.108.255.6 peer-group internal

neighbor 131.108.255.14 peer-group internal

neighbor 141.199.1.1 remote-as 1001

neighbor 141.199.1.1 send-community

neighbor 141.199.1.1 route-map setcommunity out

access-list 1 deny 0.0.0.0

access-list 1 permit any

route-map setcommuntiy permit 10

set community no-export

route-map setattributes permit 10

match ip address 2

set weight 1000

set community 1000

line con 0

line aux 0

line vty 0 4

end

Example 6-70 displays the full working configuration on R2. Notice R2 is not configured for peer groups.

Example 6-70. R2's Full Working Configuration

hostname R2

enable password cisco

interface Ethernet0/0

ip address 131.108.1.2 255.255.255.0

interface Serial1/0

bandwidth 128

ip address 131.108.255.1 255.255.255.252

no ip directed-broadcast

no ip mroute-cache

interface Serial1/1

Description Link to Internet

ip address 151.100.2.1 255.255.255.252

interface Serial1/2

ip address 131.108.255.9 255.255.255.252

clockrate 128000

router bgp 1

no synchronization

network 131.108.255.0 mask 255.255.255.252

network 131.108.255.8 mask 255.255.255.252

neighbor 131.108.1.1 remote-as 1

neighbor 131.108.255.2 remote-as 1

neighbor 131.108.255.10 remote-as 1

neighbor 151.100.1.1 remote-as 1002

neighbor 151.100.1.1 send-community

neighbor 151.100.1.1 route-map setcommunity out

route-map setcommunity permit 10

set community no-export

line con 0

line aux 0

line vty 0 4

end

Example 6-71 displays the full working configuration on R3. Notice R3 is not configured for peer groups.

Example 6-71. R3's Full Working Configuration

hostname R3

enable password cisco

interface Ethernet0

ip address 141.108.1.1 255.255.255.0

interface Serial0

ip address 131.108.255.6 255.255.255.252

interface Serial1

ip address 131.108.255.10 255.255.255.252

router bgp 1

no synchronization

network 141.108.1.0 mask 255.255.255.0

network 131.108.255.4 mask 255.255.255.252

network 131.108.255.8 mask 255.255.255.252

neighbor 131.108.255.5 remote-as 1

neighbor 131.108.255.9 remote-as 1

no ip classless

route-map setweight permit 10

match ip address 1

set weight 1

route-map setweight permit 20

match ip address 2

line con 0

line aux 0

line vty 0 4

end

Example 6-72 displays the full working configuration on R4. Notice R4 is not configured for peer groups.

Example 6-72. R4's Full Working Configuration

hostname R4

enable password cisco

interface Ethernet0

ip address 151.108.1.1 255.255.255.0

interface Serial0

ip address 131.108.255.2 255.255.255.252

clockrate 125000

interface Serial1

ip address 131.108.255.14 255.255.255.252

clockrate 125000

interface Serial3

ip address 131.108.255.10 255.255.255.252

clockrate 125000

router bgp 1

no synchronization

network 131.108.255.0 mask 255.255.255.252

network 131.108.255.12 mask 255.255.255.252

network 151.108.1.0 mask 255.255.255.0

neighbor 131.108.255.1 remote-as 1

neighbor 131.108.255.13 remote-as 1

line con 0

line aux 0

line vty 0 4

end