Juniper SRX – Upgrading JunOS from USB

There’s a few ways to do this. Here’s the easiest:

First, format your USB drive as fat32. Download the compressed image from Juniper (e.g. junos-srxsme-15.1X49-D80.4-domestic.tgz) and load it onto the USB drive.

Whilst logged into the SRX’s console, plug in the USB drive. You’ll see something like the below:

  1. umass1: TOSHIBA TransMemory, rev 2.00/1.00, addr 2
  2. da1 at umass-sim1 bus 1 target 0 lun 0
  3. da1: <TOSHIBA TransMemory 1.00> Removable Direct Access SCSI-4 device
  4. da1: 40.000MB/s transfers
  5. da1: 7400MB (15155200 512 byte sectors: 255H 63S/T 943C)

This tells you that the USB drive is available at /dev/da1. Assuming your drive has a single partition, that means the filesystem will be at /dev/da1s1.

Jump into the FreeBSD shell:

  1. start shell

Create a directory and mount the USB drive to it:

  1. mkdir /var/tmp/usb/
  2. mount_msdosfs /dev/da1s1 /var/tmp/usb/

Check that your JunOS image is present on the mount:

  1. root@% ls -1 /var/tmp/usb/
  2. junos-srxsme-15.1X49-D80.4-domestic.tgz

Jump back to the main JunOS console:

  1. exit

Install the image:

  1. request system software add no-copy /var/tmp/usb/junos-srxsme-15.1X49-D80.4-domestic.tgz

Reboot your device:

  1. request system reboot in 0

Once rebooted, sanity check your new install. If all is ok, you need to copy the JunOS image to the backup partition else if your SRX ever fails to boot then it will boot into your old JunOS:

  1. request system snapshot slice alternate

Once done, you can check it:

  1. root> show system software
  2. Information for junos:
  3.  
  4. Comment:
  5. JUNOS Software Release [15.1X49-D80.4]
  6.  
  7. root> show system software backup
  8. Backup JUNOS package information:
  9. File name: /altroot/cf/packages/junos-15.1X49-D80.4-domestic
  10. File size: 249978054

And that’s it.

Juniper SRX PPPoE Configuration for Plusnet ADSL

This was a bit of a faff, so I thought I’d document it. The setup here is an ADSL modem plugged into ge-0/0/4 with the SRX doing PPPoE (CHAP) via that modem. Apparently this is the same for VDSL2 (FTTC) via the BT OpenReach modem also. Config below:

  1. interfaces {
  2. ge-0/0/4 {
  3. description "Plusnet Off-Net WAN via Zyxel Modem";
  4. unit 0 {
  5. encapsulation ppp-over-ether;
  6. }
  7. }
  8. pp0 {
  9. unit 0 {
  10. ppp-options {
  11. chap {
  12. default-chap-secret "your-password";
  13. local-name "yourusername@plusdsl.net";
  14. no-rfc2486;
  15. passive;
  16. }
  17. }
  18. pppoe-options {
  19. underlying-interface ge-0/0/4.0;
  20. idle-timeout 0;
  21. auto-reconnect 10;
  22. client;
  23. }
  24. family inet {
  25. mtu 1480;
  26. negotiate-address;
  27. }
  28. }
  29. }
  30. }
  31. routing-options {
  32. static {
  33. route 0.0.0.0/0 next-hop pp0.0;
  34. }
  35. }
  36. security {
  37. zones {
  38. security-zone public {
  39. interfaces {
  40. pp0.0 {
  41. host-inbound-traffic {
  42. system-services {
  43. ping;
  44. traceroute;
  45. ike;
  46. ssh;
  47. }
  48. }
  49. }
  50. }
  51. }
  52. }
  53. flow {
  54. tcp-mss {
  55. all-tcp {
  56. mss 1440;
  57. }
  58. }
  59. }
  60. }

 

An overview of JunOS Quality of Service (QoS / CoS) configuration

JunOS QoS configuration is flexible, albeit a little tricky to understand. It has a few key components which I shall list and then explain. There’s other less common things which are possible, I will not try to explain these here. This is largely based around SRX devices but it should be mostly applicable to other devices such as EX, MX and J Series:

Key Components

  • Interface Egress Queues – When a physical interface tries to send more traffic than its bandwidth permits, packets are queued in one of a few different numbered queues
  • Interface Bandwidth Definition – You should manually define the bandwidth of an interface if it is lower than the line speed. For example, a 1gbit interface connected to a 200mbit fibre ethernet line needs to be defined as being 200mbit else it will assume 1gbit and QoS will not work
  • Forwarding Classes – These effectively assign a name to a numbered queue, for example assured-forwarding
  • Assignment of traffic to a forwarding class – This can be done in a number of ways:
    • Classifiers – These observe DSCP, Inet Precedence or other marker types to assign ingress traffic to forwarding classes
    • Firewall Rules – Ingress traffic can be matched with firewall rules and assigned to forwarding classes
  • Drop Profiles – A drop profile defines the probability of packets being dropped when a queue reaches a certain size
  • Schedulers – These define how differently queued egress traffic is prioritized
  • Scheduler Maps – These link forwarding classes to schedulers

Interface Egress Queues

When a physical interface tries to send more traffic than its bandwidth permits, packets are queued in one of a few different numbered queues. You can see queues in the “extensive” interface output.

  1. root@edge> show interfaces pt-1/0/0 extensive
  2. Physical interface: pt-1/0/0, Enabled, Physical link is Up
  3. Egress queues: 8 supported, 4 in use
  4. Queue counters: Queued packets Transmitted packets Dropped packets
  5. 0 best-effort 1024518 1024201 317
  6. 1 expedited-fo 607 607 0
  7. 2 assured-forw 7775 7775 0
  8. 3 network-cont 7948 7948 0

You can see a few things here:

  • 8 queues are supported but only 4 are in use
  • Queues have been assigned named forwarding classes
  • The number of packets that have passed through each queue
  • The number of packets which have been dropped from each queue

Interface Bandwidth Definition

If your egress interface has less bandwidth than the actual interface speed, for example you have 1gbit interface connected to a 200mbit Ethernet circuit, you need to specify the bandwidth of the Interface. The configuration for this is as follows:

  1. interfaces {
  2. reth1 {
  3. description "Internet Connection";
  4. unit 0 {
  5. /* This is the available bandwidth of this connection, minus 10% */
  6. bandwidth 90m;
  7. }
  8. }
  9. }

It is suggested that you set the bandwidth to about 90% of the ISP stated speed. E.g. for a “200mbit fibre ethernet line”, set it to 180m. Setting it too low isn’t going to police your speed – you will still get maximum throughput. Setting it too high will try to allocate too high a minimum bandwidth to each queue and you’ll start to experience issues.

Forwarding Classes

A forwarding class is mapped to a numbered queue. Traffic is assigned to forwarding classes and thus into the right queues. JunOS comes with a default configuration which is suitable for many implementations – for example VOIP prioritization on a small to medium sized office network.

  1. root@edge> show class-of-service forwarding-class
  2. Forwarding class ID Queue Policing priority SPU priority
  3. best-effort 0 0 normal low
  4. expedited-forwarding 1 1 normal low
  5. assured-forwarding 2 2 normal low
  6. network-control 3 3 normal low

If you want to configure more, you can consult the Juniper documentation.

Assignment of Traffic to a Forwarding Class

This can be done in a number of ways. Here I shall cover 2 different ways:

Classifiers

These observe DSCP, Inet Precedence or other marker types to assign ingress traffic to forwarding classes. JunOS comes with a default classifier for each type of classification (DSCP, MPLS, Inet Precedence, etc.). On a private network which you control, this is my preferred way of doing it. You should mark the packets as close to the source as possible. VOIP phones will usually mark packets themselves. Other stuff may need to be marked on switches or other routers.

Here’s a (very) short excerpt of the default DSCP classifier on a branch SRX:

  1. root@edge> show class-of-service classifier type dscp
  2. Classifier: dscp-default, Code point type: dscp, Index: 7
  3. Code point Forwarding class Loss priority
  4. 000000 best-effort low
  5. 001010 assured-forwarding low
  6. 101110 expedited-forwarding low
  7. 101111 best-effort low
  8. 110000 network-control low

Have a look at the default and see how it suits you. You may want to tweak it a little. You can extend default classes and change only a few things, without the need to redefine the whole lot. For VOIP, you may want to assign AF31 (011010) to assured-forwarding. You also need to assign the classifier to your ingress interface in order to classify the traffic as it comes in. Here’s how you do that:

  1. class-of-service {
  2. classifiers {
  3. dscp voip {
  4. import default;
  5. forwarding-class assured-forwarding {
  6. /* Default classfier is ok, except we also need AF31 */
  7. loss-priority low code-points 011010;
  8. }
  9. }
  10. }
  11. interfaces {
  12. /* This is the interface(s) behind which VOIP phones reside */
  13. reth2 {
  14. unit * {
  15. classifiers {
  16. dscp voip;
  17. }
  18. }
  19. }
  20. }
  21. }

We “import” the default DSCP classifier and simply assign the AF31 codepoint to the assured-forwarding class.

Firewall Rules

You can use firewall rules to classify traffic into a forwarding class. The below example shows how to classify SIP traffic into the assured-forwarding class:

  1. firewall {
  2. family inet {
  3. filter VOICE {
  4. term SIP {
  5. from {
  6. protocol udp;
  7. source-port 5060;
  8. destination-port 5060;
  9. }
  10. then {
  11. forwarding-class assured-forwarding;
  12. accept;
  13. }
  14. }
  15. term ALL {
  16. then accept;
  17. }
  18. }
  19. }
  20. }
  21. interfaces {
  22. interface fe-0/0/7 {
  23. unit 0 {
  24. family inet {
  25. filter {
  26. input VOICE;
  27. }
  28. address 1.2.3.4/24;
  29. }
  30. }
  31. }
  32. }

Drop Profiles

A drop profile defines the probability of packets being dropped when a queue reaches a certain size. Here is an example config:

  1. class-of-service {
  2. drop-profiles {
  3. low_drop {
  4. fill-level 95 drop-probability 0;
  5. fill-level 100 drop-probability 100;
  6. }
  7. med_drop {
  8. fill-level 75 drop-probability 0;
  9. fill-level 95 drop-probability 30;
  10. }
  11. high_drop {
  12. fill-level 50 drop-probability 0;
  13. fill-level 95 drop-probability 50;
  14. }
  15. }
  16. }

For each drop profile, you define a number of fill levels and drop probabilities. For example in the high_drop profile above, when the queue becomes 95% full, 50% of packets will be dropped.

Schedulers

Schedulers are the key component in the whole setup. They are associated with forwarding classes and define how traffic in the given class is treated with respect to other traffic. They define a few key things:

  • The minimum amount of bandwidth a class is to be given
  • The minimum amount of buffer that a class is to be given
  • The “priority” of that class, relative to other classes
  • The drop profiles associated with each loss priority

It is important to understand how JunOS will prioritize traffic based on these settings. This is documented here. The summary is:

A given queue is “in profile” if it has not exceeded its allocated minimum bandwidth. Traffic will be sent from the highest priority queue which is “in profile”.

Here is an example scheduler configuration:

  1. class-of-service {
  2. schedulers {
  3. ef {
  4. transmit-rate percent 15;
  5. buffer-size percent 15;
  6. priority high;
  7. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  8. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  9. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  10. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  11. }
  12. nc {
  13. transmit-rate percent 5;
  14. buffer-size percent 5;
  15. priority medium-high;
  16. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  17. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  18. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  19. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  20. }
  21. be {
  22. transmit-rate {
  23. remainder;
  24. }
  25. buffer-size {
  26. remainder;
  27. }
  28. priority low;
  29. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  30. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  31. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  32. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  33. }
  34. af {
  35. transmit-rate percent 50;
  36. buffer-size percent 50;
  37. priority medium-low;
  38. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  39. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  40. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  41. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  42. }
  43. }
  44. }

This defines a few different schedulers – one for each forwarding class. You will see below how schedulers are associated with forwarding classes. My classes are prioritized in the order ef, nc,. af, be. They are allocated a proportion of the interface’s bandwidth. It is important to note that this is the minimum bandwidth. For example, if there is only best-effort (be) traffic, it will get the full interface bandwidth.

It is important to tweak the percentages to reflect your own traffic. If, for example, you are a large call centre in which VOIP makes up 75% of your Internet traffic, then 15% for EF is probably a little low.

Scheduler Maps

Scheduler maps associate forwarding classes with schedulers. You then assign a scheduler map to an interface such that the schedulers are used for egress traffic on that interface. Below is a map that associates the 4 schedulers that I defined above with the 4 default forwarding classes on an SRX. This map is assigned to each egress interface where the scheduler(s) should be used.

  1. class-of-service {
  2. scheduler-maps {
  3. normal {
  4. forwarding-class expedited-forwarding scheduler ef;
  5. forwarding-class assured-forwarding scheduler af;
  6. forwarding-class best-effort scheduler be;
  7. forwarding-class network-control scheduler nc;
  8. }
  9. }
  10. interfaces {
  11. /* This is your egress interface */
  12. reth1 {
  13. scheduler-map normal;
  14. }
  15. }
  16. }

