OSPF LSA Types

For many years I’ve been struggling to memorize OSPF LSA types. Finally, I have decided to create a lab that shows all those LSA types that are supported by Cisco in OSPFv2 (IPv4-OSPF).

Here is my lab topology:

Type 1 – Router LSA

According to the documentation LSA type 1 is sent by any router within the area and contains the information about its directly connected links.

To see it I start packet capture in R1 Fa0/0 interface and reset the OSPF process at R2 to provoke LSA flood. Theoretically I should see two Type 1 LSA coming from R2: one for link 10.0.2.0/30 and another one for 10.0.1.0/24.

Here is what actually appears:

Two LSAs. One with unicast destination and one destined to “ALL OSPF ROUTERS” multicast address. Both contain the same information:

The information on both links is passed inside one Type 1 LSA. Links are presented with their IDs. There is a proper alogithm to derive Link ID depending on link type, in case of Transit that appears in this LSA network it’s DR IP address. The reason why R2 sends two LSA probably has to do with Cisco implementation of OSPF and the fact that R2 has broadcast multicaccess segment connected to it’s Fa0/1 interface.

This is how Type 1 LSA has been sent:

Type 2 – Network LSA

Type 2 LSA is generated by DR elected for multiaccess segment to inform its neighbors about this segment existence. An example of such a segment is the interconnecion between R2 R3 and R4. From R2 we can see that R4 got elected as DR (it’s router ID is 172.16.2.1):

R2#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.16.1.1 1 FULL/BDR 00:00:37 10.0.1.1 FastEthernet0/1
172.16.2.1 1 FULL/DR 00:00:34 10.0.1.2 FastEthernet0/1

So putting capture on R2 fa0/0 and resetting its OSPF process we should get Type 2 LSA from R4 containing information on R2-R3-R4 segment. Here it is, packed together with some other LSAs:

Notice the subnet mask for the segment, DR ID (Advertising Router) and three attached router IDs.

So Type 2 LSA flow is the following:

LSA Type 2

This type of LSA then gets resent by all the routers within the area (in this example R2 will resend it to R1). Advertising router field within the LSA will retain its original value as R4 being the DR is the one responsible for the LSA.

Type 3 – Summary LSA

Type 3 LSAs are sent by ABR. When a link-state change occurs within one of the areas connected to it, it sends this type of LSA to all the other areas thus notifying them about that change. For example, when R2 Fa0/0 link goes down we can expect R3 to notify R6 about this change with Type 3 LSA.

Setting capture for Fa0/0 on R6 and shutting down Fa0/0 on R2 we get the following:

Notice the Metric field value. Setting it to 16777215 (FFFFFF hexadecimal) is a way to mark link as unreachable and signal to other OSPF routers to withdraw its data from their databases.

R3 generates Type 3 LSA because it gets notified of the change by Type 1 LSA coming from R2. Here is the flow diagram:

Please note that the name “summary LSA” has nothing to do with route summarization feature. Nothing gets summarized here, at least by default.

Type 4 – ASBR summary LSA

Type 4 LSAs are also sent by ABR. By using them ABR notifies it’s connected areas about the presence of ASBR in any of these areas. In my topology R3(ABR) would notify R6 which is in Area 1 about the presence of R1(ASBR) in Area 0 using LSA of this type. Later on R6 will receive some external route information from R1 and the Type 5 LSA announcing this route will contain R1 Router ID, saying that this external network is behind R1. Data obtained by R6 from Type 4 LSA will tell it that R1 is behind R3.

What makes router an ASBR and thus provokes LSA Type 4 generation? It’s route redistribution from any other routing process or protocol into OSPF occurring at this router. In my topology R1 is an ASBR as it redistributes routes from RIP into OSPF.

So, again, R3, being an ABR, should notify R6 about the presence of R1 using Type 4 LSA. But how does R3 get to know that R1 is an ASBR and not just any common intra-area router? The answer is: R1 notifies everyone within Area 0 of itself being an ASBR by setting a special (E) flag in Type 1 LSAs it sends. Here it is:

