Tag Archives: junos

Layer-2 VPNs on Junos

Reading Time: 7 minutes

It has been a busy few weeks trying to stay ahead of all the new work that has been coming towards myself and the team, due to the in sourcing of the core network! Lucky enough for my team, we have finally got our hands onto full end-to-end connectivity! Fun times 😀

With that being said, I’ve been given a wee project to provision a circuit for a business customer between two sites for a Proof Of Concept. As this circuit is being using as a POC (for now), it was agreed that a Layer 2 VPN (L2VPN/pseudowire) will be best suited, because a simple point-to-point connection was needed between two PEs. As we have a MPLS enabled network, it was decided that would be the easiest way to get their POC up and running quickly, as we were under a bit of a hard deadline!

For me, it was good little project, even though I know what L2VPNs were and how they work, I had never configured one myself. You see where I’m going with this now?

This post will over note how to configure L2VPN with Junos 😀

L2VPN, also known as a pseudowire, is defined in RFC4665, where they are called Virtual Private Wire Service (VPWS):

The PE devices provide a logical interconnect such that a pair of CE devices appears to be connected by a single logical Layer 2 circuit. PE devices act as Layer 2 circuit switches. Layer 2 circuits are then mapped onto tunnels in the SP network. These tunnels can either be specific to a particular VPWS, or be shared among several services. VPWS applies for all services, including Ethernet, ATM, Frame Relay, etc. Each PE device is responsible for allocating customer Layer 2 frames to the appropriate VPWS and for proper forwarding to the intended destinations.

In essence, L2VPNs are virtual point-to-point circuit that use the underlying Transport Labels (LDP/RSVP) or a statically defined MPLS path to go between two PE’s, that allows the extension of a layer 2 broadcast domain. If you need multiple sites on the same layer 2 broadcast you will need to consider Virtual Private Lan Service (VPLS) or Ethernet VPN (EVPN).

Within Junos there are 3 ways of configuring L2VPNs, two are regarded as modern way and has been rectified with RFC’s with an additional legacy method. Kompella and Martini are regarded as the industry standard, with Circuit Cross-Connect (CCC) seen as legacy:

  • Circuit Cross-Connect: The Circuit Cross-Connect style of L2VPN uses a single Outer Label, also known as the Tunnel/Transport Label, to transport L2 payload from PE to PE. CCC can ONLY use RSVP as MPLS transport, in addition each CCC connection has its own dedicated RSVP-signalled LSP associated, the transport label cannot be shared between multiple connections. LSPs are manually created on each PE to determines which circuit the frame belongs to on the other end.
  • Martini: The Martini style of L2VPN has a pair of labels before the L2 frame. The Outer label is the transport mechanism that allows the frame from egress interface from the sending PE to ingress interface of the receiving PE. The Inner label, known as the VC Label, is the label that informs the receiving PE, where the L2VPN payload should go. It is important to note that if you are using the Martini style, although either LDP or RVSP can be used MPLS transport, that LDP is used for the signalling of the VC label. So if the RSVP is used as the MPLS transport, LDP will need to be enabled on the loopback address of both PE routers. A minimum of 2 LSPs will need to be set, as MPLS LSPs are unidirectional.
  • Kompella: The Kompella style of L2VPN is similar to Martini style as both use stacked labels before the Layer 2 payload and both can use LDP, RSVP or both as Transport Label. There difference comes in that unlike Martini, Kompella uses BGP signalling as its VC Label. This means you will need to have BGP enabled network, in addition, it’s not compulsory to send static LSPs as BGP provides a mechanism for autodiscovery of new point-to-point links similar to a VPLS. Although Kompella has a more complex configuration, because of its usage of BGP signalling it is regarded as the best option for large scale deployments as it will in-conjunction with other BGP families. RFC6624 has more details on L2VPN using BGP for Auto-Discovery and Signaling

In our network, we use the Kompella style of L2VPNs. The bulk and most depth of my testing was with that method… Although I was able to get a wee bit of naughty time after to configure the other methods 🙂

The topology I’ll be working with is a simple one. I’ve a got a single MX480 broken up into 3 Logical Systems.

L2VPN Topology


The underlying IGP is IS-IS with RSVP, LDP and BGP enabled. This is a mirror, of what we have in production. With all the L2VPNs the customer facing physical interface has to be set to the correct encapsulation. For my testing, as I wont be using VLANs, Bridging or Setting a VPLS. I used ethernet-ccc and had set the logical interface to family ccc, you can find out more about the different physical encapsulations here

Interface ConfigRSVPMPLSBGPIS-ISLDP
set interfaces xe-0/1/0 enable
set interfaces xe-0/1/0 encapsulation ethernet-ccc
set interfaces xe-0/1/0 unit 0 family ccc
set protocols rsvp interface xe-1/0/0.0
set protocols rsvp interface xe-1/0/2.0
set protocols mpls explicit-null
set protocols mpls ipv6-tunneling
set protocols mpls no-decrement-ttl
set protocols mpls interface xe-1/0/0.0
set protocols mpls interface xe-1/0/2.0
set protocols bgp group Master type internal
set protocols bgp group Master local-address 192.168.2.1
set protocols bgp group Master family inet unicast
set protocols bgp group Master family inet6 unicast
set protocols bgp group Master local-as 100
set protocols bgp group Master neighbor 192.168.2.2 
set protocols bgp group Master neighbor 192.168.2.3
set protocols isis reference-bandwidth 1000g
set protocols isis level 1 disable
set protocols isis level 2 wide-metrics-only
set protocols isis interface xe-1/0/0.0 ldp-synchronization
set protocols isis interface xe-1/0/0.0 point-to-point
set protocols isis interface xe-1/0/0.0 link-protection
set protocols isis interface xe-1/0/2.0 ldp-synchronization
set protocols isis interface xe-1/0/2.0 point-to-point
set protocols isis interface xe-1/0/2.0 link-protection
set protocols isis interface xe-1/0/3.0 ldp-synchronization
set protocols isis interface xe-1/0/3.0 point-to-point
set protocols isis interface xe-1/0/3.0 link-protection
set protocols isis interface lo0.0
sset protocols ldp track-igp-metric
set protocols ldp explicit-null
set protocols ldp transport-address router-id
set protocols ldp interface xe-1/0/0.0
set protocols ldp interface xe-1/0/2.0
set protocols ldp interface lo0.0

All configurations will be done on the Master and SiteA, and for my examples I will show work done on the Master Instance. With all that out of the way… Let’s get cracking 😀

Kompella

As stated before, BGP is used as the VPN signalling method, with that in mind, we will need to enable layer-2 signalling within MP-BGP. This is simply done by adding the command family l2vpn signaling with the BGP stanza. This can be added globally within BGP or under the specific neighbour.

