NetNotes

Port-channel note

We have the following setup of a port-channel between to Catalyst 3750s - SW1 Gi0/1 and Gi0/2, bundled in a port-channel are connected to Gi0/1 and Gi0/2 on SW2:

SW1:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

SW2:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

In order for the port-channel to form successfully, all port members need to have identical: › Continue reading

Tags: port-channel, Switching

Jeff Doyle on IGP selection

A podcast of a short interview with Jeff Doyle, talking about choosing the right IGP, OSPF, IS-IS etc,

Tags: IGPs, Routing

OSPF Adjacency building. ExStart. Exchange.

The following is a short description of the OSPF adjacency building process and specifically of the Database Description part of it.

We have a serial PPP interconnection between two routers, named R5 and R1. We have just set a hello interval of 5 seconds on the PPP interface serial0/1 between R1(routerID: 1.1.1.254) and R5(routerID; 1.1.1.5), which is different than the default value of 10 seconds, set on the R5 side of the link. After the expiration of the dead-interval, defaulting to 4X hello interval (calculated automatically), during which period R1 has not received a matching hello packet from R5, we can see that R1 drops the neighbor relationship for R5. We can observe this happening with the following:

R1#debug ip ospf adj

Here’s the moment when the neighbor is dropped, with a dead timer expired message, on R1:

R1#
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead, state DOWN
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#

Let’s have a look at the neighbors R1 has for ospf process 1:

R1#sh ip ospf neighb

Neighbor ID Pri State Dead Time Address Interface
1.1.1.3 1 FULL/BDR 00:00:31 192.168.101.254 FastEthernet0/0.101
1.1.1.3 1 FULL/BDR 00:00:31 192.168.102.254 FastEthernet0/0.102
1.1.1.3 1 FULL/ - 00:01:50 192.168.123.3 Serial0/0
1.1.1.5 1 FULL/ - 00:01:55 192.168.123.5 Serial0/0
1.1.1.4 1 FULL/ - 00:01:49 192.168.123.4 Serial0/0
R1#

This confirms 1.1.1.5 has been flushed from the neighbor-table for interface serial0/1, and is no longer recognised as a valid ospf neighbor on this interface. (Note: in the topology used, we have an extra L3 link to 1.1.1.5 through serial0/0 and a frame-relay cloud, connecting to 1.1.1.5 with a specific IP address of 192.168.123.5). In such a situation, the neighbor relationship finite-state-machine cannot move into the Two-Way neighbor state, and the only thing happening are transitions between Down->Init upon receipt of each hello packet from 1.1.1.5 over the serial0/1 interface.

After we have confirmed the neighbor relationship is dropped, we can set the hello-interval back to the default value, in order to let the neighbor relationship to form again and observe the process.

› Continue reading