Complete Configuration

A complete configuration to correctly apply QoS to VOIP traffic, assuming phones will set AF31 for signalling (SIP) and EF for media (RTP):

  1. class-of-service {
  2. classifiers {
  3. dscp voip {
  4. import default;
  5. forwarding-class assured-forwarding {
  6. /* Default classfier is ok, except we also need AF31 */
  7. loss-priority low code-points 011010;
  8. }
  9. }
  10. }
  11. drop-profiles {
  12. low_drop {
  13. fill-level 95 drop-probability 0;
  14. fill-level 100 drop-probability 100;
  15. }
  16. med_drop {
  17. fill-level 75 drop-probability 0;
  18. fill-level 95 drop-probability 30;
  19. }
  20. high_drop {
  21. fill-level 50 drop-probability 0;
  22. fill-level 95 drop-probability 50;
  23. }
  24. }
  25. interfaces {
  26. /* This is the interface(s) through which VOIP phones access the Internet */
  27. reth1 {
  28. scheduler-map normal;
  29. }
  30. /* This is the interface(s) behind which VOIP phones reside */
  31. reth2 {
  32. /* This is the interface unit(s) through which VOIP phones access the Internet */
  33. unit 123 {
  34. classifiers {
  35. dscp voip;
  36. }
  37. }
  38. }
  39. }
  40. scheduler-maps {
  41. normal {
  42. forwarding-class expedited-forwarding scheduler ef;
  43. forwarding-class assured-forwarding scheduler af;
  44. forwarding-class best-effort scheduler be;
  45. forwarding-class network-control scheduler nc;
  46. }
  47. }
  48. schedulers {
  49. ef {
  50. transmit-rate percent 15;
  51. buffer-size percent 15;
  52. priority high;
  53. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  54. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  55. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  56. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  57. }
  58. nc {
  59. transmit-rate percent 5;
  60. buffer-size percent 5;
  61. priority medium-high;
  62. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  63. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  64. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  65. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  66. }
  67. be {
  68. transmit-rate {
  69. remainder;
  70. }
  71. buffer-size {
  72. remainder;
  73. }
  74. priority low;
  75. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  76. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  77. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  78. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  79. }
  80. af {
  81. transmit-rate percent 50;
  82. buffer-size percent 50;
  83. priority medium-low;
  84. drop-profile-map loss-priority high protocol any drop-profile high_drop;
  85. drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
  86. drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
  87. drop-profile-map loss-priority low protocol any drop-profile low_drop;
  88. }
  89. }
  90. }

Chassis clustering a Juniper SRX firewall via a switch

Intro

It is recommended that clustered SRX devices are directly connected. To do this, you need to run 2 cables, one for the control plane and the other for the fabric. This is sometimes not easy (or cheap) in a data centre environment where the firewalls are in different racks – especially given that the control link must be copper, on most SRX devices, and is thus limited to 100m.

You can also cluster SRX devices by connecting the links into a switch. A common use for this would be to cluster 2 firewalls, each in different racks, via your core switching chassis cluster.

tldr; (sorry, it’s still quite long)

You’ll need to read the chassis cluster guide. Here’s the one for the SRX 300, 320, 340, 345, 550 and 1150. On pages 44 and 45 you will see diagrams of how the devices must be connected. Most SRX devices enforce the use of a particular port for the control plane. When clustered, the control port will be renamed to something like fxp1. The fabric can usually be any port you like.

Connect the control and fabric ports of each SRX device into your switch.

The switch ports need to be configured like so:

  • MTU 8980
  • Access port (no VLAN tagging)
  • A unique VLAN – control and fabric need their own VLAN (e.g. control = 701, fabric = 702). The VLAN should have only 2 ports in it (e.g. firewall 1 control port and firewall 2 control port)
  • IGMP snooping turned off
  • CDP/LLDP/other junk turned off

You must first delete the configuration for the control interface, on each firewall, if it exists. If you don’t do this, you’ll be stuck in a strange state when the firewalls come back up as they will error when loading the configuration. If you can, you may as well delete all interfaces:

  1. edit
  2. delete interfaces
  3. commit

Log into each firewall via its console port. On firewall 1:

  1. set chassis cluster cluster-id 1 node 0 reboot

On firewall 2:

  1. set chassis cluster cluster-id 1 node 1 reboot

