Archive
The perils of CPM filters and how to use them – 7750 SROS
Control plane filtering on the 7750 is managed with CPM filters, any time you want to secure you device or protocols you need to use these guys. They are basically access control to the processors and used wisely they are incredibly powerful. Use them foolishly and they may cost you your job. Configure them incorrectly and you can isolate your node or bring down your entire network! There is an urban legend that someone made a change to CPM filters from SAM and pushed them out to all nodes and unfortunately all remote access was lost, mega truck roll time!
****************** Caveat and warning time ******************
I am writing this post from memory, with some output I was able to find. I don’t have
any lab equipment to test this on so nothing below can be considered tested and/or safe
to deploy. You can do some serious damage with control plane filters. Do not deploy
without doing your own testing and/or vendor support. I’m not taking responsibility for
your actions. I can’t over emphasize testing every single change no matter how small.
**********************************************************************
OK so now the formalities are done with what can CPM filters do? I guess the first thing is they are not supported on the SR1 (or the 7210, they have other methods) so you need a bigger router. Like I said above they allow us to permit or deny addresses and protocols access to the CPM. You can configure MAC, IPv4, IPv6 filters but we will focus on IPv4 for today.
The first, and probably most crucial, is the default action applied to the filters. If you have no filters configured and you set the default action to deny then get in your car and head to site. Let’s set the default to accept which you should always do when you are making the filter list for the first time.
configure system security cpm-filter default-action accept
For reference the keyword to set the deny all else is ‘drop’ instead of ‘accept’
Now we have allowed all access to the routers control plane. Anything else we specify will either be allowed or dropped. Anything we don’t match at this point will be allowed as well, highly insecure. It’s up to you to determine your security policy and ensure it is based on best practice.
For the remainder of this post we will look at OSPF ensuring it is secure (we still need authentication of course). We will create filters for OSPF but also create a log mechanism to ensure any denied traffic is signalled to the operations guys. We will permit what we want, explicitly denying what we don’t and ignore the default action until the end.
Let’s configure the prefixes we want to match against and allow, assuming the neighbours are on 10.10.10.0/24
configure system security cpm-filter ip-filter entry 10 create description "allow ospf" action accept match protocol ospf-igp src-ip 10.10.10.0/24 exit exit
Lets deny all other OSPF
entry 20 create description "drop all other ospf" action drop log 123 match protocol ospf-igp exit exit
If any OSPF traffic not sourced from 10.10.10.0/24 hits the CPM it will be dropped and because we have the default action set to accept all traffic will be successful beyond this.
In order to verify if packets are being processed or not issue this command and you will see something similar to the following:
show system security cpm-filter ip-filter =============================================================================== CPM IP Filter (applied) =============================================================================== Id Dropped Forwarded Description ------------------------------------------------------------------------------- 10 0 648 "allow ospf" 20 11 0 "drop all other ospf"
What this tells us is 648 packets have been accepted sourced from 10.10.10.0/24. These will allow us to form adjacencies. The makey-uppy 11 dropped packets are assumed to be from any other address that we don't trust. You can see more detailed output on a per entry basis by specifying entry $number$ in the show command.
Now you will notice the log 123 statement in the deny entry. This will allow us to have a record of denied OSPF packets by sending entries to syslog.
First lets configure a syslog specific log
configure log syslog 2 description "send naughty ospf to syslog server" address 172.16.1.1 exit all
Here we are saying log 2 is used for syslog and the IP of the syslog server is 172.16.1.1. We now need to reference the syslog credentials in the filter log.
configure filter log 123 create description "log for untrusted ospf" destination syslog 2 wrap-around no shutdown
What we have done now is send logs for entry 20, based on its mapping to log 123, to the server listed in syslog 2. It's extra work to do all this but it's this type of modularity that I like about SROS.
So what have we achieved? We can now form adjacencies with our neighbours without being open to any attack from other routers outside of our controlled prefix. Of course we must secure our entire control plane as best we can. You should look to permit your IGP, LDP, RSVP, BGP, VRRP if you use it, multichassis protocols such as MC-LAG, BFD along with management protocols such as TACACS, SSH, NTP etc. This list is by no means exhaustive, you need to analyze your network traffic to see what you have hitting your CPMs. Once you have identified all relevant traffic, test your filters then set your default action to drop using
configure system security cpm-filter default-action drop
CPM filters are a must but they need to be respected or they will create more work for you down the road.
Segment routing basics on IOS XRv
Well the day has finally come, segment routing is in the land of the hardware-have-nots with the release of demo image 5.2.0 for IOS XRv. I was about to hit the hay last night when I saw the location appearing on the Twitter courtesy of @ciscoiosxr and my tiredness quickly left me. I have been waiting for something on SR for what seems like an eternity, imagine my sadness when the files started downloading at 200K, Santa was going to make me wait. Finally the vmdk downloaded and I was ready to go.
In this post I will show you a brief outline of how to configure SR in ISIS and some basic reachability. It’s pretty straightforward to get a base network up and running but unfortunately there is not a lot of documentation on it. Have a look here for some info on CRS 5.2.x which mentions it. Also for reference have a read of the draft here.
So, what does the topology look like?
Each router is running ISIS (process is called SR), there is no explicit MPLS configuration required in the traditional sense (mpls ldp, rsvp etc). XR1 and XR5 are PEs and have a VPNv4 session between each other. The customer VRF has one loopback defined on each PE which is redistributed in to VRF to prove the concept.
The only place we need to make changes from typical routing configuration is under the ISIS process:
RP/0/0/CPU0:XR3#sho run router isis SR Wed Jul 9 13:12:59.112 UTC router isis SR is-type level-2-only net 49.0001.0000.0000.0003.00 address-family ipv4 unicast metric-style wide segment-routing mpls ! interface Loopback0 address-family ipv4 unicast prefix-sid index 20003 ! ===snipiddy snip, nothing special here===
The only changes we had to make were to add in segment-routing mpls under the IPv4 unicast AF and set a prefix segment ID on the loopback address. Now from my reading of the draft the loopback should be a Node SID but that command doesn't seem to be available in this release. The number you choose for your SID will be altered by the OS and fit in to the actual range in use which is platform dependent. Here we support over 1 million labels so the configured prefix SID is added to 900000 with a max value of 65535 (more on that later). I chose 2000x where x is XRx from the node name. As an aside you cannot configure the prefix-sid index on a physical interface:
RP/0/0/CPU0:XR1(config)#router isis SR RP/0/0/CPU0:XR1(config-isis)#int g0/0/0/0 RP/0/0/CPU0:XR1(config-isis-if)#add ipv4 RP/0/0/CPU0:XR1(config-isis-if-af)#prefix index 30001 RP/0/0/CPU0:XR1(config-isis-if-af)#commit Wed Jul 9 14:31:37.859 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
Now let's have a look at the network and see what we can see. Again documentation isn't readily available so bear with me here...
We can see XR1 is sending us one VPNv4 prefix, which is 10.0.0.1/32, the loopback10 address from VRF CUST over yonder the network:
RP/0/0/CPU0:XR5#sho bgp vpnv4 uni summ | i 1.1.1.1 Wed Jul 9 13:29:31.354 UTC 1.1.1.1 0 65000 62 62 7 0 0 00:58:53 1 RP/0/0/CPU0:XR5#sho bgp vpnv4 uni vrf CUST 10.0.0.1/32 | b 1.1.1.1 Wed Jul 9 13:31:09.727 UTC 1.1.1.1 (metric 40) from 1.1.1.1 (1.1.1.1) Received Label 16000 Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 6 Extended community: RT:1:1 Source VRF: CUST, Source Route Distinguisher: 1:1 RP/0/0/CPU0:XR5#
And just to be sure this is what XR1 is sending
RP/0/0/CPU0:XR1#sho bgp vpnv4 uni labels | i 1/32 Wed Jul 9 13:36:07.657 UTC 10.0.0.1/32 0.0.0.0 nolabel 16000
We are receiving our label from XR1 of 16000, standard XR fare there. How about the MPLS forwarding table? Lets look from XR5 to XR1 via XR3 and XR2 (path via XR4 is costed out)
RP/0/0/CPU0:XR5#sho mpls for labels 920001 Wed Jul 9 13:38:23.908 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 920001 No ID Gi0/0/0/0 10.3.5.3 4585
RP/0/0/CPU0:XR3#sho mpls for labels 920001 Wed Jul 9 13:37:47.240 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 920001 No ID Gi0/0/0/0 10.2.3.2 5269
RP/0/0/CPU0:XR2#sho mpls for labels 920001 Wed Jul 9 13:38:47.046 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 Pop No ID Gi0/0/0/0 10.1.2.1 5868
And finally lets looks at the ISIS database on XR1
RP/0/0/CPU0:XR1#sho isis database verbose XR1.00-00 | b Seg Wed Jul 9 13:43:26.497 UTC Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535 Metric: 10 IS-Extended XR1.01 Metric: 10 IS-Extended XR1.03 Metric: 10 IP-Extended 1.1.1.1/32 Prefix-SID Index: 20001, R:0 N:0 P:0 Metric: 10 IP-Extended 10.1.2.0/24 Metric: 10 IP-Extended 10.1.4.0/24
Here we can see the Prefix SID is set to 20001 and also the range supported to 65535. We're all about the link state protocol so XR5 sees:
RP/0/0/CPU0:XR5#sho isis da ver XR1.00-00 | b Seg Wed Jul 9 13:44:42.612 UTC Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535 Metric: 10 IS-Extended XR1.01 Metric: 10 IS-Extended XR1.03 Metric: 10 IP-Extended 1.1.1.1/32 Prefix-SID Index: 20001, R:0 N:0 P:0 Metric: 10 IP-Extended 10.1.2.0/24 Metric: 10 IP-Extended 10.1.4.0/24
Now if we look at the CEF tables for the default VRF and the CUST VRF lets see what we have:
RP/0/0/CPU0:XR5#sho cef 1.1.1.1/32 | i label
Wed Jul 9 13:48:58.124 UTC
local label 920001 labels imposed {920001}
The BGP next hop will be using 920001 for the transport label and we know the VPN label issued by BGP over on XR1 will be 16000 so the label stack for VRF CUST on XR5 towards 10.0.0.1/32 on XR1 is...
RP/0/0/CPU0:XR5#sho ip cef vrf CUST 10.0.0.1/32 | i label
Wed Jul 9 13:51:29.064 UTC
next hop 10.3.5.3/32 Gi0/0/0/0 labels imposed {920001 16000}
Magic. Now does this work in the dataplane? We should see traffic MPLS'd via XR3 and XR2 and finally IPv4'd in the VRF at XR1
RP/0/0/CPU0:XR5#trace vrf CUST 10.0.0.1 so 10.0.0.5 Wed Jul 9 13:52:21.800 UTC Type escape sequence to abort. Tracing the route to 10.0.0.1 1 10.3.5.3 [MPLS: Labels 920001/16000 Exp 0] 39 msec 49 msec 29 msec 2 10.2.3.2 [MPLS: Labels 920001/16000 Exp 0] 29 msec 29 msec 39 msec 3 10.1.2.1 39 msec * 39 msec
Beautiful! As we can see the label stack stays consistent across the network as every node knows that 920001 is the label to reach 1.1.1.1/32, our BGP next hop from XR5.
In the opposite direction we should have a transport label of 920005 and the VPN label, which should be 16000 as well, coincidentally as there is only a single service and no other signalling protocols in play.
RP/0/0/CPU0:XR1#trace vrf CUST 10.0.0.5 so 10.0.0.1 Wed Jul 9 13:53:59.443 UTC Type escape sequence to abort. Tracing the route to 10.0.0.5 1 10.1.2.2 [MPLS: Labels 920005/16000 Exp 0] 119 msec 39 msec 39 msec 2 10.2.3.3 [MPLS: Labels 920005/16000 Exp 0] 39 msec 29 msec 29 msec 3 10.3.5.5 39 msec * 29 msec
One of the benefits of SR is being able to statically route your traffic without maintaining state associated with RSVP. I don't know if that feature is available in this release, I haven't found anything yet.
Pig iron time, can we configure a prefix SID higher than 65535? No would be the answer
RP/0/0/CPU0:XR3(config)#router isis SR RP/0/0/CPU0:XR3(config-isis)#int lo0 RP/0/0/CPU0:XR3(config-isis-if)#add ipv4 uni RP/0/0/CPU0:XR3(config-isis-if-af)#prefix index 65536 RP/0/0/CPU0:XR3(config-isis-if-af)#commit Wed Jul 9 13:26:46.825 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors RP/0/0/CPU0:XR3(config-isis-if-af)#prefix index 65535 RP/0/0/CPU0:XR3(config-isis-if-af)#commit Wed Jul 9 13:26:51.565 UTC RP/0/0/CPU0:XR3(config-isis-if-af)#do sho mpls for | i 655 Wed Jul 9 13:27:03.434 UTC 965535 Aggregate default: Per-VRF Aggr[V] \
I hope to write more on SR as more and more features become available, and interop stuff between vendors but for now enjoy the wonder that is the IGP delivered label.
iamjeffvader's studymotron and rantatorium 