OSPF Fast Hello – What’s the Point of Changing Hello Multiplier?

OSFP Fast Hello allows you to reduce OSPF convergence time by reducing OSPF Dead Interval to 1 second and Hello Interval to a fraction of 1 second. The command to configure OSPF Fast Hello on Cisco IOS is the following:

ip ospf dead-interval minimal hello-multiplier 5

Dead Interval affects convergence time directly by specifying how much time OSPF waits for a hello message from neighbor until considering it down. When you enable OSPF Fast Hello  using the command above there is no way to tune it any more. But what’s with the second parameter? You can change Hello Multiplier and that basically means changing Hello Interval which is 1 / Hello Multiplier seconds. What could be the purpose of making routers to send Hello packets more or less frequently ?

First argument is quite obvious: CPU resources. The more Hello packets router receives per second, the more CPU load it has. Also the more neighbors the router the more it will be affected.

The second  is the sensitivity to failures. More Hello packets means more sensitivity to short communication interruptions between neighbors. Less Hello packets can lead to situation when link goes down and then up in between two Hello packets received.

The third is that convergence time still gets affected, but in a different way than when you change Dead Interval. By convergence time here I mean the amount of time that passes from actual communication failure till the neighbor is declared down.  When decreasing Hello Interval (i.e. increasing Hello Multiplier) this time gets closer to the actual 1 second.  It’s important to understand that Dead Interval is counted since the moment when the last Hello packet was received. Here is an example of different convergence times with the same Dead and Hello intervals:

OSPFConvergence

Both diagrams show four Hello packets being received per second (hello multiplier = 4) or one per 0,25 sec. The time passed between communication failure and OSPF taking down the neighbor depends on the time passed between failure and last Hello packet. In the example above it can vary in between and 0,751 and 0,999 sec.  The shorter the interval between Hello packets the less is this variation of convergence time interval.

Here are two logs showing similar situations (Hello interval is 200 ms and the convergence times are different from the example above, but still gives the idea):

*Dec 17 13:43:13.537: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:13.628: OSPF-100 HELLO Et0/0: Rcv hello from 10.0.0.1 area 0 10.0.0.1
*Dec 17 13:43:13.739: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:13.835: OSPF-100 HELLO Et0/0: Rcv hello from 10.0.0.1 area 0 10.0.0.1
*Dec 17 13:43:13.872: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:ip access-group denyany in
*Dec 17 13:43:13.935: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:14.128: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:14.331: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:14.527: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:14.725: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:43:14.837: %OSPF-5-ADJCHG: Process 100, Nbr 10.0.0.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

 

*Dec 17 13:44:27.188: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:27.212: OSPF-100 HELLO Et0/0: Rcv hello from 10.0.0.1 area 0 10.0.0.1
*Dec 17 13:44:27.378: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:27.410: OSPF-100 HELLO Et0/0: Rcv hello from 10.0.0.1 area 0 10.0.0.1
*Dec 17 13:44:27.559: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:ip access-group denyany in
*Dec 17 13:44:27.575: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:27.778: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:27.982: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:28.186: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:28.383: OSPF-100 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.2
*Dec 17 13:44:28.416: %OSPF-5-ADJCHG: Process 100, Nbr 10.0.0.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

The communication is being “broken” by applying an ACL that blocks all the traffic coming to interface. In the first example the last Hello packet is received at 13:43:13.835, the communications stops at 13:43:13.872 and neighbor gets declared down at 13:43:14.837. The time between losing communication and tearing down the neighbor relationship is 965 msec.

The second log shows communication being interrupted at 13:44:27.559 and neighbor going down at 13:44:28.416 which gives us the time interval of 857 msec between losing communication and tearing down the neighbor.

By setting Hello Multiplier value to the highest 20 you may get convergence time dispersion somewhere between and 951 and 999 ms.

Don’t forget, that this all is about the case when the communications between OSPF neighbors is lost, while the link protocol and media on the interfaces connecting stays up. In cases when the interface goes down convergence occurs much faster because the interface failure itself triggers LSA and SPF recalculation.

Layer 2 across Layer 3. Part 1 – L2TP

Several tasks I’ve been up to recently have made me study solutions to interconnect Layer 2 network segments across Layer 3 infrastructure. I decided to do a series of quick review of the technologies that serve this purpose. The most detailed information could be found in standards and vendors documents, there is no point to rewrite all of it here. What I was intended to is just produce a sort of quick reference/cheatsheet for what I have studied.

The first is Layer 2 Tunneling Protocol.

Lab 

Here is a network diagram I used:

Lab Diagram
Lab Diagram
  • R4 and R5 represent two hosts in the same VLAN. Those are the ones that need to be interconnected across the WAN.
  • R2 and R3 represent border routers in each location.
  • R1 is just a transport WAN emulation.

Starting configuration for border routers:

R2 R3
interface FastEthernet0/0
  description -= WAN =-
  ip address 115.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 115.0.0.1
interface FastEthernet0/0
 description -= WAN =-
 ip address 116.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 116.0.0.1

The starting configuration for R1, R4 and R5 is just IP addresses assigned to interfaces according to the diagram.

The basic L2TPv3 configuration

L2TP is probably the most straightforward method to implement Layer-2 interconnection across Layer-3 WAN. Basic config looks like this:

R2

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

R3

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

Here is the result:

L2TPv3 Tunnel Established
L2TP Tunnel Established

All the traffic coming to FastEthernet 2/0 port of any of the border routers gets encapsulated and sent to the opposite site where it gets decapsulated while going out of another FastEthernet 2/0 interface. As a result we can ping R5 from R4 and vice versa as if they were connected directly by Layer-2 link:

R5#ping 192.168.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 88/98/120 ms
R4#ping 192.168.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/116/156 ms

The broadcast traffic also gets propagated successfully:

R4#ping 255.255.255.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 192.168.1.5, 152 ms
Reply to request 1 from 192.168.1.5, 108 ms
Reply to request 2 from 192.168.1.5, 152 ms
Reply to request 3 from 192.168.1.5, 104 ms

Some theory

The obvious advantage of L2TP is that in order to implement it you don’t need anything but Layer 3 connectivity between devices that will terminate both ends of the tunnel.

Here is what happens to the Layer 2 Payload when it gets transferred over the tunnel:

Encapsulation Scheme
Encapsulation Scheme

First, L2TPv3 Header gets added to the original Layer 2 Frame. It contains all the information needed to identify the Tunnel and the Session.

Second IP Delivery Header containing source and destination IP addresses of the tunnel peers (in our case R2 and R3 routers) and UDP Header are added to deliver the packet to the other end device that will decapsulate it. On transport layer L2TPv3 uses port 1701.

The packet flow to establish the connection is the following:

L2TP Control Packet Flow
L2TP Control Packet Flow

Verifying 

Checking tunnel and session states:

R2#show l2tun

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
1401476767 197244710  R3            est    116.0.0.2       1     l2tp_default_cl

LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID
                                 Vcid, Circuit
4141636091 3431548551 1401476767 123, Fa2/0           est    00:02:50 1

You can see the tunnel Virtual Circuit ID 123 configured and it’s state as established.

Here is a debug command showing tunnel establishment process where you can see packets related to tunnel setup marked bold. R2 plays the role of the server in this case, so the tunnel establishment process begins with it receiving SCCRQ, responds SCCRP and so on. Notice also the states the system passes through (Idle, Proc-SCCRQ, Wt-SCCN, etc.) till it gets to established.

R2#debug l2tp event
*Dec  8 23:52:23.159: L2X  tnl   08318:________: Create logical tunnel
*Dec  8 23:52:23.159: L2TP tnl   08318:________: Create tunnel
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     version set to Cisco-V3
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.167: L2TP tnl   08318:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCRQ
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC    Idle->Proc-SCCRQ
*Dec  8 23:52:23.179: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCRQ
*Dec  8 23:52:23.183: L2TP tnl   08318:70A47756:     class name l2tp_default_class
*Dec  8 23:52:23.191: L2TP       _____:________: Check for existing cc
*Dec  8 23:52:23.191: L2TP       _____:________:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer router id: 116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer hostname: R3
*Dec  8 23:52:23.199: L2TP       _____:________:   and version: V3
*Dec  8 23:52:23.203: L2TP       _____:________:   No other cc exists to tie with
*Dec  8 23:52:23.203: L2TP tnl   08318:70A47756: FSM-CC ev SCCRQ-OK
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCRQ->Wt-SCCCN
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC do Tx-SCCRP
*Dec  8 23:52:23.211: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.211: L2TP tnl   08318:70A47756: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC ev Sock-Ready
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC    in Wt-SCCCN
*Dec  8 23:52:23.219: L2TP tnl   08318:70A47756: FSM-CC do Ignore-Sock-Up
*Dec  8 23:52:23.355: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC    Wt-SCCCN->Proc-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCCN
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC ev SCCCN-OK
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCCN->established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: FSM-CC do Established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: Control channel up
*Dec  8 23:52:23.387: L2TP tnl   08318:70A47756:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.431: L2X  _____:_____:________: Create logical session
*Dec  8 23:52:23.435: L2TP _____:_____:________: Create session
*Dec  8 23:52:23.435: L2TP _____:_____:________:   Using ICRQ FSM
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn ev created
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn    Init->Idle
*Dec  8 23:52:23.443: L2TP _____:_____:________: FSM-Sn do none
*Dec  8 23:52:23.443: L2TP _____:_____:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.447: L2TP _____:_____:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC ev Session-Conn
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC    in established
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756: FSM-CC do Session-Conn-Est
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756:   Session count now 1
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn ev CC-Up
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn    in Idle
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: FSM-Sn do CC-Up-Ignore0-1
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: Session attached
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn ev Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn    Idle->Proc-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn do Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE:   Chose application XCONNECT
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.471: L2TP tnl   08318:70A47756:   XCONNECT Session count now 1
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Remote AC is now UP
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Set HA epoch to 0
*Dec  8 23:52:23.475: L2TP _____:08318:ECEDBDCE:
*Dec  8 23:52:23.495: L2X  _____:_____:________: Destroying logical session
*Dec  8 23:52:23.495: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   Need cc version: Cisco-V3
*Dec  8 23:52:23.503: L2TP 00001:08318:ECEDBDCE:   Sequencing default tx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE:   Sequencing default rx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE: no cookies enabled
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICRQ-OK
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn Proc-ICRQ->Wt-Tx-ICRP
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP-Local-Check
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Local-Cont
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Tx-ICRP->Wt-Rx-ICCN
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP
*Dec  8 23:52:23.523: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Sock-Ready
*Dec  8 23:52:23.531: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.535: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-Sock-Up
*Dec  8 23:52:23.555: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Setup
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.563: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-Setup
*Dec  8 23:52:23.799: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Rx-ICCN
*Dec  8 23:52:23.803: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Rx-ICCN->Proc-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Rx-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE:   MTU is 65535
*Dec  8 23:52:23.811: L2TP 00001:08318:ECEDBDCE: Session data plane UP
*Dec  8 23:52:23.815: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.819: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.839: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICCN-OK
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Proc-ICCN->established
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Established
*Dec  8 23:52:23.847: L2TP 00001:08318:ECEDBDCE: Session up
*Dec  8 23:52:23.851: L2TP 00001:08318:ECEDBDCE:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.895: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.899: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.903: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Up
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in established
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-UP

Similar packet exchange information can be seen with debug vpdn command.

In case you need to reset L2TPv3-tunnel, the following command can be used:

R2#clear l2tun remote ip 116.0.0.2

Simple ASA Access-lists Configuration Technique

The plot

Some day some application or server person comes and wants to deploy some new service on top of your network. The deployment implies installing several new network endpoints (servers, workstations or some other IP-enabled devices) in several network security zones and granting them necessary access permissions. The person is in a hurry to finish the deployment ant test it. You are in a hurry with your day-to-day tasks. The solution vendors documentation often doesn’t explain well what network protocols it uses and which direction the connections between different solution components are going to be established (I have experienced this with new CCTV solution that was being deployed this week). Or you just study the doc which seems well detailed, configure everything according to it, but the service just doesn’t work and neither of you two can be sure whether it’s a firewall or the application level configuration problem.

Solution?

One common way to resolve this is to temporarily permit all traffic between all the IP addresses involved “just to test it works”. Quite often in such cases the deployment gets successfully finished, everyone is happy, the person who was deploying this new has to go on with his or her job, you  have to go on with your job, so no one has time to correct the permissions you have configured for the tests and they stay forever…

Here is a general algorithm I try to use while operating Cisco ASA in order to avoid this:

First configure what vendor asks you to

Study the application vendor documentation. Configure the permissions it asks you to configure. If points are unclear in the documentation – just skip it. Vendor may say something like “Server A and Network Device B need ports X and Y to be opened between them” but doesn’t say which direction the traffic is going to flow and sometimes doesn’t even specify whether it is going to be TCP or UDP. You don’t want to configure both TCP and UDP in both directions, just to make sure. Skip it, and investigate later.

An important thing: configure each pair of Source/Destination hosts/networks and port/protocol as a separate line. Here is an example for some network device and two servers it should be talking to:

Initial permissions configuration
Initial permissions configuration

Second: configure an explicit deny

For each pair of Source/Destination hosts or networks configure an explicit deny line below the permit statements configured in a previous step:

Explicit deny statement
Explicit deny statement

Enable logging for these statements, set the Logging Level to the one that is being logged to ASDM (or your Syslog-server) and an interval of 1 second:

Enabling logging for explicit deny
Enabling logging for explicit deny

This will be used to collect data on denied traffic.

At the end you will have something like this:

Initial config with explicit deny statements for each Source-Destination pair
Initial config with explicit deny statements for each Source-Destination pair

Third: test, check, and correct configuration

Ask a person who deploys the new service to do the tests while observing the logs configured for deny statements. If something fails, check the logs for denied packets and if there are any, analyze  whether this traffic should be permitted or not. If it should – add necessary permissions above the deny line and do the test again:

ASA999
Check explicit deny line logs for denied packets

You may need to repeat this step several times while new features of the service that is being deployed are being tested.

Fourth: let it run for some time and then check and correct it again

Everything went up and running. Now let it work for some time and check the hit counters for ACL lines.

It depends on particular situation, but commonly if some ACL line wasn’t hit by a single packet during 2-3 moths you may consider disabling it.

Also you may disable the explicit deny line at this step.

Fifth: re-arrange the configuration if possible

Ultimately it is group the Sources and Destinations and ports/protocols into groups to make configuration look shorter and easier to read:

Final configuration. Ports and protocols grouped into Service Groups
Final configuration. Allowed ports and protocols grouped into Service Groups

The grouping might be different, for example, you may want to group some ports and protocols based on their role, creating Service Groups such as “NetworkDeviceX-ServerA-Management-Access”.

This way I normally end up having quite well organized configuration that permits just what is needed to be permitted and serves as a good reference for documenting how the deployed service works from the network point of view.

Planning internal IP subnets (v4)

Here are some techniques and general considerations I use when designing IP addressing plans:

Don’t make subnets too large or too small