Wait for the firewalls to finish rebooting. Check the status of the cluster like so:

  1. show chassis cluster status

One node should be primary and the other secondary. Make sure you wait for all the “Monitor-failures” to clear before continuing.

Now you can work solely on the primary node… so you can log out of the secondary. You’ll need to assign the physical ports that you connected up for the fabric to the interfaces fab0 and fab1. Note that the ports on the secondary device will have been re-numbered. That is to say the on-board ports will no longer be ge-0/0/something, but will rather be something like ge-5/0/something. The number prefix depends on the model of SRX and, specifically, how many PIM slots it has. You’ll need to read the chassis clustering guide to work out what to do for your model.

  1. set interfaces fab0 fabric-options member-interfaces ge-0/0/2
  2. set interfaces fab1 fabric-options member-interfaces ge-5/0/2
  3. commit

Check the full cluster status:

  1. run show chassis cluster interfaces

You should see both control and fabric as Up.

Config for Juniper EX Series Switches

The below is the config for an EX series virtual chassis (VC). It’s simpler than if you had unclustered switches as you don’t need to worry about carrying VLANs between switches. If you don’t have a VC, you’ll need to do a little more on top of this.

  1. vlans {
  2. VLAN701 {
  3. description fw_control_link;
  4. vlan-id 701;
  5. }
  6. VLAN702 {
  7. description fw_fabric_link;
  8. vlan-id 702;
  9. }
  10. }
  11. protocols {
  12. igmp-snooping {
  13. vlan VLAN701 {
  14. disable;
  15. }
  16. vlan VLAN702 {
  17. disable;
  18. }
  19. }
  20. lldp {
  21. interface ge-0/0/17.0 {
  22. disable;
  23. }
  24. interface ge-4/0/17.0 {
  25. disable;
  26. }
  27. interface ge-0/0/18.0 {
  28. disable;
  29. }
  30. interface ge-4/0/18.0 {
  31. disable;
  32. }
  33. }
  34. }
  35. interfaces {
  36. ge-0/0/17 {
  37. description FW-01_Control_Link;
  38. mtu 8980;
  39. unit 0 {
  40. family ethernet-switching {
  41. port-mode access;
  42. vlan {
  43. members VLAN701;
  44. }
  45. }
  46. }
  47. }
  48. ge-0/0/18 {
  49. description FW-01_Fabric_Link;
  50. mtu 8980;
  51. unit 0 {
  52. family ethernet-switching {
  53. port-mode access;
  54. vlan {
  55. members VLAN702;
  56. }
  57. }
  58. }
  59. }
  60. ge-4/0/17 {
  61. description FW-02_Control_Link;
  62. mtu 8980;
  63. unit 0 {
  64. family ethernet-switching {
  65. port-mode access;
  66. vlan {
  67. members VLAN701;
  68. }
  69. }
  70. }
  71. }
  72. ge-4/0/18 {
  73. description FW-02_Fabric_Link;
  74. mtu 8980;
  75. unit 0 {
  76. family ethernet-switching {
  77. port-mode access;
  78. vlan {
  79. members VLAN702;
  80. }
  81. }
  82. }
  83. }
  84. }

Debugging

Check the status of nodes in the cluster:

  1. show chassis cluster status

Find out which interfaces are in the cluster:

  1. show chassis cluster interfaces

This will show you if data is being sent/received over the control and fabric links:

  1. show chassis cluster statistics

Check if the arp table has entries for the other firewall (i.e. they have layer 2 connectivity):

  1. show arp | match fxp

Configuring Node Specific Things

When you change the configuration on one node, it will be automatically applied on the other nodes. However, you will want some settings that are specific to a single node – for example hostname and management IP. You can set these settings into groups <nodename>, e.g. groups node0.

You’ll also need to set apply-groups “${node}” in order to have the node specific configuration apply to the right nodes.

Example config below for configuring hostname and management IP:

  1. groups {
  2. node0 {
  3. system {
  4. host-name fw-01;
  5. }
  6. interfaces {
  7. fxp0 {
  8. unit 0 {
  9. family inet {
  10. address 192.168.1.1/24;
  11. }
  12. }
  13. }
  14. }
  15. }
  16. node1 {
  17. system {
  18. host-name fw-02;
  19. }
  20. interfaces {
  21. fxp0 {
  22. unit 0 {
  23. family inet {
  24. address 192.168.1.2/24;
  25. }
  26. }
  27. }
  28. }
  29. }
  30. }
  31. apply-groups "${node}";