set protocols bgp group Master family l2vpn signaling

With the signalling sorted we can go straight into the configuration of the L2VPN. Just like L3VPNs, L2VPNs configuration is done within the routing-instance stanza and uses the same parameters as L3VPN by having Route Distinguisher (RD) and Route-Target/vrf-target (RT). The RD has to be unique per device with RT matching on all devices within the L2VPN, this is important, so that traffic can be routed accordingly per site. In addition, routing-instance has to be set to l2vpn and the interface(s) have to be defined within the routing-instance as well.

set routing-instances Master instance-type l2vpn
set routing-instances Master interface xe-0/1/0.0
set routing-instances Master route-distinguisher 100:0001
set routing-instances Master vrf-target target:100:0000

Next the properties for that site within the L2VPN will need to configured under protocol l2vpn within the routing-instance. The encapsulation has to match all site that want to participate within the VPN. The Site identifier must be unique to the entire site within the L2VPN as the site ID is used to compute label values for site-to-site communications. The interface(s) have to be defined within l2vpn and l2vpn site stanzas.

set routing-instances Master protocols l2vpn encapsulation-type ethernet
set routing-instances Master protocols l2vpn interface xe-0/1/0.0
set routing-instances Master protocols l2vpn site Master site-identifier 1
set routing-instances Master protocols l2vpn site Master interface xe-0/1/0.0
Full Kompella Configuration
set routing-instances Master instance-type l2vpn
set routing-instances Master interface xe-0/1/0.0
set routing-instances Master route-distinguisher 100:0001
set routing-instances Master vrf-target target:100:0000
set routing-instances Master protocols l2vpn encapsulation-type ethernet
set routing-instances Master protocols l2vpn interface xe-0/1/0.0
set routing-instances Master protocols l2vpn site Master site-identifier 1
set routing-instances Master protocols l2vpn site Master interface xe-0/1/0.0
set protocols bgp group Master family l2vpn signaling

Verification

The primary command that will be used to check the status of a pseudowire would be show l2vpn connections. As Komplella signalling uses BGP, we will be able to do a show bgp summary and see a route being advertised within the l2vpn and routing instance tables show route table Master.l2vpn.0 or show route table bgp.l2vpn.0 respectfully. Additionally we will be able to mpls.0 table to confirm that the L2VPN incoming label and interface(s) for the pseudowire have made the routing table, by using show route table mpls.0.

Show l2vpn Connectionsshow bgp summaryshow route table Master.l2vpn.0show route table mpls.0
[email protected]> show l2vpn connections    
Layer-2 VPN connections:

Legend for connection status (St)   
EI -- encapsulation invalid      NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch     WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down    NP -- interface hardware not present 
CM -- control-word mismatch      -> -- only outbound connection is up
CN -- circuit not provisioned    <- -- only inbound connection is up
OR -- out of range               Up -- operational
OL -- no outgoing label          Dn -- down                      
LD -- local site signaled down   CF -- call admission control failure      
RD -- remote site signaled down  SC -- local and remote site ID collision
LN -- local site not designated  LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status  IL -- no incoming label
MM -- MTU mismatch               MI -- Mesh-Group ID not available
BK -- Backup connection	         ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby	 SN -- Static Neighbor
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

Legend for interface status 
Up -- operational           
Dn -- down

