As 1550s APs go end-of-sale in March 2016, two model series are available to choose from Cisco Outdoor portfolio: full-feature 1570 and compact 1530. The latter in turn has two options:
● 15 30I: 3×3 MIMO with 3 spatial streams (2.4 GHz) and 2×3 MIMO with 2 spatial streams (5 GHz)
● 1530E: 2×2 MIMO with 2 spatial streams (2.4 GHz) and 2×2 MIMO with 2 spatial streams (5 GHz)
(1570 has 4×4 MIMO with 3 spatial streams)
The obvious benefit of 1530 is it’s compact and easy-to-mount design. We have just received one which we are going to install on a bus stop in order to provide internet service for waiting passengers. For this installation we chose the one with internal antennas.
I have decided to post some photos of the AP just in case anyone wants to see it closer. In my opinion it looks very nice.
Notice two ports named LAN and PoE. They are for daisy-chaining two APs (when one AP provides wired Ethernet to another). Here is a plug used to seal the network cable (copper is the only option):
My advice for everyone who acquiring this AP model to consider AIR-ACC1530-PMK2= mount kit that has tilt mechanism so you can direct the AP as needed. The one that comes by default suits you if you want to mount it on a pole vertically. As always – check the radiation pattern.
More detailed information can be found in Deployment Guide, provided by Cisco.
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:
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.
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
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/0interface 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/0interface FastEthernet2/0 description -= LAN =- no ip address xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class
Here is the result:
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
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
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:
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
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
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
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
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:
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. 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.
