Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Layer 3 EtherChannelRouted Port-ChannelNo Switchport Configuration

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure a Layer 3 EtherChannel between two Layer 3-capable switches, assigning an IP address directly to the port-channel interface rather than to individual physical interfaces, and verify OSPF forms exactly one neighbor relationship across the bundled link rather than treating each physical member as a separate path.

Lab Purpose

Every EtherChannel configured earlier in this series was a Layer 2 switched bundle. A Layer 3 EtherChannel instead combines multiple physical links into a single routed interface, useful for high-bandwidth links between distribution or core Layer 3 switches where the connection needs an IP address directly rather than functioning as a VLAN trunk.

Lab Topology

Switch1 (Layer 3 capable) ---- Gi1/0/1, Gi1/0/2 ----
                                                  Switch2 (Layer 3 capable)

Po1 on Switch1: 10.99.1.1/30
Po1 on Switch2: 10.99.1.2/30

Task 1: Configure the Physical Interfaces as Layer 3 Channel Members

Remove any switchport configuration from Gi1/0/1 and Gi1/0/2 on both switches, and bundle them into a Layer 3 port-channel.

Task 2: Assign an IP Address to the Port-Channel Interface

Configure the IP address directly on Po1 on both switches, rather than on any individual physical interface.

Task 3: Verify the Bundle Formed Correctly

Confirm both member links are bundled and active.

Task 4: Verify Basic Connectivity

Ping between the two Po1 addresses.

Task 5: Enable OSPF and Verify a Single Neighbor Relationship

Enable OSPF on the Po1 interfaces and confirm exactly one neighbor forms, not two.

Solution and Verification

Switch1(config)# interface range gigabitethernet1/0/1-2
Switch1(config-if-range)# no switchport
Switch1(config-if-range)# channel-group 1 mode active

-- "no switchport" is what makes this a
-- Layer 3 bundle rather than the Layer 2
-- switched bundles configured in earlier
-- EtherChannel labs

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# no switchport
Switch2(config-if-range)# channel-group 1 mode active

Switch1(config)# interface port-channel 1
Switch1(config-if)# ip address 10.99.1.1 255.255.255.252
Switch1(config-if)# no shutdown

Switch2(config)# interface port-channel 1
Switch2(config-if)# ip address 10.99.1.2 255.255.255.252
Switch2(config-if)# no shutdown

Switch1# show etherchannel summary

Group  Port-channel  Protocol   Ports
------+-------------+-----------+-----------------------
1      Po1(RU)       LACP       Gi1/0/1(P)  Gi1/0/2(P)
-- "R" in the flags indicates this is a
-- Layer 3 (routed) port-channel, distinct
-- from the "S" (switched/Layer 2) flag
-- seen in earlier EtherChannel labs

Switch1# ping 10.99.1.2

!!!!!
Success rate is 100 percent (5/5)

Switch1(config)# router ospf 1
Switch1(config-router)# network 10.99.1.0 0.0.0.3 area 0

Switch2(config)# router ospf 1
Switch2(config-router)# network 10.99.1.0 0.0.0.3 area 0

Switch1# show ip ospf neighbor

Neighbor ID     Pri   State           Address         Interface
2.2.2.2          1     FULL/  -        10.99.1.2        Port-channel1
-- Exactly one neighbor relationship formed
-- over the single logical Port-channel1
-- interface, rather than OSPF attempting to
-- form separate adjacencies over Gi1/0/1
-- and Gi1/0/2 individually

Key Takeaway

The no switchport command is the single defining difference that converts an EtherChannel from a Layer 2 switched bundle into a Layer 3 routed one — once configured this way, the IP address and any routing protocol configuration belongs entirely on the logical Port-channel interface, never on the individual physical members, exactly mirroring how VLAN and trunk settings were applied to the logical bundle rather than individual members in the Layer 2 EtherChannel labs covered earlier in this series.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه