Visualizzazione post con etichetta HA. Mostra tutti i post
Visualizzazione post con etichetta HA. Mostra tutti i post

giovedì 4 dicembre 2014

JUNIPER SRX240 HA FAILS

Buon salve all,
how are you? How does proceed your digital life?

Today I would like to speak, again, about Juniper SRX and HA. Today I would like to speak you about an issue I encounter in my digital working life. I receive two new Juniper SRX240 with the firmware 12.1X44 already on board.


My goal is to create the cluster of both SRX 240 and the starting point was following these Juniper instructions: SRX Getting Started - Configure Chassis Cluster (High Availability) on a SRX240 device

Probably it's my fault, probably not, it doesn't matter. The point was that, the first check suggest by Juniper:

In the SRX configuration, remove any existing configuration associated with the interfaces that will be transformed into fxp0 (out-of-band management) and fxp1 (control link) when the chassis cluster feature is enabled. 

it didn't work, and so I  was not able to start the cluster configuration. I tried a lot of things, beleve me, but nothing work. Finaly I found the following Juniper document that solve my issue: [SRX] How to recover or prevent a chassis cluster from going into a Hold/Lost state

I propose you, here, the main passage of the document. Very usefull and solving for my case.

The main purpose of the document is to explain how to remove the configuration on the interfaces that will be used as fxp0 (out-of-band management) and fxp1 (control) in a chassis cluster. Pay attention, this is a very

Important:  When configuring your chassis cluster, these two interfaces should NOT have any configuration.  This is a prerequisite.

Follow the instructions for an SRX running 'factory default config' or for an existing stand-alone SRX below:

For an SRX running 'factory default config':
The 'factory default config' by default contains configuration on the interfaces that are transformed into the fxp0 and fxp1 interfaces. Therefore, it needs to be deleted by you before enabling chassis cluster mode.

There are two conditions that a device is running a 'factory default config':
  • A new device
    • Generally it is seen in the production environment that the new devices are used for the chassis cluster. These new devices come with the factory-default configuration which have some or the other config on these interfaces.
  • Device crashes and comes back with factory default config.
    • Rarely, but if a device in chassis cluster mode crashes, it may come up with the factory default configuration.

To remove the configuration on the interfaces, it is typically easiest to delete the factory-default configuration and configure the device from scratch.

To delete the configuration:

Warning: The following procedure removes the current configuration.  

  • Get into the configuration mode.
  • Execute the # delete command. (This command deletes the current configuration from the device.) 
root# delete
This will delete the entire configuration
Delete everything under this level? [yes,no] (no) yes 
3

  • Configure the root password and commit:
root# set system root-authentication plain-text-password
root# commit


OR
For an existing stand-alone SRX:
If your SRX is currently running in a production environment, then check to see if there is configuration on the interfaces that will be transformed into fxp0 and fxp1. To determine which interfaces will be transformed into fxp0 and fxp1, refer to KB15356 - How are interfaces assigned on J-Series and SRX platforms when the chassis cluster is enabled and Node Interfaces on Active SRX Series Chassis Clusters.

Then to find the configuration for those interfaces, run these commands in configuration mode and delete all the configuration from every configuration hierarchy in which those interfaces are being used:

show | display set | match <control port physical interface>
show | display set | match <fxp0l port physical interface>


If you wish to remove the entire config and reconfigure the device for chassis cluster, follow the procedure to delete the entire configuration, as shown in the 'factory default config' instructions.


in my case I run the first one of the two solution. When done I start again following the instructions about clustering SRX240 appliances and all was good.

And for today it's all.

I hope this post can help you and your troubleshooting! 
Have a nice day!
DiGiTsHaMaN 


venerdì 4 luglio 2014

JUNIPER SRX 1400 LAYER 2 HA

Buon salve all,
how are you? How does proceed your digital life?
Today I return to speak about the Juniper SRX 1400 and, in particular, about another issue we have in our environment: the configuration of HA via layer 2 Cisco Switches.

First of all I spend two simple words about Juniper SRX and HA.
In a cluster there needs to be a lot of communication between the two cluster nodes. This communication is mainly required to synchronize states and send keepalives to detect that the other node is still present. 

This communication is going over two different links: a ‘control’ link and a ‘fabric’ link.
  • The control link is used to send control traffic between both the Routing Engines (REs) and between the Primary RE (RG0 primary) and the remote Packet Forwarding Engine (PFE).
  • The fabric link connects both PFE’s together. This link is utilized for two main functions.
