NetNotes

weird commands on CISCO3825 boot

I was quite disturbed at first when I recently saw the following commands being logged after a router boot-up:

idx   sess           user@line      Logged command
1     1        console@console  |access-list 199 permit icmp host 10.10.10.10 host 20.20.20.20
2     1        console@console  |crypto map NiStTeSt1 10 ipsec-manual
3     1        console@console  |match address 199

4     1        console@console  |set peer 20.20.20.20

5     1        console@console  |exit
6     1        console@console  |no access-list 199
7     1        console@console  |no crypto map NiStTeSt1

In this case I am fully certain that there was nothing connected to the console of the device during the aforementioned boot process… a brief google later it turned out the crypto map in question was part of the autotest process of the crypto accelerator when the router boots up.

http://www.securityfocus.com/archive/75/474377/30/180/threaded

Tags: autotest, crypto accelerator, crypto map

cable testing on a cisco 3750

Catalyst 2960, 2970, 3560/3560-E, и 3750/3750-E switches have a built-in Time-Domain Reflectometer that can be used to test cabling directly from the switchports. TDR is not supported neither on 10Gig interfaces, nor FastEthernet or SFP interfaces.

Example:

SW01#test cable-diagnostics tdr interface gigabitethernet2/1
TDR test started on interface Gi2/1

A TDR test can take a few seconds to run on an interface

Use ’show cable-diagnostics tdr’ to read the TDR results.
SW01#

SW01#sh cable-diagnostics tdr interface gig2/1
TDR test last run on: March 02 00:31:15

Interface Speed Local pair Pair length Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi2/1 100M Pair A 47 +/- 4 meters Pair A Normal
Pair B 48 +/- 4 meters Pair B Normal
Pair C 48 +/- 4 meters Pair C Open
Pair D 48 +/- 4 meters Pair D Open
SW01#

The output shows the outgoing interface, the working bandwidth of the interface, and also which local pair corresponds to which remote one, approximated length of the cabling pair, and the pair status:

• Normal;
• Open - not connected;
• Not Completed - TDR testing was unsuccessful;
• Not supported - TDR testing not supported on the interface;
• Shorted - cable short ;);

Tags: cable testing, Catalyst 3750, Switching, TDR

TCP congestion control and queueing

TCP mechanisms for traffic regulation and congestion-control

Standard TCP implementations have several mechanisms for congestion-avoidance:

• TCP Slow-start - this is the standard method for increasing the amount of data being transported - starting exponentially at one segment, and after a certain point - in a linear way (congestion-avoidance behaviour), and for regulating this amount in cases of congestion after the traffic source;
• TCP congestion-avoidance - works together with TCP Slow-start and defines a means of regulating the volume of data to be sent in TCP - de facto providing something like flow-control at the source;
• TCP Fast retransmit - defines an accelerated retransmission of part of the data, upon receipt of a minimum of 3 duplicate acknowledgements, without waiting for the TCP retransmission timeout to expire;
• TCP Fast recovery - after sending the missing segment of the fast-restransmit mechanism, TCP goes on with linear growing of the amount of information in transport (congestion avoidance), instead of starting a new slow-start from the beginning;

TCP Slow-start

During a TCP session establishment one of the variables being initialized at the end nodes is the cwnd - congestion window. › Continue reading

Tags: congestion avoidance, congestion control, QoS, queueing, slow-start, TCP

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,

 

 Standard Podcast: Play Now | Play in Popup | Download

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