Instance: Master
  Local site: Master (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jun  4 12:36:46 2016           2
      Remote PE: 192.168.2.2, Negotiated control-word: Yes (Null)
      Incoming label: 800001, Outgoing label: 800000
      Local interface: xe-0/1/0.0, Status: Up, Encapsulation: ETHERNET

[email protected]> show bgp summary 
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       0          0          0          0          0          0
inet6.0              
                       0          0          0          0          0          0
bgp.l2vpn.0          
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.2.2             100       3234       3229       0       1  1d 0:19:17 Establ
  inet.0: 0/0/0/0
  inet6.0: 0/0/0/0
  Master.l2vpn.0: 1/1/1/0
  bgp.l2vpn.0: 1/1/1/0
192.168.2.3             100       5735       5724       0       1 1d 19:06:59 Establ
  inet.0: 0/0/0/0
  inet6.0: 0/0/0/0
  Master.l2vpn.0: 0/0/0/0
  bgp.l2vpn.0: 0/0/0/0/

[email protected]> show route table Master.l2vpn.0 

Master.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100:1:1:1/96                
                   *[L2VPN/170/-101] 1d 20:37:12, metric2 1
                      Indirect
100:2:2:1/96                
                   *[BGP/170] 00:01:02, localpref 100, from 192.168.2.2
                      AS path: I, validation-state: unverified
                    > to 192.168.1.14 via xe-1/0/0.0, Push 0
                      to 192.168.1.6 via xe-1/0/2.0, Push 300000

[email protected]> show route table mpls.0 protocol l2vpn    

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

800001             *[L2VPN/7] 23:30:09
                    > via xe-0/1/0.0, Pop       Offset: 4
xe-0/1/0.0         *[L2VPN/7] 00:06:20, metric2 100
                    > to 192.168.1.14 via xe-1/0/0.0, Push 800000 Offset: 252
                      to 192.168.1.6 via xe-1/0/2.0, Push 800000, Push 300000(top) Offset: 252

From the end host point of view, we have end-to-end connectivity 😀

[email protected]:~$ ping -c 2 -q 192.168.137.3
PING 192.168.137.3 (192.168.137.3) 56(84) bytes of data.

--- 192.168.137.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.431/0.637/0.843/0.206 ms
Note
The route given from the show route table Master.l2vpn.0 is the Route Distinguisher of the other end of the pseudowire

Martini

Martini signalling uses LDP, as stated before, and with LDP enabled already, I will focus on the actual configuration, which is done within the protocol l2circuit stanza. Compared to Kompella, the configuration for Martini style of L2VPNs is much simpler. All that is needed is for:

  • The remote neighbour to be defined. In my example I will be using the loopback address SiteA as the remote neighbour
  • The customer facing interface connecting into the VPN
  • Set a circuit ID, that must match on both sides

All this can be done in one line!

set protocols l2circuit neighbor 192.168.2.2 interface xe-0/1/0.0 virtual-circuit-id 1

With that we have Martini style L2VPN configured 🙂

Verifications

To check the status of Martini style L2VPN, you will use show l2circuit connections, the output is near enough the same as show l2vpn connections. Martini, as discussed above, uses LDP for the signalling, we will be able to use show ldp neighbor to check that the neighbour relationship with the remote side has been successful and we will be able to check the LDP database by using show ldp database to verify that new labels associated with the pseudowire (L2CKT) has been installed into the database. Additionally you can check the inet.3 and mpls.0 routing tables, by using show route table inet.3 & show route table mpls.0

Show l2circuit Connectionsshow ldp neighborshow ldp databaseshow route table inet.3show route table mpls.0
[email protected]> show l2circuit connections 
Layer-2 Circuit Connections:

Legend for connection status (St)   
EI -- encapsulation invalid      NP -- interface h/w not present   
MM -- mtu mismatch               Dn -- down                       
EM -- encapsulation mismatch     VC-Dn -- Virtual circuit Down    
CM -- control-word mismatch      Up -- operational                
VM -- vlan id mismatch		 CF -- Call admission control failure
OL -- no outgoing label          IB -- TDM incompatible bitrate 
NC -- intf encaps not CCC/TCC    TM -- TDM misconfiguration 
BK -- Backup Connection          ST -- Standby Connection
CB -- rcvd cell-bundle size bad  SP -- Static Pseudowire
LD -- local site signaled down   RS -- remote site standby
RD -- remote site signaled down  HS -- Hot-standby Connection
XX -- unknown

Legend for interface status  
Up -- operational            
Dn -- down                   
Neighbor: 192.168.2.2 
    Interface                 Type  St     Time last up          # Up trans
    xe-0/1/0.0(vc 1)          rmt   Up     Jun  5 14:03:37 2016           1
      Remote PE: 192.168.2.2, Negotiated control-word: Yes (Null)
      Incoming label: 300000, Outgoing label: 300016
      Negotiated PW status TLV: No
      Local interface: xe-0/1/0.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No

[email protected]> show ldp neighbor      
Address            Interface          Label space ID         Hold time
192.168.2.2        lo0.0              192.168.2.2:0            43
192.168.1.6        xe-1/0/2.0         192.168.2.3:0            14
192.168.1.14       xe-1/0/0.0         192.168.2.2:0            13

[email protected]> show ldp database                             
Input label database, 192.168.2.1:0--192.168.2.2:0
  Label     Prefix
 299984      192.168.2.1/32
      0      192.168.2.2/32
 300000      192.168.2.3/32
 300016      L2CKT CtrlWord ETHERNET VC 1

Output label database, 192.168.2.1:0--192.168.2.2:0
  Label     Prefix
      0      192.168.2.1/32
 299968      192.168.2.2/32
 299984      192.168.2.3/32
 300000      L2CKT CtrlWord ETHERNET VC 1

Input label database, 192.168.2.1:0--192.168.2.3:0
  Label     Prefix
 300016      192.168.2.1/32
 300000      192.168.2.2/32
      0      192.168.2.3/32

Output label database, 192.168.2.1:0--192.168.2.3:0
  Label     Prefix
      0      192.168.2.1/32
 299968      192.168.2.2/32
 299984      192.168.2.3/32

[email protected]> show route table inet.3 192.168.2.2 

inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.2.2/32     *[LDP/9] 1d 21:16:06, metric 100
                    > to 192.168.1.14 via xe-1/0/0.0, Push 0
                      to 192.168.1.6 via xe-1/0/2.0, Push 300000
                    [RSVP/10/1] 1d 01:14:11, metric 100
                    > to 192.168.1.6 via xe-1/0/2.0, label-switched-path to-siteA

[email protected]> show route table mpls.0 protocol l2circuit 

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

300000             *[L2CKT/7] 00:05:13
                    > via xe-0/1/0.0, Pop       Offset: 4
xe-0/1/0.0         *[L2CKT/7] 00:05:13, metric2 100
                    > to 192.168.1.14 via xe-1/0/0.0, Push 300016 Offset: 252
                      to 192.168.1.6 via xe-1/0/2.0, Push 300016, Push 300000(top) Offset: 252

From the end host point of view, connectivity between the two is there 🙂

[email protected]:~$ ping -c 2 -q 192.168.137.3
PING 192.168.137.3 (192.168.137.3) 56(84) bytes of data.

--- 192.168.137.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.358/0.532/0.707/0.176 ms

Circuit Cross-Connect

As CCC doesn’t support stacked labels unlike Kompella and Martini, we will need to configure 2 static LSPs between the PE routers. CCC needs to have a LSP for to transmit and another to receive traffic. So firstly, we will need to get the LSPs configured. The received LSP will be configured on the remote PE, so under protocols mpls label-switched-path stanza, this is where we will define the LSP. I've used the loopback address of the remote end with the underlying IGP working out the best path.

set protocols mpls label-switched-path to-siteA to 192.168.2.2
set protocols mpls label-switched-path to-siteA no-cspf

With the LSPs configured, we will need to go under the protocol connections stanza. We need to define the customer facing interface(s) that will be connecting into the VPN, then set the transmit LSP and receive LSP, this will be the name of the LSP set on the remote end.

set protocols connections remote-interface-switch siteA interface xe-0/1/0.0
set protocols connections remote-interface-switch siteA transmit-lsp to-siteA
set protocols connections remote-interface-switch siteA receive-lsp to-Master

With that we are sorted!

Verifications

In regards with CCC there's less show commands, from what I’ve found (let me know if there's more please), but we can check the pseudowire's status by using show connections. We can confirm the Transmit (Ingress) and Receive (Egress) LSP using show mpls lsp and finally, we will be able to mpls.0 table to confirm that the L2VPN incoming label and interface(s) for the pseudowire have made the routing table, by using show route table mpls.0.

Show Connectionsshow mpls lspshow route table mpls.0
[email protected]> show connections 
CCC and TCC connections [Link Monitoring On]
Legend for status (St):             Legend for connection types:
 UN -- uninitialized                 if-sw:  interface switching
 NP -- not present                   rmt-if: remote interface switching
 WE -- wrong encapsulation           lsp-sw: LSP switching
 DS -- disabled                      tx-p2mp-sw: transmit P2MP switching
 Dn -- down                          rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up     Legend for circuit types:
 <- -- only inbound  conn is up      intf -- interface
 Up -- operational                   oif  -- outgoing interface
 RmtDn -- remote CCC down            tlsp -- transmit LSP
 Restart -- restarting               rlsp -- receive LSP


Connection/Circuit                Type        St      Time last up     # Up trans
siteA                             rmt-if      Up      Jun  3 12:42:55           1
  xe-0/1/0.0                        intf  Up
  to-siteA                          tlsp  Up
  to-Master                         rlsp  Up

[email protected]> show mpls lsp                           
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.2.2     192.168.2.1     Up     0 *     to-siteA         to-siteA
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.2.1     192.168.2.2     Up       0  1 FF  300080        - to-Master
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

[email protected]> show route table mpls.0 protocol ccc    

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

300080             *[CCC/7] 00:00:04
                    > via xe-0/1/0.0, Pop      