The first function is to synchronize the session states between the two nodes. This is done via RTO (real-time objects) packets going over the fabric link. There are many types of RTO messages, but some of the most important ones are the ‘session create’ and ‘session delete’ messages.
The second function of the fabric link is to pass traffic that needs to cross both nodes. This can only occur in A/A scenarios where traffic might enter an interface on one cluster node and needs to exit out of an interface on the other cluster node. Such traffic is also called Z-mode traffic.


The issue we experimented was very simple: we configure our to SRX 1400 for HA, and we do this into the LAB, connecting the two firewall directly throught two cables, one for the control link and one for the fabric link. In this configuration all was ok. When we migrate to the field, installing one firewall into one techincal room and the other one into another, connecting the controll link and fabric link to the Cisco switch 3850, there was no way to bring up the HA.

MTU Considerations from Juniper Documentation
Inter-cluster messages cannot be fragmented, requiring the transport network to have the ability accommodate them. The minimum MTU required for all platforms is 9014, with the exception of the SRX100s that require an MTU of 1632.
Due to the extra fabric headers added to the packets before they are sent through the fabric link, the MTU of the interfaces used in Z-mode deployments should not exceed1500 bytes on SRX100 platforms and 8900 bytes on any other platform.
Note: If you are connecting each of the fabric links through a switch, you must enable the jumbo frame feature on the corresponding switch ports. If both of the fabric links are connected through the same switch, the RTO-and-probes pair must be in one virtual LAN (VLAN) and the data pair must be in another VLAN. Here too, the jumbo frame feature must be enabled on the corresponding switch ports.

And also from a technical forum somewhere in the great sea of the internet:
FYI, it is supported on the High-end SRX. Look for an application note named "SRX series services gateways cluster deployment across layer 2 networks" (google will find it - its somewhere on the juniper website).

We did such a setup with 3400s a while back and it takes quite a bit of work to get this up and running:
  • if your switches perform IGMP snooping, try disabling it
  • if the switches are cisco, you need to disable the ip-header verification. They will verify the IP header even for switched traffic, and the packets sent by the SRXs aren't valid IP so they will get dropped without any logging
The solution we found to bring up the HA links was to enable the MTU Jumbo Fraime on the Cisco switches. We found also that on Cisco 3850 to enable the MTU Jumbo Fraime you need to enable it on all the switch and you have to reboot the firewall. On the contrary, on Cisco 6500 you can enable the MTU Jumbo Frame by single port. So we migrate the HA Links on Cisco 6500 and everything wa ok. Below you can find the configuration of the single port:


Configuration of the two ports on the first Cisco 6500

interface GigabitEthernet1/5/2
description Fw Juniper Prim Srx1400 Datalink Ge0/0/0 Fab0
switchport
switchport access vlan X
switchport mode access
mtu 9216
no logging event link-status
no snmp trap link-status
storm-control broadcast level 10.00
no cdp enable
spanning-tree portfast edge
spanning-tree bpduguard enable
end

interface GigabitEthernet1/5/3
description Fw Juniper Prim Srx1400 Control_link Ge0/0/10 Link0
switchport
switchport access vlan Y
switchport mode access
mtu 9216
no logging event link-status
no snmp trap link-status
storm-control broadcast level 10.00
no cdp enable
spanning-tree portfast edge
spanning-tree bpduguard enable
end


Configuration of the two ports on the second Cisco 6500

interface GigabitEthernet2/5/2
description Fw Juniper Sec Srx1400 Datalink Ge4/0/0 Fab1
switchport
switchport access vlan X
switchport mode access
mtu 9216
no logging event link-status
no snmp trap link-status
storm-control broadcast level 10.00
no cdp enable
spanning-tree portfast edge
spanning-tree bpduguard enable
end

interface GigabitEthernet2/5/3
description Fw Juniper Sec Srx1400 Control_link Ge4/0/10 Link1
switchport
switchport access vlan Y
switchport mode access
mtu 9216
no logging event link-status
no snmp trap link-status
storm-control broadcast level 10.00
no cdp enable
spanning-tree portfast edge
spanning-tree bpduguard enable
end


On the Juniper SRX 1400 firewall no change into the configuration file is required.

 I hope this post can help you and your troubleshooting!

Have a nice day!
DiGiTsHaMaN