Chapter 6. Transparent Mode
There are two common challenges to deploying traditional Layer 3 network firewalls into a network. The first challenge is that you typically must change the IP routing to support the new firewall into the network, which can be a particularly difficult task, especially when dealing with readdressing segments. The other challenge with traditional firewalls is that they are very weak routers, at least in terms of dynamic routing protocol support, not to mention the fact that the security teams, which managed the firewalls, are typically separate from the teams that managed the routing infrastructure.
Because the SRX runs Junos, you’re already equipped with the best routing platform there is, so routing support isn’t an issue for the SRX, even though it is for many competitive firewalls and the previous generation of ScreenOS devices.
Transparent mode essentially allows the SRX to act as a Layer 2 bridge with the added security functionality of being a stateful firewall, as well as providing additional services such as IPS and AppSecure.
Transparent Mode Overview
Fundamentally, transparent mode is very similar to Layer 3 routed mode on the SRX platform. Although there are some limitations that are discussed later in this chapter that you should be aware of when balancing the decision to deploy transparent mode, this is a feature that certainly has its place in contemporary networking. First this chapter reviews the reasons for deployment, how the technology functions, and the different components and concepts to be aware of when deploying transparent mode. After this review, actual configuration examples are shown through a case study.
When to Use Transparent Mode
You should consider using transparent mode because certain networking scenarios are not ideal for a Layer 3 implementation of a firewall. The good news is that transparent mode can be a viable alternative for administrators who want to avoid deployment dilemmas that Layer 3 implementations can cause. In this section, we review common scenarios where transparent mode can provide significant value.
Segmenting a Layer 2 domain
Sometimes day-to-day operations require that a firewall be placed where it did not exist before, a common example being for compliance with security standards such as PCI, HIPAA, SOX, and other international security standards. For instance, these standards might require that firewalling is present between a web server farm and a database server farm existing in a DMZ. Although integrating a Layer 3 firewall might be an option, it would require you to make IP address changes on at least one set of the devices. This can be easier than it sounds, especially if you have lots of hooks accessing the applications by IP address and if the applications cannot easily change their IP address. In this situation, you can simply implement a transparent mode firewall between the web and server farms, without having to change any IP addresses or make any changes on the application side. At the same time, you can now enforce security between these different segments.
Figure 6-1 shows a before and after view of how a transparent mode SRX can be inserted into a network to provide security.
As you can see, if the firewall is in Layer 3 mode, it can’t separate hosts on the same Layer 2 domain because of where it is logically placed. If you wanted to insert a Layer 3 firewall, you could, but you would need to re-IP-address your network to accommodate the changes. Transparent mode firewalls, on the other hand, do not segment your network from a Layer 3 perspective, and therefore they can sit between hosts on the same Layer 2 network to protect them from other hosts on the same Layer 2 network, along with enforcing security against remote attacks.
Complex routing environments
Traditional firewalls typically did not make good routers, both from a routing capacity perspective and from a feature perspective. Now that Juniper offers a firewall that is on Junos, there is a very complete routing infrastructure on the firewall itself, so this might not be as big a concern as it is with other products. Nevertheless, some environments might feel more comfortable with firewalls only performing security functions, and leaving routing up to other devices. In these environments, firewalls can sit between routers transparently and simply inspect the traffic and forward it like a Layer 2 switch.
Separation of duties
In some environments, separate teams manage the routing, switching, firewalling, and IPS services, or some combination of these roles. In these environments, having routing on the firewalls might mean separate teams have to be involved, which might not be ideal. Although there is no technical reason for using transparent mode in this scenario, other factors such as logistical and political issues can make transparent mode more ideal.
Existing transparent mode infrastructure
Sometimes an existing transparent mode firewall infrastructure is in place that must be upgraded. In these scenarios, swapping out the existing transparent mode firewalls with new transparent mode firewalls is the easiest transition, as switching from Layer 2 to Layer 3 would result in changes that need to occur with the Layer 3 infrastructure.
MAC Address Learning
An SRX in transparent mode acts like a switch with regard to how it forwards traffic. As you know, a true Layer 2 switch does not forward based on IP addresses, but rather based on the destination MAC addresses of the frames it receives. To forward to a destination, the SRX must learn where the MAC addresses “live” on the network. To do this, the SRX learns on which ports MAC addresses are located based on the source MAC address that is learned on that particular port. These entries are cached into a bridging table on the SRX and are used for packet forwarding, including policy lookup, as we discuss in the section Transparent Mode Flow Process later in this chapter. If the SRX does not know on which port in the VLAN the destination MAC address can be reached, it performs one of two actions depending on the configuration:
- Flood the frame
By default, the SRX simply floods the packet out all interfaces in the same VLAN except the port on which the packet arrived. This is how a switch normally functions when it doesn’t know the destination MAC address.
- ARP with traceroute
In some cases, customers might not wish to flood any packets out for security reasons, so Junos offers you an alternative to flooding the traffic, which is to send an Address Resolution Protocol (ARP) and optionally an ICMP packet with a TTL of 1, while queuing the packet. If no destination responds, the original packet is dropped.
Transparent Mode and Bridge Loops, Spanning Tree Protocol
One thing you must be aware of when working with transparent mode firewalls is that if you do not properly configure a transparent mode firewall, you might trigger a bridge loop. If you are connecting the SRX directly to routed interfaces on peer devices, this should not be an issue, but if you are connecting the SRX to switch interfaces, you need to give some thought to your design. Because at the time of this writing the SRX does not actively participate in Spanning Tree Protocol (STP) itself, it does forward the BPDUs and the STP messages. Additionally, you might need to tweak your spanning tree configuration to properly forward traffic to the active SRX node. If you do not do this, traffic might not pass through the SRX, or failovers between nodes might not function properly. These different configurations are examined throughout this chapter.
Transparent Mode Limitations
There are some limitations when it comes to transparent mode on the SRX, particularly in contrast to ScreenOS. You should be aware of the following limitations before configuring transparent mode:
- Virtual private network support
At the time of this writing, VPN termination on Integrated Routing and Bridging (IRB) interfaces is not supported in transparent mode. This termination is supported on VLAN interfaces in ScreenOS, but it is not yet supported on the SRX in transparent mode. This feature will likely be supported in the future.
- Mixed mode Layer 2/Layer 3 support
At the time of this writing, you can only configure Layer 2 or Layer 3, but not both simultaneously. This was never supported on ScreenOS, however, and is likely to be supported in the near future on SRX.
- Network Address Translation
At the time of this writing, NAT is not supported in transparent mode. Policy NAT is supported in ScreenOS starting with version 6.1, but this is not yet supported in the SRX for transparent mode.
- Virtual router support
At the time of this writing, you cannot place IRB interfaces into different virtual routers; they must remain in the master
inet.0routing table.- Q-in-Q tunneling
Q-in-Q tunneling is not supported on the high-end SRX (either in Layer 3 or in Layer 2) at the time of this writing.
- Changing modes
To change from Layer 3 to Layer 2 mode (or vice versa) you must reboot the chassis.
- Limitations per release
Because there are many variations of platforms and releases, it would be too extensive to compile into a book. The best option is to refer to the pathfinder tool, which documents up-to-date releases with what features are supported. This requires a customer portal login. In pathfinder, you will want to use the feature explorer to review feature limitations for transparent mode as well as any other feature support that is listed here.
Transparent Mode Components
There are several components of transparent mode, some common to Layer 3 and some specific to transparent mode itself. This section examines the different components of transparent mode; configuration examples follow later in the chapter. These components are also the building blocks of the case study at the end of the chapter.
Interfaces, family bridge, and bridge domains in transparent mode
Transparent mode ushers in a few new concepts concerning interfaces and forwarding. Transparent mode follows the same interface model as standard Layer 3 interfaces, with the use of physical interface properties, followed by logical interface configuration. The main differences that exist are as follows:
- Family bridge
Rather than using family Inet, Inet6, ISO, and so on, because there is no explicit IP address configuration, we will use the family bridge, which is the same as what the MX Series uses for its platform.
- Interface addressing
In transparent mode, there is no IP address assigned to a logical interface. The SRX functions as a switch and not as a router. Traffic is switched toward the SRX by listening for MAC addresses and determining that they live on the other side of the SRX. The interfaces do have MAC addresses, but the source and destination MAC addresses of transit traffic will never be of the SRX’s interfaces themselves. A concept of IRB interfaces allows you to send management traffic to the SRX, but other than that, the traffic will not be addressed to the SRX itself.
- Bridge domains
These are the Layer 2 equivalent of virtual routers in Layer 3 mode. Essentially, bridge domains allow you to separate the Layer 2 traffic, including spanning tree domains, and other forwarding options. We will cover bridge domains and how they influence transparent mode in the section Configuring Integrated Routing and Bridging later in this chapter.
Interface Modes in Transparent Mode
In transparent mode, there are two different modes in which you can place an interface: access mode and trunk mode. If you have any experience with the EX Series or MX Series platforms, the SRX follows the same convention here, although, unlike the EX Series platform (and like the MX Series platform), the SRX uses the family bridge convention.
- Access mode
Access mode is the default mode for family bridge interfaces. In access mode, the interface only has a single unit that uses a single VLAN member, which can be configured for the interface. Traffic arriving on the interface is classified with the VLAN, which is configured. The term access mode comes from the fact that most end systems that access the network on these types of interfaces are configured on a switch. For the SRX, however, access mode simply means there is only a single VLAN configured on the interface.
- Trunk mode
The SRX supports the ability to terminate multiple VLANs on a single interface through the use of 802.1q trunking. To accommodate this, you will need to configure an interface in trunk mode, which uses VLAN tagging to differentiate VLANs for the purposes of separation and classification of traffic. You can use a native VLAN, which is untagged, or you can use an interface with all tagged VLANs. When using trunk mode, you can configure multiple units (logical interfaces), each having one or more VLAN members present on it.
Note
You cannot mix both access mode units and trunk mode units on a single interface, and, if you are using access mode, you can only have a single unit present. Just like Layer 3 mode, you can put different logical interface units into different zones, and you can put different VLANs into different bridge domains (similar to how you can put different logical interface units into different virtual routers in Layer 3 mode).
Bridge Domains
As mentioned earlier in this chapter, bridge domains are used to logically separate traffic on the SRX. In reality, they are very similar to VLANs in terms of how the traffic is processed in the system; however, the bridge domain allows Junos to abstract the VLANs and their associated tags from the actual traffic processing. Typically, most implementations require that you configure a separate bridge domain for each VLAN, although this isn’t a strict requirement; you can bridge multiple VLANs together if you wish.
Within a bridge domain, you can configure either a single or multiple VLANs to be part of the same bridge domain; however, you can only configure an IRB interface in a bridge domain if you are using a single VLAN for the bridge domain.
IRB Interfaces
As mentioned, the standard logical interfaces on the SRX do not support IP addresses when the SRX is configured in transparent mode; however, the SRX does support a special type of interface called an IRB interface. You can think of an IRB interface as a VLAN interface from Junos’ switching capabilities. IRB interfaces are virtual interfaces that allow you to configure IP addressing on the interface so that even in transparent mode you can communicate with the SRX on data plane interfaces. Of course, even in transparent mode you can manage the device through the fxp0 interface, which does have full management capabilities. The purpose of IRB interfaces is to allow you to manage a transparent mode device on the data plane by making an addressable interface. The IRB interface cannot route traffic itself; rather, you can use it to accept inbound management connections, including pings, SSH, Telnet, and HTTP, and you can make outbound connections on the IRB interface to other devices.
Note
In transparent mode, you cannot put IRB interfaces into different virtual routing instances, because different virtual routers are not supported.
Transparent Mode Zones
For those of you who have a rich experience working with
ScreenOS, there is a slight difference with the way security zones are
defined in Junos. Unlike ScreenOS, where you were required to prepend a
Layer 2 security zone name with L2-<name>, in Junos there is no
requirement for any special naming convention. Security zones are
associated with Layer 2 by the interfaces that are in them, and
therefore the system is smart enough to know it is a Layer 2 zone
without any special naming requirements. So, in reality, there are no
differences between Layer 2 and Layer 3 security zones from a
configuration perspective. Just like Layer 3 security zones, you place
the logical interfaces (e.g., ge-0/0/4.20) into the security zones, so
the SRX can support not only access mode interfaces but also 802.1q
VLANs that are bound to a specific unit on a trunk link. One exception
is that IRB interfaces themselves are not placed within security zones,
but the surrounding Layer 2 interfaces are, so you can still filter out
traffic for them. We cover this in more detail in the configuration
examples later in this chapter.
Transparent Mode Security Policy
Security policies in transparent mode are almost identical to those in Layer 3, with the only exception being that VPN is not supported in transparent mode, so therefore policy-based VPNs would not be supported within the security policies.
For those of you who do not have experience with ScreenOS, the Layer 2 security policies in Junos are pretty straightforward. In transparent mode, the security policy is no different from a Layer 3 policy. The transparent mode policy is still composed of filtering based on from-to-zones, source addresses, destination addresses, and applications (source port, destination port, and protocol). However, one thing to keep in mind is that, unlike ScreenOS, intrazone blocking is always enforced (for both Layer 2 and Layer 3 modes), so you always need a security policy, even for traffic coming from and going to the same zone (e.g., from Trust to Trust). Also note that in transparent mode, you cannot filter on Layer 2 components (again, we cover this later in this chapter).
Transparent Mode Specific Options
Transparent mode supports the following flow configurations that are not supported in Layer 3:
- Block all non-IP packets
If the SRX sees non-IP packets (or packets that are not involved with IP, such as ARP, Internet Group Management Protocol [IGMP], or DHCP, for example), the SRX will silently drop them. This includes broadcast and multicast traffic.
- Bypass all non-IP unicast traffic
This option permits non-IP unicast traffic to be sent through the box. Note that this does not include IPv6, which is dropped if you attempt to forward it through the SRX. If you do need to forward IPv6 through the SRX, the recommendation is to use GRE tunneling on the routers.
- No packet flooding
By default, the SRX floods all packets with an unknown destination MAC address out all interfaces in the same VLAN on which the packet arrived, except the source interface. This is the standard behavior for bridging and switching devices when they do not know on which port the destination MAC address can be reached. Some administrators would like to avoid this behavior if the destination MAC address is not known and have the SRX ARP for the destination MAC address. There are two options for this: ARP and send an ICMP traceroute, or just simply ARP.
QoS in Transparent Mode
The SRX supports the ability to perform Quality of Service (QoS) in transparent mode. Transparent mode QoS allows you to perform classification and rewriting based on 802.1p values, along with being able to do standard shaping and priority processing based on these QoS values. Note that transparent mode does not support classification or rewriting based on IP precedence or Differentiated Services Code Point (DSCP) values, only on the Layer 2 802.1p values. So if you need to classify based on IP precedence or DSCP, you should do it upstream or downstream and copy the equivalent values into the 802.1p field so that the SRX can apply the appropriate QoS in transparent mode. The section Configuring Transparent Mode QoS later in this chapter takes a deep look at this functionality.
VLAN Rewriting
Many network engineers consider VLAN rewriting (also known as VLAN retagging) as the NAT of Layer 2 VLAN tags when in Layer 2 mode. In some networks, VLAN rewriting is used to ensure that “clean” traffic that might be on the same VLAN has passed through a firewall; to do this, we can use different VLAN tags on different sides of the firewall. In other cases, there might be a handoff between different network boundaries (e.g., between a customer and an ISP), so to keep things simple on the customer end, VLAN rewriting can be used to ensure that there is no VLAN overlap. In Layer 3 mode, networks can be segmented simply by routing the traffic between VLANs (including performing other services such as firewalling and IPS); however, in Layer 2 mode, a device does not perform any of the routing transforms to route traffic between Layer 3 networks. When you want to transform the VLAN on one side of the firewall in transparent mode, you would want to use VLAN rewriting. Essentially, VLAN rewriting simply defines how the VLANs are translated by mapping VLANs on a one-to-one ratio. For instance, in Figure 6-2, we are mapping VLAN 20 to VLAN 80. We cover this concept later in the configuration example section.
Note
Only tagged traffic on VLANs can be translated. This means the traffic on the native VLAN cannot be translated because there is no tag. You would need to make sure the surrounding networking devices tagged this native VLAN on their end, for you to translate the VLAN on the SRX.
High Availability with Transparent Mode
The SRX supports the ability to operate an SRX chassis cluster in transparent mode. Chassis clustering in transparent mode operates very similarly to Layer 3 mode, but with the same differences as standalone Layer 3 compared to standalone Layer 2.
When operating in transparent mode HA clusters, you need to be especially aware of bridge loops and how transparent mode triggers traffic failovers. In Layer 3 mode, the SRX will send Gratuitous ARPs (GARPs) out the new active reth interface member after a failover to signal to the surrounding switches that the SRX’s MAC address has moved to a new interface (that of the new active reth member). In transparent mode, there is no active MAC address or IP address on which to terminate the traffic, so no GARPs can be sent. Instead, the SRX flaps the old active interfaces up and down to trigger an STP recalculation. If STP is not properly configured on the surrounding switches (if applicable), it can lead to traffic not failing over or other disruptions. Note that in active/passive mode, only one SRX in the cluster has its data plane active at a time (just like in active/passive Layer 3 mode). In Layer 2 active/active mode, an individual redundancy group is only active on a single SRX data plane at a time, but both SRX data planes can have different redundancy groups active on them, just like Layer 3 active/active. Of course, you can’t have an individual redundancy group active on both cluster members at the same time, as this would cause a bridge loop. The case study later in this chapter includes an example of using transparent mode in HA. In addition, the next section details where to use STP and what version of STP you should be using, and Chapter 7 discusses chassis clustering in great detail.
Spanning Tree Protocol in transparent mode Layer 2 deployments
When Layer 3 devices surround the SRX cluster in transparent mode, there really isn’t much of a concern for spanning tree. However, in many cases, Layer 2 switching will be deployed surrounding the SRX transparent mode cluster. In these cases, although the SRX will not forward traffic that it receives on an interface that is not active for its redundancy group, it will forward the BPDUs, and therefore the switches will view this as a network loop. Disabling STP is generally a bad idea in a production network because if someone makes a mistake, it can trigger a bridge loop because STP is disabled. At the same time, using standard STP can be less than ideal because of failover timings (up to 50 seconds after a topology change).
Note
It doesn’t really matter if you are using active/passive or active/active. The concerns are going to be the same.
Here are some guidelines for what you should use for the transparent mode switching architecture:
- Transparent mode without VLAN trunking
If you are not using VLAN trunking on your transparent mode reth interfaces, you can simply use RSTP, which will provide much better failover times and reliability than standard STP.
- Multiple Spanning Tree Protocol (MSTP)
MSTP is actually preferable to RSTP, although in the case of no VLAN trunking, it shouldn’t make much of a difference.
- Transparent mode with VLAN trunking
If VLAN trunking is used, it is possible that a bridge loop might occur within an individual VLAN, but not on the entire trunk itself. RSTP does not provide any way to prevent bridge loops within VLANs on a trunk unless the entire link has a loop on the native VLAN. Instead, you can use MSTP, which enables you to provide separate instances of STP. This gives you the same benefits of RSTP in terms of redundancy, but with the ability to separate STP domains similar to PVST+.
Note
You can use Cisco proprietary protocols such as PVST+ and RPVST, but there really isn’t much of a point with the standardized implementations of STP that exist.
Transparent Mode Flow Process
The transparent mode flow process is very similar to that of the routed Layer 3 mode flow processing. Essentially, the differences between Layer 2 and Layer 3 are in the forwarding process, and at the same time, there are some features that are not supported in transparent mode. There is no difference in the packet flow in terms of the flow between the Network Processing Unit, control point, and Services Processing Unit (SPU) on the high-end SRXs; all of this occurs in the same fashion. However, the actual process within the SPU varies slightly. The branch devices do not use NPUs, CPs, or SPUs, so the portions that do not apply to the branch SRXs will be noted.
Figure 6-3 shows the transparent mode packet flow.
Slow-path SPU packet processing
Slow-path packet processing consists of the following steps:
The initial packet is forwarded from the NPU to the CP and then from the CP to the SPU, which the CP selects to process the flow (data center SRX only).
The policing, stateless filtering, and screens can be performed on the SPU (although this can also occur elsewhere). Most of the screens are performed on the NPU, but a few screens are performed on the SPU. These screens are typically related to processing session limits (in conjunction with the CP, which knows about the session numbers of all source and destination IP addresses being processed on the box; data center SRX only). On the branch devices, these functions are all performed within the single data plane processor.
The SPU will determine if it knows about the session or not. If the session is known, it will fast-path the session, but in the case of a new session, additional processing must be performed (data center SRX only).
Transparent mode differs from Layer 3 routed mode because not only is there no IP address on its interfaces, but also it does not perform forwarding based on a routing lookup, but rather based on a bridging lookup, as both network segments are within the same Layer 3 domain. Two scenarios occur during packet processing:
If the destination MAC address is known, it is “learned,” similar to how a bridge or switch would normally function by simply listening for packets and examining the source MAC address. When a new source MAC address is learned, it is added to the bridging table. If the destination MAC address for the packet that the SRX is forwarding is known, it determines the egress interface (and therefore the egress zone) based on the bridging lookup.
If the destination MAC address is unknown, the SRX must try to determine what port the destination MAC address lives on (even if only two interfaces are present). By default, the SRX simply floods the packet out all interfaces in the same VLAN, except for the port on which the packet arrived. This is how a switch normally functions when it doesn’t know the destination MAC address. In some cases, customers might not wish to flood any packets out for security reasons. For this reason, Junos offers you an alternative to flooding the traffic, which is to send an ARP, and optionally a traceroute, while queuing the packet. If no destination responds, the original packet is dropped. You can configure how the platform responds to unknown destination MAC addresses in the flow configuration, configured later in this chapter.
Step 4 determined what destination interface to forward the traffic out of, and therefore the destination zone is known. The source zone is known as soon as the packet arrives, because the system knows what interface it arrived on, and therefore what the source zone is. With the knowledge of the source and destination zones in hand, the SRX can then do a policy lookup in the from-to- zone context. The SRX performs a policy lookup in the specific from-to-zone context to match traffic on the source IP, destination IP, and application (source/destination ports and protocol).
If ALGs are configured, such as FTP, the SRX must examine any control traffic that is matched to an ALG. An example of this would be port 21 for FTP, although custom ports can also be used by the ALG, which is configured in a custom application object. For ALG control traffic, the SRX must do several things. First, it must perform packet reassembly if fragmentation is used, along with TCP reassembly if the application message spans multiple TCP packets. Then the ALG determines if any additional data sessions need to be opened on the SRX.
After the ALG stage is processed (if present), the SRX performs additional services, such as IPS, if configuration is present.
The last stage of packet processing before forwarding the initial packet is to install the session. In the case of the high-end SRX, the session will be installed on the ingress/egress NPUs along with the CP and, of course, the session table of the SPU processing the traffic itself (data center SRX only). On the branch SRX, the data plane will simply forward the packet from the data plane CPU out the correct interface.
The packet is sent to the egress NPU where it will be forwarded out the egress interface (data center SRX only).
Fast-path SPU packet processing
In Figure 6-3, you can see fast-path processing by following the flowchart and taking the Match Session “Yes” track. The fast-path packet process consists of the following steps:
An inbound packet is received by an interface and sent to the NPU, which provides processing for that interface. The NPU performs a session lookup and determines that it knows the session and the SPU processing it. The NPU then forwards the packet directly to the SPU that owns the session (data center SRX only).
Policing, stateless filtering, and screens are performed. Technically, the screens that are applied after the initial packet setup are all on the NPU on the high-end SRX platforms. On the branch SRX, these functions are applied directly by the data plane CPU.
The SPU or branch data plane CPU determines if it knows about the session already, which in this case it does. The session entry will provide cached instructions on how to process the packet so that the SRX does not have to do any forwarding or policy checks, as these have already been determined in the first packet processing. Note that if the egress interface that the session is tied to fails, the SRX will attempt to find a new forwarding path for the destination MAC address, if possible. It either floods the packet or sends an ARP, and optionally a traceroute, depending on your configuration.
If ALGs are configured, such as FTP, the SRX must examine any control traffic that is matched to an ALG. An example of this would be port 21 for FTP, although custom ports can also be used by the ALG, which are configured as custom application objects. For ALG control traffic, the SRX must do several things. First, it must perform packet reassembly if fragmentation is used, along with TCP reassembly if the application message spans multiple TCP packets. The ALG then determines if any additional data sessions need to be opened on the SRX.
After the ALG stage is processed (if present), the SRX performs additional services such as IPS, if configuration is present.
The packet is sent to the egress NPU where it is forwarded out the egress interface (data center SRX only). The branch device’s data plane CPU directly forwards the traffic out the correct egress interface.
Session teardown
All sessions must come to an end at some point. A session could be terminated for several different reasons:
- TCP
A FIN or RESET is sent.
- Session timeout
Sessions that do not have any traffic after the defined idle timeout for that service will be cleared as a session ageout.
- ALG
An ALG can terminate a session based on the control traffic. This could terminate the control portion, data portion, or both of the session.
- Other
There are other reasons why a session might be cleared out, such as an IPS closing a session due to an attack being detected. Changes to policies or policy schedules can also trigger a session to close.
After a session has been closed, the SPU signals to the ingress/egress NPUs, the CP, and, if in an HA chassis cluster, its peer SPU that the session has closed.
Configuring Transparent Mode
Now that you have learned the various components of transparent mode, you can evaluate the configuration of the SRX in transparent mode. This section covers examples of the different concepts of transparent mode in the same order in which they were introduced in the preceding section.
Configuring Transparent Mode Basics
This example creates four interfaces. Two of the interfaces are going to be in access mode and two are going to be in trunk mode. Additionally, there are six different VLANs and six different bridge domains.
The interfaces and VLANs are as follows:
ge-0/0/1 will be in access mode, with VLAN 10 as its VLAN for unit 0.
ge-0/0/2 will be in access mode, with VLAN 20 as its VLAN for unit 0.
ge-0/0/3 will be in trunk mode, with VLAN 10 on unit 10, VLAN 30 on unit 30, and VLAN 40 on unit 40.
ge-0/0/4 will be in trunk mode, with VLAN 20 on unit 10, VLAN 50 on unit 50, and VLAN 60 on unit 60.
The six bridge domains are each called L2-VLAN-XX where
XX is the VLAN number. The bridge domains
logically separate the traffic for the different VLANs.
{secondary:node0}[edit]
root@SRX3400-1# edit interfaces ge-0/0/1 unit 0 family bridge
{secondary:node0}[edit interfaces ge-0/0/1 unit 0 family bridge]
root@SRX3400-1# set interface-mode access vlan-id 10
{secondary:node0}[edit interfaces ge-0/0/1 unit 0 family bridge]
root@SRX3400-1# up 3
{secondary:node0}[edit interfaces]
root@SRX3400-1# edit ge-0/0/2 unit 0 family bridge
{secondary:node0}[edit interfaces ge-0/0/2 unit 0 family bridge]
root@SRX3400-1# set interface-mode access vlan-id 20
{secondary:node0}[edit interfaces ge-0/0/2 unit 0 family bridge]
root@SRX3400-1# up 3
{secondary:node0}[edit interfaces]
root@SRX3400-1# edit ge-0/0/3
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set unit 10 family bridge interface-mode trunk vlan-id-list 10
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set unit 30 family bridge interface-mode trunk vlan-id-list 30
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set unit 40 family bridge interface-mode trunk vlan-id-list 40
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set vlan-tagging
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# up
{secondary:node0}[edit interfaces]
root@SRX3400-1# edit ge-0/0/4
{secondary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# set unit 20 family bridge interface-mode trunk vlan-id-list 20
{secondary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# set unit 50 family bridge interface-mode trunk vlan-id-list 50
{secondary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# set unit 60 family bridge interface-mode trunk vlan-id-list 60
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set vlan-tagging
{secondary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# up
{secondary:node0}[edit interfaces]
root@SRX3400-1# show
ge-0/0/1 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 10;
}
}
}
ge-0/0/2 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 20;
}
}
}
ge-0/0/3 {
vlan-tagging;
unit 10 {
family bridge {
interface-mode trunk;
vlan-id-list 10;
}
}
unit 30 {
family bridge {
interface-mode trunk;
vlan-id-list 30;
}
}
unit 40 {
family bridge {
interface-mode trunk;
vlan-id-list 40;
}
}
}
ge-0/0/4 {
vlan-tagging;
unit 20 {
family bridge {
interface-mode trunk;
vlan-id-list 20;
}
}
unit 50 {
family bridge {
interface-mode trunk;
vlan-id-list 50;
}
}
unit 60 {
family bridge {
interface-mode trunk;
vlan-id-list 60;
}
}
}
{secondary:node0}[edit interfaces]
root@SRX3400-1# up
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-10 domain-type bridge vlan-id 10
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-20 domain-type bridge vlan-id 20
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-30 domain-type bridge vlan-id 30
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-40 domain-type bridge vlan-id 40
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-50 domain-type bridge vlan-id 50
{secondary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-60 domain-type bridge vlan-id 60
{secondary:node0}[edit]
root@SRX3400-1# show bridge-domains
L2-VLAN-10 {
domain-type bridge;
vlan-id 10;
}
L2-VLAN-20 {
domain-type bridge;
vlan-id 20;
}
L2-VLAN-30 {
domain-type bridge;
vlan-id 30;
}
L2-VLAN-40 {
domain-type bridge;
vlan-id 40;
}
L2-VLAN-50 {
domain-type bridge;
vlan-id 50;
}
L2-VLAN-60 {
domain-type bridge;
vlan-id 60;
}Before you can switch from Layer 3 to Layer 2, you must reboot the firewalls in the cluster. This is required whenever switching from Layer 3 to Layer 2 modes.
{secondary:node0}[edit]
root@SRX3400-1# commit and-quit
warning: Interfaces are changed from route mode to transparent mode. Please
reboot the device or all nodes in the HA cluster!
node0:
configuration check succeeds
node1:
warning: Interfaces are changed from route mode to transparent mode. Please
reboot the device or all nodes in the HA cluster!
commit complete
node0:
commit complete
{primary:node0}
root@SRX3400-1> request system reboot
{secondary:node2}
root@SRX3400-2> request system rebootYou might be asking yourself, why is vlan-id used for the access mode interfaces
and vlan-id-list for the trunk mode
interfaces? This is because access mode interfaces can only have a
single VLAN ID (which is untagged). With trunk mode interfaces, you can
have multiple units, each with different VLANs, or you can tie a group
of VLANs to a single trunk mode logical interface. These will be bridged
separately (if they are part of different bridge domains), but it
essentially allows you to take a shortcut with defining the interfaces
themselves.
One important thing to note from this example is that for the trunk interfaces with this configuration, any untagged packets are dropped (or packets tagged for VLANs that you are not looking for). If you would like to accept untagged packets, you would want to use the following code:
{secondary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set native-vlan-id 5Traditional Switching
Plain Layer 2 switching is covered in Chapter 4. For complete and through coverage of the Junos switching capabilities, please refer to Junos Enterprise Switching.
Configuring Integrated Routing and Bridging
Transparent mode does not use Layer 3 IP addresses on its interfaces; therefore, there is no way to communicate with it directly or to send traffic from the transparent mode interfaces directly. To solve this issue, the SRX supports IRB interfaces, so you can send traffic from the SRX as well as manage the SRX on these interfaces. IRB interfaces are not required in transparent mode, but they are required if you want to send traffic out the data plane or receive traffic directed at the SRX on the data plane in transparent mode. In this example, the SRX is configured to send syslog messages out the IRB.0 interface in transparent mode, along with allowing inbound management via SSH and ping. To do this, configure the following:
Configure the IRB.0 interface in VLAN 60, with an IP address of 192.168.60.1/24.
Route traffic to syslog server 192.16.15.20 via next-hop 192.168.60.254.
Allow inbound SSH and pings for the IRB.0 interface.
{primary:node0}[edit]
root@SRX3400-1# set interfaces irb unit 0 family inet address 192.168.60.1/24
{primary:node0}[edit]
root@SRX3400-1# show interfaces irb
unit 0 {
family inet {
address 192.168.60.1/24;
}
}
{primary:node0}[edit]
root@SRX3400-1# set routing-options static route 192.168.15.20 next-hop192.168.60.254
{primary:node0}[edit]
root@SRX3400-1# show routing-options
static {
route 192.168.15.20/32 next-hop 192.168.60.254;
}
{primary:node0}[edit]
root@SRX3400-1# set bridge-domains L2-VLAN-60 routing-interface irb.0
{primary:node0}[edit]
root@SRX3400-1# show bridge-domains L2-VLAN-60
domain-type bridge;
vlan-id 60;
routing-interface irb.0;
{primary:node0}[edit]
root@SRX3400-1# set system services ssh
{primary:node0}[edit]
root@SRX3400-1# show system services
ssh;
{primary:node0}[edit]
root@SRX3400-1# edit firewall family inet filter Services term Inbound
{primary:node0}[edit firewall family inet filter Services term Inbound]
root@SRX3400-1# set Inbound from protocol tcp
{primary:node0}[edit firewall family inet filter Services term Inbound]
root@SRX3400-1# set from destination-port 22
{primary:node0}[edit firewall family inet filter Services term Inbound]
root@SRX3400-1# set then accept
{primary:node0}[edit firewall family inet filter Services term Inbound]
root@SRX3400-1# up
{primary:node0}[edit firewall family inet filter Services]
root@SRX3400-1# edit term ICMP
{primary:node0}[edit firewall family inet filter Services term ICMP]
root@SRX3400-1# set from protocol icmp icmp-type echo-request
{primary:node0}[edit firewall family inet filter Services term ICMP]
root@SRX3400-1# set then accept
{primary:node0}[edit firewall family inet filter Services term ICMP]
root@SRX3400-1# up
{primary:node0}[edit firewall family inet filter Services]
root@SRX3400-1# show
term Inbound {
from {
protocol tcp;
destination-port 22;
}
then accept;
}
term ICMP {
from {
protocol icmp;
icmp-type echo-request;
}
then accept;
}
{primary:node0}[edit]
root@SRX3400-1# set interfaces irb unit 0 family inet filter input Services
{primary:node0}[edit]
root@SRX3400-1# show interfaces irb
unit 0 {
family inet {
filter {
input Services;
}
address 192.168.60.1/24;
}
}Configuring Transparent Mode Security Zones
Now that you have seen the interfaces and placed them into their respective bridge domains, let’s add them into security zones on the SRX. As mentioned earlier in the chapter, the Layer 2 security zones don’t have any special properties to them, and the configuration is just like Layer 3. In this example, the interfaces that were created two examples ago are configured as follows:
Place interface ge-0/0/1.0 into the trust zone.
Place interface ge-0/0/2.0 into the untrust zone.
Place interfaces ge-0/0/3.40, ge-0/0/4.20, and ge-0/0/4.60 into the trust zone.
Place interfaces ge-0/0/3.10, ge-0/0/3.30, and ge-0/04.50 into the untrust zone.
Enable ping and SSH for all interfaces in the trust zone; only allow ping for interfaces in the untrust zone.
{primary:node0}[edit]
root@SRX3400-1# edit security zones security-zone trust
{primary:node0}[edit security zones security-zone trust]
root@SRX3400-1# show
host-inbound-traffic {
system-services {
ping;
ssh;
}
}
interfaces {
ge-0/0/1.0;
ge-0/0/3.40;
ge-0/0/4.20;
ge-0/0/4.60;
}
{primary:node0}[edit security zones security-zone trust]
root@SRX3400-1# up
{primary:node0}[edit security zones]
root@SRX3400-1# edit security-zone untrust
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# set interfaces ge-0/0/2.0
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# set interfaces ge-0/0/3.10
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# set interfaces ge-0/0/3.30
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# set interfaces ge-0/0/4.50
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# set host-inbound-traffic system-services ping
{primary:node0}[edit security zones security-zone untrust]
root@SRX3400-1# show
host-inbound-traffic {
system-services {
ping;
}
}
interfaces {
ge-0/0/2.0;
ge-0/0/3.10;
ge-0/0/3.30;
ge-0/0/4.50;
}Configuring Transparent Mode Security Policies
305 Now that the separate logical Layer 2 interfaces have been created and assigned to security zones, let’s create security policies to dictate what traffic is or isn’t allowed to pass through the device between the various zones.
In this example, the following properties are configured:
Create a rule from trust to untrust that allows any HTTP, HTTPS, SMTP, and FTP traffic to go from the three trust networks 172.31.20.0/24, 172.31.40.0/24, and 172.31.60.0/24 to the three untrust networks 172.31.10.0/24, 172.31.30.0/24, and 172.31.50.0/24.
Create a rule that allows only UDP-DNS and PING to return from the three untrust networks to the three trust networks.
Log all policies on session close.
Set the default policy to Deny-All (it should be set as this by default).
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.20.0/24 172.31.20.0/24
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.40.0/24 172.31.40.0/24
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.60.0/24 172.31.60.0/24
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.10.0/24 172.31.10.0/24
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.30.0/24 172.31.30.0/24
{primary:node0}[edit]
root@SRX3400-1# set security address-book address 172.31.50.0/24 172.31.50.0/24
{primary:node0}[edit]
root@SRX3400-1# show security zones
security-zone untrust {
host-inbound-traffic {
system-services {
ping;
}
}
interfaces {
ge-0/0/2.0;
ge-0/0/3.10;
ge-0/0/3.30;
ge-0/0/4.50;
}
}
security-zone trust {
host-inbound-traffic {
system-services {
ping;
ssh;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
ge-0/0/3.40;
ge-0/0/4.20;
ge-0/0/4.60;
}
}
{primary:node0}[edit]
root@SRX3400-1# edit security policies from-zone trust to-zone untrust policyAllow-Traffic
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# set match source-address [ 172.31.20.0/24 172.31.40.0/24172.31.60.0/24 ]
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# set match destination-address [ 172.31.10.0/24 172.31.30.0/24172.31.50.0/24 ]
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# set match application [ junos-http junos-https junos-smtpjunos-ftp ]
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# set then permit
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# set then log session-close
{primary:node0}[edit security policies from-zone trust to-zone untrust policy
Allow-Traffic]
root@SRX3400-1# up 2
{primary:node0}[edit security policies]
root@SRX3400-1# edit from-zone untrust to-zone trust policy Allow-Inbound
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# set match source-address [ 172.31.10.0/24 172.31.30.0/24172.31.50.0/24 ]
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# set match destination-address [ 172.31.20.0/24 172.31.40.0/24172.31.60.0/24 ]
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# set match application [ junos-dns-udp junos-ping ]
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# set then permit
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# set then log session-close
{primary:node0}[edit security policies from-zone untrust to-zone trust policy
Allow-Inbound]
root@SRX3400-1# up 2
{primary:node0}[edit security policies]
root@SRX3400-1# set default-policy deny-all
{primary:node0}[edit security policies]
root@SRX3400-1# show
from-zone trust to-zone untrust {
policy Allow-Traffic {
match {
source-address [ 172.31.20.0/24 172.31.40.0/24 172.31.60.0/24 ];
destination-address [ 172.31.10.0/24 172.31.30.0/24 172.31.50.0/24 ];
application [ junos-http junos-https junos-smtp junos-ftp ];
}
then {
permit;
log {
session-close;
}
}
}
}
from-zone untrust to-zone trust {
policy Allow-Inbound {
match {
source-address [ 172.31.10.0/24 172.31.30.0/24 172.31.50.0/24 ];
destination-address [ 172.31.20.0/24 172.31.40.0/24 172.31.60.0/24 ];
application [ junos-dns-udp junos-ping ];
}
then {
permit;
log {
session-close;
}
}
}
}
default-policy {
deny-all;
}Configuring Bridging Options
309 Several bridging options can be configured on the SRX to manipulate how it processes packets and performs learning operations in transparent mode. Typically, you won’t need to alter the configuration of these options, but just in case, this section demonstrates how to do exactly that.
In this example, the following configurations are performed:
Your network has some legacy applications that require IPX, DECNET, AppleTalk, and Banyan VINES. Because the SRX does not support these protocols, configure the firewall to just bypass them from the firewall for processing.
Your security posture is strict in terms of information leakage, so configure the SRX not to flood any packets with an unknown MAC address.
{primary:node0}[edit]
root@SRX3400-1# edit security flow bridge
{primary:node0}[edit security flow bridge]
root@SRX3400-1# set bypass-non-ip-unicast
{primary:node0}[edit security flow bridge]
root@SRX3400-1# set no-packet-flooding
{primary:node0}[edit security flow bridge]
root@SRX3400-1# show
bypass-non-ip-unicast;
no-packet-flooding;Restricting BPDUs to VLANs
In an effort to provide more deployment flexibility, Juniper added the ability to restrict BPDUs to only the VLANs on which they originate. As stated, the default behavior is to receive and then flood BPDUs out all active ports on the SRX. To activate this new behavior, only one command is required to be entered and then committed.
[edit]
root@srx3600n0# set security flow bridge bpdu-vlan-flooding
[edit]
root@srx3600n0# show security flow
bridge {
bpdu-vlan-flooding;
}
[edit]
root@srx3600n0 # commit and-quitConfiguring Transparent Mode QoS
QoS in transparent mode is essentially the same as Layer 3 mode, with the primary exceptions of how the classification is performed and how the rewriting can be performed (802.1p bits only).
Classify traffic matching the 802.1p bits 011 to the Expedited Forwarding Class (low loss priority) and 802.1p bits 111 to the Assured Forwarding Class (high loss priority) on interfaces reth0 and reth1.
On reth0 and reth1, rewrite the outgoing 802.1p bits from 011 to 000 and 111 to 101, respectively.
[edit] root@SRX3600-1#edit class-of-service classifiers ieee-802.1 011[edit class-of-service classifiers ieee-802.1 011] root@SRX3600-1#set forwarding-class expedited-forwarding loss-priority low code-points 011[edit class-of-service classifiers ieee-802.1 011] root@SRX3600-1#up 1[edit class-of-service classifiers] root@SRX3600-1#edit ieee-802.1 111[edit class-of-service classifiers ieee-802.1 111] root@SRX3600-1#set forwarding-class assured-forwarding loss-priority high code-points 111[edit class-of-service classifiers ieee-802.1 111] root@SRX3600-1#up 2[edit class-of-service] root@SRX3600-1#edit rewrite-rules[edit class-of-service rewrite-rules] root@SRX3600-1#edit ieee-802.1 011[edit class-of-service rewrite-rules ieee-802.1 011] root@SRX3600-1#set forwarding-class expedited-forwarding loss-priority low code-point 000[edit class-of-service rewrite-rules ieee-802.1 011] root@SRX3600-1#up[edit class-of-service rewrite-rules] root@SRX3600-1#edit ieee-802.1 111[edit class-of-service rewrite-rules ieee-802.1 111] root@SRX3600-1#set forwarding-class assured-forwarding loss-priority high code-point 101[edit class-of-service rewrite-rules ieee-802.1 111] root@SRX3600-1#up 2[edit class-of-service] root@SRX3600-1#set interfaces reth0 unit 0 classifiers ieee-802.1 011[edit class-of-service] root@SRX3600-1#set interfaces reth0 unit 0 rewrite-rules ieee-802.1 011[edit class-of-service] root@SRX3600-1#set interfaces reth1 unit 0 classifiers ieee-802.1 111[edit class-of-service] root@SRX3600-1#set interfaces reth1 unit 0 rewrite-rules ieee-802.1 111[edit class-of-service] root@SRX3600-1#showclassifiers { ieee-802.1 011 { forwarding-class expedited-forwarding { loss-priority low code-points 011; } } ieee-802.1 111 { forwarding-class assured-forwarding { loss-priority high code-points 111; } } } interfaces { reth0 { unit 0 { classifiers { ieee-802.1 011; } rewrite-rules { ieee-802.1 011; } } } reth1 { unit 0 { classifiers { ieee-802.1 111; } rewrite-rules { ieee-802.1 111; } } } } rewrite-rules { ieee-802.1 011 { forwarding-class expedited-forwarding { loss-priority low code-point 000; } } ieee-802.1 111 { forwarding-class assured-forwarding { loss-priority high code-point 101; } } }
Configuring VLAN Rewriting
Earlier in this chapter, we mentioned that you can use VLAN rewriting to rewrite one VLAN to another on an interface. This example does exactly that, with the following configuration:
On interface ge-0/0/3, configure VLAN retagging to translate VLAN 100 to VLAN 10. Use unit 10 for this translation.
On interface ge-0/0/4, configure VLAN retagging to translate VLAN 200 to VLAN 20. Use unit 20 for this translation.
{primary:node0}[edit]
root@SRX3400-1# edit interfaces ge-0/0/3
{primary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# set unit 10 family bridge vlan-rewrite translate 100 10
{primary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# show
vlan-tagging;
unit 10 {
family bridge {
interface-mode trunk;
vlan-id-list 10;
vlan-rewrite {
translate 100 10;
}
}
}
unit 30 {
family bridge {
interface-mode trunk;
vlan-id-list 30;
}
}
unit 40 {
family bridge {
interface-mode trunk;
vlan-id-list 40;
}
}
{primary:node0}[edit interfaces ge-0/0/3]
root@SRX3400-1# up
{primary:node0}[edit interfaces]
root@SRX3400-1# edit ge-0/0/4
{primary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# set unit 20 family bridge vlan-rewrite translate 200 20
{primary:node0}[edit interfaces ge-0/0/4]
root@SRX3400-1# show
vlan-tagging;
unit 20 {
family bridge {
interface-mode trunk;
vlan-id-list 20;
vlan-rewrite {
translate 200 20;
}
}
}
unit 50 {
family bridge {
interface-mode trunk;
vlan-id-list 50;
}
}
unit 60 {
family bridge {
interface-mode trunk;
vlan-id-list 60;
}
}As you can see here, you need to configure vlan-rewrite under a logical unit that is
configured as a trunk link. In the case of ge-0/0/3, traffic that
arrives inbound, tagged with VLAN 100, is translated on ingress to VLAN
10 and processed accordingly. When traffic on VLAN 10 is leaving the SRX
on that interface, it is reverse-translated on egress to VLAN 100. The
same is true for ge-0/0/4 translating from VLAN 200 to 20 and vice
versa. The main command that empowers this is the set interfaces <interface> unit <unit>
family bridge interface-mode trunk translate <incoming-vlan>
<translated-vlan> command. In addition, you must define
the VLANs that are present on the unit using the vlan-id-list command.
Troubleshooting and Operation
Troubleshooting issues in transparent mode are almost identical to troubleshooting Layer 3, with a few exceptions that are the focus here. First, this section lists some of the useful commands in Layer 2 that you should be aware of, and then we will work our way through a step-by-step troubleshooting plan. Additional troubleshooting methodologies can be found in Chapter 8.
The next few commands are unique to transparent mode. We cover the rest of the steps in the section Transparent Mode Troubleshooting Steps later in this chapter.
The show bridge domain Command
The show bridge domain
command lists all of the active bridge domains on the device, along with
the associated VLANs and interfaces for those domains. If you are
experiencing an issue where traffic isn’t flowing, you should check this
first to make sure you have the correct interface, VLAN, and bridge
domain configuration.
root@SRX3400-1> show bridge domain
Routing instance Bridge domain VLAN ID Interfaces
default-switch L2-VLAN-10 10
ge-0/0/1.0
ge-0/0/3.10
default-switch L2-VLAN-20 20
ge-0/0/2.0
ge-0/0/4.20
default-switch L2-VLAN-30 30
ge-0/0/3.30
default-switch L2-VLAN-40 40
ge-0/0/3.40
default-switch L2-VLAN-50 50
ge-0/0/4.50
default-switch L2-VLAN-60 60
ge-0/0/4.60The show bridge mac-table Command
The show bridge
mac-table command is important for looking at the bridge MAC
learning table. If you do not see the MAC addresses for the hosts in the
correct bridge domain on the correct interface of this output, either
the SRX is not seeing the MAC addresses at all (check the surrounding
networking devices) or you’re seeing them on the wrong interface or
bridge domain (which might require some configuration changes).
{primary:node0}
root@SRX3400-1> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)
Routing instance : default-switch
Bridging domain : L2-VLAN-20, VLAN : 20
MAC MAC Logical
address flags interface
00:1f:12:31:d3:21 D ge-0/0/2.0
00:1f:12:f4:ef:1c D ge-0/0/2.0The show l2-learning global-information Command
This command lists the global configuration for the SRX bridge domains.
{primary:node0}
root@SRX3400-1> show l2-learning global-information
Global Configuration:
MAC aging interval : 300
MAC learning : Enabled
MAC statistics : Disabled
MAC limit Count : 131071
MAC limit hit : Disabled
MAC packet action drop: Disabled
LE aging time : 1200
LE BD aging time : 1200The show l2-learning global-mac-count Command
You might also want to check how many MAC addresses your system currently knows about, to ensure that the table is not full. At the time of this writing, the SRX supports 64,000 MAC address entries in the table.
{primary:node0}
root@SRX3400-1> show l2-learning global-mac-count
2 dynamic and static MAC addresses learned globallyThe show l2-learning interface Command
Although the SRX doesn’t support STP natively at the time of this writing, it will forward the BPDUs to ensure that there are no bridge loops. Additionally, there might be reasons why an interface is forwarding or VLANs within an interface are not forwarding, such as the physical interface being down, as shown in this example:
{primary:node0}
root@SRX3400-1> show l2-learning interface
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/1.0 131071
L2-VLA.. 131071 Forwarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/3.30 131071
L2-VLA.. 131071 Discarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/3.40 131071
L2-VLA.. 131071 Discarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/4.20 131071
L2-VLA.. 131071 Discarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/2.0 131071
L2-VLA.. 131071 Forwarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/4.50 131071
L2-VLA.. 131071 Discarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/4.60 131071
L2-VLA.. 131071 Discarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-0/0/3.10 131071
L2-VLA.. 131071 DiscardingTransparent Mode Troubleshooting Steps
Here are some recommended sequential troubleshooting steps for working in transparent mode.
Check the spanning tree.
An issue with the spanning tree is the most common issue when traffic is not flowing through the SRX properly, as surrounding networking gear with spanning tree enabled could put the data interfaces into a blocking state. This is not an issue with the SRX itself, but you will need to run the respective commands on the surrounding networking gear to determine if any of the interfaces that are connected to the SRX are in the blocking state. In the Juniper Networks EX Series Ethernet Switches, you would do this in Junos with the
show spanning-tree interfacecommand to look for interfaces in theBLKstate. On the MX Series, you would look in Junos with theshow l2-learning interfacecommand.Note
Checking the spanning tree is particularly important when dealing with HA clusters, as the interfaces could be in the blocking state for one member and not the other. You should test failover to ensure it works properly.
Check to see if MAC addresses are being learned.
The absence of MAC addresses in the SRX bridging table certainly indicates that there is an issue, along with MAC addresses not appearing on the correct VLANs or interfaces. On the SRX, you can use the
show bridge mac-tablecommand.Check the configuration.
The first common issue that occurs with transparent mode is often a configuration mistake, including the wrong VLAN IDs or incorrect bridge domains. You must check the configuration on the surrounding networking devices along with the SRX. On the SRX, you would want to start by looking at the
show bridge domaincommand to make sure the VLAN configuration is properly mapped to the correct domains. You might also want to review the configuration of the surrounding devices.Check that the native VLANs are properly configured.
On both the SRX and the surrounding networking devices, you must make sure the correct native VLANs are used (if any), or else there could be an issue with interpreting the traffic. The same is true for properly matching the correct traffic to the correct VLAN. If you do not have the correct mappings, there will be issues. Note that the units do not technically need to match between the two devices, but making sure the correct tags and the correct classification are used is essential.
Check that sessions are being established.
If the traffic appears to be arriving on the SRX on the correct interfaces and VLANs, you should check to make sure the sessions are being established and matched to the correct rule. You can do this initially by just looking at the session table using the
show security flow session <modifiers>command along with running the standard flow tracing operations. For instance, you can enable thebasic-datapathdebug and send the output to the file L2Debug. Additionally, you should configure a packet filter based around the traffic you are looking for to ensure that you don’t match unnecessary traffic. Make sure to turn the debugging off after the issue has been resolved to ensure that performance isn’t impacted.{primary:node0}[edit] root@SRX3400-1#edit security flow traceoptions{primary:node0}[edit security flow traceoptions] root@SRX3400-1#set flag basic-datapath{primary:node0}[edit security flow traceoptions] root@SRX3400-1#set file L2Debug{primary:node0}[edit security flow traceoptions] root@SRX3400-1#set packet-filter MatchTraffic interface ge-0/0/1.0 source-prefix172.31.0.0/16 destination-prefix 192.168.1.1 {primary:node0}[edit security flow traceoptions] root@SRX3400-1#showfile L2Debug; flag basic-datapath; packet-filter MatchTraffic { source-prefix 172.31.0.0/16; destination-prefix 192.168.1.1/32; interface ge-0/0/1.0; }Examine the debug output.
From your debugs, you should be able to determine that the traffic is entering and exiting the correct interfaces, along with being matched by the correct security policy. If this isn’t happening, the output in the debug should provide you with hints about what you need to change to resolve the issue.
Check if you are using any unsupported features or running into a known issue.
Remember that some SRX features are not yet supported in transparent mode. We covered them at the beginning of this chapter, and you might check with the Juniper documentation for actual timing of these features. For known issues, you should check the release notes of the version you are running, along with any subsequent releases for issues that have been resolved in case it sounds like a bug. If you are using these features, that could be causing the issue. Check with the JTAC if you suspect this.
Troubleshoot the surrounding networking equipment.
If the SRX appears to be processing the traffic properly and the traffic appears to be entering and exiting the SRX, you should access the neighboring devices to make sure the traffic is actually reaching them and that they are processing the traffic correctly. The methodology you would follow on the other devices depends on the device, but if you can, do an end-to-end packet trace to try to determine where things are breaking down. That is definitely useful when all other steps seem to yield no information.
Check the Juniper Knowledge Base.
The Juniper Knowledge Base might have additional information for troubleshooting these issues, along with potential major known issues.
Call JTAC.
If all else fails, and you have gathered all of the data from your troubleshooting steps, you should call JTAC for additional assistance in troubleshooting the issue. Having information such as network diagrams, packet captures, and access to the devices is very helpful for finding a speedy resolution (see Chapter 8 for a series of commands to run output that JTAC might want or need to see).
Sample Deployments
Now that you have covered all of the concepts related to transparent mode, let’s bring it all together and provide a full configuration example, along with the use of chassis clustering to achieve an HA solution.
There really isn’t much difference between clustering a transparent mode pair and clustering a Layer 3 mode pair from a configuration or concept perspective—you just need to be aware of the surrounding networking configuration to accommodate transparent mode.
This case study performs the following configuration according to this book’s network diagram (see Figure 6-4):
Create a chassis cluster with the two SRX3600s that protect the DMZ. Configure all of the properties of the HA cluster as you see fit (except the interfaces as described shortly). Use ge-0/0/9 and ge-13/0/9 for the data links.
Support trunk link reth0, which will serve as the backbone link. Reth0 will have two tagged VLANs, one for VLAN 100 and another that allows VLAN 30 inbound, but translates it to VLAN 1. Reth0 will be composed of the physical interfaces ge-0/0/0 and ge-13/0/0.
There will be four other reth interfaces that connect into a switch before connecting to the end servers. These will all use the access mode interfaces. Reth1 will belong to the VoIP PBX zone and will be composed of ge-0/0/1 and ge-13/0/1. Reth2 will be in the WebApp zone and will be composed of ge-0/0/2 and ge-13/0/2. Reth3 will be in the Email-Server zone and will be composed of ge-0/0/3 and ge-13/0/3. Finally, reth4 will be in the Database zone and will be composed of ge-0/0/4 and ge-13/0/4. All of these interfaces will be in VLAN 30.
Create the respective bridge domains.
Create an IRB.30 interface with an IP address of 172.31.30.254/24.
For your policies, create the following:
Allow Dept-A and Dept-B to talk to the PBX via Real Time Streaming Protocol (RTSP) and vice versa.
Allow inbound HTTP and HTTPS to the web server from any IP coming from the backbone.
Allow the web server to query the database with SQL.
Allow SMTP connections into the email server and from the email server out, along with DNS.
Set the chassis cluster IDs and node configuration, and reboot as follows:
root@SRX3400-1>set chassis cluster cluster-id 1 node 0 rebootroot@SRX3400-2>set chassis cluster cluster-id 1 node 1 reboot
Note
This is an operational mode command. Also, because this is using SRX3600s, you don’t need to configure any control ports.
{primary:node0}[edit]
root@SRX3400-1# set interfaces fab0 fabric-options member-interfaces ge-0/0/9
{primary:node0}[edit]
root@SRX3400-1# set interfaces fab1 fabric-options member-interfaces ge-13/0/9Configure the node-specific properties.
{primary:node0}[edit]
root@SRX3400-1# set groups node0
{primary:node0}[edit]
root@SRX3400-1# set groups node1
{primary:node0}[edit]
root@SRX3400-1# set groups node0 system host-name SRX3600-1
{primary:node0}[edit]
root@SRX3400-1# set groups node0 interfaces fxp0 unit 0 family inet address10.3.5.1/24
{primary:node0}[edit]
root@SRX3400-1# set groups node0 system backup-router 10.3.5.254 destination0.0.0.0/0
{primary:node0}[edit]
root@SRX3400-1# set groups node1 system host-name SRX3600-2
{primary:node0}[edit]
root@SRX3400-1# set groups node1 interfaces fxp0 unit 0 family inet address10.3.5.2/24
{primary:node0}[edit]
root@SRX3400-1# set groups node1 system backup-router 10.3.5.254 destination0.0.0.0/0
{primary:node0}[edit]
root@SRX3400-1# set apply-groups ${node}Configure the reth count and redundancy groups.
{primary:node0}[edit]
root@SRX3400-1# set chassis cluster reth-count 5
{primary:node0}[edit]
root@SRX3400-1# set chassis cluster redundancy-group 0 node 0 priority 129
{primary:node0}[edit]
root@SRX3400-1# set chassis cluster redundancy-group 0 node 1 priority 128
{primary:node0}[edit]
root@SRX3400-1# set chassis cluster redundancy-group 1 node 0 priority 129
{primary:node0}[edit]
root@SRX3400-1# set chassis cluster redundancy-group 1 node 1 priority 128Configure the reth and IRB interfaces.
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-0/0/0 gigether-options redundant-parent reth0
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-13/0/0 gigether-options redundant-parent reth0
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-0/0/1 gigether-options redundant-parent reth1
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-13/0/1 gigether-options redundant-parent reth1
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-0/0/2 gigether-options redundant-parent reth2
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-13/0/2 gigether-options redundant-parent reth2
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-0/0/3 gigether-options redundant-parent reth3
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-13/0/3 gigether-options redundant-parent reth3
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-0/0/4 gigether-options redundant-parent reth4
{primary:node0}[edit]
root@SRX3400-1# set interfaces ge-13/0/4 gigether-options redundant-parent reth4
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth0 redundant-ether-options redundancy-group 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth1 redundant-ether-options redundancy-group 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth2 redundant-ether-options redundancy-group 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth3 redundant-ether-options redundancy-group 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth4 redundant-ether-options redundancy-group 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth0 vlan-tagging
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth0 unit 100 family bridge interface-mode trunkvlan-id-list 100
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth0 unit 30 family bridge interface-mode trunk
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth0 unit 30 family bridge vlan-rewrite translate30 1
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth1 unit 0 family bridge interface-mode accessvlan-id 100
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth2 unit 0 family bridge interface-mode accessvlan-id 100
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth3 unit 0 family bridge interface-mode accessvlan-id 100
{primary:node0}[edit]
root@SRX3400-1# set interfaces reth4 unit 0 family bridge interface-mode accessvlan-id 100
{primary:node0}[edit]
root@SRX3400-1# set interfaces irb unit 100 family inet address 172.31.100.254/24{primary:node0}[edit]
root@SRX3400-1# set bridge-domains VLAN1 domain-type bridge vlan-id 1
{primary:node0}[edit]
root@SRX3400-1# set bridge-domains VLAN100 domain-type bridge vlan-id 100routing-interface irb.100Configure security zones and address objects.
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Backbone interfaces reth0.100
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Backbone interfaces reth0.30
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones VoIP interfaces reth1
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones WebApp interfaces reth2
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Email-Server interfaces reth3
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Database interfaces reth4
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Backbone address-book addressDept-A 10.1.0.0/16
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Backbone address-book addressDept-B 10.2.0.0/16
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones VoIP address-book address VoIP-PBX 172.31.100.50/32
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones WebApp address-book addressWebApp 172.31.100.60/32
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Email-Server address-bookaddress WebApp 172.31.100.70/32
{primary:node0}[edit]
root@SRX3400-1# set security zones security-zones Database address-book address172.31.100.80/32Configure the security policies.
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone VoIP policy Allow-RTSP matchsource-address [ Dept-A Dept-B ] destination-address VoIP-PBX application junos-rtsp
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone VoIP policy Allow-RTSP then permit
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone VoIP to-zone Backbone policy Allow-RTSP-Out matchsource-address VoIP-PBX destination-address [ Dept-A Dept-B ] application junos-rtsp
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone VoIP policy Allow-RTSP-Out thenpermit
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone WebApp policy Allow-Inbound-Webmatch source-address any destination-address WebApp application [ junos-httpjunos-https ]
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone WebApp policy Allow-Inbound-Webthen permit
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone WebApp to-zone Database policy Allow-Web-Queriesmatch source-address WebApp destination-address Database application[ junos-sql ]
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone WebApp to-zone Database policy Allow-Web-Queriesthen permit
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone Email-Server policy Allow-Emails-Inbound match source-address any destination-address Email-Server application [ junos-smtp ]
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Backbone to-zone Email-Server policy Allow-Emails-Inbound then permit
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Email-Server to-zone Backbone policy Allow-Emails-Outbound match source-address Email-Server destination-address any application [ junos-smtp junos-dns-udp ]
{primary:node0}[edit security policies]
root@SRX3400-1# set from-zone Email-Server to-zone Backbone policy Allow-Emails-Outbound then permit
{primary:node0}[edit security policies]
root@SRX3400-1# set default-policy deny-allSummary
Transparent mode is a very powerful feature that can dramatically ease the deployment of a firewall while providing advanced support for securing your network. Most of the configuration relating to transparent mode is just like standard Layer 3 routed mode, but there are a few new concepts that you need to be aware of regarding the actual interface and VLAN configurations.
Although transparent mode is typically quite easy to deploy, you do need to be aware of the potential for bridge loops, along with the fact that spanning tree might cause links to go into the blocking state, and therefore not pass traffic properly.
In this chapter, we discussed many tools on the SRX and surrounding devices that can help you to determine the cause of an issue so that you can take appropriate steps to resolve it.
Finally, there are a few limitations of transparent mode at the time of this writing that you need to be aware of. As time goes on, Juniper will continue to strive to eliminate these limitations and achieve full-feature parity, so monitor the Junos release notes to determine what new features and support have arrived in the latest release. After all, Juniper comes out with new software every three months, so things can be developed quite quickly for the SRX.
Study Questions
- Questions
Why is transparent mode a popular deployment model for firewall deployments?
What is the name of the family used on interfaces in transparent mode?
How can a device in transparent mode communicate with other devices on the network if the interfaces do not have any Layer 3 addressing?
What is the difference between interfaces in access mode and trunk mode?
What is the default method for resolving an unknown MAC address when the SRX has received a packet with an unknown MAC address and needs to forward it?
If you have non-IP traffic on your network, how can you have the SRX forward it?
With what fields can the SRX perform QoS for transit traffic?
What is the purpose of VLAN rewriting?
What is the most common issue in transparent mode that prevents traffic from flowing properly through the SRX?
How does the SRX inform surrounding networking equipment to recalculate spanning tree in the event of a failure?
- Answers
Transparent mode allows easy deployment of a firewall because the underlying network structure does not need to change from a Layer 3 perspective, thus making it easy to deploy a firewall in transparent mode. Additionally, because the device does not have to perform any routing, this makes it ideal when being inserted into complex routing topologies, although this isn’t so much of an issue with the SRX because the SRX supports Junos.
The family bridge is the family used on the interface in transparent mode.
In transparent mode, you can use IRB interfaces within VLANs to provide a virtual Layer 3 interface that can send and receive traffic, although it cannot route transit traffic itself at the time of this writing.
Access mode interfaces provide a single untagged interface on which traffic can arrive. Access mode interfaces do allow the interface to classify any traffic being received on them as being from a particular VLAN; however, the traffic itself is not tagged. Trunk interfaces allow the interface to accept traffic from multiple VLANs, which are distinguished by different tags (a tag or range of tags can be allowed by a particular bridge domain) along with the ability to support a native VLAN that has no tag, but all untagged traffic will be classified as being part of this VLAN on the system.
The default method of resolution is to forward the packet out all interfaces in the same VLAN except the one on which it was received. Alternatively, you can configure the SRX to ARP for the destination on behalf of the client, along with sending an ICMP with a TTL of 1 to determine the interface on which the destination MAC address lives.
You will need to enable the
set security flow bridge bypass-non-ip-unicastcommand to allow all non-IP traffic (except IPv6, which currently will be dropped unless tunneled) through the SRX.The SRX can perform classification and rewriting with the 802.1p bits that are present in 802.1q frames. You cannot use IP precedence or DSCP bits for classification on the SRX in transparent mode; you can only do so in Layer 3 mode.
VLAN rewriting, also known as VLAN retagging, allows the SRX to swap the incoming or outgoing VLAN tag with another that the system will use for internal processing. This is useful when you want to translate the VLAN tags on the SRX without using routing to transform the packets.
A misconfigured spanning tree can result in surrounding network equipment thinking there is a loop in the network, and therefore putting interfaces in blocking mode that otherwise shouldn’t be. This can also impact the failover between chassis cluster members.
The SRX will flap the interfaces for the respective secondary redundancy groups that are failing over so that the switches will recalculate spanning tree in favor of the new primary node for the respective redundancy groups.
Get Juniper SRX Series now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
