Priorities can also be modified using interface monitoring, so if a particular interface goes offline we can decrement the priority of that node (also covered below). I would rather not set preempt on RG0 for a few reasons – which we’ll cover in the next section.
The higher priority wins here – so if you set node0 to a higher priority and preempt is enabled, then node0 will actively try to take ownership of RG1. # set chassis cluster redundancy-group 1 preempt # set chassis cluster redundancy-group 1 node 1 priority 50 # set chassis cluster redundancy-group 1 node 0 priority 200 # set chassis cluster redundancy-group 0 node 1 priority 50 In order to do that – you’ll have to configure each cluster member with a priority: # set chassis cluster redundancy-group 0 node 0 priority 200 You’re likely going to want to set up a priority for each RG – and maybe even preemptive fail-over. In most configurations, dumping all of your reth interfaces into RG1 will be sufficient. Then you would make RG1 primary on node0, and RG2 primary on node1. In order to achieve an active/active firewall configuration, you would need to create two separate virtual routers, each with their own reth interfaces and different RGs. This way the virtual routing instance and all of it’s associated interfaces will always run on the same SRX node.
For example, we might want be planning on only using one virtual routing instance on our SRX – so we would create RG1 and assign out interfaces to belong to it.Ī quick note – all interfaces in a single virtual router must belong to the same RG. A single RG can be configured as primary on one of the two active SRX firewalls is a cluster – with the ability to fail over to the other node.
In order to set the number of available reth interfaces, we’ll use the following command: # set chassis cluster reth-count 5Ī redundancy group, or RG, is used as a container for logically grouping redundant interfaces/virtual routers which must fail over together. For example, if you tell the SRX that you need 5 reth interfaces, then the SRX will allocate system resources to manage those interfaces. This is likely a memory thing, since each SRX also has a different maximum number of reth interfaces that can be configured. You’re also going to need to keep in mind that the SRX requires you to specify how many redundant ethernet interfaces will be configured. Next, we enter into the reth1 config, and associate it to a redundancy group. In the config above, we first take both of our interfaces (xe-0/0/16 on node0, and xe-7/0/16 on node1) and tell them that they now belong to a redundant interface group (reth1). # set interfaces reth1 redundant-ether-options redundancy-group 1 # set interfaces xe-7/0/16 gigether-options redundant-parent reth1 Here is how we would do that: # set interfaces xe-0/0/16 gigether-options redundant-parent reth1 Let’s say that we have a Juniper SRX 1500 cluster, and we want to create a redundant interface for one of our 10Gb ports. This will create a shared interface between your SRX pair, where you can configure IP address and VLAN information to be shared between the two. These interfaces are also often referred to as reth interfaces. So first thing is first – Once you have a cluster configured, you’ll probably want to configure a few sets of redundant ethernet interfaces. So now that we have a basic cluster setup – Let’s explore some of the additional options and configuration items.
Srx300 show mac address how to#
In last weeks post, we took a look at how to set up a chassis cluster on a Juniper SRX Firewall.
0 kommentar(er)
