Recently I moved from Christchurch to Sydney and wanted to have some fun doing various labs and tests between two SRXs, one over here and the other in Christchurch. These were mentioned in my first blog if you haven’t already seen. The reason I’m writing this blog is I’ve found a gap online where I can’t seem to find anyone who has written up something for doing RSVP based MPLSoGRE. There are a few variants, some using LDPoGRE or LDPoGREoIPSEC which is all very good, but if you’re like me, you’ll love the power and granuality of RSVP. The other reason is my move also took me into a new company that doesn’t use Juniper mainstream on the SP network, and any Junos OS I could use to do anything was keeping me sane!
Aside from doing virtual labs on VMWare firefly machines, I wanted to give this real world scenario a go, that being, running an MPLS network between Christchurch and Sydney on two simple DSL connections using SRX. Currently and as far to my knowledge, SRXs can’t do MPLS in flow mode, however, Junos OS allows you to manually change traffic to packet mode which ill demonstrate soon. OF course you could have your SRX or J series router in packet mode, but depending on the application of your Juniper device, that may just not suit. Firstly I’ll verify for you that my SRX is in flow mode
<perrin@srx-au> show security flow status Flow forwarding mode: Inet forwarding mode: flow based Inet6 forwarding mode: drop MPLS forwarding mode: drop ISO forwarding mode: drop Advanced services data-plane memory mode: Default Flow trace status Flow tracing status: off Flow session distribution Distribution mode: RR-based>
Setting up the configuration
This example will use GRE between two public IP addresses and won’t run over a IPSEC VPN. (If you wanted to you would just setup the GRE tunnel with the two addresses specified inside the IPSEC section of your VPN)
set security ipsec vpn srx_aus ike proxy-identity local 188.8.131.52/32 set security ipsec vpn srx_aus ike proxy-identity remote 184.108.40.206/32
I’ll make another post on more detail for this kind of setup. Anyhow, standard GRE..
set interfaces gr-0/0/0 unit 2 description "inet.0 - TUNNEL_SERVICE - Australia SRX GRE Tunnel for MPLS" set interfaces gr-0/0/0 unit 2 tunnel source 220.127.116.11 set interfaces gr-0/0/0 unit 2 tunnel destination 18.104.22.168 set interfaces gr-0/0/0 unit 2 family inet mtu 1516 set interfaces gr-0/0/0 unit 2 family inet address 10.0.255.4/31 set interfaces gr-0/0/0 unit 2 family mpls filter input MPLS-packet-mode
set interfaces lo0 unit 0 family inet address 22.214.171.124/32
I’ll quickly confirm the GRE tunnel operation.
perrin@srx-au> ping 10.0.255.4 source 10.0.255.5 count 5 PING 10.0.255.4 (10.0.255.4): 56 data bytes 64 bytes from 10.0.255.4: icmp_seq=0 ttl=64 time=75.513 ms 64 bytes from 10.0.255.4: icmp_seq=1 ttl=64 time=74.488 ms 64 bytes from 10.0.255.4: icmp_seq=2 ttl=64 time=74.344 ms 64 bytes from 10.0.255.4: icmp_seq=3 ttl=64 time=73.671 ms 64 bytes from 10.0.255.4: icmp_seq=4 ttl=64 time=74.476 ms --- 10.0.255.4 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 73.671/74.498/75.513/0.590 ms
You’ll notice I have a firewall filter added to family MPLS on the GRE interface. This is the key to running the MPLS on a flow based SRX.
perrin@srx-nz> show configuration firewall family mpls filter MPLS-packet-mode | display set set firewall family mpls filter MPLS-packet-mode term all-traffic then packet-mode set firewall family mpls filter MPLS-packet-mode term all-traffic then accept
As this filter has no “from” statement, all traffic is matched then processed with “then” and as you can see I’m turning packet-mode on for MPLS traffic only”
Because the rest my SRX environment is still running in flow mode, there are a few small things that need to be accounted for. One of those is “intra-zone” traffic, that is, two interfaces inside the same zone, talking to each other. In this particular setup, that is communication between lo0 and gr-0/0/0.2. To keep things simple for this example, I have added a allow all policy for this zone.
set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match source-address any set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match destination-address any set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match application any set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all then permit
Here you can see that loopback traffic transit gr-0/0/0.2
Session ID: 11663, Policy name: allow_all/9, Timeout: 1772, Valid In: 126.96.36.199/1 --> 188.8.131.52/1;rsvp, If: gr-0/0/0.2, Pkts: 1671, Bytes: 373840 Out: 184.108.40.206/1 --> 220.127.116.11/1;rsvp, If: .local..0, Pkts: 0, Bytes: 0
Security Zone config for interfaces participating in the MPLS
perrin@srx-au> show configuration security zones security-zone Tunnel_Services | display set set security zones security-zone Tunnel_Services interfaces gr-0/0/0.2 host-inbound-traffic protocols all set security zones security-zone Tunnel_Services interfaces lo0.0 host-inbound-traffic protocols all
Now for the basic MPLS and RSVP configuration:
perrin@srx-au> show configuration protocols mpls | display set set protocols mpls label-switched-path 5-to-1 to 18.104.22.168 set protocols mpls interface gr-0/0/0.2 perrin@srx-au> show configuration protocols rsvp | display set set protocols rsvp interface gr-0/0/0.2
It’s a very simple configuration set and I’m only specifying one very basic LSP, at this stage I am not running, primary/seconday paths with fast reroute etc. Just keeping it basic for this demonstration. (there will be further blogs with more advanced CSPF material) The backbone of any MPLS network in a service provider network, is a solid IGP configuration and in my case MP-BGP with all the right knobs turned on for the type of traffic I want to run over this network. Here is my example OSPF and BGP configuration.
perrin@srx-au> show configuration protocols ospf | display set set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface gr-0/0/0.2 interface-type p2p perrin@srx-au> show configuration protocols bgp group mpls-core | display set set protocols bgp group mpls-core type internal set protocols bgp group mpls-core multihop set protocols bgp group mpls-core local-address 22.214.171.124 set protocols bgp group mpls-core family inet unicast set protocols bgp group mpls-core family inet multicast set protocols bgp group mpls-core family inet-vpn unicast set protocols bgp group mpls-core family inet6 unicast set protocols bgp group mpls-core family inet6 multicast set protocols bgp group mpls-core family inet6-vpn unicast set protocols bgp group mpls-core family l2vpn signaling set protocols bgp group mpls-core graceful-restart set protocols bgp group mpls-core neighbour 126.96.36.199
OSPF here is pretty straight forward. I have changed the interface type to point to point mode. Usually OSPF listens on multicast address 188.8.131.52, but instead now the SRX will unicast the OSPF packets to the remote instead of mulicast. Makes sense when there is only one device listening. You need to make 100% sure you have traffic engineering turned on else your LSPs won’t stand up. OSPF uses Type 10 opaque LSAs to carry traffic engineering extensions. This populates the traffic engineering database with this information. As you can see above there is a few more BGP parameters setup, many of these needed for our setup here. For example, to enable your bgp to carry network layer reachability information (NLRI) for particular traffic types, I’ve setup the “inet unicast” likewise with “inet6″ for ipv6 information. What we are going to use here most of all is “l2vpn signalling” and “inet-vpn unicast” for VPLS and L3 VRFs.
Lets do some verification for what we have done so far. OSPF and BGP are standing up
perrin@srx-au> show ospf neighbor Address Interface State ID Pri Dead 10.0.255.4 gr-0/0/0.2 Full 184.108.40.206 128 32 perrin@srx-au> show ospf database opaque-area OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len OpaqArea 220.127.116.11 18.104.22.168 0x8000001e 1076 0x22 0x178f 28 OpaqArea*22.214.171.124 126.96.36.199 0x8000001e 1479 0x22 0x2777 28 OpaqArea 188.8.131.52 184.108.40.206 0x8000002c 120 0x22 0xded0 136 OpaqArea*220.127.116.11 18.104.22.168 0x8000002c 119 0x22 0x7d39 136 perrin@srx-au> show bgp neighbor 22.214.171.124 Peer: 126.96.36.199+56907 AS 64514 Local: 188.8.131.52+179 AS 64514 Type: Internal State: Established Flags: **Output ommited**
Great everything is working so far. One thing I would recommend checking is that your OSPF database contains OpaqArea LSA types! If you add a detail on the end of that command you will get a world of information about what TE stuff OSPF is transporting. When the BGP neighbour is being checked, you can verify all the address families that have been configured
perrin@srx-au> show bgp neighbor 184.108.40.206 | match "Address families" Address families configured: inet-unicast inet-multicast inet-vpn-unicast inet6-unicast inet6-multicast inet6-vpn-unicast l2vpn-signaling
Right lets check the MPLS side of things starting with whether the LSP is up.
perrin@srx-au> show rsvp interface RSVP interface: 1 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark gr-0/0/0.2 Up 1 100% 800Mbps 800Mbps 0bps 0bps perrin@srx-au> show mpls lsp Ingress LSP: 2 sessions To From State Rt P ActivePath LSPname 220.127.116.11 18.104.22.168 Up 0 * 5-to-1 Total 2 displayed, Up 1, Down 1 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 22.214.171.124 126.96.36.199 Up 0 1 FF 3 - 1-to-5 Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
We can also verify the CSPF operation by adding detail on the end of the previous command.
perrin@srx-au> show mpls lsp detail ingress Ingress LSP: 2 sessions 188.8.131.52 From: 184.108.40.206, State: Up, ActiveRoute: 0, LSPname: 5-to-1 ActivePath: (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1) 10.0.255.4 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.0.255.4
You can see here that the LSP has successfully negioated a ERO (Explicit Route Object) and received a confirmation RRO (Route Record Object). To quickly summarise what these are, the ERO will list either loose or strict LSRs the LSP must transit. The RRO is a record of LSRs the LSP has transited to establish the path, essentially a list of address the path has gone through.
Now remember, when creating an LSP, you are building a path in one direction, this is not an automatic bidirectional path so you must remember to create a mirrored path on your remote device. This can be verified with “show mpls lsp” command and confirming you have a ingress and egress LSP. Naturally if you were running and LDP based MPLS topology things would be a little difference, but for RSVP, thats how we take care of business.
At this stage, you are pretty much ready to add your L2 and L3 VRFs into the mix and get some traffic running across this link. I will make another post on configuring these and I will go into further detail on setup and verification.
I hope this will serve as a real world working example that will help with studies or maybe even a production application for anyone who is interested. From here, I will be adding some posts on some more advanced features of RSVP like using fast reroute, primary, secondary paths and some other cool stuff like that in the future as well!