xe-0/1/0.0         *[CCC/10/1] 00:00:04, metric 100
                    > to 192.168.1.14 via xe-1/0/0.0, label-switched-path to-siteA

Finally to confirm end-to-end reachability between the end hosts

[email protected]:~$ ping -c 2 -q 192.168.137.3
PING 192.168.137.3 (192.168.137.3) 56(84) bytes of data.

--- 192.168.137.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.358/0.532/0.707/0.176 ms

I had planned to have a wee bit more to this post, with what I was actually testing ,however, this is getting a bit longer than I expected, so I'll make this into a two-part 😉

My next post will detail, how you can use traffic engineering to manipulate a L2VPN path between 2 PE routers! Hope to see you there 😀

References

Darren's Blog L2VPN in Junos
RFC4665
MPLS l2VPN
RFC6624
RFC6074
Vlan based CCC L2vpn

Share this:
Share

Upgrading Dual Routing Engine Juniper MX Series

Reading Time: 4 minutes

In one of my previous post, I explained how you would go about upgrading a Juniper EX switch. I said whenever I got the chance to upgrade a MX Series Router, I’ll get something noted down…… *raises hands* today is the day! As I’ve said in a few posts, there has been a lot of change and now team is now getting access to the Core Juniper MX Series Routers. As part of this increased access, one of our first tasks is it upgrade JunOS from 12.3R5.7 to 14.1R6.4. With most, if not, all MX Series above the MX80, they will come with two Routing Engines (RE), and both are independent of each other. This is being the case, when upgrading a MX; you will need to upgrade each RE by individually.

This post will go over what you will need to do upgrade an MX Router, in my setup I’ll be upgrading a Juniper MX480 Router and I’ll be doing the upgrade via the console port on each Routing Engine.

To link two Routing Engines together, you would need to apply similar configuration to what I used:

set groups re0 system host-name re0-mx480
set groups re0 interfaces fxp0 unit 0 family inet address x.x.x.x/x
set groups re1 system host-name re1-mx480
set groups re1 interfaces fxp0 unit 0 family inet address x.x.x.x/x
set apply-groups re1
set apply-groups re0

set chassis redundancy graceful-switchover
set routing-options nonstop-routing
set system commit synchronize

With that all cleared up.. Let’s get cracking 🙂

Pre Works

Upload the new firmware version to wherever you normally keep it them. Currently, we would normally upload the package into the /var/tmp folder on the device in question

[[email protected] ~]$ scp jinstall-14.3R6.4-domestic-signed.tgz re0-mx480:/var/tmp

After just saying how you to link the two REs together, for an upgrade, you will need to disable graceful-switchover and nonstop-routing. Skipping this step can potentially result in the control plane and forwarding plane having two different JUNOS versions, which can cause a number of potential issues!

deactivate chassis redundancy graceful-switchover
deactivate routing-options nonstop-routing

Upgrade Process

Having disabled both graceful-switchover and nonstop-routing, log onto the Backup RE, either by console or from the Master RE run the command request routing-engine login re1. Once on the Backup RE, you will need to run the command request system software validate add /var/tmp/xxx reboot.

[email protected]> request system software validate add /var/tmp/jinstall-14.1R6.4-domestic-signed.tgz reboot
NOTE
If you’re like us and save the new firmware package to the local device, when you run the software add command DO NOT set what RE has the package stored. If you do you add the package’s location once the upgrade is completed, on one of the RE, it will delete the image from the device!
Additionally you had requested a session from re0 to re1 to connect to Backup RE, once the RE reboots, you get this message and get booted off

[email protected]>                                                                                
*** FINAL System shutdown message from [email protected] ***                 

System going down IMMEDIATELY                                                  

                                                                               
rlogin: connection closed

If you have console access, you can watch the upgrade ticking along, if you don’t, you can confirm the Backup RE is up and running by using the command show chassis routing-engine, it will show the status and hardware stats for both Routing Engines.

show chassis routing-engine output
[email protected]> show chassis routing-engine    
Routing Engine status:
  Slot 0:
    Current state                  Master
    Election priority              Master (default)
    Temperature                 31 degrees C / 87 degrees F
    CPU temperature             37 degrees C / 98 degrees F
    DRAM                      3584 MB (3584 MB installed)
    Memory utilization          20 percent
    CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     4 percent
      Interrupt                  0 percent
      Idle                      96 percent
    Model                          RE-S-2000
    Serial ID                      9012021718
    Start time                     2016-03-22 13:14:37 GMT
    Uptime                         3 hours, 38 minutes, 16 seconds
    Last reboot reason             Router rebooted after a normal shutdown.
    Load averages:                 1 minute   5 minute  15 minute
                                       0.01       0.01       0.00
Routing Engine status:
  Slot 1:
    Current state                  Backup
    Election priority              Backup (default)
    Temperature                 33 degrees C / 91 degrees F
    CPU temperature             38 degrees C / 100 degrees F
    DRAM                      3584 MB (4096 MB installed)
    Memory utilization          16 percent
    CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     0 percent
      Interrupt                  0 percent
      Idle                     100 percent
    Model                          RE-S-2000
    Serial ID                      9012022174
    Start time                     2016-03-22 16:47:56 GMT
    Uptime                         4 minutes, 45 seconds
    Last reboot reason             Router rebooted after a normal shutdown.
    Load averages:                 1 minute   5 minute  15 minute
                                       0.34       0.47       0.23

Having upgraded Backup RE, to reduce the downtime and service impact, you can failover the Master Routing Engine, so that the Backup becomes the new Master Routing Engine. This is an manual process by running the command, from the current Master RE, request chassis routing-engine master switch. This WILL cause a brief outage as the PFE is reset and the new firmware is loaded.

[email protected]> request chassis routing-engine master switch    
warning: Traffic will be interrupted while the PFE is re-initialized
Toggle mastership between routing engines ? [yes,no] (no) yes 

Resolving mastership...
Complete. The other routing engine becomes the master.

You can confirm by running show chassis routing-engine again on RE0

AFTER failing over Routing Engine
[email protected]> show chassis routing-engine 
Routing Engine status:
  Slot 0:
    Current state                  Backup
    Election priority              Master (default)
    Temperature                 32 degrees C / 89 degrees F
    CPU temperature             39 degrees C / 102 degrees F
    DRAM                      3584 MB (3584 MB installed)
    Memory utilization          16 percent
    CPU utilization:
      User                       2 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      97 percent
    Model                          RE-S-2000
    Serial ID                      9012021718
    Start time                     2016-03-22 13:14:37 GMT
    Uptime                         3 hours, 50 minutes, 7 seconds
    Last reboot reason             Router rebooted after a normal shutdown.
    Load averages:                 1 minute   5 minute  15 minute
                                       0.21       0.07       0.02