The general recommendation for subnets containing end hosts (workstations, IP phones, printers etc.) is around 500, but in my opinion it’s better to keep it limited to 254. /24 subnets are much more handy to operate as you have your network and host part divided on octets boundary, something like 10.72.31.x, where x is the host part of the address. /23 and larger subnets make you do some math each time you want to know which network does particular host belong to. Nothing bad will happen when the amount of workstations exceed the /24 limit, you will just need to assign another subnet. And if you plan well from the start the new subnets will easily fit the designed addressing scheme (below I have some thoughts on this topic).

Subnets that you use for wireless hosts may be treated differently, as it is common to have Broadcast and Multicast disabled in wireless networks and you may assign the subnet based on the amount of hosts you estimate to have in particular SSID. But even here there are options such as VLAN Select that allow you to map various let’s say /24 subnets to one SSID and maintain wireless clients within the same IP-address assignment scheme.

Also, unless you have a need to fit into certain range (for example when you are planning a branch and already have assigned certain network that you have to split into subnets), don’t be greedy. There is plenty of addresses in RFC1918 space, so just choose some of the private IP ranges and divide it into /24 subnets.

Point-to-point links

Of course there is no need to waste /24 subnets on Layer-3 point-to-point interconnections. I recommend to choose one or more /24 ranges that you dedicate to p2p-links addressing and split it into /31 networks.

Using 31-bit prefixes allows you to divide a class C network into 128 pairs of addresses, one for each end of the link, without wasting any on subnet and broadcast addresses, which is what happens when you use 30-bit ones. The only limitation I know is that this subnets don’t support directed broadcasts. Also you have to check that your network equipment supports the feature. One common example is Cisco ASA which doesn’t support it at least for now, but on any IOS/IOS-XE/IOS-XR routing device it is that simple:

interface GigabitEthernet1/36 
 description -= Link to SW1 Gi0/0/1 =-
 ip address 10.24.4.26 255.255.255.254
 
interface GigabitEthernet0/0/1
 description -= Link to RTR1 Gi1/36 =-
 ip address 10.24.4.27 255.255.255.254

Here is an RFC Document on this feature.

Plan for growth

Your network may grow and the amount of hosts in some subnets may exceed these subnets limits. I use two techniques to plan for growth:

1) Skipping 2x subnets when assigning them, like this:

Workstations: 10.25.0.0/24
IP Phones: 10.25.16.0/24
Printers: 10.25.32.0/24

So that when in the future you will need to assign another subnet for workstations it will be 10.25.1.0/24, 10.25.16.0/24 for IP Phones and so on. The scheme will stay like this:

Workstations: 10.25.0.0/24
Workstations: 10.25.1.0/24
Workstations: 10.25.2.0/24
IP Phones: 10.25.16.0/24
IP Phones: 10.25.17.0/24
IP Phones: 10.25.18.0/24
Printers: 10.25.32.0/24
Printers: 10.25.33.0/24
Printers: 10.25.34.0/24

By doing this you keep subnets of the same host types together and if you need to match for example all the IP Phones with an ACL line it will be 10.25.16.0 0.0.15.255. Same can be easily be done for Workstations and Printers.

The only problem I see here is that you have to estimate the maximum number of subnets you are going to have for each of the host types and skip corresponding amount of subnets before assigning subnets of different type. In the example above the 17th Workstations subnet will already be crossing the IP Phones range, so you only have space for 16 Workstations subnets.

2) Keep assigning new subnets for the same type of hosts within 2x interval:

Workstations: 10.25.0.0/24
IP Phones: 10.25.1.0/24
Printers: 10.25.2.0/24
Workstations: 10.25.16.0/24
IP Phones: 10.25.17.0/24
Printers: 10.25.18.0/24
Workstations 10.25.32.0/24
IP Phones: 10.25.33.0/24
Printers: 10.25.34.0/24

The binary math looks like this:

Workstations IP Phones: Printers:
3rd octet values 0000 0000 (0) 0000 0001 (1)
0000 0010 (2)
0001 0000 (16)
0001 0001 (17)
0001 0010 (18)
0010 0000 (32)
0010 0001 (33)
0010 0010 (34)