Wireshark already interprets E flag set as “AS boundary router”.

So when R3 receives this LSA it sends Type 4 LSA to notify R6:

Advertising router field contains R3 Router-ID, Link State ID contains R1 (ASBR) Router ID.

Here is what the process looks like:

Type 5 – External LSA

LSA Type 5 is used to advertise external routes in all the OSPF areas. External in this case means not calculated or generated by OSPF process, but redistributed from other routing protocols, redistributed static or connected routes. As an example route for 192.168.99.0/24 network should be advertised by R1 using this type of LSA.

Putting R7 Loopback0 interface into shutdown provokes LSA flooding out of R1 FastEthernet0/0 notifying it as unreachable. Here is the capture:

Type 7 – NSSA External LSA

This LSA Type contains external routes information as well as Type 5 LSA. The difference is that Type 7 LSA is propagated across Not-so-Stubby area and Type 5 LSA is not. On ABR that connects NSSA to Backbone area Type 7 LSA gets converted into Type 5 LSA.

In my topology R5 should notify R4 about changes with interface Loopback0 (172.16.102.0/24 subnet) using this type of LSA.

Here is a Type 7 LSA sent by R5 on it’s Loopback0 shutdown:

and here is LSA 5 generated by R4 for Area0, containing information on the same link:

LSA Type 5 generated by ABR, based on the information from received LSA Type 7

Transcoding on Cisco Unified Border Element

Previously to use hardware (PVDM-based) transcoding you needed to register DSPFarm on CUCM or CME. But what if you don’t use any of these call control platforms, just have a router working as CUBE and want to accept one call leg and set up another with a codec different from originating? Starting with CUBE 9.0 Cisco has introduced Local Transcoding Interface (LTI) feature that permits you to register transcoding DSPFarm profile on CUBE itself.

CUBE version is mapped to IOS version, some information on version correspondence can be found here. The exact CUBE version on your router can be verified with show cube status command.

The call flow I used to test the feature is the following:

Here is a configuration example:

voice-card 0
dsp services dspfarmdspfarm profile 1 transcode universal
codec g729r8
codec g729br8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application CUBE <--- this command makes the profile to register and interact with CUBE
no shutdown <--- Don't forget this, the profile is shutdown by default

First, checking that DSPFarm profile has registered successfully:

#show dspfarm profile
Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resources Out of Service : 0
Number of Resources Active : 0
Codec Configuration: num_of_codecs:6
Codec : g729r8, Maximum Packetization Period : 60
Codec : g729br8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60

Then trying to establish the call.

Verification

After the remote party answered the call, we can see RTP streams for both call legs up:

#sh voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 2
Port range not configured, Min: 16384, Max: 32767Ports Ports Ports
Media-Address Range Available Reserved In-useDefault Address-Range 8091 101 2VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 510647 510648 17882 10012 X.X.X.6 X.X.X.1
2 510648 510647 17884 12818 Y.Y.Y.68 Y.Y.Y.147
Found 2 active RTP connections

It doesn’t tell us though which codec both call legs are using. Show call active voice command does that:

#show call active voice brief

Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
2CD9 : 510647 307788128ms.1 () +16290 pid:520 Answer 3309 active
dur 00:00:36 tx:1831/292960 rx:1826/292160 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP X.X.X.1:10012 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off Transcoded: Yes
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

2CD9 : 510648 307788138ms.1 () +16270 pid:521 Originate 3000 active
dur 00:00:36 tx:1825/36500 rx:1831/36620 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP Y.Y.Y.147:12818 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 TextRelay: off Transcoded: Yes
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

Here are the active sessions on configured DSPFarm:

