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.
Initial configuration you can find here: SR1_initial SR3_initial XR1_initial linux
Data plane protection for IPv4
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 |
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 |
RP/0/0/CPU0:XR1(config)#show conf |
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:
|
A:SR3# ping 10.1.0.2 source 10.1.0.3 count 1 |
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:
|
A:SR1# show filter log 101 |
In Cisco IOS XR (ASR 9000) you can see it in all logs:
|
RP/0/0/CPU0:XR1#show logging |
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 |
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 |
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.
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
*A:SR1>config>filter# info |
RP/0/0/CPU0:XR1(config)#show conf |
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:
|
A:SR3# ping fe80::2:2301-“toXR1” count 1 |
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 |
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 |
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 |
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:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
*A:SR1>config>filter# info |
RP/0/0/CPU0:XR1(config)#show conf |
Let’s verify availability first of all at path SR1/Lo1 to XR1/Lo1:
|
PING 10.1.22.1 56 data bytes |
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 |
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 |
And here are the hits of access-lists:
|
RP/0/0/CPU0:XR1#show access-lists |
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) |
At Cisco IOS XR I was able to see both incoming and outgoining packets:
|
RP/0/0/CPU0:Aug 4 02:46:24.252 : ospfv3[1030]: PKT: Recv: HLO l:36 inst:1 aid:0.0.0.0 from GigabitEthernet0/0/0/0.10 fe80::1:1001 (10.1.11.6) |
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:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
*A:SR1# configure router |
RP/0/0/CPU0:XR1(config)#show conf |
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!
Support us
BR,
Anton Karneliuk
