Juniper tincture: Prepare Juniper SRX. Part 1

juniper - juniper (eng.)

The other day, two Juniper SRX 550s got into my tenacious paws. They didn’t just happen to be, but to organize a reliable ipsec and NAT gateway, as well as an OSPF router. Well, since the most important thing for us is reliability, we’ll begin with it.

In order to ensure the fault tolerance of services, critical nodes usually duplicate. For data centers, this is practically a standard - N + N or at least N + 1. In this case, the devices can operate both independently from each other and in a cluster. For both types, there are pros and cons, but if you need not just routing / switching, but something more “intelligent” (for example, the same NAT or IPSec), then you just can't do without a cluster. So with a planned upgrade, it was routers that could work in a cluster as a replacement for the Cisco 7201. In this regard, ASR 1k went to the forest (as well as ISR), ASA was not considered (because I do not know how to cook it), and VSS from Cat6503 is too fat in terms of price and in terms of electricity consumed.

The hero of our story. (Here and below - pictures from the official site of Juniper)

So after searching (short-lived), the choice fell on the Juniper SRX 550, and the choice, in my opinion, turned out to be the right one.
Juniper SRX is a branch / head office (HQ) solution for VPN, Internet access and traffic filtering up to L7.
')
This is a very successful line, successfully competing with the Cisco ASA family. Although it is positioned as firewalls, in fact it is a complete solution for routing and filtering traffic, as well as organizing VPN. Scope - from small offices to data centers. Capabilities - from IPSec to VPLS (including Zone-based NAT, Firewall, IPS / IDS and anti-virus protection). Add to this the imputed licensing policy (hi, Cisco!), The abundance of supported interfaces (there are cards for xDSL, E1 / T1 transport, ethernet switching, as well as models with 3G / LTE support) and at the output we get almost perfect "borderline" solution for enterprise (both central office and branches). Practically - because there is not yet, alas, a full-fledged support for telephony, and even a heap of everything that exists, for example, in the same ISR. And the rest - just super.

Inside - a full-fledged JunOS with all the consequences. Accordingly, if there is experience in setting up other Juniper equipment, then there will be no problems at all.

First of all, of the two SRXs, we will collect one cluster that will provide us with a HA, employees - a stable relationship, and administrators - a good and healthy sleep. To do this, you need two links between the devices - data and control. Management, at the same time, everyone can have their own. SRX Junior Series support only Active-Standby clustering, in which one device handles traffic processing and the other synchronizes with it periodically, down to TCP and IPSec sessions, so that, if something happens to the first, immediately take on its responsibilities no downtime for the user. The scheme is quite common today, Juniper did not invent anything new. For older lines positioned in the data center, active-active work is possible.



1. Cooking links
The management will live on the ports ge-0/0/0 of each router. He will be fxp0.
Next, collect the fabric-link (data) and control-link (signaling). fabric is assembled at ports ge-0/0/2; control - on ge-0/0/1. In this case, the control will be denoted as fxp1. And yet, these device-specific interfaces, i.e. each device can be controlled separately (below I will show how to set up routing to control both nodes at once).
More information about the appointment of these links can be read directly on the site Juniper (English mova) .

The remaining ports can be used as you wish.

2. Putting the cluster
Putting the cluster into a trivial team:

set chassis cluster cluster-id <0-15> node <0-1> reboot 

Where 0-15 is the id of the stack (actually 1-15, 0 is the inactive stack). The stack number affects the generated virtual mac for the external reth interface, so if you have more than one srx pair on the network, the cluster id should differ between them.
0-1 is the node number. Accordingly, to build a cluster, we must execute this command at each node, and the cluster id should be the same, and the node id should differ.

After the reboot, the interfaces on the second node will be referred to as ge-9/0 / x to avoid confusion.

3. Customization



4. Failover
Redundancy Groups is a virtual interface that includes ports from both nodes. One of the interfaces is in the Active state, the second is in standby. As soon as the active node fails for any reason, or the link disappears on the active interface, the traffic switches to the backup node. At the same time, aggregated interfaces (ae) cannot be added to reth groups.

Now the most interesting - the so-called. reth interfaces This is not a portchannel in the classical sense, it is exactly a failover pair. Those. on the switch side, it will simply be two ports with the same settings.

As you might have noticed, with the help of priorities, you can configure the failover groups so that both devices will work approximately evenly. This, of course, is not a full-fledged active-active job, but, for example, you can “decompose” the load on both devices.

Apply changes:

 commit 

5. Light touches
We have set up a cluster, there are minor touches that later, I think, will definitely come in handy:


Cluster Diagnostics:

 show chassis cluster statistics show chassis cluster control-plane statistics show chassis cluster data-plane statistics show chassis cluster status redundancy-group 1 

On this cluster can be considered ready to work.

PS Configs, if possible, removed under spoilers, I think, so it is more correct. If you need to get - write in the comments.