#show dspfarm all
Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resources Out of Service : 0
Number of Resources Active : 1
Codec Configuration: num_of_codecs:6
Codec : g729r8, Maximum Packetization Period : 60
Codec : g729br8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED0 1 33.1.0 UP 1 USED xcode 1 510648 799 807
0 1 33.1.0 UP 1 USED xcode 1 510647 804 797
0 1 33.1.0 UP N/A FREE xcode 1 - - -
0 1 33.1.0 UP N/A FREE xcode 1 - - -
0 1 33.1.0 UP N/A FREE xcode 1 - - -Total number of DSPFARM DSP channel(s) 4

Codec negotiation process

All the output below is taken using debug ccsip messages. Messages not related to codec negotiation are omitted.

First, CUBE receives SIP INVITE from Local IP PBX with SDP containing G.711 A-law and µ-law:

Received:

INVITE sip:3000@x.x.x.6 SIP/2.0

Via: SIP/2.0/UDP x.x.x.1:5060;branch=z9hG4bK23d6e61b;rport

From: "3309" <sip:3309@pbx.local>;tag=as3d61976b

To: <sip:3000@x.x.x.6>

Contact: <sip:3309@x.x.x.1>

Call-ID: 763b91d53953a6f118dda08347245740@pbx.local

CSeq: 102 INVITE

User-Agent: Local PBX

Max-Forwards: 70

Date:

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces

Content-Type: application/sdp

Content-Length: 235

v=0
o=root 4037 4037 IN IP4 X.X.X.1
s=session
c=IN IP4 X.X.X.1
t=0 0
m=audio 10012 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Then it resends the INVITE to Remote IP PBX proposing the same codecs:

Sent:
INVITE sip:3000@Y.Y.Y.147:5060 SIP/2.0
Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK24310A3
Remote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=off
From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587968-2B6
To: <sip:3000@Y.Y.Y.147>
Date: Fri, 08 Jan 2016 15:14:29 GMT
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1490163159-3041989093-2599734236-3876816822
User-Agent: Cisco-SIPGateway
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1452266069
Contact: <sip:3309@Y.Y.Y.68:5060>
Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289v=0
o=CiscoSystemsSIP-GW-UserAgent 3992 8898 IN IP4 Y.Y.Y.68
s=SIP Call
c=IN IP4 Y.Y.Y.68
t=0 0
m=audio 17884 RTP/AVP 8 0 101 19
c=IN IP4 Y.Y.Y.68
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

The Remote PBX responds with an error message:

Received:

SIP/2.0 488 Not acceptable here

Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK24310A3;received=Y.Y.Y.68

From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587968-2B6

To: <sip:3000@Y.Y.Y.147>;tag=as55df16aa

Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68

CSeq: 101 INVITE

Server: Remote PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

Content-Length: 0

The response means that some media capability (we know it’s a codec) is not acceptable at the remote end. RFC3261 says this type of message MAY include a description of media capabilities that weren’t accepted so this could have told us what exactly the remote end didn’t like, but unfortunately in this case it doesn’t.

Anyway, CUBE sends another INVITE message, proposing G.729 codec:

Sent:
INVITE sip:3000@Y.Y.Y.147:5060 SIP/2.0
Via: SIP/2.0/UDPY.Y.Y.68:5060;branch=z9hG4bK244210D
Remote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=off
From: "3309" <sip:%239193093803@Y.Y.Y.68>;tag=12587AFC-2DC
To: <sip:3000@Y.Y.Y.147>
Date: Fri, 08 Jan 2016 15:14:29 GMT
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1490163159-3041989093-2599734236-3876816822
User-Agent: Cisco-SIPGateway
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Timestamp: 1452266069
Contact: <sip:3309@Y.Y.Y.68:5060>
Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 337v=0
o=CiscoSystemsSIP-GW-UserAgent 3992 8899 IN IP4 Y.Y.Y.68
s=SIP Call
c=IN IP4 Y.Y.Y.68
t=0 0
m=audio 17884 RTP/AVP 8 0 18 101 19
c=IN IP4 Y.Y.Y.68
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

