What is Redundant Trunk Group (RTG) ?

--> Redundant Trunk Group (RTG) is a feature used on the Juniper EX Series switches as a replacement for STP.

--> Redundant Trunk Group (RTG) provides a loop-free Layer 2 topology without requiring Spanning Tree to be running on the access-layer switches.

--> Redundant Trunk Group (RTG) works by making one interface as active and the other interface as standby.

--> Redundant Trunk Group (RTG) enabled interfaces do not send/forward BPDUs and discard BPDUs if received on RTG-enabled interfaces.

--> A maximum of only two links can be configured in an RTG group and Up to 16 RTG groups are supported for the EX Series switches.

--> One Interface Will be acting as an active interface and forwarding data traffic while the other interface remains in standby mode.

--> By default, the highest numbered interface in an RTG group is the active interface to forward the traffic.

--> We can manually make one interface as primary interface in RTG group by using the command.

--> If primary interface goes down then secondary interface starts forwarding the data traffic in RTG Group.

--> In order RTG to work, STP need to be disabled on RTG enabled interfaces.

--> Juniper recommends keeping STP enabled for other ports that are not enabled for RTG to prevent Layer 2 loop.

Configuration:

Kareem@switch# set ethernet-switching-options redundant-trunk-group RTG_Group1 interface ge-0/1/0.0
Kareem@switch# set ethernet-switching-options redundant-trunk-group RTG_Group1 interface ge-0/1/1.0

Ref: Juniper

Md.Kareemoddin

How to prevent DOS/DDOS attacks on Juniper SA/Pulse Connect?

--> In order to prevent from Denial of Service (DoS), Distributed Denial of Service (DDoS) from the same IP address, You can configure Lockout options to protect the Secure Access (SA).

--> Juniper SA blocks the IP address of the user who is trying to perform Denial of Service (DoS), Distributed Denial of Service (DDoS) or Password Guessing Attacks.

--> Juniper SA does not block the User Account, it simply blocks the IP Address of the User.

--> If you try to login with another username via the same IP address (or computer) during the lockout period, it will also not be able to authenticate; until the lockout is over.

--> The terms that are used in the Lockout Options Settings are as follows:

Rate: Specify the number of failed sign-in attempts to allow per minute.

Attempts: Specify the maximum number of failed sign-in attempts to be allowed, before triggering the initial lockout.

Lockout period: Specify the number of minutes that you want the SA to lock out the IP address.

Ex:

Rate: 3 (attempts per minute)

Attempts: 180 

Duration: 2 (duration of lockout in minutes)

--> The SA determines the maximum initial period of time (in minutes) to allow the failed sign-in attempts to occur by dividing the specified number of attempts by the rate.

--> For example, 180 attempts divided by a rate of 3 results for an initial period of 60 minutes.

--> If 180 or more failed sign-in attempts occur within 60 minutes or less, the SA locks out the IP address being used for the failed sign-in attempt.

--> After the 2 minute lockout period has expired, the IP address is unlocked and users are again allowed to login from that IP address.

--> For the next 60 minutes, the determining factor for the next lockout is only the rate (3 attempts/minute) that is configured above.

Anonymous server in Juniper SA

--> The anonymous server feature allows users to access the SA Series SSL VPN Appliance without providing a username or password.

--> Instead, when a user enters the URL of a sign-in page that is configured to authenticate against an anonymous server, the SA Series SSL VPN Appliance bypasses the standard sign-in page, and immediately displays the welcome page to the user.

--> You may choose to use anonymous authentication if you think that the resources on the SA Series SSL VPN Appliance do not require extreme security, or if you think that other security measures provided through the SA Series SSL VPN Appliance are sufficient.

--> For example, you may create a user role with limited access to internal resources, and then authenticate that role with a policy that only requires users to sign in with an IP address that resides within your internal network.

--> When defining and monitoring an anonymous server instance, note that you can only add one anonymous server configuration. It is not possible to authenticate administrators against the anonymous server.