Routing Engine status:
  Slot 1:
    Current state                  Master
    Election priority              Backup (default)
    Temperature                 33 degrees C / 91 degrees F
    CPU temperature             41 degrees C / 105 degrees F
    DRAM                      3584 MB (4096 MB installed)
    Memory utilization          22 percent
    CPU utilization:
      User                      43 percent
      Background                 0 percent
      Kernel                    28 percent
      Interrupt                  0 percent
      Idle                      29 percent
    Model                          RE-S-2000
    Serial ID                      9012022174
    Start time                     2016-03-22 16:47:56 GMT
    Uptime                         16 minutes, 42 seconds
    Last reboot reason             Router rebooted after a normal shutdown.
    Load averages:                 1 minute   5 minute  15 minute
                                       4.71       1.11       0.46

Having failed over the RE now, all that needed is to repeat the same command as before request system software validate add /var/tmp/xxx reboot to install the new firmware on RE0

[email protected]> request system software add /var/tmp/jinstall-14.1R6.4-domestic-signed.tgz reboot

Once the Routing-Engine has upgraded you need to re-enable graceful-switchover and non-routing, first, you will see why in moment.

activate chassis redundancy graceful-switchover
activate routing-options nonstop-routing

After commit synchronising those changes, you will need to set RE0 back to the Master Routing Engine. This will be done by running request chassis routing-engine master switch from RE1 now.

[email protected]>request chassis routing-engine master switch 
Toggle mastership between routing engines ? [yes,no] (no) yes 

Resolving mastership...
Complete. The other routing engine becomes the master.

{backup}
[email protected]> 

Now that Graceful Switchover is enable when you run the command you wont see the same warning about traffic being disrupted, this is because Graceful Switchover preserves interface and kernel information allowing the PFE to continue forwarding packets, even though one of the REs is unavailable.

NOTE
More detail Graceful Switchover can be found on Juniper’s TechLibrary

We will need to save a backup of the currently running and active file system by issuing the command request system snapshot on both primary as well as backup REs

[email protected]> request system snapshot 
Doing the initial labeling...
Verifying compatibility of destination media partitions...
Running newfs (899MB) on hard-disk media  / partition (ad2s1a)...
Running newfs (100MB) on hard-disk media  /config partition (ad2s1e)...
Copying '/dev/ad0s1a' to '/dev/ad2s1a' .. (this may take a few minutes)
Copying '/dev/ad0s1e' to '/dev/ad2s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config

Finally, confirm the code version by running show version invoke-on all-routing-engine. I’ve used the commands show version and show version invoke-on other-routing-engine just because I can put the two outputs into a table-like thing and it looks neater in a post :p

show version RE0show version RE1
{master}
[email protected]> show version          
Hostname: RE0-MX480-02
Model: mx480
Junos: 14.1R6.4
JUNOS Base OS boot [14.1R6.4]
JUNOS Base OS Software Suite [14.1R6.4]
JUNOS Packet Forwarding Engine Support (M/T/EX Common) [14.1R6.4]
JUNOS Packet Forwarding Engine Support (MX Common) [14.1R6.4]
JUNOS platform Software Suite [14.1R6.4]
JUNOS Runtime Software Suite [14.1R6.4]
JUNOS Online Documentation [14.1R6.4]
JUNOS Services AACL Container package [14.1R6.4]
JUNOS AppId Services [14.1R6.4]
JUNOS Services Application Level Gateways [14.1R6.4]
JUNOS Services Captive Portal and Content Delivery Container package [14.1R6.4]
JUNOS Border Gateway Function package [14.1R6.4]
JUNOS Services HTTP Content Management package [14.1R6.4]
JUNOS IDP Services [14.1R6.4]
JUNOS Services LL-PDF Container package [14.1R6.4]
JUNOS Services Jflow Container package [14.1R6.4]
JUNOS Services MobileNext Software package [14.1R6.4]
JUNOS Services Mobile Subscriber Service Container package [14.1R6.4]
JUNOS Services PTSP Container package [14.1R6.4]
JUNOS Services NAT [14.1R6.4]
JUNOS Services RPM [14.1R6.4]           
JUNOS Services Stateful Firewall [14.1R6.4]
JUNOS Voice Services Container package [14.1R6.4]
JUNOS Services Crypto [14.1R6.4]
JUNOS Services SSL [14.1R6.4]
JUNOS Services IPSec [14.1R6.4]
JUNOS py-base-i386 [14.1R6.4]
JUNOS Kernel Software Suite [14.1R6.4]
JUNOS Crypto Software Suite [14.1R6.4]
JUNOS Routing Software Suite [14.1R6.4]
{master}
[email protected]> show version invoke-on other-routing-engine 
re1:
--------------------------------------------------------------------------
Hostname: RE1-MX480-02
Model: mx480
Junos: 14.1R6.4
JUNOS Base OS boot [14.1R6.4]
JUNOS Base OS Software Suite [14.1R6.4]
JUNOS Packet Forwarding Engine Support (M/T/EX Common) [14.1R6.4]
JUNOS Packet Forwarding Engine Support (MX Common) [14.1R6.4]
JUNOS platform Software Suite [14.1R6.4]
JUNOS Runtime Software Suite [14.1R6.4]
JUNOS Online Documentation [14.1R6.4]
JUNOS Services AACL Container package [14.1R6.4]
JUNOS Services Application Level Gateways [14.1R6.4]
JUNOS AppId Services [14.1R6.4]
JUNOS Services Captive Portal and Content Delivery Container package [14.1R6.4]
JUNOS Border Gateway Function package [14.1R6.4]
JUNOS Services HTTP Content Management package [14.1R6.4]
JUNOS Services Jflow Container package [14.1R6.4]
JUNOS IDP Services [14.1R6.4]
JUNOS Services LL-PDF Container package [14.1R6.4]
JUNOS Services MobileNext Software package [14.1R6.4]
JUNOS Services Mobile Subscriber Service Container package [14.1R6.4]
JUNOS Services NAT [14.1R6.4]           
JUNOS Services RPM [14.1R6.4]
JUNOS Services PTSP Container package [14.1R6.4]
JUNOS Services Stateful Firewall [14.1R6.4]
JUNOS Voice Services Container package [14.1R6.4]
JUNOS Services SSL [14.1R6.4]
JUNOS Services Crypto [14.1R6.4]
JUNOS Services IPSec [14.1R6.4]
JUNOS py-base-i386 [14.1R6.4]
JUNOS Kernel Software Suite [14.1R6.4]
JUNOS Crypto Software Suite [14.1R6.4]
JUNOS Routing Software Suite [14.1R6.4]

And with that, we have an upgraded Dual Routing Engine MX Series router! 😀 Yay! I’ll most likely, now that I’ve got the access, mess about with ISSU upgrade on MX next so keep an eye for that one!

