Chassis clustering a Juniper SRX firewall via a switch


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. }


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;
  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;
  25. }
  26. }
  27. }
  28. }
  29. }
  30. }
  31. apply-groups "${node}";

Changing the outgoing SMTP (sending) IP address in Postfix

This is far easier than I thought it’d be. I had to change it to get around some blacklisting my primary IP obtained after an unfortunate spamming incident from a compromised user.

Just add the following to your postfix’s and restart Postfix:

  1. smtp_bind_address=

Where is your new outgoing IP address.

How to detect Sonos devices on your network

How to detect Sonos devices on your network

A potential project requires me to detect Sonos devices on a network and find their IP addresses. Since Sonos only has 2 Mac Address OUIs an ARP scanner seemed the best way to do this. As such, I rightfully reinvented the wheel and wrote a slightly glorified ARP scanner with detection for Sonos OUIs. Sadly, PHP wasn’t quite suitable for this due to it’s lack of AF_PACKET sockets so it’s in C.

It’ll run on Linux and scan a network when given an interface name. Tweaks more than welcome as GitHub Pull Requests.

Code’s on my GitHub at

How to set up Internet connection (WAN) failover in Cisco IOS including e-mail notifications

As a revision to my earlier post on the matter, here’s a better constructed way to achieve the same effect with a little more accuracy.

Here’s a diagram of the approximate topology that this will cater to:

Network Diagram

Network Diagram

I shall assert the following facts:

  1. The “ISP’s Router” is IP address
  2. The DSL model is IP address
  3. The source interface that connects to the ISP router is FastEthernet0/0
  4. There is an SMTP server that this router has permission to send via at
  5. Your e-mail address is

First we use “track” to create 2 track entries to do route tracking. The first defines a “reachability” track which will be used to monitor for and perform actions on the failure of the primary route. This also delays the actions it performs on failure and restore by 20 and 60 seconds respectively to negate the effect of temporary blips. The second is a stub which allows us to take the secondary route up or down.

  1. track 1 rtr 123 reachability
  2. delay down 20 up 60
  3. track 2 stub-object
  4. default-state down

Next we add the routes. There’s 2 default gateways added, each associated with the track entries. There is also a route to ensure that all traffic to the “ISP’s Router” is sent out of the fa0/0 interface. This is for monitoring.

  1. ip route name FIBRE track 1
  2. ip route 254 name ADSL_BACKUP track 2
  3. ip route FastEthernet0/0

Now we use ip sla to provide the details for our reachability track regarding what it should test. In this case, it pings the “ISP’s Router” every 4 seconds:

  1. ip sla 123
  2. icmp-echo source-interface FastEthernet0/0
  3. timeout 2000
  4. frequency 4
  5. ip sla schedule 123 life forever start-time now

Finally we add some event handling to perform some actions on the failure and restore of the primary line. These bring up the second route and e-mail you a notification:

  1. event manager applet TRACK-1-TIMEOUT
  2. event track 1 state down
  3. action 1.0 track set 2 state up
  4. action 1.1 mail server "" to "" from "monitor@router.local" subject "IP SLA 123 Timeout" body "Timeout on the primary line"
  5. event manager applet TRACK-1-OK
  6. event track 1 state up
  7. action 1.0 track set 2 state down
  8. action 1.1 mail server "" to "" from "monitor@router.local" subject "IP SLA 123 Restored" body "Primary line restored"

That’s largely it. It contrasts with my earlier post in such that it ignores the effect of temporary blips in the line and also sends e-mail notifications.


How to disable ICMP redirects in pfSense

When a router’s next hop gateway is in the same subnet as the previous hop, it’ll send an ICMP redirect to the previous router in order to cut itself out of the routing. In some setups, this may not be desirable.

To disable this on pfSense, go to System->Advanced and change to the System Tunables tab. Edit net.inet.ip.redirect and/or net.inet6.ip6.redirect to change their values to 0 (zero).