Access-lists (ACL) in Nokia (Alcatel-Lucent) SR and Cisco IOS XR
Anton Karneliuk
Hello my friend,
In this article I’ll cover two functions of access-lists, which they have in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR: data plane protection and policy based routing. Though usually you don’t use them in lab, in real network their importance and distribution is really high.
Topology
Physical topology that we has built in previous series coupled with trunking are as good so we don’t need to change it. That’s why we’ll just recall it:
The logical topology is very similar to the previous one, which we used for ISIS configuration:
IPv4/OSPFv2 and IPv6/OSPFv3 is already configured. Pay attention that we have two different processes: 1 (red links on the image) and 2 (yellow links on the image). Each process has a loopback interface at each router that is announces only via this process. Two processes are needed to show you how policy routing (or more correctly access-list based forwarding – ABF) works.
The first task, which access-lists solve, is data plane security. So access-lists just filter the traffic based on desired conditions. Their logic is very straightforward:
Find the interesting traffic based on configured match parameters.
Apply the configured action (either forward traffic further or drop it).
Each entry in access-list, which is called access control entry or ACE, has a number. Access-list is checked for matched starting from lower number and continues until first match. When the match is found, then the configured action is performed and no more checks are done. That’s why it’s important to configure the more specific rules with lower numbers (on the top access-list). If there is no match, then default action is applied. Default action is drop both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, though you can change it Nokia (Alcatel-Lucent) SR OS. In Cisco IOS XR you also can allow all traffic just by configuring usual rule that allows all traffic.
Let’s configure the filter in such a way:
allow any OSPF traffic;
deny ICMP traffic from peer IP address at this interface (and log such packets);
allow any other traffic.
This access-lust should be applied at SR1 in the direction from SR3 and at XR1 in the direction from SR3. Before applying the rule it is possible to make ping from interface IP addresses at SR3:
A:SR3# ping 10.1.0.2 source 10.1.0.3
PING 10.1.0.2 56 data bytes
64 bytes from 10.1.0.2: icmp_seq=1 ttl=64 time=7.36ms.
—- 10.1.0.2 PING Statistics —-
1 packets transmitted, 1 packets received, 0.00% packet loss
round-trip min = 7.36ms, avg = 7.36ms, max = 7.36ms, stddev = 0.00ms
!
!
A:SR3# ping 10.2.0.2 source 10.2.0.3
PING 10.1.0.2 56 data bytes
64 bytes from 10.1.0.2: icmp_seq=1 ttl=64 time=7.36ms.
—- 10.1.0.2 PING Statistics —-
1 packets transmitted, 1 packets received, 0.00% packet loss
round-trip min = 7.36ms, avg = 7.36ms, max = 7.36ms, stddev = 0.00ms
Let’s configure such access-lists for mentioned routers, what involves both Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR:
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>filter# info
————————–
log 101 create
destination memory 500
exit
ip-filter 1 create
default-action forward
description “ACL_SR3_IN”
entry 10 create
match protocol ospf-igp
exit
action forward
exit
entry 20 create
match protocol icmp
src-ip 10.1.0.3/32
exit
log 101
action drop
exit
exit
————————–
*A:SR1>config>router# info
————————–
interface “toSR3”
ingress
filter ip 1
exit
exit
————————–
RP/0/0/CPU0:XR1(config)#show conf
ipv4 access-list ACL_SR3_IN
10 permit ospf any any
20 deny icmp host 10.2.0.3 any log
30 permit ipv4 any any
!
interface GigabitEthernet0/0/0/0.23
ipv4 access-group ACL_SR3_IN ingress
!
End
First of all you can mention that in Nokia (Alcatel-Lucent) SR OS you configure separate logging for access-lists. In the article about logging we have covered many interesting things, but not these one. In Cisco IOS XR there are no separate log streams, so they are sent to all destinations, which satisfy their severity (informational – level 6).
Also you can notice, that in Cisco IOS XR you configure the whole rule just in one line. In Nokia (Alcatel-Lucent) SR OS it is easier to correct rule as its components are configured separately.
Let’s check if configured access-lists achieve their goal:
As you can see the ping from interface’s IP address don’t work, though it works for loopback addresses. Also you can check log for dropped packets. In Nokia (Alcatel-Lucent) VSR (SR 7750) you do it as follows:
Besides logs, you can check how does your access-lists works in terms of proceeded packets and so on. In Nokia (Alcatel-Lucent) SR OS you do it as follows:
A:SR1# show filter ip 1
============================================================================
IP Filter
============================================================================
Filter Id : 1 Applied : Yes
Scope : Template Def. Action : Forward
System filter: Unchained
Entries : 2
Description : ACL_SR3_IN
—————————————————————————-
Filter Match Criteria : IP
—————————————————————————-
Entry : 10
Description : (Not Specified)
Log Id : n/a
Src. IP : 0.0.0.0/0
Src. Port : n/a
Dest. IP : 0.0.0.0/0
Dest. Port : n/a
Protocol : 89 Dscp : Undefined
ICMP Type : Undefined ICMP Code : Undefined
Fragment : Off Src Route Opt : Off
Sampling : Off Int. Sampling : On
IP-Option : 0/0 Multiple Option: Off
TCP-syn : Off TCP-ack : Off
Option-pres : Off
Match action : Forward
Next Hop : Not Specified Ing. Matches : 218 pkts (19776 bytes)
Egr. Matches : 0 pkts
—————————————————————————-
Entry : 20
Description : (Not Specified)
Log Id : 101
Src. IP : 10.1.0.3/32
Src. Port : n/a
Dest. IP : 0.0.0.0/0
Dest. Port : n/a
Protocol : 1 Dscp : Undefined
ICMP Type : Undefined ICMP Code : Undefined
Fragment : Off Src Route Opt : Off
Sampling : Off Int. Sampling : On
IP-Option : 0/0 Multiple Option: Off
TCP-syn : Off TCP-ack : Off
Option-pres : Off
Match action : Drop Ing. Matches : 6 pkts (636 bytes)
Egr. Matches : 0 pkts
============================================================================
!
!
A:SR1# show filter ip 1 associations
============================================================================
IP Filter
============================================================================
Filter Id : 1 Applied : Yes
Scope : Template Def. Action : Forward
System filter: Unchained
Entries : 2
Description : ACL_SR3_IN
—————————————————————————-
Filter Association : IP
—————————————————————————-
– Router Interface toSR3(Ingress)
—————————————————————————-
Filter associated with IOM: 1
============================================================================
At the beginning of the output above you can check, if the access-list is in use or not. Then in each entry you can see the number of matched packets and all the applied match rules. In Cisco IOS XR you have the following commands:
RP/0/0/CPU0:XR1#show access-lists ipv4
ipv4 access-list ACL_SR3_IN
10 permit ospf any any (261 matches)
20 deny icmp host 10.2.0.3 any log (4 matches)
30 permit ipv4 any any (1 match)
!
!
RP/0/0/CPU0:XR1#show access-lists ipv4 usage pfilter location all
Interface : GigabitEthernet0/0/0/0.23 Input ACL : ACL_SR3_IN
Output ACL : N/A
Data plane protection for IPv6
Let’s configure the same security rule for IPv6 data plane, as we’ve just done it for IPv4 addresses.
One exception for IPv6 traffic is that we allow NDP packets, which are ARP substitute in IPv6 world. Without NDP we are unable to make resolution of MAC addresses to IPv6.
RP/0/0/CPU0:XR1(config)#show conf
ipv6 access-list ACL_SR3_IN
10 permit ospf any any
18 permit icmpv6 any any nd-na
19 permit icmpv6 any any nd-ns
20 deny icmpv6 host fe80::3:2301 any log
30 permit ipv6 any any
!
interface GigabitEthernet0/0/0/0.23
ipv6 access-group ACL_SR3_IN ingress
!
End
As IPv4 and IPv6 access-lists live in different name spaces, so it’s OK to use the same name. It’s up to you, whether to do it or not, but it’s possible.
The next thing is that we configure new log stream in Nokia (Alcatel-Lucent) SR OS. We can to reuse the previously configured, but new is more convenient. According to our task, we should be able to ping loopback IP addresses from another loopback IP addresses, but we shouldn’t be able to ping interconnect IP:
It works as it should. All the show commands are the same as it were for IPv4. The only difference is that you should use “ipv6” as a keyword instead of “ipv4”.
Access-list based forwarding
Access-list based forwarding (shortly ABF) is an easiest form of policy based routing (PBR). It’s quite controversial tool, because it might makes troubleshooting of the network much more difficult. The main idea here is to send packets based on other parameter then destination IP address as it’s done in traditional routing. Let’s take a look how traffic from Lo2 at SR3 reaches the Lo2 at SR1:
A:SR3# ping 10.2.11.1 source 10.2.33.1 count 1
PING 10.2.11.1 56 data bytes
64 bytes from 10.2.11.1: icmp_seq=1 ttl=63 time=7.96ms.
—- 10.2.11.1 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 7.96ms, avg = 7.96ms, max = 7.96ms, stddev = 0.000ms
!
!
A:SR3# traceroute 10.2.11.1 source 10.2.33.1
traceroute to 10.2.11.1 from 10.2.33.1, 30 hops max, 40 byte packets
1 0.0.0.0 * * *
2 10.2.11.1 (10.2.11.1) 12.9 ms 16.2 ms 17.0 ms
It seems very weird, frankly speaking, but Cisco IOS XR isn’t reflected in the path. I’ve taken a look into wire:
Cisco IOS XR responds to traceroute packets (UDP) with ICMP – TTL exceeded messages instead of ICMP port unreachable messages. To be honest I have ideas why it is so. It makes my task to show you ABF a little bit more complex, but I still want to do it.
Take a look in RIB at XR1:
RP/0/0/CPU0:XR1#show route ipv4 10.2.11.1/32
Routing entry for 10.2.11.1/32
Known via “ospf 2”, distance 110, metric 100, type intra area
Installed Aug 4 08:01:47.806 for 00:46:33
Routing Descriptor Blocks 10.2.0.0, from 10.2.11.1, via GigabitEthernet0/0/0/0.11
Route metric is 100
No advertising protos.
Packets to prefix 10.2.11.1/32 are sent to 10.2.0.0 via interface gi 0/0/0/0.11 at XR1. Now let’s see how packets from SR1 are sent to 10.1.22.1/32:
A:SR1# show router route-table 10.1.22.1/32
============================================================================
Route Table (Router: Base)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
10.1.22.1/32 Remote OSPF(1) 00h49m17s 10 10.1.0.1 101
—————————————————————————-
No. of Routes: 1
So works ordinary routing (more precisely, destination based routing). Now let’s change it. Take a look at our topology again:
We want to make the following changes in IP forwarding:
From SR3/Lo1 to XR1/Lo1
At SR1 over toXR1_p2
From SR3/Lo2 to SR1/Lo2
At XR1 over g0/0/0/0.10
All other traffic should be untouched. In order to get the desired forwarding pattern we have to add one rule to existing access-lists in direction of SR3. In order to check that traffic really comes at interesting interfaces (without ability to use traceroute), let’s create basic access-lists and attach then at interfaces SR1-XR1:
Let’s verify availability first of all at path SR1/Lo1 to XR1/Lo1:
PING 10.1.22.1 56 data bytes
64 bytes from 10.1.22.1: icmp_seq=1 ttl=254 time=4.63ms.
—- 10.1.22.1 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 4.63ms, avg = 4.63ms, max = 4.63ms, stddev = 0.000ms
!
!
A:SR3# ping 10.1.0.1 source 10.1.33.1 count 1
PING 10.1.0.1 56 data bytes
64 bytes from 10.1.0.1: icmp_seq=1 ttl=254 time=7.71ms.
—- 10.1.0.1 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 7.71ms, avg = 7.71ms, max = 7.71ms, stddev = 0.000ms
The connectivity isn’t broken, so it’s good. Now let’s take a look into new access-lists that have been just configured for matching traffic:
A:SR1# show filter ip 10
============================================================================
IP Filter
============================================================================
Filter Id : 1 Applied : Yes
Scope : Template Def. Action : Forward
—————————————————————————-
Filter Match Criteria : IP
—————————————————————————-
Entry : 10
Description : (Not Specified)
Log Id : n/a
Src. IP : 10.1.33.1/32
Src. Port : n/a
Dest. IP : 10.1.22.1/32
Dest. Port : n/a
Ing. Matches : 0 pkts Egr. Matches : 1 pkts (84 bytes)
============================================================================
!
!
A:SR1# show filter ip 11
============================================================================
IP Filter
============================================================================
Filter Id : 11 Applied : Yes
Scope : Template Def. Action : Forward
—————————————————————————-
Filter Match Criteria : IP
—————————————————————————-
Entry : 10
Description : (Not Specified)
Log Id : n/a
Src. IP : 10.1.33.1/32
Src. Port : n/a
Dest. IP : 10.1.0.1/32
Dest. Port : n/a
Ing. Matches : 0 pkts Egr. Matches : 1 pkts (84 bytes)
============================================================================
You can see that egress counters have increased by the number of sent packets. It means that our access-list based forwarding works (ABF) at least in Nokia (Alcatel-Lucent) SR OS. Let’s check, if Cisco IOS XR behaves as we have configured:
A:SR3# ping 10.2.11.1 source 10.2.33.1 count 1
PING 10.2.11.1 56 data bytes
64 bytes from 10.2.11.1: icmp_seq=1 ttl=63 time=6.88ms.
—- 10.2.11.1 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 6.88ms, avg = 6.88ms, max = 6.88ms, stddev = 0.000ms
!
!
A:SR3# ping 10.2.0.0 source 10.2.33.1 count 1
PING 10.2.0.0 56 data bytes
64 bytes from 10.2.0.0: icmp_seq=1 ttl=63 time=7.32ms.
—- 10.2.0.0 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 7.32ms, avg = 7.32ms, max = 7.32ms, stddev = 0.000ms
And here are the hits of access-lists:
RP/0/0/CPU0:XR1#show access-lists
ipv4 access-list ACL_SR3_IN
10 permit ospf any any (16 matches)
20 deny icmp host 10.2.0.3 any log 25 permit icmp host 10.2.33.1 host 10.2.11.1 nexthop1 ipv4 10.1.0.0 (1 match) 30 permit ipv4 any any (1 match)
ipv4 access-list CHECK1
10 permit ipv4 host 10.2.33.1 host 10.2.11.1
20 permit ipv4 any any
ipv4 access-list CHECK2
10 permit ipv4 host 10.2.33.1 host 10.2.0.0
20 permit ipv4 any any
Unfortunately Cisco IOS XR (or more precisely my version of Cisco IOS XRv) doesn’t show the hits for egress access-lists, but I’m quite sure that it’s just bug. As we see the counters at ingress access-lists properly increasing, I hope it works.
The main problem with ABF is that these routes aren’t visible in routing table. And as we see, there are some problems in interoperability of traceroute between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, making troubleshooting of IP connectivity a real nightmare.
For IPv6 the configuration of ABF is pretty the same and you can find in final configuration files:
Lessons learned
Upon configuring lab for this article, I faced the problem that initially IPv6/OPSFv3 adjacency between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR haven’t come up. Debug in Nokia (Alcatel-Lucent) SR OS wasn’t informative, as I saw only outgoing packets:
34 2016/09/02 08:15:22.21 UTC MINOR: DEBUG #2001 Base OSPFv3(Inst: 2)
“OSPFv3(Inst: 2): PKT
>> Outgoing OSPF packet on I/F toXR1_p1 area 0.0.0.0
OSPF Version : 3
Router Id : 10.1.11.6
Area Id : 0.0.0.0
Checksum : 0000 InstanceID : 1
Packet Type : HELLO
Packet Length : 36 “
At Cisco IOS XR I was able to see both incoming and outgoining packets:
I was writing this article in train, so I had no access to Internet to find the solution so I had to invent it myself, what I find very interesting task. In the log you can see with bold, that instance ID is different between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. The reason for that is different behavior of OSPFv3 operation. When you configure in Nokia (Alcatel-Lucent) different processes of OSPFv3 they are separated by instances in the time of creation as it doesn’t have process names, as you have in Cisco. In Cisco IOS XR you can add instance to OSPFv3 configuration though it isn’t mandatory. And as you can see in the article about IPv6/OSPFv3, we haven’t configured it. In current article, where we have two separate processes, it’s needed. The following configuration was applied:
RP/0/0/CPU0:XR1(config)#show conf
router ospfv3 1 <-name, not instance instance 1
!
router ospfv3 2 <-name, not instance instance 2
!
end
For IPv4/OSPFv2 there is no such problem, as instance ID isn’t included in hello packet.
Conclusion
Access-lists were used for a long time in networks, especially at so called border nodes, what are actually network elements that has external connections. From the security point of view it’s very simple measure (if we compare it with IPS/IDS and statefull firewalls), it’s very often used at Internet routers, which don’t have any firewall in between. From routing point of view, ABF sometimes can really help. Several times I use it myself during migration phases of real network, where it’s impossible to implement target solution at once without interruption of services. Nevertheless I don’t recommend use it as permanent solution, because troubleshooting of ABF (and I seen it myself as well) is really difficult, because if the engineer is not aware of such solution, he won’t find it very quick. Take care and good bye!