Reference

Configuring Dual Routing Engines MX Series
Procedure to Upgrade JUNOS on a Dual Routing Engine System
Understanding Graceful Switchover (GRES)

Share this:
Share

Configuring IPv4 DHCP Juniper SRX

Reading Time: 1 minute

After configuring a Dual Stacked DHCP server and DHCPv6 on Juniper SRX, it’s only right that I did something on Configuring DCHPv4 on a Juniper SRX.

This wont be a long or detailed post, as the configuration is very much the same as my previous post on how to configure DHCPv6 on a SRX, and I’ve went thought quite a lot before about how DHCP works etc.

First, under the system services dhcp-local-server stanza, you will need to create group and set a physical or logical interface that will have DHCP enabled

[email protected]# show system services dhcp-local-server    
group dhcpv4-group {
    interface vlan.3407;
}

Next, under the access address-assignment stanza, you will need to set the network, the DHCP range and set the IP address that the router will be using within the DCHP pool. The propagate-settings will take configuration from the client DHCP on vlan.3407, if not otherwise specified, most importantly name-server which changes from ISP to ISP and is very important otherwise name resolutions on the LAN won’t work.

[email protected]# show access   
address-assignment {
    pool v4 {
        family inet {
            network 172.31.106.16/29;
            range v4-range {
                low 172.31.106.18;
                high 172.31.106.22;
            }
            dhcp-attributes {
                router {
                    172.31.106.17;
                }
                propagate-settings vlan.3407;
            }
        }
    }
}

This will be all configuration needed to have DHCPv4 on Juniper SRX220. For troubleshooting DHCP you will be able to use the commands below:

[email protected]> show dhcp ? 
Possible completions:
  client               Show DHCP client information
  relay                Show DHCP relay information
  server               Show DHCP server information
  snooping             Show DHCP snooping information
  statistics           Show DHCP service statistics

As I said, this is the quick post :p

I have included the set commands used in my example below:

DHCP Set Commands
set system services dhcp-local-server group dhcpv4-group interface vlan.3407
set access address-assignment pool v4 family inet network 172.31.106.16/29
set access address-assignment pool v4 family inet range v4-range low 172.31.106.18
set access address-assignment pool v4 family inet range v4-range high 172.31.106.22
set access address-assignment pool v4 family inet dhcp-attributes router 172.31.106.17
set access address-assignment pool v4 family inet dhcp-attributes propagate-settings vlan.3407
Share this:
Share

IPv6 and Junos – Stateful Auto-configuration with DHCPv6

Reading Time: 4 minutes

As part of my on-going IPv6 testing, I was asked to look into stateful auto-configuration for devices and host using DHCPv6. I had already looked into Stateless Address Auto configuration and looked into another method of providing stateful auto-configuration using a Dual Stacked DHCP server. This time I’ll be looking into how this could be done using Juniper hardware, to be specific Juniper SRX series routers. If you haven’t used DHCP before my other DHCP related post gave an explanation on what DHCP is and how DHCPv6 communications work slightly different to DHCPv4. With that in mind, I won’t be going over what DHCP is again, but instead I’ll be going straight into the good stuff!

Lets get cracking 😀

For this test I had simple topology; I used a Juniper SRX220 as the DHCP server and a single ESXi Ubuntu 14.04LTS hosts connected on port ge-0/0/0 as the client.

Firstly, with the SRX, I had to enabled IPv6 flow mode. By default, IPv6 IS NOT enabled. You enable IPv6 flow mode by running the command set security forwarding-options family inet6 mode flow-based, once committed you’ll need to reboot the device for the change to take effect. When the SRX is finished booting you can confirm IPv6 flows will be able to be permitted by using show security flow status:

[email protected]> show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: RR-based
  Flow ipsec performance acceleration: off
  Flow packet ordering
    Ordering mode: Hardware

Now that we know we can actually get stateful IPv6 flows traversing the SRX, we can start with enabling the SRX as a DHCPv6 server.

Under the system services dhcp-local-server stanza, we will need to confirm that we’ll be using DHCPv6 and set the interface(s) that will be requesting addresses. Additionally there are a few optional commands. For my example I’ve set the max limit of DHCP clients to 100 by using the interface-client-limit statement, and by default there are no limits on amount of clients that can request an address.

[email protected]# show system services 
dhcp-local-server {
    dhcpv6 {
        overrides {
            interface-client-limit 100;
        }
        group v6 {
            interface vlan.100;
        }
    }
}

Next, under the access address-assignment stanza is where we’ll set the prefix pool that will be advertised to host, and your IP range. In addition, within this stanza you’re able to set other DHCP details such as lease time, grace period and dns-server under dhcp-attributes. The attributes are optional however they should be looked into and configured according to your own requirements.

[email protected]# show access   
address-assignment {
    pool v6 {
        family inet6 {
            prefix 2001:192:168:1::/64;
            range dhcpv6-range {
                low 2001:192:168:1::200/128;
                high 2001:192:168:1::299/128;
            }
            dhcp-attributes {
                maximum-lease-time 120;
                grace-period 3600;
            }
        }
    }
}

We need to set the SRX so that the router advertises our IPv6 prefix on the correct interface, and in addition, by adding the statement managed-configuration, the router will be both stateful (DHCP) and stateless (SLAAC) address assignments. Finally, in order for the DHCPv6 server to allow DHCPv6 requests, a security policy is needed to enable DHCPv6 traffic.

ProtocolsSecurity Zone
[email protected]# show protocols 
router-advertisement {
    interface vlan.100 {
        managed-configuration;
        prefix 2001:192:168:1::/64;
    }
}
[email protected]# show security zone security-zone internal {
    tcp-rst;
    interfaces {
        vlan.100 {
            host-inbound-traffic {
                system-services {
                    dhcpv6;
                }
            }
        }
    }
}

With SRX configured, we can now check the client side to make sure it’s enabled for DHCP. On the client, we have to set its interface to listening for DHCP packets. For IPv6 we’ll need to set the interface to DHCP under /etc/network/interfaces.

[email protected]:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
{...}
auto eth1
iface eth1 inet dhcp

# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 dhcp

Now that we have both the SRX and the client configured, we can bring it all together and run some tests!

Verification Testing

On the client, we’ll request an IP address from the SRX by running dhclient eth1 -6 -v and can confirm that an address has been successful assigned by doing an ifconfig