which remote PBX accepts sending an OK response with acceptable media capabilities list including G.729. This actually happens when remote user picks up the phone. Here is the message:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK244210D;received=Y.Y.Y.68From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587AFC-2DC
To: <sip:3000@Y.Y.Y.147>;tag=as25e69ab7
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
CSeq: 102 INVITE
Server: Remote PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:3000@Y.Y.Y.147:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 263v=0
o=root 1736022661 1736022661 IN IP4 Y.Y.Y.147
s=Asterisk PBX 11.14.2
c=IN IP4 Y.Y.Y.147
t=0 0
m=audio 12818 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

The call proceeds with two legs using different codecs as expected.

The whole flow looks the following way (Red bars mark messages listed above, the ones containing codecs information):

An error 488 Not acceptable here could be avoided by changing the outgoing dial-peer configuration. CUBE proposes G.711 codecs first because of the voice-class applied to its outgoing dial-peer. This voice-class lists the codecs with the following preference order:

voice class codec 3
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g729br8

Changing the priority or leaving just G.729 will do the trick.

Layer 2 across Layer 3. Part 2 – EoMPLS

Continuing L2 across L3 topic started with post about L2TP.

Another easy-to-setup way to interconnect two Ethernet segments across Layer 3 network is EoMPLS, a particular case of AToM.

