Scenario:
Office network consists of two internet facing SRX firewalls (FW1 and FW2) and L3 main switch (CORE-SW1). Core switch can be from any vendor, in our case, its a cisco device. Firewalls are connected to two different ISPs, FW1 is connected to ISP1 and FW2 is connected to FW2. CORE-SW1 has L3 uplinks to each SRX and has a couple of different VLAN L3 interfaces where users live, it is a default gateway for LAN.
Both firewall have IPsecVPN links to the datacenter network, which consists of actually two datacenters connected via 10g DCI. Clients/Users of the remote office need to be able to connect to the internet and also to the datacenter. We need to be able to fail over to the secondary ISP should the primary fail. Active/Active scenario is preferred.
How to view Juniper SRX default applications
#show configuration groups junos-defaults applications
#
# File Transfer Protocol
#
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
#
# Trivial File Transfer Protocol
#
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
#
# Real Time Streaming Protocol
#
application junos-rtsp {
application-protocol rtsp;
protocol tcp;
destination-port 554;
}
#
# Network Basic Input Output System- networking protocol used on
# Windows networks session service port
Read moreJuniper SRX: selectively disable TCP SYN or Sequence checking
SRX are stateful firewalls and will only allow traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This of course means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.
Whenever possible its best to ensure that asymmetric flows can't occur, but this is not always possible. Therefor you can disable these checks globally on the SRX:
commit synchronize force
To enforce a commit synchronize on the Routing Engines, log in to the Routing Engine from which you want to synchronize and issue the commit synchronize command with the force option:
[edit]user@host# commit synchronize force
re0:re1:commit complete
re0:commit complete
[edit]user@host#
For the commit synchronization process, the master Routing Engine commits the configuration and sends a copy of the configuration to the backup Routing Engine. Then the backup Routing Engine loads and commits the configuration. So, the commit synchronization between the master and backup Routing Engines takes place one Routing Engine at a time. If the configuration has a large text size or many apply-groups, commit times can be longer than desired.
SRX cluster initial setup
SRX cluster initial setup:
1. Power on both SRX units. Console to the first one.
2. Enable cluster mode and reboot the devices:
On device A: >set chassis cluster cluster-id 1 node 0 reboot
On device B: >set chassis cluster cluster-id 1 node 1 reboot
3. Remove default configuration:
root> configure shared
delete interfaces
delete system services dhcp
delete security nat
delete protocols stp
set protocols rstp
delete security policies
delete security zones
delete vlans
4. Configure authentication and ssh access on each device:
root# set system root-authentication plain-text-password
root# set system services ssh root-login allow
5. Configure the device specific configurations such as host names and management IP addresses. This is specific to each device and is the only part of the configuration that is unique to its specific node. This is done by entering the following commands (all on the primary node):
on Node0:
root# set groups node0 system host-name nyc-broadway-451-0
root# set groups node0 interfaces fxp0 unit 0 family inet address 172.25.25.1/24
set apply-groups "${node0}"
on Node1:
root# set groups node1 system host-name nyc-broadway-451-1
root# set groups node1 interfaces fxp0 unit 0 family inet address 172.25.25.2/24
set apply-groups "${node1}"
The 'set apply-groups' command is run so that the individual configs for each node, set by the above commands, are applied only to that node. This command is required.
6. Configure the FAB links (data plane links for RTO sync, etc):
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab0 fabric-options member-interfaces ge-0/0/3
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/3
7. Configure the Redundancy Group 0 for the Routing Engine failover properties. Also configure Redundancy Group 1 (all the interfaces will be in one Redundancy Group in this example) to define the failover properties for the Reth interfaces.
set chassis cluster reth-count 3
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
-configure switch fabric
set interfaces swfab0 fabric-options member-interfaces ge-0/0/4
set interfaces swfab1 fabric-options member-interfaces ge-5/0/4
8. Configure interfaces
set interfaces ge-0/0/15 gigether-options redundant-parent reth0
set interfaces ge-5/0/15 gigether-options redundant-parent reth0
Minimum effort SRX Cluster upgrade procedure
This is a minimum effort upgrade procedure for an SRX Branch cluster.
It as assumed that the cluster is being managed through a reth interface, thus there is no direct access to node1 via fxp0, and that the cluster is running at least JunOS 10.1r1, thus the ability to login to the backup node from the master node exists.
For a minimum downtime upgrade procedure instead of a minimum effort one, see Juniper KB17947, or use the cable pulling method described in these forums by contributor rahula.
Read moreHow to upgrade a SRX cluster with minimal downtime
Problem or Goal:
At no time can a cluster have mismatched code versions. This can result in network instability and unpredictable behavior. This means that to properly upgrade a cluster without ISSU (not supported on SRX Branch devices), you would need to ensure that both nodes are rebooted and do not attempt to connect to each other with different Junos code versions.
Zero downtime is not currently possible on SRX clusters. The goal of this article is to provide a means to upgrade an SRX cluster with the minimum amount of downtime possible. The following events can be expected during this process:
- All sessions, which have network address translation, will be lost.
- All sessions utilizing ALG (Like FTP, SIP, and so on) will be lost.
- Dynamic routing protocol adjacencies will need to be re-established upon failover between the devices.
- All other existing sessions will be able to fail between devices.
- Depending on the network configuration, traffic will failover between devices with mimimal packet loss.
SRX240 cluster management interface
You've discovered one of the more aggravating "features" of the SRX products. The fxp0 interfaces become "out of band" management, and I use the quotes because Juniper has a very different opinion of what "out of band" means than many other manufacturers and customers. Personally I think it's an incredibly impractical way to do management, and I don't even use fxp0 interfaces on my clusters because I can't stand the way Juniper thinks they should work.
Read more