Requesting an addressifconfig eth1
[email protected]:~$ sudo dhclient eth1 -6 -v 
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  | X-- Request address 2001:192:168:1::111.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT:  | X-- Request address 2001:192:168:1::200.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT: Solicit on eth1, interval 1060ms.
RCV: Advertise message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250973
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32 (s: 153, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 2001:192:168:1::200
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth1, interval 930ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250974
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
PRC: Bound to lease 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38:31.
[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          inet6 addr: 2001:192:168:1::200/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12342 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4052626 (4.0 MB)  TX bytes:3303461 (3.3 MB)

Having confirmed that an IP address from DHCP pool has been assigned on the client, we can now look on SRX to see what has happened there!

Firstly, I checked to see if I could see the session flow from the client to SRX by running show security flow session. As the output below shows, as per RFC3315, DHCPv6 communications are done on UDP ports 546 (clients) and 547 (server/relay) and via link-local addresses.

[email protected]> show security flow session       
Session ID: 1, Policy name: self-traffic-policy/1, Timeout: 1800, Valid
  In: 10.1.0.17/46789 --> 10.1.0.158/22;tcp, If: ge-0/0/7.0, Pkts: 5631, Bytes: 416401
  Out: 10.1.0.158/22 --> 10.1.0.17/46789;tcp, If: .local..0, Pkts: 3109, Bytes: 389005

Session ID: 9, Policy name: self-traffic-policy/1, Timeout: 54, Valid
  In: fe80::120e:7eff:fe4e:2e88/547 --> fe80::20c:29ff:fe4f:26c5/546;udp, If: .local..0, Pkts: 2, Bytes: 288
  Out: fe80::20c:29ff:fe4f:26c5/546 --> fe80::120e:7eff:fe4e:2e88/547;udp, If: vlan.100, Pkts: 0, Bytes: 0
Total sessions: 2

We only get two show commands with a DHCP server, whether it’s v4 or v6, show dhcpv6 server binding and show dhcpv6 server statistics.

  • show dhcpv6 server binding provides details on the address that has been assigned to a client, which including; MAC address, Prefix, Lease time, current state and interface.
  • show dhcpv6 server statistics, as the name suggests, provides figures on sent and receive messages between the server and clients.
DHCPv6 BindingsDHCPv6 Statistics
[email protected]> show dhcpv6 server binding        
Prefix                  Session Id  Expires  State    Interface    Client DUID
2001:192:168:1::200/128 2           74       BOUND    vlan.100     LL_TIME0x1-0x1ddd0462-00:0c:29:4f:26:c5
[email protected]> show dhcpv6 server statistics 
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             0
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               0
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               1
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

For completeness, I had the client release the assigned address to check the statistics, just to make sure I did see an increment change.

Releasing Assigned AddressDHCPv6 Statistics
[email protected]:~$ sudo dhclient -6 -v -r eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
XMT: Forming Release, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Release Address 2001:192:168:1::200
XMT:  V IA_NA appended.
XMT: Release on eth1, interval 1070ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
[email protected]> show dhcpv6 server statistics    
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             1
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               1
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               3
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

And with that a DHCPv6 Server has been configured using a Juniper SRX series router!

I’ve included a useful show command and the set commands that I used in my example below 🙂

Operational CommandsSet Commands
show security flow session
show dhcpv6 server binding
show dhcpv6 server statistics
clear dhcpv6 server binding
clear dhcpv6 server statistics
set security forwarding-options family inet6 mode flow-based

set system services dhcp-local-server dhcpv6 overrides interface-client-limit 200
set system services dhcp-local-server dhcpv6 group v6 interface vlan.100

set protocols router-advertisement interface vlan.100 prefix 2001:192:168:1::/64

set access address-assignment pool v6 family inet6 prefix 2001:192:168:1::/64
set access address-assignment pool v6 family inet6 range dhcpv6-range low 2001:192:168:1::200/128
set access address-assignment pool v6 family inet6 range dhcpv6-range high 2001:192:168:1::299/128
set access address-assignment pool v6 family inet6 dhcp-attributes maximum-lease-time 120
set access address-assignment pool v6 family inet6 dhcp-attributes grace-period 3600

set security zones security-zone internal interfaces vlan.100 host-inbound-traffic system-services dhcpv6

More in-depth detailed information can be found on Juniper’s TechLibrary pages

Share this:
Share

Leaking Routes into a Routing-Instance

Reading Time: 4 minutes

In a previous post I wrote about how I went about configuring a NTP server and setting NTP clients. A few days later, when speaking with my senior, the plan changed slightly and we weren’t configuring our own NTP server using Linux based OS, but get satellite feeds running our own LANTIME Stratum 1 Server o_O! In other words that previous post is now invalid haha!

For now I don’t know if I’ll be involved in that side of the project, I hope I am, but that’s for another day! Back to my actual point, because of the environment we run in our datacentres, our firewalls run with Virtual-Router Routing-Instances. A Virtual Router is similar than Cisco’s VRF concept however, with Juniper’s a Virtual Router is used for non-VPN related applications. So, I was asked to investigate if it was possible for our firewalls to be NTP clients to a NTP server via the master instance and also be able to act as a NTP server to attached clients within a routing-instance.

Note
You can get more detail about Juniper’s Routing-Instance Types on their TechLibrary Routing Instances Overview

Although it sounds a bit of a mouthful, the topology itself is quite straightforward. The diagram below shows the topology I’ll be testing with:

Routing

As the diagram shows, I’ll be using a standalone Juniper SRX220h and two ESXi Ubuntu 14.04LTS servers. The SRX will be a NTP client of the NTP server (km-vm4) via the master inet.0 table. The second client km-vm1 will be located within the Routing-Instance “test” and will be using the SRX220 as its NTP server. Security policies will need to be defined, as the stateful functionalities of the SRX will still be in use. Without creating security between the zones all traffic will be dropped.

Note
The Base configuration used in this topology is below. (I using this SRX for IPv6 testing as well, so ignore the vlan name lol)
Base Config
set interfaces ge-0/0/0 enable
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members internal-v6
set interfaces ge-0/0/1 enable
set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members ntp-server
set interfaces vlan unit 100 family inet address 192.168.1.1/24
set interfaces vlan unit 101 family inet address 192.168.2.1/24

set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match source-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match destination-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match application junos-ntp
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp then permit

set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match source-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match destination-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match application junos-ntp
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp then permit

set security zones security-zone vlan100 interfaces vlan.100 host-inbound-traffic system-services any-service
set security zones security-zone vlan101 interfaces vlan.101 host-inbound-traffic system-services any-service

set routing-instances test instance-type virtual-router
set routing-instances test interface vlan.100

set vlans internal-v6 vlan-id 100
set vlans internal-v6 l3-interface vlan.100
set vlans ntp-server vlan-id 101
set vlans ntp-server l3-interface vlan.101

With this setup, the overall goal of this testing is to see if it’s possible to advertise specific routes from the inet.0 table to another routing table, to allow end to end connectivity between routing instances.

This post will not show/explain how the stateful functionalities of the SRX series firewall works. That will be in another post :p

With all that talk and background out of the way… Let’s get cracking 🙂

With the NTP server already configured, the SRX need to set as an NTP client. This configuration is done under system ntp stanza. We set the remote server, ntp version and preference. In addition, I set two other statements; one is optional and the other had to be set. The statements, boot-server and source-address, Juniper defines these statements as:

  • boot-server: When the router or switch boots, it immediately synchronizes with the boot server even if the NTP process is explicitly disabled or if the time difference between the client and the boot server exceeds the threshold value of 1000 seconds.
  • source-address: This is statement useful for controlling which source address NTP will use to access your network when it is either responding to an NTP client request from your network or when it itself is sending NTP requests to your network.

As described above, and in a nutshell, by adding the source-address this will allow other clients/devices to set an IP address that’s located on the SRX as their remote NTP server. Thus providing a /32 address that can be advertised. For my example the address 192.168.2.1, the gateway address for the ntp server, will be the address used as the source address.

[email protected]# show system ntp 
boot-server 192.168.2.100;
server 192.168.2.100 version 4 prefer;
source-address 192.168.2.1;

We can verify the NTP association by using the command show ntp assocication.

[email protected]# run show ntp associations                      
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.100   43.255.190.16    3 -  148  256  377    2.313    0.748   0.063

With NTP verified on the SRX, we have to leak the NTP source address for the SRX 192.168.2.1 from the inet.0 table to the test.inet.0 table. As we can see, when we look at the routing instance’s routing table, we don’t have the route installed into the table:

[email protected]# run show route table test.inet.0      

test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.1.0/24     *[Direct/0] 04:02:28
                    > via vlan.100
192.168.1.1/32     *[Local/0] 06:31:31
                      Local via vlan.100

To get the route installed into the test.inet.0 table, we’ll need to leak the 192.168.2.1/32 route into the test.inet.0 table, and we’ll do this by creating two policy statements. For my example I’ve named them master and instance just for ease!

  • Master: This statement allows all routes from routing instance test to be accepted into the master routing table.
  • Instance: This statement has two terms. Term 1 only allows the exact route 192.168.2.1/32 from the master instance to be accepted. Term 2 denies all other routes from master instance.
[email protected]# show policy-options 
policy-statement master {
    from instance test;
    then accept;
}
policy-statement instance {
    term 1 {
        from {
            instance master;
            route-filter 192.168.2.1/32 exact;
        }
        then accept;
    }
    term 2 {
        then reject;
    }
}

Now we’ll need to import the relevant policy into each instance, under the routing-options stanza for the inet.0 table and routing-instance test routing-options for the test.inet.0 table.

Master Instance Routing-OptionsRouting-Instance Routing-Options
[email protected]# show routing-options 
static {
    route 0.0.0.0/0 {
        next-hop 10.1.0.1;
        no-readvertise;
    }
}
instance-import master;
[email protected]# show routing-instances test routing-options 
instance-import instance;

Having committed the policy statements, when we check both routing tables we can see the 192.168.1.0/24 route have been leaked into the inet.0 table, and that only the 192.168.2.1/32 route has been installed into the test.inet.0 table. All other routes have not been leaked.

inet.0 tabletest.inet.0 table
[email protected]> show route table inet.0 

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


0.0.0.0/0          *[Static/5] 1w2d 09:40:34
                    > to 10.1.0.1 via ge-0/0/7.0
10.1.0.0/24        *[Direct/0] 1w2d 09:40:34
                    > via ge-0/0/7.0
10.1.0.158/32      *[Local/0] 1w2d 09:40:39
                      Local via ge-0/0/7.0
192.168.1.0/24     *[Direct/0] 2d 04:15:32
                    > via vlan.100
192.168.1.1/32     *[Local/0] 2d 04:15:32
                      Local via vlan.100
192.168.2.0/24     *[Direct/0] 2d 07:20:32
                    > via vlan.101
192.168.2.1/32     *[Local/0] 3d 08:44:24
                      Local via vlan.101
[email protected]> show route table test.inet.0   

test.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.1.0/24     *[Direct/0] 09:32:22
                    > via vlan.100
192.168.1.1/32     *[Local/0] 12:01:25
                      Local via vlan.100
192.168.2.1/32     *[Local/0] 05:28:32
                      Local via vlan.101

Finally, on the client we’ll need to set a static route so that the host knows if it wants to get the 192.168.2.0/24 subnet it will need to use the gateway 192.168.1.1 via eth1

[email protected]:~$ sudo route add -net 192.168.2.0/24 gw 192.168.1.1 dev eth1
[email protected]:~$ ip route
default via 10.1.0.1 dev eth0 
10.1.0.0/24 dev eth0  proto kernel  scope link  src 10.1.0.137 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.100 
192.168.2.0/24 via 192.168.1.1 dev eth1

Once that route has been installed we can see that the host has now become a NTP client to the SRX by running the command ntpq -p. In addition on the SRX, we can see the flow session between inet.0 and test.inet.0 routing tables.

NTP AssociationSRX flow Session
[email protected]:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.1     192.168.2.100    4 u   15   64    3    2.086   -0.094   0.109
[email protected]> show security flow session destination-prefix 192.168.2.1 
Session ID: 21218, Policy name: allow-ntp/4, Timeout: 40, Valid
  In: 192.168.1.100/123 --> 192.168.2.1/123;udp, If: vlan.100, Pkts: 7, Bytes: 532
  Out: 192.168.2.1/123 --> 192.168.1.100/123;udp, If: .local..5, Pkts: 7, Bytes: 532
Total sessions: 1

And with that we’ve been able to route between routing instances! The most important thing that I found whilst do this testing is that you need to remember to add the static route on the host or device that is directly connected to router with the routing-instance. This same setup would work with a switch in between the SRX and end host, just have the static route and you’ll be sorted. In addition to having the right security policies, as they’ll bite you in the bum as well :p

I’ve included the set commands that I used in my example below, if you wanted to give it a try for yourself 🙂

Set Commands
set system ntp boot-server 192.168.2.100
set system ntp server 192.168.2.100 version 4
set system ntp server 192.168.2.100 prefer
set system ntp source-address 192.168.2.1

set routing-options instance-import p1

set policy-options policy-statement p1 from instance test
set policy-options policy-statement p1 then accept

set policy-options policy-statement p2 term 1 from instance master
set policy-options policy-statement p2 term 1 from route-filter 192.168.2.1/32 exact
set policy-options policy-statement p2 term 1 then accept
set policy-options policy-statement p2 term 2 then reject

set routing-instances test routing-options instance-import p2

Reference

Juniper Knowledge Base: NTP over routing-instance on EX-series switches
Juniper TechLibrary: NTP Configuring

Share this:
Share