The right four digits indicate the subnet type and the value stays the same for each subnet containing the same type of hosts. The left four digits (marked with bold) indicate subnet number within particular type. Here you can increase the left part even after it crosses the octet boundary, so you have a lot of space to assign future subnets of each hosts type. But here you have to estimate well the number of subnet types you’ll want to assign. The example above allows you to create only 16 types of subnets.

Writing a universal ACL line here will be a bit more complicated. For example all current and future IP Phones subnets will fall into: 10.25.1.0 0.0.240.255, but that’s only if you won’t cross the octet boundary assigning subnets.

Assign VLAN numbers matching 3rd IP subnet octet

Or vice-versa. Or just make them correspond to each other in some way that is easy to understand. A very handy technique, that eliminates a lot of confusion. Which VLAN does the printer with an IP 10.25.34.17 belong to? An easy answer is:

Subnet type IP Address/Mask VLAN
Workstations: 10.25.0.0/24 1000
Workstations: 10.25.1.0/24 1001
Workstations: 10.25.2.0/24 1002
IP Phones: 10.25.16.0/24 1016
IP Phones: 10.25.17.0/24 1017
IP Phones: 10.25.18.0/24 1018
Printers: 10.25.32.0/24 1032
Printers: 10.25.33.0/24 1033
Printers: 10.25.34.0/24 1034

Here VLAN number is always 1000+3rd octet number. We couldn’t afford an exact match here, because there is no VLAN 0 and using VLAN 1 is not recommended.

 

If you have any other tricks or techniques you use when you plan IP-addressing schemes, feel free to share them!

Which channel to place your AP on?

Choosing the lesser evil

Let’s say you are setting up a Wi-Fi access point. You launch some simple analyzer tool to check which channel to configure your AP for and see something like this:

int1

Given the fact that there is no way to avoid any interference, which channel would you choose?

There is a temptation to put your new AP on channel 3 as it looks like it has the lowest Received Signal Strength from foreign APs.On the other hand we have a recommendation to use channels 1, 6 and 11 of the 2.4GHz ISM band for the majority of countries. So maybe we just use channel 1 and hope that our signal will be heard well?

Two types of Wi-Fi interference

If we set our AP to channel 3 the signal spectrum will partially overlap with the AP configured for channel 1. This is called Adjacent Channel Interference:

Adjacent channel interference. The mess between channels 4 and 13 is omitted for simplicity

If we set it to channel 1 then what we will have is called Co-Channel Interference. The whole spectrum of both signals will overlap:

Co-Channel Interference
Co-Channel Interference

Wi-Fi is often called polite protocol. In practice, this means that APs and clients do their best to avoid collisions during data transmission. In short if someone is already using the channel wireless device backs off and tries to transmit its data later. All this works when one wireless device “hears” other devices data (i.e. is able to see the actual Layer-2 frames).

What happens in case of adjacent channel interference is that you have disruption on part of the channel spectrum. The signal from an AP operating on an overlapping channel is perceived as noise. The collision avoidance mechanism don’t work, both APs keep sending data whenever they want, but large part of the data comes corrupt to its destination. AP tries to change data rate and coding scheme to adapt to noisy environment and then resend the data good part of which will probably come corrupt causing the whole cycle to get repeated. More than that, the interfering AP will certainly have periods of more and less intense conversations to its clients. So your AP will try to switch to lower and higher datarates during these periods which will make the situation even worse.

Of course we all would like to operate in an interference free environment where all the channel spectrum is ours, but nowadays it is virtually impossible. So if you have to choose between co-channel and ajdacent-channel interferer, choose the first one. In the presented case channel 1 looks like the best option.

Also keep in mind that there are some other factors that will affect the performance, sometimes even more. For example, how intensely the other AP and its clients utilize the channel, the presence of non-Wi-Fi interference sources and so on.