The diagram I used for my tests and the initial configuration are the same as in my previous post on L2TP.

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`

To set up EoMPLS you need to have MPLS-enabled transport network in between the border routers. But if you don’t have this option, such as in case of interconnecting LAN segments across the internet you can just use GRE to make border routers look directly connected to each other across the tunnel. All the configurations are made for common Cisco IOS (not XE or XR).

Setting up GRE

GRE Tunnel uses outside physical interfaces IP addresses as source and destination:

R2	R3
`interface Tunnel0` `ip address 1.1.1.1 255.255.255.252` `keepalive 1 3` `tunnel source 115.0.0.2` `tunnel destination 116.0.0.2`	`interface Tunnel0` `ip address 1.1.1.2 255.255.255.252` `keepalive 1 3` `tunnel source 116.0.0.2` `tunnel destination 115.0.0.2`

Tunnel is up:

R3#sh ip int brief | inc Tunnel0
Tunnel0 1.1.1.2 YES manual up up

And we have R2 and R3 “directly connected”.

Setting up LDP

First, I have set up Loopback interfaces on both border routers:

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

interface Loopback0

 ip address 3.3.3.3 255.255.255.255

To have connectivity between Loopback interfaces I have set up OSPF (one might use static routing as well):

interface Tunnel0
ip ospf 100 area 0
interface Loopback0
ip ospf 100 area 0

So now both Loopback interfaces see each other:

R2#sh ip route ospf

Gateway of last resort is 115.0.0.1 to network 0.0.0.0

3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/1001] via 1.1.1.2, 00:01:48, Tunnel0
R3#sh ip route ospf

2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/1001] via 1.1.1.1, 00:01:20, Tunnel0

R3#ping 2.2.2.2 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/222/228 ms

Enforce the LDP router-ID on both routers:

mpls ldp router-id loop0 force

Enable label exchange over GRE Tunnel:

int tunnel0
mpls ip

Now the LDP neighborship is established:

R2#sh mpls ldp neighbor
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
TCP connection: 3.3.3.3.64467 - 2.2.2.2.646
State: Oper; Msgs sent/rcvd: 8/8; Downstream
Up time: 00:00:12
LDP discovery sources:
Tunnel0, Src IP addr: 1.1.1.2
Addresses bound to peer LDP Ident:
116.0.0.2 3.3.3.3 1.1.1.2R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 3.3.3.3/32 0 Tu0 point2point

R3#sh mpls ldp nei
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0
TCP connection: 2.2.2.2.646 - 3.3.3.3.64467
State: Oper; Msgs sent/rcvd: 8/8; Downstream
Up time: 00:00:32
LDP discovery sources:
Tunnel0, Src IP addr: 1.1.1.1
Addresses bound to peer LDP Ident:
115.0.0.2 2.2.2.2 1.1.1.1R3#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 2.2.2.2/32 0 Tu0 point2point

We see some label (16) in show mpls forwarding-table command output, but it’s not the the label that will be used for tunneling traffic. There will be a few words later in this post about MPLS labels use with EoMPLS.

Now we have the following:

Setting up the EoMPLS Interconnection

Similarly to L2TPv3 we now configure the interconnection (Virtual Circuit) using xconnect.

interface fastethernet2/0

xconnect 3.3.3.3 2222 encapsulation mpls

interface fastethernet2/0

xconnect 2.2.2.2 2222 encapsulation mpls

Verifying

Trying ping between hosts:

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 = 120/143/224 ms

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 100 percent (5/5), round-trip min/avg/max = 96/134/208 ms

And to the broadcast address:

R5#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.4, 152 ms
Reply to request 1 from 192.168.1.4, 188 ms
Reply to request 2 from 192.168.1.4, 180 ms
Reply to request 3 from 192.168.1.4, 172 ms

Checking that the Virtual Circuit is established:

R2#show mpls l2transport vc detail

Local interface: Fa2/0 up, line protocol up, Ethernet up

Destination address: 3.3.3.3, VC ID: 2222, VC status: up

Output interface: Tu0, imposed label stack {17}

Preferred path: not configured

Default path: active

Next hop: point2point

Create time: 03:38:36, last status change time: 01:26:33

Signaling protocol: LDP, peer 3.3.3.3:0 up

Targeted Hello: 2.2.2.2(LDP Id) -> 3.3.3.3

Status TLV support (local/remote)   : enabled/supported

Label/status state machine        : established, LruRru

Last local dataplane   status rcvd: no fault

Last local SSS circuit status rcvd: no fault

Last local SSS circuit status sent: no fault

Last local  LDP TLV    status sent: no fault

Last remote LDP TLV    status rcvd: no fault

MPLS VC labels: local 17, remote 17

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Remote interface description: -= LAN =-

Sequencing: receive disabled, send disabled

VC statistics:

packet totals: receive 1382, send 1394

byte totals:   receive 140659, send 185950

packet drops:  receive 0, seq error 0, send 3

R3#show mpls l2transport vc detail

Local interface: Fa2/0 up, line protocol up, Ethernet up
Destination address: 2.2.2.2, VC ID: 2222, VC status: up
    Output interface: Tu0, imposed label stack {17}
    Preferred path: not configured
    Default path: active
    Next hop: point2point
Create time: 03:36:10, last status change time: 01:24:29
Signaling protocol: LDP, peer 2.2.2.2:0 up
    Targeted Hello: 3.3.3.3(LDP Id) -> 2.2.2.2
    Status TLV support (local/remote)   : enabled/supported
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: no fault
      Last local SSS circuit status rcvd: no fault
      Last local SSS circuit status sent: no fault
      Last local LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 17, remote 17
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description: -= LAN =-
Sequencing: receive disabled, send disabled
VC statistics:
    packet totals: receive 1374, send 658
    byte totals:   receive 139272, send 88278
    packet drops: receive 0, seq error 0, send 1

In both commands output above we see Virtual Circuit ID that we have configured (2222), it’s status (Up), and the tunnel label (17). This is an actual label used in traffic “encapsulation/decapsulation”. The encapsulation itself consists in appending the label to the packet sent across the tunnel.

Looking at the ping capture between R4 and R5 we can see how the packet is formed:

ICMP Echo Request transferred over Layer 2 MPLS Tunnel

ICMP Echo Reply transferred over Layer 2 MPLS Tunnel

Both captures show ICMP packet inside the Ethernet frame. Above that comes the Label 17 which we saw in show mpls l2transport vc detail command output. This is so-called VC Label that actually identifies Layer 2 interconnection. Above that comes GRE header and then IPv4 header used to deliver packet from one border router to another. This configuration theoretically can be used to establish EoMPLS interconnection across any sort of Layer 3 WAN, i.e. to perform the same task as L2TPv3 usually does.

Here are the final configurations for both routers:

mpls ldp router-id Loopback0 force
!
interface FastEthernet0/0
description -= WAN =-
ip address 115.0.0.2 255.255.255.252
!
interface Loopback0
ip address 2.2.2.2 255.255.255.25
!
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
keepalive 1 3
tunnel source 115.0.0.2
tunnel destination 116.0.0.2
ip ospf 100 area 0
mpls ip
!
interface Loopback0
ip ospf 100 area 0
!
interface fastethernet2/0
xconnect 3.3.3.3 2222 encapsulation mpls
!
ip route 0.0.0.0 0.0.0.0 115.0.0.1

mpls ldp router-id Loopback0 force
!
interface FastEthernet0/0
description -= WAN =-
ip address 116.0.0.2 255.255.255.252
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
ip address 1.1.1.2 255.255.255.252
keepalive 1 3
tunnel source 116.0.0.2
tunnel destination 115.0.0.2
!
interface fastethernet2/0
xconnect 2.2.2.2 2222 encapsulation mpls
ip ospf 100 area 0
mpls ip
!
interface Loopback0
ip ospf 100 area 0
!
ip route 0.0.0.0 0.0.0.0 116.0.0.1

The general case

The more general use case for EoMPLS is when a service provider uses it to give Layer 2 interconnectivity to its customer. The EoMPLS VC starts at one PE router, crosses the MPLS-enabled service provider network (a number of P routers) and gets terminated at another PE router. In this case instead of GRE the MPLS transport is used. The series of labels gets attached and popped from the packet above the VC label. The network diagram I used to emulate this looks the following:

This is how ICMP echo request from R5 to R6 (192.168.1.5 to 192.168.1.6) travels across the MPLS WAN:

R1 → R2

R2 → R3

R3 → R4

The packet carries two labels: the inner one identifies the VC as in previous case and the outer one is used to transport packet across the MPLS network. The outer label gets discarded on R3, because of penultimate-hop-popping so we don’t see it on R3 → R4 segment.

The outer label can easily change on the way, because it is local for each MPLS router interface. The captures above just show the case where both R1 and R2 got the same label (23) assigned for packets that are being forwarded towards 4.4.4.4/32 prefix. However it’s not always the case. Here is an example with echo reply packet going back from R6 to R5:

R4 → R3

R3 → R2

R2 → R1

Outer label gets switched from 18 to 16 and then discarded on R2. The inner label stays the same.

Here is a diagram showing the packet flow for echo-request and echo-reply:

mplsbblab3flow — Packet flow with EoMPLS across MPLS WAN

Cisco 1532 compact outdoor AP

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.

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:

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:

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:

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:

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:

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:

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:

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.

Don't Fragment

Network Engineer experience

Implementation

OSPF LSA Types

Type 1 – Router LSA

Type 2 – Network LSA

Type 3 – Summary LSA

Type 4 – ASBR summary LSA

Type 5 – External LSA

Type 7 – NSSA External LSA

Transcoding on Cisco Unified Border Element

Verification

Codec negotiation process

Layer 2 across Layer 3. Part 2 – EoMPLS

Setting up GRE

Setting up LDP

Setting up the EoMPLS Interconnection

Verifying

The general case

Cisco 1532 compact outdoor AP

Layer 2 across Layer 3. Part 1 – L2TP

Lab

The basic L2TPv3 configuration

R2

R3

Some theory

Verifying

Simple ASA Access-lists Configuration Technique

The plot

Solution?

First configure what vendor asks you to

Second: configure an explicit deny

Third: test, check, and correct configuration

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

Fifth: re-arrange the configuration if possible