Chapter 4. SRX Networking Basics
The Junos OS has support for the majority of the available networking protocols. A small device such as an SRX100 supports MPLS, VPLS, switching, IS-IS, BGP, and dozens of other protocols. It is quite amazing to have such a wide variety of technologies available in one device. The SRX is a versatile device. Being able to offer so much protocol support and also offering security features is wonderful. As SRX experts, both my coauthor and myself have discussed hundreds of use cases and deployment models with customers. The majority of these deployments use only the minimal amount of networking features. Around 25 percent of SRX deployments use the more advanced networking features of the SRX. These specific deployments would not be possible if the SRX was unable to support these advanced features. However, when deciding on how to best cover networking on the SRX, we chose to keep the networking section focused on best practices rather than covering the corner case deployments. We want to guide you to supported, commonly used designs that we consider best practices.
The majority of the book is focused on the security aspects of the SRX. In this chapter, we review the basics of getting the SRX onto your network and how to deploy the SRX in what we consider a standard best practice. Because the networking side of Junos is so robust, we often see customers attempting to be overly creative with their networking designs. There is nothing wrong with this. It is fun to deploy a dozen routing instances and multiple routing protocols. Often it is needed, but for the majority of SRX deployments it is not. When dealing with a network deployment, it is best to focus on the minimal requirements for a working design. Each additional component that is added can cause an unexpected level of difficulty. Our suggestion is to keep your designs simple and focus on keeping the design minimalistic. This will ensure a successful deployment and ease troubleshooting in the event that trouble occurs.
Interfaces
To get our networking device to apply security to traffic, we must first integrate it into our network. To do so, we must start by configuring its interfaces. This is a very basic and essential step to any deployment, but it is typically where an installation starts. The majority of the administration time on an SRX is spent on policy tuning and reviewing the security logs. For a security device, this is where you want to spend your time, sharpening your security policy.
The deployment capabilities are quite diverse when it comes to an SRX. The majority of the SRX deployments use Ethernet interfaces. Although the branch SRX devices do offer dozens of WAN interfaces, the configuration is essentially the same outside of the physical configuration for the interface. We suggest you check the latest Junos documentation on the WAN interfaces as this changes quite often with newer drivers in current versions of Junos. Also we have made a decision to treat IPv6 as a first-class citizen. Throughout this chapter we show how to configure both IPv4 and IPv6. If you have not had a chance, please do take some time to learn IPv6. It is relatively simple once you start using it (128-bit IP addresses do take some getting used to). If you are not familiar with IPv6, I suggest Silvia Hagen’s IPv6 Essentials (O’Reilly). This is where I started a number of years ago, and I highly recommend it.
Physical Interfaces
A networking device without interfaces isn’t much of a networking device. Because a Junos device is always in the network, and most of the time it is in the path of the network, it is critical to understand interface configuration.
Some Junos interface concepts might seem foreign to administrators who are migrating from other OSs. Remember that the Junos CLI is designed to be extensible and scalable, and once an element is added to the configuration hierarchy after a software release is made, it is not changed. Because of this, creating an interface and modifying its parameters might seem overly complex, but it is done for a good reason: to ensure that 10 years from now the general structure of creating an interface is backward compatible.
A physical interface is an actual device that someone can touch and a cable of some sort goes into it. A logical interface is an entity that has a protocol and a network address assigned to it. A physical interface can also be called an IFD, and a logical interface is called an IFL, terms sometimes sprinkled around in the documentation or in various Junos material.168
An interface is named in a common format, and the format is shared regardless of the interface type. The first part of an interface name is the media type. Table 4-1 lists a few of the common media types and their abbreviations.
Name | Media type |
| Fast Ethernet 10/100 |
| Gigabit Ethernet 1000 |
| 10 gigabit Ethernet |
| T1 interface |
| Virtual interface that resides in a virtual LAN (VLAN) |
There are many different types of interfaces, and only a handful are represented in Table 4-1. For more information on the various interface types, refer to the Junos documentation set.
Interface names also include the location in which they are found in the chassis. This portion of the interface name consists of three numbers: the FPC number, the PIC number, and the port number.
FPC, or flexible PIC concentrator, is simply a slot in a chassis. The differentiation of FPCs typically determines how the FPC plugs into the back plane of the device. A PIC represents a physical or pluggable (both terms are seen and sometimes used interchangeably) interface card on which interfaces or ports reside. The numbering for an interface is represented in an X/Y/Z pattern, with X being the FPC, Y being the PIC, and Z being the port. An example of a complete interface name is “ge-0/0/0”.
Note
A few interface types do not fit into this format. One of these is fxp0, which is used as a management port. You can configure it with most of the options that an interface can use, such as IP addresses, but this interface cannot route traffic because it is not a transient interface. We discuss the fxp0 interface in the next section.
Each physical interface has some physical properties that you can
configure, such as speed, duplex, and auto-negotiation; these properties
vary based on interface type. Because of all the variations that are
possible, it’s best to check the latest Junos documentation to get the
most up-to-date configuration options. In most cases, though, the
command-line help, using ?, will give
you what you need. Typically, on an Ethernet interface, you will not
need to configure the specific properties.
For physical interfaces, the physical configuration properties are under the “ether-options” hierarchy. The configuration specifics and name of this “options” section will vary based on the type of interface, the Junos platform, or both. Under the ether-options, as we will call it from now on, you can specify the duplex as well as the speed. These are the most common settings that someone would configure under the physical interfaces properties. The most common would be disabling the physical interface. In this next configuration example, we look at both.
root@SRXEdge# set fastether-options ?
Possible completions:
> 802.3ad IEEE 802.3ad
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
auto-negotiation Enable auto-negotiation
ignore-l3-incompletes Ignore L3 incomplete errors
ingress-rate-limit Ingress rate at port (1..100 megabits per second)
loopback Enable loopback
> mpls MPLS options
no-auto-negotiation Don't enable auto-negotiation
no-loopback Don't enable loopback
> redundant-parent Parent of this interface
> source-address-filter Source address filters
[edit interfaces fe-0/0/0]
root@SRXEdge#As we can see here, these are the configuration options under a fast Ethernet interface on an SRX100. It doesn’t offer much in the customization for physical properties as these options are found under the interface itself. Because the underlying hardware is different on each platform the options might vary a bit.
[edit interfaces fe-0/0/0]
root@SRXEdge# set ?
Possible completions:
accounting-profile Accounting profile name
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
description Text description of interface
disable Disable this interface
encapsulation Physical link-layer encapsulation
> fastether-options Fast Ethernet interface-specific options
flexible-vlan-tagging Support for no tagging, or single and double
802.1q VLAN tagging
gratuitous-arp-reply Enable gratuitous ARP reply
> hold-time Hold time for link up and link down
link-mode Link operational mode
mac Hardware MAC address
mtu Maximum transmit packet size (256..9192)
native-vlan-id Virtual LAN identifier for untagged frames (0..4094)
no-gratuitous-arp-reply Don't enable gratuitous ARP reply
no-gratuitous-arp-request Ignore gratuitous ARP request
no-per-unit-scheduler Don't enable subunit queuing on Frame Relay or
VLAN IQ interface
no-traps Don't enable SNMP notifications on state changes
passive-monitor-mode Use interface to tap packets from another router
per-unit-scheduler Enable subunit queuing on Frame Relay or VLAN IQ
interface
speed Link speed
> traceoptions Interface trace options
traps Enable SNMP notifications on state changes
> unit Logical interface
vlan-tagging 802.1q VLAN tagging support
[edit interfaces fe-0/0/0]
root@SRXEdge#Here we can see that both speed and duplex can be set under the interface itself.
[edit interfaces fe-0/0/0] root@SRXEdge# show speed 100m; link-mode full-duplex; [edit interfaces fe-0/0/0] root@SRXEdge#
They can also be set as shown with the set commands instead of the Junos hierarchy.
[edit interfaces fe-0/0/0] root@SRXEdge# show | display set set interfaces fe-0/0/0 speed 100m set interfaces fe-0/0/0 link-mode full-duplex [edit interfaces fe-0/0/0] root@SRXEdge#
Here is an example from an SRX3600 displaying the gigabit Ethernet options as well as the rest of the physical options at the root hierarchy under the interface itself. Both speed and link mode are in bold.
root@srx3600n0#set gigether-options? Possible completions: > 802.3ad IEEE 802.3ad + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > auto-negotiation Enable auto-negotiation flow-control Enable flow control ignore-l3-incompletes Ignore L3 incomplete errors loopback Enable loopback no-auto-negotiation Disable auto-negotiation no-flow-control Don't enable flow control no-loopback Don't enable loopback > redundant-parent Parent of this interface [edit interfaces ge-0/0/0] root@srx3600n0# set ? Possible completions: accounting-profile Accounting profile name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups description Text description of interface disable Disable this interface encapsulation Physical link-layer encapsulation > gigether-options Gigabit Ethernet interface-specific options gratuitous-arp-reply Enable gratuitous ARP reply > hierarchical-scheduler Enable hierarchical scheduling > hold-time Hold time for link up and link downlink-mode Link operational modemac Hardware MAC address mtu Maximum transmit packet size (256..9192) native-vlan-id Virtual LAN identifier for untagged frames (0..4094) no-gratuitous-arp-reply Don't enable gratuitous ARP reply no-gratuitous-arp-request Ignore gratuitous ARP request no-per-unit-scheduler Don't enable subunit queuing on Frame Relay or VLAN IQ interface no-traps Don't enable SNMP notifications on state changes > optics-options Optics options > otn-options Optical Transmission Network interface-specific options per-unit-scheduler Enable subunit queuing on Frame Relay or VLAN IQ interface port-mirror-instance Port-mirror the packet to specified instance promiscuous-mode Enable promiscuous mode for L3 interfacespeed Link speed> traceoptions Interface trace options traps Enable SNMP notifications on state changes > unit Logical interface vlan-tagging 802.1q VLAN tagging support [edit interfaces ge-0/0/0] root@srx3600n0#
Finally, disabling an interface is easy to do and it can be done as one command. It is common to disable interfaces during testing or troubleshooting.
[edit interfaces fe-0/0/0] root@SRXEdge# show disable; [edit interfaces fe-0/0/0] root@SRXEdge# show | display set set interfaces fe-0/0/0 disable [edit interfaces fe-0/0/0] root@SRXEdge#
Either way, configuring the options is straightforward. Depending
on the version of Junos and the underlying hardware, the options can
vary. It is best to check the latest Junos documentation to see how to
configure the specific options that you are looking for. By default,
Junos interfaces do not have to be shown in the configuration. This is
great, as you can preconfigure interfaces before you even have the
hardware, but it is also confusing to first-time users, as you might
wonder what interfaces you have available. It is easy to see what
hardware you have installed in your device. This can be done a few
different ways. Most commonly, you would use the show interfaces terse command. This would
display what interfaces are in the system, their physical status (up or
down), and if there are any logical interfaces configured.
[edit interfaces fe-0/0/0] root@SRXEdge# run show interfaces terse Interface Admin Link Proto Local Remotefe-0/0/0up up fe-0/0/0.0 up up inet 11.12.13.14/28 gr-0/0/0 up up ip-0/0/0 up up lt-0/0/0 up up mt-0/0/0 up up sp-0/0/0 up up sp-0/0/0.0 up up inet sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16 10.0.0.6 --> 0/0 128.0.0.1 --> 128.0.1.16 128.0.0.6 --> 0/0fe-0/0/1up up fe-0/0/1.0 up up eth-switchfe-0/0/2up up fe-0/0/2.0 up up eth-switchfe-0/0/3up up fe-0/0/3.0 up up eth-switchfe-0/0/4up down fe-0/0/4.0 up down eth-switchfe-0/0/5up down fe-0/0/5.0 up down eth-switchfe-0/0/6up down fe-0/0/6.0 up down eth-switchfe-0/0/7up down fe-0/0/7.0 up down eth-switch gre up up ipip up up irb up up lo0 up up lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet 10.0.0.1 --> 0/0 10.0.0.16 --> 0/0 128.0.0.1 --> 0/0 128.0.0.4 --> 0/0 128.0.1.16 --> 0/0 lo0.32768 up up lsi up up mtun up up pimd up up pime up up pp0 up up ppd0 up up ppe0 up up st0 up up st0.0 up up inet 10.250.0.1/30 tap up up [edit interfaces fe-0/0/0] root@SRXEdge#
There certainly is a lot to take in from that one command. You
will be able to see all of the physical, virtual, and logical interfaces
in the system with that one command. The part that we want to focus on
in this section is finding the physical interfaces. In the preceding
display all of the physical interfaces are shown in bold. We can verify
that these are physical interfaces in two ways. First, we can see that
they display the media type, fe for fast Ethernet, and they use the
X/Y/Z naming to show where they are
located in the chassis. It is possible to use the show chassis hardware command to also see what
cards are physically installed in the chassis.
root@SRXEdge> show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis AU5209AF0571 SRX100H Routing Engine REV 08 750-021773 AT5209AF0571 RE-SRX100H FPC 0 FPC PIC 0 8x FE Base PIC Power Supply 0 root@SRXEdge>
In this, we can see that there is one 8xFE (eight fast Ethernet port) PIC installed. These interfaces are built into the chassis. A more complex example can be seen next from an SRX3600 chassis. Because the SRX3600 is a modular platform, the administrator installs the majority of its components. The physical interfaces are displayed in bold in the following example:
root@srx3600n0> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis AB3009AA0002 SRX 3600
Midplane REV 07 710-020310 AAAR9529 SRX 3600 Midplane
PEM 0 rev 10 740-027644 I262GR008F10P DC Power Supply
PEM 1 rev 10 740-027644 I262GR00CC10P DC Power Supply
CB 0 REV 16 750-021914 AAAZ3985 SRX3k RE-12-10
Routing Engine BUILTIN BUILTIN Routing Engine
CPP BUILTIN BUILTIN Central PFE Processor
Mezz REV 08 710-021035 AAAT1432 SRX HD Mezzanine Card
FPC 0 REV 12 750-021882 AAAK9268 SRX3k SFB 12GE
PIC 0 BUILTIN BUILTIN 8x 1GE-TX 4x 1GE-SFP
FPC 1 REV 16 750-020321 AABV2891 SRX3k 2x10GE XFP
PIC 0 BUILTIN BUILTIN 2x 10GE-XFP
Xcvr 0 REV 01 740-014289 C745XU00K XFP-10G-SR
Xcvr 1 REV 01 740-014289 T08A15927 XFP-10G-SR
FPC 2 REV 13 750-016077 AACV7526 SRX3k SPC
FPC 3 REV 13 750-016077 AACV7484 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Cp-Flow
FPC 4 REV 05 750-016077 TV3939 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 5 REV 13 750-016077 AABS4961 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 6 REV 13 750-016077 AACY8034 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 7 REV 11 750-016077 AAAK0085 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 8 REV 13 750-016077 AACV5262 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 9 REV 13 750-016077 AACW2994 SRX3k SPC
PIC 0 BUILTIN BUILTIN SPU Flow
FPC 10 REV 13 750-017866 AAAK8644 SRX3k NPC
PIC 0 BUILTIN BUILTIN NPC PIC
FPC 11 REV 12 750-017866 AAAF7971 SRX3k NPC
PIC 0 BUILTIN BUILTIN NPC PIC
FPC 12 REV 15 750-017866 AACY0754 SRX3k NPC
PIC 0 BUILTIN BUILTIN NPC PIC
Fan Tray 0 REV 06 750-021599 VR9733 SRX 3600 Fan Tray
root@srx3600n0>Management Interfaces
One of the most controversial interfaces in a Junos platform is the dedicated management port, also known as fxp0. All data center SRX devices come with a built-in physically dedicated fxp0 port. On the branch devices, the fxp0 interface is only created on entering cluster mode (discussed in Chapter 7). The original design of the fxp0 interface was to provide a dedicated physical interface that is directly connected to the route engine, the idea being that even if the data plane would be completely utilized, you would still have direct access to the route engine for management.
In a typical service provider network, there is a dedicated segment to just device management. This way, all of the devices could be reachable no matter the state of the transit network, and no management protocols would need to be turned on where customer’s traffic passes. This is an excellent idea, and we consider this to be an ideal best practice. If possible, please do create an out-of-band network and use it as your sole method of management.
Now the reality is that most enterprise customers do not follow this as a best practice. Typically, in an enterprise, management is done in-band or on traffic passing ports. In a service provider, you have nontrusted third-party data transiting your network. In no way would you want to trust any management traffic that is intermixed with this traffic. In an enterprise, the situation is very different. An enterprise typically has trusted or partially trusted traffic transiting their networks. Because of this, in-band management is logical and it saves the enterprise from building another dedicated network. I use the term enterprise loosely, as here I use it as any non-service-provider network.
With that said, let’s talk about the challenges that are currently presented with the fxp0 interface. This interface is stuck in the main or often referred to as the master routing instance or table (routing instances are discussed later in the chapter). This creates a bit of a dilemma, as most enterprises would want to keep their network simple and utilize a single routing table. However, it seems strange to have this other management interface inside the same routing table. Let’s break down the various concerns for this scenario in the remainder of this section.
First, routes that are associated with fxp0 are never pushed into the data plane’s forwarding table. This means that those routes are not in a place that would impact transit traffic. To show this further, let’s take a look at the routing table from the perspective of the CLI and what the data plane can see. In our example, the only default route that we have configured is via fxp0.
root@srx3600n0> show configuration routing-options
rib inet6.0 {
static {
route 2003::0/120 next-hop 2001::fe;
route 2004::0/120 next-hop 2005::fe;
}
}
static {
route 0.0.0.0/0 next-hop 172.19.100.1;
route 10.102.5.0/24 next-hop 10.102.1.254;
route 10.102.6.0/24 next-hop 10.102.2.254;
}
root@srx3600n0> show route
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 1w1d 23:50:11
> to 172.19.100.1 via fxp0.0
10.102.1.0/24 *[Direct/0] 1w1d 23:49:26
> via xe-1/0/0.0
10.102.1.1/32 *[Local/0] 5w1d 23:08:37
Local via xe-1/0/0.0
10.102.2.0/24 *[Direct/0] 1w1d 23:49:25
> via xe-1/0/1.0
10.102.2.1/32 *[Local/0] 5w1d 23:08:37
Local via xe-1/0/1.0
10.102.3.0/24 *[Direct/0] 1w1d 23:49:26
-- truncated ---
root@srx3600n0> show route forwarding-table
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 2 0:1b:c0:56:a0:0 ucst 357 5 fxp0.0
default perm 0 rjct 36 1
0.0.0.0/32 perm 0 dscd 34 1
10.102.1.0/24 intf 0 rslv 569 1 xe-1/0/0.0
10.102.1.0/32 dest 0 10.102.1.0 recv 567 1 xe-1/0/0.0
10.102.1.1/32 intf 0 10.102.1.1 locl 568 2
10.102.1.1/32 dest 0 10.102.1.1 locl 568 2
10.102.1.254/32 dest 0 10.102.1.254 hold 602 3 xe-1/0/0.0
10.102.1.255/32 dest 0 10.102.1.255 bcst 566 1 xe-1/0/0.0
10.102.2.0/24 intf 0 rslv 585 1 xe-1/0/1.0
10.102.2.0/32 dest 0 10.102.2.0 recv 583 1 xe-1/0/1.0
10.102.2.1/32 intf 0 10.102.2.1 locl 584 2
10.102.2.1/32 dest 0 10.102.2.1 locl 584 2
10.102.2.254/32 dest 0 10.102.2.254 hold 604 3 xe-1/0/1.0
10.102.2.255/32 dest 0 10.102.2.255 bcst 582 1 xe-1/0/1.0
10.102.3.0/24 intf 0 rslv 573 1 xe-1/0/0.0
-- truncated ---At this point, if you look, you can see the default route in all of the preceding commands. This would look as if the fxp0 route is present in the data plane. However, if we go into the data plane directly (don’t try this at home!), we can see that the route is not installed on the data plane.
[flowd]FPC3.PIC0(vty)# show route ip IPv4 Route Table 0, default.0, 0x0: Destination NH IP Addr Type NH ID Interface ------------ --------------- -------- ----- --------- default Reject 36 RT-ifl 0 0.0.0.0 Discard 34 RT-ifl 0 10.102.1/24 Resolve 569 RT-ifl 70 xe-1/0/0.0 ifl 70 10.102.1.0 10.102.1.0 Recv 567 RT-ifl 70 xe-1/0/0.0 ifl 70 10.102.1.1 10.102.1.1 Local 568 RT-ifl 0 10.102.1.254 Hold 602 RT-ifl 70 xe-1/0/0.0 ifl 70 10.102.1.255 Bcast 566 RT-ifl 70 xe-1/0/0.0 ifl 70 10.102.2/24 Resolve 585 RT-ifl 71 xe-1/0/1.0 ifl 71 10.102.2.0 10.102.2.0 Recv 583 RT-ifl 71 xe-1/0/1.0 ifl 71 -- truncated --
As you can see in the actual data plane, the default route is not used. Now for our final example of this, we will install a default route in the data plane and you can see the difference. The point to note here is that it is perfectly fine, although somewhat illogical, to utilize the fxp0 in the same routing instance as transit traffic. Once the new default route was used, it took over for all of the traffic of the other default route.
root@srx3600n0> show route inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both0.0.0.0/0*[Static/5] 1w2d 00:03:49 to 172.19.100.1 via fxp0.0> to 10.102.1.254 via xe-1/0/0.010.102.1.0/24 *[Direct/0] 1w2d 00:03:04 > via xe-1/0/0.0 10.102.1.1/32 *[Local/0] 5w1d 23:22:15 Local via xe-1/0/0.0 10.102.2.0/24 *[Direct/0] 1w2d 00:03:03 > via xe-1/0/1.0 10.102.2.1/32 *[Local/0] 5w1d 23:22:15 Local via xe-1/0/1.0 10.102.3.0/24 *[Direct/0] 1w2d 00:03:04 > via xe-1/0/0.0 -- truncated --- root@srx3600n0> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netifdefault user 2 10.102.1.254 hold 602 6 xe-1/0/0.0default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 10.102.1.0/24 intf 0 rslv 569 1 xe-1/0/0.0 10.102.1.0/32 dest 0 10.102.1.0 recv 567 1 xe-1/0/0.0 10.102.1.1/32 intf 0 10.102.1.1 locl 568 2 10.102.1.1/32 dest 0 10.102.1.1 locl 568 2 10.102.1.254/32 dest 0 10.102.1.254 hold 602 6 xe-1/0/0.0 10.102.1.255/32 dest 0 10.102.1.255 bcst 566 1 xe-1/0/0.0 -- truncated --- [flowd]FPC3.PIC0(vty)# show route ip IPv4 Route Table 0, default.0, 0x0: Destination NH IP Addr Type NH ID Interface ------------ ----------- -------- ----- ---------default Hold 602 RT-ifl 0 xe-1/0/0.0 ifl 700.0.0.0 Discard 34 RT-ifl 0 10.102.1/24 Resolve 569 RT-ifl 70 xe-1/0/0.0 ifl 70 -- truncated ---
Best practice is to reduce the number of routes to the minimum for the fxp0 interface. There are some other use cases specific to dealing with chassis cluster, and those cases are discussed in Chapter 7. Another option that an administrator will use is to leave the fxp0 interface in the master routing instance and place all traffic interfaces in their own instance. This is reviewed later in this chapter.
The biggest challenge is that some services require the use of the master routing table to utilize their service, specifically with logging being the biggest issue, which is discussed later in this chapter. Since the release of the SRX, Juniper has been moving the majority of its services into any other routing instances, but due to the nature of how Junos shares its code with other platforms (e.g., MX or EX), a few services remain in the master VR. Throughout the book, these specific problems are highlighted in their respective sections.
Virtual Interfaces
Before we start to review the more interesting interface configurations, there are some interfaces that were displayed before that might be a bit confusing. As shown in the following display, there are many interfaces that are shown but they do not physically exist in the system. These interfaces are known as virtual interfaces. They are used for specific use cases. In Junos, for traffic to be processed, it typically needs to ingress an interface. Once the traffic is sent through an interface, it will then be acted on by specific policies, configurations, or both. Because of this, there are some virtual interfaces that exist to solve some specific problems. The most commonly used interfaces are shown in Table 4-2.
Name | Media type |
| Secure tunnel interface (IPsec VPNs) |
| IP in IP tunneling (6in4 tunneling) |
| Generic router encapsulation |
| Protocol independent multicast |
| PIM decapsulation |
| PIM encapsulation |
| Logical tunnel interface |
| Loopback interface |
Overall, these interfaces are only important when you need them for a specific application. Otherwise, I suggest ignoring these interfaces. Throughout the book, these interfaces are discussed when needed, but otherwise they are unused.
Logical Interfaces
When an interface is configured for use on the network, it must always be configured with what is known as a unit. A unit is a logical entity that is applied to an interface. A physical interface must have at least 1 unit, but it can have as many as 16,000, depending on the need. Although this seems strange at first, it is actually extremely advantageous when configuring your device. It gives the administrator a sense of flexibility in how the device is configured. It also allows the simple migration of units between interfaces.
To communicate with other hosts and pass traffic through the device, protocols must be configured. Junos supports numerous protocols for network communication and several can be configured per unit. The most common protocol that is used is IPv4. This is the current standard on the Internet and in most networks. IPv6 is growing in popularity, and because of this, Junos has support for it as well. When configuring an interface, a protocol is called a family. This is because a protocol is often a family of protocols; an example is IP, as IP uses ICMP, TCP, and UDP for messaging purposes. Table 4-3 lists some of the most commonly supported families.
Family | Description |
inet | IPv4 protocol |
inet6 | IPv6 protocol |
iso | ISO protocol used for IS-IS |
ethernet-switching | Used for Layer 2 Ethernet switching |
As stated, IPv4 is the most common protocol in use today, but IPv6 is up and coming. Here is an example of what an interface with both IPv4 and IPv6 would look like.
root@SRXEdge# show interfaces vlan
unit 0 {
family inet {
address 10.0.1.2/24;
}
family inet6 {
address 2005:A704:C163::1/64;
}
}
[edit]
root@SRXEdge# show interfaces vlan | display set
set interfaces vlan unit 0 family inet address 10.0.1.2/24
set interfaces vlan unit 0 family inet6 address 2005:A704:C163::1/64
[edit]
root@SRXEdge#As seen here, configuring an IP address is fairly straightforward. To do so, you must first specify the unit, then the family, then the address that you would like applied. The command words unit, family, and address are used when specifying the configuration. These words are in bold in the preceding example.
Most administrators typically only utilize unit 0. The number doesn’t particularly matter. The best practice is to use zero unless you are defining a VLAN tag to that unit. If a tag is defined, then chose a unit number that matches the tag number. The one thing that you do not want to do is randomly choose unit numbers on each interface. Keep some sort of theme or organization to the unit number. Doing so will make it much easier for the next person who has to look at the configuration.
When using units, there are some command-line tricks that you need to be aware of. It is possible to identify a unit using two methods. Both are displayed here.
[edit] root@SRXEdge# set interfacesvlan unit 0[edit] root@SRXEdge# set interfacesvlan.0
In this example, using the word unit or the optional period joining the interface name and the unit number specified the unit configuration. The majority of the time the period is used, as it saves three characters of typing and it is also how interfaces are displayed in the operational configuration. The best practice is to use the period; when you keep typing interface configurations, you will be happy that you saved those three characters.
Although there is a lot that you can configure on a unit, the specific configurations are discussed in their appropriate sections and chapters. For now, you should be able to configure an IP address, which is what is required.
Switching Configuration
On the branch SRX Series (see Chapter 1), most Ethernet interfaces support the ability to do switching. The switching capabilities in the branch SRX Series are inherited from Juniper Networks’ EX Series Ethernet Switches, so the functionality and configuration are nearly identical.
The most common configuration type is an access port. An access port is a port that does not accept VLAN tagged packets, but rather tags the packets internally to the switch. It will also allow the packet to exit as a tagged packet on a trunk port. (A VLAN must be assigned to an interface even if the traffic will never exit the device as a packet tagged with the VLAN. In cases such as these, the actual VLAN tag used is irrelevant.)
[edit interfaces ge-0/0/2.0] root@JunosBook#set family ethernet-switching[edit interfaces ge-0/0/2.0] root@JunosBook#set family ethernet-switching port-mode access[edit interfaces ge-0/0/2.0] root@JunosBook#showunit 0 { family ethernet-switching { port-mode access; vlan { members 100; } } } [edit interfaces ge-0/0/2.0] root@JunosBook#
Here, ethernet-switching was
added as a family (remember that a family represents a protocol suite,
and in this case it represents switching). The port was set to access mode, which internally tags the packet
after it enters the port. It is tagged with VLAN 100, as that is what is
configured under the vlan stanza. An
access port can only have a single VLAN configured. When configuring a
VLAN, it can be specified with the tag number or a configured VLAN name.
We discuss VLAN configuration later in this section.
Most of the branch SRX Series devices have several ports that you
can configure for switching. In some cases, up to 24 sequential ports
can be used for switching. Instead of having to configure all of the
ports by hand, it’s possible to use the interface range command. This configuration
allows you to select several ports and then apply the same commands
across all of the interfaces.
[edit interfaces]
root@JunosBook# show
interface-range interfaces-trust {
member ge-0/0/1;
member fe-0/0/2;
member fe-0/0/3;
member fe-0/0/4;
member fe-0/0/5;
member fe-0/0/7;
unit 0 {
family ethernet-switching {
vlan {
port-mode access;
members 100;
}
}
}
}An interface range must be given a unique name, and then one or more interfaces can be added as members of the range. At this point, any configuration option that can normally be added to an interface can be added here. Because of this, the use of interface ranges is not just limited to switching. For example, unit 0 was created with Ethernet switching and VLAN 100. On commit, all interfaces have the same configuration applied to them.
Up to this point, all VLANs have been used with just a number tag. It is also possible to create VLANs and give them a name that allows for easier management and identification in the configuration. You can use the VLAN name instead of the tag name anywhere in the configuration.
[edit vlans]
root@JunosBook# show
vlan-trust {
vlan-id 100;
interface {
fe-0/0/6.0;
}
l3-interface vlan.0;
}
[edit vlans]
root@JunosBook#Each VLAN is given a custom name. This name must be unique and must not overlap with any other existing VLAN name. You also must assign a VLAN ID to the VLAN. You can configure several other options under a VLAN, the most common of which concern the direct configuration of interfaces. Previously, when Ethernet switching was configured on each interface, a VLAN had to be configured. In this configuration example, the VLAN can be configured from one central location directly under the VLAN. Either option is valid; the usage is based on personal preference.
The other common option is the use of a VLAN interface. A VLAN interface allows for the termination of traffic that can then be routed out another interface on the device. The VLAN interface is accessible from any port that is a member of that VLAN. The interface is configured just like any other interface type.
[edit] root@JunosBook#edit interfaces[edit interfaces] root@JunosBook#set vlan.0 family inet address 1.2.3.4/24[edit interfaces] root@JunosBook#edit interfaces[edit interfaces] root@JunosBook#show vlanunit 0 { family inet { address 1.2.3.4/24; } } [edit interfaces] root@JunosBook#
A trunk port is a port that has two or more VLANs configured on it, and traffic entering a trunk port must be tagged with a VLAN tag. A trunk port is typically used when connecting the SRX to another switch.
[edit] root@JunosBook#edit interfaces[edit interfaces] root@JunosBook#set ge-0/0/2.0 family ethernet-switching port-mode trunk[edit interfaces] root@JunosBook#set ge-0/0/2.0 family ethernet-switching vlan members 200[edit interfaces] root@JunosBook#show ge-0/0/2.0family ethernet-switching { port-mode trunk; vlan { members [ 100 200 ]; } } [edit interfaces] root@JunosBook#
As you can see, the configuration here is very similar to an access port. The differences are minor, as the port mode is configured as a trunk and multiple VLAN members are added to the port. Traffic entering the port must be tagged and must match the VLANs configured on the port.
Aggregate Interfaces
On most SRX platforms, it is possible to configure aggregate Ethernet interfaces. These interfaces are special, as they allow the addition of multiple Ethernet ports to the same logical interface. The most common use case for this is as a redundant Ethernet interface (reth). This is a special type of interface that is used in high availability clusters. This is covered fully in Chapter 7. However, another interface that is used in standalone devices is the ae interface.
Configuring an ae interface is easy. The biggest challenge is that it needs to be connected to either another aggregate interface or to a special switch. These interfaces are used when you want to offer additional bandwidth to an interface beyond what it can handle as a single interface.
To configure an aggregate interface, you must first activate these interfaces by specifying how many aggregate interfaces you want active. An example of this is shown here.
[edit]
root@SRXEdge# set chassis aggregated-devices ethernet device-count 2
root@SRXEdge# show | compare
[edit]
+ chassis {
+ aggregated-devices {
+ ethernet {
+ device-count 2;
+ }
+ }
+ }To see how the command was applied, we issued show | compare. This shows the changes made to
the configuration. As can be seen in the previous example, the aggregated devices are specified under the
chassis hierarchy. Think about this as if we are inserting a virtual
card into the chassis. Once this configuration is committed, you will be
able to see the interfaces.
[edit] root@SRXEdge# run show interfaces terse | match ae ae0 up down ae1 up down [edit] root@SRXEdge#
To show the interfaces from configuration mode, we issued
run. This says “run this operational
command from configuration mode.” It is very convenient, as you need to
check your work. We then took the output of the interfaces command and
passed it to match, looking specifically for the string
ae. This interface type is known as aggregate
Ethernet. The ae interface can represent any type of Ethernet interface
so the media does not matter. You cannot mix media types when
aggregating interfaces on the SRX; they must be the same type.
Now you must add in which interfaces will be members of the aggregate device. This is done under the physical interfaces themselves under the ether-options, which relates to some of the advanced physical characteristics of the interfaces.
[edit]
root@SRXEdge# set interfaces fe-0/0/6 fastether-options 802.3ad ae0
[edit]
root@SRXEdge# set interfaces fe-0/0/7 fastether-options 802.3ad ae0
[edit]
root@SRXEdge# show | compare
[edit interfaces]
+ fe-0/0/6 {
+ fastether-options {
+ 802.3ad ae0;
+ }
+ }
+ fe-0/0/7 {
+ fastether-options {
+ 802.3ad ae0;
+ }
+ }As can be seen in the previous code example, the parent they belong to was specified under the 802.3ad hierarchy. The number 802.3ad represents the IEEE standard for aggregate interfaces. Feel free to look it up if you would like to know more about the specification. Now that the child links are configured, we can specify an IP address on our newly created aggregate interface.
[edit]
root@SRXEdge# set interfaces ae0.0 family inet6 address 2002:1234::1/64
[edit]
root@SRXEdge# show | compare
[edit interfaces]
+ fe-0/0/6 {
+ fastether-options {
+ 802.3ad ae0;
+ }
+ }
+ fe-0/0/7 {
+ fastether-options {
+ 802.3ad ae0;
+ }
+ }
+ ae0 {
+ unit 0 {
+ family inet {
+ address 2.3.4.5/24;
+ }
+ family inet6 {
+ address 2002:1234::1/64;
+ }
+ }
+ }
[edit]
root@SRXEdge# commit
commit complete
[edit]
root@SRXEdge# run show interfaces ae0 terse
Interface Admin Link Proto Local Remote
ae0 up up
ae0.0 up up inet 2.3.4.5/24
inet6 2002:1234::1/64
fe80::2e6b:f5ff:fe02:82c0/64
[edit]
root@SRXEdge#As we can see, once committed, the ae0.0 interface shows up as any other interface would be displayed.
LACP protocol
Although bundled links are fantastic, as they give you additional bandwidth, they are quite dumb. By default, aggregate interfaces do not negotiate to the other side of the physical link. They just assume that the other side of the link is up and that everything will be fine. As we all know, this is never the case in a network. To help with this, a protocol can be configured over the links called Link Aggregation Control Protocol (LACP). At the time of the writing of this book, LACP is only supported in Level 3 mode and not in Level 2 or transparent mode. Please check the Juniper support site for the latest updates and notes.
LACP offers a few important features, the first being link detection. LACP can detect that not only the link is up, but that the other side is active. There might be a Layer 1 switch (a switch that handles physical cabling connectivity) in between the two devices that has an error, or the other device might have some sort of issue. Second, LACP confirms that the other side can correctly handle the aggregate interfaces. The best practice is to use LACP when available. In an LACP configuration, one side should be configured as passive and the other as active. This sets the SRX to passively receive LACP messages. For the branch SRX, due to the small CPUs in the device, it is suggested to set the mode to slow.
[edit interfaces ae0 aggregated-ether-options]
root@SRXEdge# set minimum-links 1
[edit interfaces ae0 aggregated-ether-options lacp]
root@SRXEdge# set periodic slow
[edit interfaces ae0 aggregated-ether-options lacp]
root@SRXEdge# set passive
[edit interfaces ae0 aggregated-ether-options]
root@SRXEdge# show
minimum-links 1;
lacp {
passive;
periodic slow;
link-protection;
}Once configured, it is fairly easy to check the status of your LACP links. 187
root@SRXEdge> show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity fe-0/0/6 Actor No No Yes Yes Yes Yes Slow Active fe-0/0/6 Partner No No Yes Yes Yes Yes Slow Passive fe-0/0/7 Actor No No Yes Yes Yes Yes Slow Active ge-0/0/7 Partner No No Yes Yes Yes Yes Slow Passive LACP protocol: Receive State Transmit State Mux State fe-0/0/6 Current Slow periodic Collecting distributing fe-0/0/7 Current Slow periodic Collecting distributing root@EX2200-C1>
Transparent Interfaces
By default, an SRX operates in what is known as routing or Layer 3 mode. This means that the device forwards packets based on their destination IP address. This is how the majority of SRX devices are deployed. However, there are times when implementing a firewall in this mode is not possible. An example would be if the network routing configuration were unable to be altered. This could be due to lack of IP addresses or the need to keep security implemented as a separate domain.
Whatever the reason might be, the SRX offers a feature called transparent mode. Transparent mode forwards packets based on their destination MAC address rather than their IP. However, the device still allows the user to block or allow hosts based on the same IP-based policies that are available in the routing mode. For complete information on how to utilize transparent mode, please see Chapter 6.
Configuring transparent mode interfaces is one step in the transparent mode configuration process. To do so is actually quite similar to how we configured an interface with an IP address. To enable a transparent mode interface, we would use the family bridge as opposed to family inet or inet6. We also need to specify a VLAN ID that binds the interface into a Layer 2 bridge domain. Think of this as placing the interface into a specific broadcast domain. Doing so limits the scope of which hosts can see each other.
root# show interfaces
fe-0/0/2 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 10;
}
}
}
[edit]
root# show interfaces | display set
set interfaces fe-0/0/2 unit 0 family bridge interface-mode access
set interfaces fe-0/0/2 unit 0 family bridge vlan-id 10
[edit]
root#If you are initially configuring transparent mode, a reboot is required after the configuration is committed. This will load the appropriate image on the data plane to forward based on MAC addresses as opposed to IP.
root# commit check warning: Interfaces are changed from route mode to transparent mode. Please reboot the device or all nodes in the HA cluster! configuration check succeeds
Zones
A zone is a logical construct that is applied to an interface and is used as a building block for security policies on the SRX Series Services Gateways and the Juniper Networks J Series Services Routers. The concept of the zone originated on the ScreenOS platform from NetScreen Technologies. When creating a security policy, the idea is to allow traffic from a source to go to a destination. The zone adds another dimension to that by allowing for the concept of a source zone and a destination zone. This was very different from all of the existing firewall products of the time. The division of a security policy base into multiple smaller policy sets, or contexts, enhanced performance and simplified management.
Security Zones
Creating a security zone is simple, as the minimum
requirement is just a name. In the past, on NetScreen products, there
was a concept of having prenamed zones called
Trust, Untrust, and
DMZ. These zone names were always left in place
because the original ScreenOS devices actually used these as the
interface names. Juniper has moved away from having the default names,
and now allows users to name the zones whatever they want. Security
zones are located under the security
zones stanza.
[edit security zones]
root@SRX210-A# show
security-zone SuperZone {
interfaces {
ge-0/0/0.0;
}
}
[edit security zones]
root@SRX210-A#Security zones offer little to no value without the addition of
interfaces. In the example shown here, the ge-0/0/0.0 interface is added
to the new zone named SuperZone. The
zone is now ready to be used in various security policies.
At least one interface must be bound in a zone to be able to use it to create security policies. Multiple interfaces can be added to a zone as well, and this might be helpful, depending on the goal of the network design. An interface can only be a member of one zone at a time. Logical interfaces are added to a zone, so it’s possible to have multiple logical interfaces that are members of the same physical interface be members of multiple zones.
Functional Zones
Functional zones are a logical entity that is applied to the interface to enable it to have a special function. Interfaces that are a member of a functional zone cannot be used in a security zone. On the SRX, the only functional zone available at the time this book was written was the management zone. Adding an interface into the management zone allows the interface to be used for out-of-band management, a helpful tool for devices such as the branch SRX Series devices, which do not have a dedicated interface for management.
[edit security zones] root@JunosBook#set functional-zone management interfaces fe-0/0/6.0[edit security zones] root@JunosBook#edit functional-zone management[edit security zones functional-zone management] root@JunosBook#showinterfaces { fe-0/0/6.0; } host-inbound-traffic { system-services { all; } } [edit security zones functional-zone management] root@JunosBook#
Adding an interface to a functional zone is the same as
using a security zone. A new element shown in this configuration is
host inbound traffic. The host inbound traffic stanza can be configured
under any zone, and it allows for the acceptance of two different types
of traffic to the SRX itself. If the host inbound traffic is not
configured, traffic will not be accepted. This is different from
creating a security policy, as a security policy is only for transit
traffic and not for traffic terminating on the device.
root@JunosBook#set host-inbound-traffic system-services ?Possible completions: all All system services any-service Enable services on entire port range dns DNS and DNS-proxy service finger Finger service ftp FTP http Web management service using HTTP https Web management service using HTTP secured by SSL ident-reset Send back TCP RST to IDENT request for port 113 ike Internet Key Exchange lsping Label Switched Path ping service netconf NETCONF service ntp Network Time Protocol service ping Internet Control Message Protocol echo requests reverse-ssh Reverse SSH service reverse-telnet Reverse telnet service rlogin Rlogin service rpm Real-time performance monitoring rsh Rsh service sip Enable Session Initiation Protocol service snmp Simple Network Management Protocol service snmp-trap Simple Network Management Protocol traps ssh SSH service telnet Telnet service tftp TFTP traceroute Traceroute service xnm-clear-text JUNOScript API for unencrypted traffic over TCP xnm-ssl JUNOScript API service over SSL [edit security zones functional-zone management] root@JunosBook#set host-inbound-traffic protocols ?Possible completions: all All protocols bfd Bidirectional Forwarding Detection bgp Border Gateway Protocol dvmrp Distance Vector Multicast Routing Protocol igmp Internet Group Management Protocol ldp Label Distribution Protocol msdp Multicast Source Discovery Protocol ndp Enable Network Discovery Protocol nhrp Next Hop Resolution Protocol ospf Open Shortest Path First ospf3 Open Shortest Path First version 3 pgm Pragmatic General Multicast pim Protocol Independent Multicast rip Routing Information Protocol ripng Routing Information Protocol next generation router-discovery Router Discovery rsvp Resource Reservation Protocol sap Session Announcement Protocol vrrp Virtual Router Redundancy Protocol [edit security zones functional-zone management] root@JunosBook#set host-inbound-traffic protocols
The first type of host inbound traffic is called
system services. System services traffic is related
to any service that is used for management on the SRX. This includes
SSH, Telnet, and DNS. The other type of host inbound traffic is
protocols. These are routing protocols or other
protocols that are used for communicating with other network devices.
Each individual service can be turned on, or all of them can be turned
on using the all flag.
Note
Given that an SRX is most often deployed as a security device, it’s best practice to reduce the total number of host inbound protocols.
Host inbound traffic can also be enabled on a per-interface basis. This is a good idea when multiple interfaces are in a zone. Also, some protocols such as DHCP can only be enabled on a single interface and not on a per-zone basis. DHCP will not be allowed unless specifically enabled under the interface.
root@host#set interfaces fe-0/0/6.0 host-inbound-traffic system-services dhcp[edit security zones functional-zone management] root@JunosBook#showinterfaces { fe-0/0/6.0 { host-inbound-traffic { system-services { dhcp; } } } } host-inbound-traffic { system-services { all; } } [edit security zones functional-zone management] root@JunosBook#
Basic Protocols
Routing protocol support and stability are key features of the Junos OS. The SRX, being a member of the Junos family, supports most of the protocols that are supported on the highest end routers. In practice, however, most customers do not use these features on the SRX. Because of this, we are only skimming the surface of what is possible on Junos. Books can easily be dedicated to just advanced routing policies without even covering the protocols. There are several other books that go over many of these routing features in the Juniper Networks Technical Library books published by O’Reilly Media, and because of this they are not covered in great depth here. Where applicable, the use of the protocols is discussed in their various sections.
With that said, there are some routing fundamentals that are important to understand. In Junos, any method that can place a route in the routing table is considered a protocol. This includes static routing. Although it might seem strange to think of static routes as being protocols in Junos, they are considered as such. When configuring routing policies, a construct similar to firewall policies but applicable to route manipulation, static routes are referred to as protocol static.
Static Routing
Static routes are routes that are statically defined and are not manipulated by external protocols. The only way a static route can disappear is if the associated interface has disappeared. Other than that, once a static route is configured, it isn’t going anywhere. Most commonly in an SRX, only static routing is used. One of the biggest reasons is to lower the scope of potential attack against the device. Keen administrators are always worried about the potential to exploit a key system. Juniper Networks spends a good deal of time hardening its routing services, but even a window with metal bars on it is still a window that can draw attention. Later in this section, we review more about best practices on when to use dynamic routing.
Configuring a static route is simple. It requires knowing what network you want to route to and what the next hop would be. The following are a few examples of static routes. The options that are variables are bolded. How to correctly select these items will be discussed next.
[edit routing-options]
root@SRXEdge# show
rib inet6.0 {
static {
route ::/0 next-hop 2004:4170:1c04:634::1;
}
}
static {
route 0.0.0.0/0 next-hop 59.12.52.174;
}
[edit routing-options]
root@SRXEdge# show | display set
set routing-options rib inet6.0 static route ::/0 next-hop 2004:4170:1c04:634::1
set routing-options static route 0.0.0.0/0 next-hop 59.12.52.174
[edit routing-options]
root@SRXEdge#Static routes are added into the routing-options hierarchy. As shown by the
previous set commands, first we specify that the route is static then we
use the keywords route and next-hop to specify the two options. For
route, we assign the prefix that we
want to assign as the destination. For next-hop, we simply specify where the prefix
will be sent. This is a bit more verbose than some devices, but Junos is
designed for extensibility that leads to more detailed commands. In our
example, we saw that the next hop was specified as an IP address. In
some cases, such as an IPsec VPN, you can also specify an interface as
the next hop. The best practice is to utilize an IP address, as that is
most relatable to the next person that would need to read the
configuration.
Configuring IPv6 routes is a bit different, as it includes one additional option to the command. For IPv6, not only do we need to specify the prefix and the next hop but we also need to specify the rib or routing information base. For IPv4 the static route, the rib does not need to be explicitly specified. But what exactly is a rib? A rib is nothing more than the formal term for a routing table or a collection of routes. Each protocol has at least one rib, but they could potentially have more if needed. Other protocols such as multiprotocol label switching also have their own rib.
When Junos was originally built, it only contained support for IPv4, and hence the static routing command is a bit focused on that protocol. Because Junos is designed to maintain backward compatibility for the configuration, there are some commands that might seem out of place, but that is due to the fact the command is quite old. As you can imagine, static routes would need to be Junos 1.0 supported features.
The naming convention when specifying a rib is family.rib number. Rib numbering always starts at zero. For IPv6, inet6 is specified as the family. For comparison, IPv4 would be represented as just inet. For the majority of deployments, only a single routing table is needed per routing instance, but there are some cases where an extremely complex routing design is needed. Junos is happy to accommodate both the simple and complex use cases. Some designs that are currently deployed use thousands of routing instances and a dozen or more tables per instance.
There are many options that are available when configuring a static route. The following are the standard options. The specific configuration items that might be of interest to an administrator are shown in bold and are discussed next.
[edit routing-options] root@SRXEdge# set static route 0/0 ? Possible completions: active Remove inactive route from forwarding table + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > as-path Autonomous system path backup-pe-group Multicast source redundancy group > bfd-liveness-detection Bidirectional Forwarding Detection (BFD) options > color Color (preference) value > color2 Color (preference) value 2 + community BGP community identifier discard Drop packets to destination; send no ICMP unreachables install Install route into forwarding table > lsp-next-hop LSP next hop >metric Metric value> metric2 Metric value 2 > metric3 Metric value 3 > metric4 Metric value 4 +next-hop Next hop to destinationnext-table Next hop to another tableno-install Don't install route into forwarding table no-readvertise Don't mark route as eligible to be readvertised no-resolve Don't allow resolution of indirectly connected next hops no-retain Don't always keep route in forwarding table > p2mp-lsp-next-hop Point-to-multipoint LSP next hop passive Retain inactive route in forwarding table >preference Preference value> preference2 Preference value 2 > qualified-next-hop Next hop with qualifiers readvertise Mark route as eligible to be readvertised receive Install a receive route for the destinationreject Drop packets to destination; send ICMP unreachablesresolve Allow resolution of indirectly connected next hops retain Always keep route in forwarding table > static-lsp-next-hop Static LSP next hop > tag Tag string > tag2 Tag string 2 [edit routing-options] root@SRXEdge#
For static routing, next-hop is the most commonly used option. However, there are a few other options that are helpful when dealing with static routing. The first two would be both metric and preference. Metric and preference are used in selecting which route is active. The routing process is a decision tree for which path should be selected to send the traffic out. Preferences are applied to each routing protocol, and then metrics are applied to routes within that protocol. Think of a preference as “How much do I trust the information provided by this protocol?” Table 4-4 shows the various default protocol preferences. The lower the preference value, the more trusted the route is.
Preference | Protocol |
0 | Direct connection |
1 | NAT Proxy-ARP routes |
4 | System routes |
5 | Static routes and Static LSPs |
7 | RSVP-signaled LSPs |
9 | LDP-signaled LSPs |
10 | OSPF internal route |
15 | IS-IS Level 1 internal route |
18 | IS-IS Level 2 internal route |
30 | Redirects |
40 | Kernel |
50 | SNMP |
55 | Router Discovery |
100 | RIP |
100 | RIPng (RIP for IPv6) |
105 | PIM |
110 | DVMRP |
130 | Aggregate |
150 | OSPF AS external routes |
160 | IS-IS Level 1 external route |
165 | IS-IS Level 1 external route |
170 | BGP |
175 | MSDP |
As you can see, there are many different routing protocols that can be used on Junos. The protocol preferences for directly connected routes, system routes, and static routes are the lowest (lower being better in selection, with an example shown in Figure 4-1) as they are the most trusted. A directly connected route is automatically created for any configured interfaces. This way, the router can determine how to access which networks it is already a part of. It has the lowest or best preference as it is connected to the device and it does not need to go through a separate hop. Next up are proxy-arp routes and system routes. These are directly added by Junos and are not configured directly by the administrator. The last route preference to discuss is back to static routes, which is set at a preference of five. The majority of the remaining routes are from various dynamic routing protocols. If need be, on a static route, it is possible to set the preference. This is typically not needed, but it is available if you choose to do so.
When we looked at ribs, we saw that it was possible to create more than one routing table. With this, we can also point a route to continue being resolved at the next table. This will force Junos to look at another table for resolution. When Junos does a route lookup, it does it in one single pass. This pass might involve looking at multiple tables to determine where to send the packet, but it will continue to follow the links until it gets to the final destination. In the next section, we review routing instances and how this comes into play there.
Finally, options that are commonly used are the reject and discard options. These options are used to drop the packet as opposed to forwarding them. They both accomplish the same goal, but reject is used to notify the host sending the packet with an ICMP message that the packet has been dropped. Discard will silently discard the packet, and it will not notify the origin router. If you are looking to drop packets, this is a fairly efficient method. The best practice would be to use the discard method on an SRX. This will prevent an attacker from trying to launch timing attacks to get the device to overload itself by sending ICMP rejects. Although that scenario is unlikely, the Internet can be a dirty place, and lowering the scope of what can be done against you is ideal.
When troubleshooting routing, it is fairly easy to see
what would happen to a particular packet. Using the operational command
show route <destination>, you
can specify what the destination host or network is and Junos will tell
you what route it is choosing.
root@SRXEdge> show route 1.2.3.4
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 1d 18:02:57
> to 52.85.92.14 via fe-0/0/0.0
root@SRXEdge> show route 10.0.2.10
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.2.0/24 *[OSPF/10] 1d 18:03:51, metric 2
> to 10.0.1.254 via vlan.0
root@SRXEdge>Here we checked two different routes. First, we looked at the destination 1.2.3.4, which was resolved, the default route of 0.0.0.0/0. Second, we looked at an internal network host, 10.0.2.10, that was found at another upstream routing device via Open Shortest Path First (OSPF). Even in complex scenarios where Junos uses dozens of routing tables, this command will show you what will happen. When showing the route table, Junos will print some metrics, such as how many destinations are available, the total number of routes, and how many are active. It will also tag which route is active. Let’s take a look at this in more detail.
root@SRXEdge> show route inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0*[Static/5] 1d 18:08:58>to 70.96.53.14 via fe-0/0/0.0 10.0.1.0/24 *[Direct/0] 1d 18:08:58 > via vlan.0 10.0.1.2/32 *[Local/0] 3d 17:14:26 Local via vlan.0 10.0.2.0/24 *[OSPF/10] 1d 18:08:50, metric 2 > to 10.0.1.254 via vlan.0
At the top of the output, we can see some basic statistics about the routing table. The other important elements to look at on a route are the identifier for what route is active. The *, +, and − characters show this. The last active route is shown by either * or +. The * shows that the route is both active and was the last active route. The previously active route is shown with the −. When there is more than one route to the same destination, they will be shown as follows, with the active route marker showing which route is used.
{primary:node0}
root@SRX-HA-0> show route table traffic.inet.0
traffic.inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:23:39
> to 10.0.1.2 via reth0.0
[OSPF/150] 1d 18:36:14, metric 0, tag 0
> to 10.0.1.2 via reth0.0Additional information on each route and why the route was selected can be seen via the detail flag. This is helpful if you aren’t sure why a route was chosen.
root@SRX-HA-0> show route table traffic.inet.0 detail
traffic.inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
0.0.0.0/0 (2 entries, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 652
Address: 0x15d0b0c
Next-hop reference count: 5
Next hop: 10.0.1.2 via reth0.0, selected
State: <Active Int Ext>
Age: 26:20
Task: RT
Announcement bits (2): 0-KRT 2-Resolve tree 1
AS path: I
OSPF Preference: 150
Next hop type: Router, Next hop index: 652
Address: 0x15d0b0c
Next-hop reference count: 5
Next hop: 10.0.1.2 via reth0.0, selected
State: <Int Ext>
Inactive reason: Route Preference
Age: 1d 18:38:55 Metric: 0 Tag: 0
Task: traffic-OSPF
AS path: IFinally, to close out this topic, Figure 4-1 is a simple reference chart that you can use to help determine why a route was chosen.
Dynamic Routing Protocols
SRX devices support a significant amount of dynamic routing protocols. This is uncharacteristic of a security device. However, the SRX inherits them from the Junos OS and its other sibling devices, such as the MX and M Series devices. This allows the SRX to be deployed in locations where other firewall products might not be able to interoperate with the surrounding networking devices. The following is an example of the routing protocol support that is offered on some SRX devices.
{primary:node0}[edit protocols]
root@SRX-HA-0# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> bfd Bidirectional Forwarding Detection (BFD) options
> bgp BGP options
> connections Circuit cross-connect configuration
> dot1x 802.1X options
> dvmrp DVMRP options
> esis End system-intermediate system options
> gvrp GVRP configuration
> iccp ICCP options
> igmp IGMP options
> isis IS-IS options
> l2-learning Layer 2 forwarding configuration
> l2circuit Configuration for Layer 2 circuits over MPLS
> l2iw Configuration for Layer 2 interworking
> lacp Link Aggregation Control Protocol configuration
> ldp LDP options
> lldp Link Layer Detection Protocol
> lldp-med LLDP Media Endpoint Discovery
> mld MLD options
> mpls Multiprotocol Label Switching options
> msdp MSDP configuration
> mstp Multiple Spanning Tree Protocol options
> neighbor-discovery IPv6 neighbor discovery
> oam Operation, Administration, and Management configuration
> ospf OSPF configuration
> ospf3 OSPFv3 configuration
> pgm PGM options
> pim PIM configuration
> ppp Configure PPP process
> pppoe Configure PPPoE process
> protection-group Protection group
> r2cp Radio-to-Router Control Protocol configuration
> rip RIP options
> ripng RIPng options
> router-advertisement IPv6 router advertisement options
> router-discovery ICMP router discovery options
> rstp Rapid Spanning Tree Protocol options
> rsvp RSVP options
> sap Session Advertisement Protocol options
> stp Spanning Tree Protocol options
> vrrp VRRP options
{primary:node0}[edit protocols]
root@SRX-HA-0#In the preceding output, the most commonly used protocols are shown in bold. Many routing protocols, such as OSPF or RIP, were originally designed with only IPv4 in mind. To be able to utilize IPv6, some protocols were modified and released as new versions. Examples of this are RIPng (IPv6 RIP) and OSPFv3. The routing protocol IS-IS has made something of a comeback in the last five years.
IS-IS natively supports IPv4 and IPv6. It is also very friendly when utilizing MPLS VPNs, as it is able to share additional information about MPLS through the protocol. The other benefit of IS-IS is that it does not run over IP. IS-IS operates using the ISO Connectionless Network Protocol (CNLS). In a security setting, this can be advantageous because few people understand this protocol or even have access to it. If an attacker is unable to talk to your device, then he will be unable to attack it. IS-IS is very similar in design to OSPF as both protocols are link-state based.
As discussed several times in this chapter, the goal of this book is to focus on the security aspects of the SRX, and because of this, we have chosen to point you to other Junos books or the Junos documentation when you need to use dynamic routing.
Spanning Tree
Because a switched network is completely flat and the paths to devices are determined by the learning of MAC addresses on switch ports, as a switch learns MAC addresses, it creates a tree or path for which MAC address can be found on which ports. The following is an example of looking at the MAC table on an SRX. This feature is only supported on the branch SRX. Transparent mode, which is supported on both branch and the data center SRX, will forward the spanning tree protocol but not participate in it.
root@SRXEdge> show ethernet-switching table Ethernet-switching table: 13 entries, 11 learned, 0 persistent entries VLAN MAC address Type Age Interfaces Vlan10 * Flood - All-members Vlan10 00:0c:29:9d:b3:86 Learn 0 fe-0/0/3.0 Vlan10 00:10:db:ff:10:00 Learn 0 fe-0/0/3.0 Vlan10 00:18:7d:1f:71:4a Learn 0 fe-0/0/3.0 Vlan10 00:18:7d:24:4a:aa Learn 0 fe-0/0/3.0 Vlan10 2c:6b:f5:02:82:88 Static - Router Vlan10 58:6d:8f:2e:c2:ee Learn 0 fe-0/0/1.0 Vlan10 5c:59:48:30:fc:96 Learn 0 fe-0/0/1.0 Vlan10 78:e7:d1:f1:e3:24 Learn 0 fe-0/0/3.0 Vlan10 78:fe:3d:e6:c1:81 Learn 0 fe-0/0/3.0 Vlan10 78:fe:3d:e6:c6:01 Learn 0 fe-0/0/3.0 Vlan10 7c:6d:62:d3:a7:5e Learn 0 fe-0/0/1.0 Vlan10 e0:cb:4e:97:67:a7 Learn 0 fe-0/0/3.0 root@SRXEdge>
This command was run from operational mode and it shows the location for all of the MAC addresses that it knows about. So what happens if a switch learns the location of a MAC on two different ports? This enters your network into a world of pain, as you now have a Layer 2 loop. A loop means that the switches will continuously forward packets in a loop (see Figure 4-2). In a routed network, this behavior would be stopped with the decrementing of the TTL on a packet. In a Layer 2 network, the packets would loop infinitely.
To solve this problem, the spanning tree protocol was invented. Spanning tree sends small messages out from its ports to calculate the topology of the switched network (see Figure 4-3). These messages are called Bridge Protocol Data Units (BDPUs). The switches work together to calculate a single path throughout the network to ensure there are no loops. It is essential to use a loop mitigation technology when using switching on an SRX. Spanning tree is the most popular in use today, but there are a few new ideas coming up the ranks to try and remove spanning tree. Spanning tree can be painful in large networks as miscalculations or misconfigurations can lead to headaches.
There are several different types of spanning tree implementations. The most commonly used on a branch SRX device is called Multiple Spanning Tree Protocol (MSTP). This protocol uses a few different technologies to enhance the original spanning tree protocol. First, it implements the same capabilities of Rapid Spanning Tree Protocol (RSTP). RSTP offers several new port roles to speed up the convergence following a link failure. RSTP and MSTP are compatible with each other. MSTP also brings another important feature to the table: it allows the creation of a spanning tree per VLAN groups. This means that if you are utilizing many different VLANs, it can provide a tree for each group of VLANs. Figure 4-4 is an example of an MSTP topology.
The basics of enabling MSTP are simple, but mastering all of the various options can be quite detailed. As this book is focused on security, we only focus on what is needed to get you up and running. Later you will find more information about MSTP and other spanning tree configurations.
root@SRXEdge# show
interface fe-0/0/1.0 {
edge;
}
interface fe-0/0/2.0 {
edge;
}
interface fe-0/0/3.0 {
edge;
}
interface fe-0/0/4.0 {
edge;
}
interface fe-0/0/5.0 {
edge;
}
interface fe-0/0/6.0 {
edge;
}
interface fe-0/0/7.0 {
edge;
}
[edit protocols mstp]
root@SRXEdge# show | display set
set protocols mstp interface fe-0/0/1.0 edge
set protocols mstp interface fe-0/0/2.0 edge
set protocols mstp interface fe-0/0/3.0 edge
set protocols mstp interface fe-0/0/4.0 edge
set protocols mstp interface fe-0/0/5.0 edge
set protocols mstp interface fe-0/0/6.0 edge
set protocols mstp interface fe-0/0/7.0 edge
[edit protocols mstp]
root@SRXEdge#This configuration specifies the interfaces on which to enable MSTP and in which mode to operate. These are configured as an edge port, as no other bridges or switches are attached. If another switch is connected, it will be able to detect it. Alternatively, ports can be configured in point-to-point mode or shared mode if you will be connecting these ports to other switches. Point-to-point specifies that the port is connected to another switch, and shared specifies that the port is on a shared switch port.
To see the status of ports, you can use the spanning-tree operational commands to identify the ports’ statuses. This will show you which ports are in forwarding mode or if they are being blocked (BLK) in the event that a potential loop is detected.
root@SRXEdge> show spanning-tree interface
Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
fe-0/0/1.0 128:514 128:514 32768.2c6bf5028288 200000 FWD DESG
fe-0/0/3.0 128:516 128:516 32768.2c6bf5028288 200000 FWD DESG
root@SRXEdge>Here is another example of a spanning tree output shown from an EX-2200-C switch. These two devices are connected together in the same topology.
root@EX2200-C1> show spanning-tree interface
Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ae0.0 128:1 128:1 32768.78fe3de6c181 10000 FWD DESG
ge-0/0/0.0 128:513 128:516 32768.2c6bf5028288 200000 FWD ROOT
ge-0/0/1.0 128:514 128:514 32768.78fe3de6c181 20000 FWD DESG
ge-0/0/2.0 128:515 128:515 32768.78fe3de6c181 20000 FWD DESG
ge-0/0/5.0 128:518 128:518 32768.78fe3de6c181 20000 FWD DESG
ge-0/0/6.0 128:519 128:519 32768.78fe3de6c181 200000 FWD DESG
ge-0/0/8.0 128:521 128:521 32768.78fe3de6c181 200000 FWD DESG
ge-0/0/9.0 128:522 128:522 32768.78fe3de6c181 200000 FWD DESG
ge-0/0/10.0 128:523 128:523 32768.78fe3de6c181 200000 FWD DESG
ge-0/0/11.0 128:524 128:524 32768.78fe3de6c181 200000 FWD DESG
root@EX2200-C1>The SRX shares the same infrastructure of switching as the EX switch product line. Because of this, the branch SRX devices share a rich set of switching features that are beyond the scope of this book. If you want to learn more details about switching configuration options, see the book Junos Enterprise Switching by Harry Reynolds and Doug Marschke (O’Reilly).
Routing Instances
A routing instance in Junos is a collection of routing tables. Routing instances are also known as VRFs in Cisco’s parlance. They are used to give you additional segregation over routing designs. As we discussed earlier regarding the fxp0 interface, there can be different uses for routing instances. A best practice is to leave the fxp0 interface in the default instance (also called the master instance in some documentation) and then place the remaining traffic passing interfaces into their own routing instance. This will provide completely separate routing domains. You can even have routes that overlap in separate routing instances. Figure 4-5 provides a logical example of what this best practice would look like.
In many simple deployments, one default routing instance is used. However, it is becoming more common to utilize multiple routing instances. Besides separating the fxp0 from your data traffic, it also allows a simple form of network virtualization on the device. This is different from the administrative separation, which can be achieved using the logical system feature that is covered in its own chapter. In any network design, it is best to keep your design simple, as it will reduce the chances of error and potential security risks.
Routing Instance Types
A routing instance can offer a collection of various capabilities. In this chapter, the focus is on using the instance type of virtual router. A virtual router instance provides both routing tables and forwarding tables. In Junos, a VRF routing instance type is used for MPLS VPNs and it contains other routing tables for it. If you are not using MPLS-based VPNs, then the virtual router type is what you should utilize. Another type of domain that is discussed later in the book is the use of bridge domains. On an SRX, this is used in transparent mode designs where forwarding is done based on MAC addresses instead of routing by IP address.
Junos does support several other routing instance types, but these are intentionally left out of this book due to its focus on security rather than solely on networking features.
Configuring Routing Instances
Using routing instances is very easy. There are two steps to activating a routing instance. First, you would create the instance, give it a name, and then specify the instance type.
[edit routing-instances]
root@SRXEdge# show
traffic {
instance-type virtual-router;
}
root@SRXEdge# show | display set
set routing-instances traffic instance-type virtual-router
[edit routing-instances]
root@SRXEdge# run show route instance
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 22/0/0
inet6.0 10/0/0
__juniper_private1__ forwarding
__juniper_private1__.inet.0 7/0/0
__juniper_private2__ forwarding
__juniper_private2__.inet.0 0/0/1
__master.anon__ forwarding
traffic virtual-router
[edit routing-instances]
root@SRXEdge#sNow the routing instance is created, it has a name, and it exists, but it doesn’t serve a lot of purpose. To make the routing instance useful, you need to add interfaces. Once interfaces are added, then the routing instance becomes active.
primary:node1}[edit]
root@SRX-HA-1# show routing-instances
traffic {
instance-type virtual-router;
interface reth0.0;
interface reth1.0;
}
{primary:node1}[edit]
root@SRX-HA-1# run show route instance
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 5/0/0
__juniper_private1__ forwarding
__juniper_private1__.inet.0 9/0/0
__juniper_private2__ forwarding
__juniper_private2__.inet.0 0/0/1
__master.anon__ forwarding
traffic virtual-router
traffic.inet.0 8/0/0
traffic.inet6.0 9/0/0
{primary:node1}[edit]
root@SRX-HA-1# run show route
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 1w4d 20:50:28
> to 10.0.1.2 via fxp0.0
10.0.1.0/24 *[Direct/0] 1w4d 20:50:30
> via fxp0.0
[Direct/0] 1w4d 20:50:30
> via fxp0.0
10.0.1.252/32 *[Local/0] 1w4d 20:50:30
Local via fxp0.0
10.0.1.253/32 *[Local/0] 1w4d 20:50:30
Local via fxp0.0
10.0.2.0/24 *[Static/5] 1w4d 20:50:28
to table traffic.inet.0
traffic.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 1w4d 13:05:41, metric 0, tag 0
> to 10.0.1.2 via reth0.0
10.0.1.0/24 *[Direct/0] 1w4d 20:50:01
> via reth0.0
10.0.1.245/32 *[Static/1] 1w4d 20:50:25
Discard
10.0.1.250/32 *[Static/1] 1w4d 20:50:25
Discard
10.0.1.254/32 *[Local/0] 1w4d 20:50:30
Local via reth0.0
10.0.2.0/24 *[Direct/0] 1w4d 20:49:56
> via reth1.0
10.0.2.1/32 *[Local/0] 1w4d 20:50:30
Local via reth1.0
224.0.0.5/32 *[OSPF/10] 1w4d 20:50:32, metric 1
MultiRecv
traffic.inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::/0 *[OSPF3/150] 1w4d 13:05:44, metric 0, tag 0
> to fe80::2e6b:f5ff:fe02:8288 via reth0.0
2001:4910:8163::/55 *[Direct/0] 1w4d 20:50:01
> via reth0.0
2001:4910:8163::2/128
*[Local/0] 1w4d 20:50:29
Local via reth0.0
2001:4910:8163:200::/55
*[Direct/0] 1w4d 20:49:56
> via reth1.0
2001:4910:8163:200::1/128
*[Local/0] 1w4d 20:50:29
Local via reth1.0
fe80::/64 *[Direct/0] 1w4d 20:50:01
> via reth0.0
[Direct/0] 1w4d 20:49:56
> via reth1.0
fe80::210:dbff:feff:1000/128
*[Local/0] 1w4d 20:50:29
Local via reth0.0
fe80::210:dbff:feff:1001/128
*[Local/0] 1w4d 20:50:29
Local via reth1.0
ff02::5/128 *[OSPF3/10] 1w4d 20:50:32, metric 1
MultiRecv
{primary:node1}[edit]
root@SRX-HA-1#In this example, we can see that there are now routes in the routing instance traffic. We also can see that there are two separate tables. One table is for inet or IPv4 and the other for inet6 or IPv6. There are two separate tables, one for each protocol, but they are both separate and contained within the same routing instance. This means that IPv4 packets will not get routed from the IPv6 routing table. Figure 4-6 shows how this table is logically laid out.
Routing instances are a powerful feature in Junos. They allow the creation of potentially thousands of separate routing domains on a single device. In large-scale deployments, we have seen customers use a thousand or more instances. This provides clear separation for instances where you want to have multiple customers on the same device but you do not want them to be able to see each other. For the purposes of this book, we are keeping the topologies relatively simple and to what we see for an average deployment.
Flow Mode and Packet Mode
On an SRX, the default mode of operation is to process traffic in what is called flow mode. This mode treats all traffic statefully or it monitors the state of all communications. This is very typical for modern firewalls. In the past, there were several types of firewalls: packet based, proxy, and stateful. Because of their effective handling of traffic and their reasonable price/performance ratio, stateful firewalls are the most commonly deployed. As the stateful firewall evolved, it began to bring in features from the other firewall types. An example of this is SSL inspection. The SRX is capable of acting as a proxy to decrypt SSL traffic. In this case, the SRX has both stateful and proxy-based properties. Also as the next-generation firewall market continues to evolve, there is an inclusion of using IPS technologies within firewalling. Application Firewall (AppFW) uses IPS-like inspection to determine what the protocol is beyond the traditional port number. By using a combination of techniques, firewalls today are able to provide a huge amount of performance with deeper traffic inspection.
On the branch SRX product lines, any SRX with a three-digit product number, such as 100 or 650, is able to operate in what is also known as packet mode. In this mode of operation, the SRX is able to inspect packets individually and not as part of a flow. The reason for this is to allow the SRX to operate more as a traditional router for some specific services. Routers and switches almost always operate in packet mode. The SRX is able to provide some services such as MPLS, IPv6 inspection bypass, and IP encapsulation, that require the administrator to process this traffic in packet mode.
There are a few different ways to utilize packet mode based on the use case. The first thing to look at is the security forwarding options. Under this stanza, packet mode can be enabled for protocols device wide, meaning that any traffic matching this protocol family will be processed in the specified mode. Alternatively, it is possible to enable packet mode selectively using firewall filters.
[edit security forwarding-options] root@SRXEdge# set ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > family Security forwarding-options for family [edit security forwarding-options] root@SRXEdge# set family ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups >inet6Family IPv6 >isoFamily ISO >mplsFamily MPLS [edit security forwarding-options] root@SRXEdge# set family
Depending on the family, there are one or more options available. For this section, we focus on the inet6 or IPv6 family.
ot@SRXEdge# set mode ? Possible completions: drop Disable forwarding flow-based Enable flow-based forwarding packet-based Enable packet-based forwarding [edit security forwarding-options family inet6] root@SRXEdge#
For inet6, there are three options available: drop, flow-based, or packet-based. Enabling drop will drop any IPv6 traffic without the need for an explicit firewall policy. Choose one of the other two options if you would like to enable flow-based processing or packet-based processing of IPv6. The best practice, if you will be using IPv6, is to enable flow-based processing. Packet-based processing can be enabled via firewall filters selectively, and it is suggested that you use only selective processing. You would want to selectively enable packet processing in the event you wanted to do 6in4 IPv6 tunneling. Changing this option will require a reboot. It is best to configure this before production or schedule a downtime event to change the option.
[edit security forwarding-options]
root@SRXEdge# show
family {
inet6 {
mode flow-based;
}
}
[edit security forwarding-options]
root@SRXEdge# show | display set
set security forwarding-options family inet6 mode flow-based
[edit security forwarding-options]
root@SRXEdge#Enabling selective IPv6 is fairly simple. Next, we present an example of how you would configure a firewall filter to allow IPv6 for 6in4 tunneling. The first step is to configure a firewall filter, which is a stateless inspection of traffic. It allows you to apply rules on a per-packet basis instead of flow based. The firewall stanza is a legacy naming option, as it was present since the origins of Junos. This makes it seem a bit confusing, as the SRX is a firewall and one would expect to configure the firewall stanza. To retain backward compatibility, however, Juniper Networks chose to leave the stanza as is and place the SRX’s configuration under the security stanza.
To configure this filter, you should specify the IP address you will be terminating your 6in4 tunnel to. This will ensure that this traffic is only processed in packet mode. The following is our example configuration.
root@SRXEdge# show
filter Allow-v6 {
term 1 {
from {
source-address {
72.52.104.74/32;
}
protocol 41;
}
then packet-mode;
}
term 2 {
from {
destination-address {
72.52.104.74/32;
}
protocol 41;
}
then packet-mode;
}
term 3 {
then accept;
}
}
[edit firewall]
root@SRXEdge# show | display set
set firewall filter Allow-v6 term 1 from source-address 72.52.104.74/32
set firewall filter Allow-v6 term 1 from protocol 41
set firewall filter Allow-v6 term 1 then packet-mode
set firewall filter Allow-v6 term 2 from destination-address 72.52.104.74/32
set firewall filter Allow-v6 term 2 from protocol 41
set firewall filter Allow-v6 term 2 then packet-mode
set firewall filter Allow-v6 term 3 then accept
[edit firewall]
root@SRXEdge#In this example, we configured a firewall filter named
Allow-v6 and added three terms to the filter.
Consider each term as a rule and the filter as a policy. Terms are
evaluated in the order in which they are inserted into the policy. For
simplicity, we named the terms as ordered integers, but you could easily
name them any word. Being descriptive on your terms is critical, as it is
kind of like inline documentation. For this policy, we specify that
traffic that is sourced or destined to the IP 72.52.104.74, and the
traffic is also if IP protocol 41. The action is to process this via
stateless packet mode. This allows the traffic to bypass the flow engine
and be processed as individual packets. Specifying protocol 41 means that
the packets have an IP protocol number of 41. This protocol is defined as
IPv6 encapsulation and is defined in both RFC 2473 and 3056. Finally, we
add in a term of then accept. This term
does not specify a “from” stanza, meaning that all other traffic not
matched by the filter will be accepted and processed as flow-based
traffic.
A firewall filter must be specifically applied to the interfaces that you wish to enforce it. This is easy to do. The two items that you must know are which interface to which you wish to apply the filter and in which direction you want to apply it. For this filter, we need to apply it on both the ingress and egress traffic.
[edit interfaces fe-0/0/0]
root@SRXEdge# show
unit 0 {
family inet {
filter {
input Allow-v6;
output Allow-v6;
}
address 52.74.55.232/24;
}
}
[edit interfaces fe-0/0/0]
root@SRXEdge# show | display set
set interfaces fe-0/0/0 unit 0 family inet filter input Allow-v6
set interfaces fe-0/0/0 unit 0 family inet filter output Allow-v6
set interfaces fe-0/0/0 unit 0 family inet address 52.74.55.232/24
[edit interfaces fe-0/0/0]
root@SRXEdge#When committing a firewall filter, best practice is to use commit confirmed. It is possible to forget the explicit accept and block yourself out of the device. Having an automated rollback will simplify the recovery of management to SRX in the event that you made a mistake in the configuration of your filter.
Sample Deployment
For our sample deployment, we are going to take a look at the configuration of the South Branch SRX100 device from our sample topology, shown in Figure 4-7. This simple configuration will allow us to demonstrate what we learned in a real-world deployment. The sample deployment will show the networking configurations including security zones. Below is the configuration in its entirety.
The first step is to configure the security zones. This does not have to be done first, but by doing it first we will know which interfaces we want to configure.
[edit]
root@SouthBranch# show security zones
security-zone untrust {
interfaces {
fe-0/0/2.0;
}
}
security-zone trust {
interfaces {
fe-0/0/3.0 {
host-inbound-traffic {
system-services {
ssh;
ping;
}
}
}
}
}
[edit]
root@SouthBranch# show security zones | display set
set security zones security-zone untrust interfaces fe-0/0/2.0
set security zones security-zone trust interfaces fe-0/0/3.0 host-inbound-traffic system-services ssh
set security zones security-zone trust interfaces fe-0/0/3.0 host-inbound-traffic system-services ping
[edit]
root@SouthBranch#We enabled ping, web management, and SSH inbound on the
trust zone. This allows local administrators to manage the device.
Externally, the fe-0/0/2.0 interface will not respond to any IP traffic.
It will keep the device in stealth mode and prevent it from being detected
in a ping scan. The zone names can be whatever you desire. We kept to
using untrust as the zone name for the external interface and trust as the
internal zone because it comes from the SRX’s ScreenOS legacy. Back in the
early days of ScreenOS, the interfaces were actually called trust and
untrust. This led to these names being the default zone names on ScreenOS
devices once unique interface naming was created. Because of this, it is
very common for these terms to still be used today in zone naming. What
follows is the output of the operational command show security zones depicting our configuration.
The “junos-host” zone is predefined on the SRX. It can be used in the
creation of policies to allow inbound traffic. We elected to use the
traditional method of configuring allowed services directly on the zone as
this chapter is focused on networking configurations.
root@SouthBranch> show security zones
Security zone: trust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
fe-0/0/3.0
Security zone: untrust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
fe-0/0/2.0
Security zone: junos-host
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 0
Interfaces:
root@SouthBranch>Next, we need to configure the IP addressing for these defined interfaces. The following is an example of this configuration:
root@SouthBranch> show configuration interfaces
fe-0/0/2 {
unit 0 {
family inet {
address 198.18.3.254/24;
}
}
}
fe-0/0/3 {
unit 0 {
family inet {
address 192.168.3.1/24;
}
}
}
root@SouthBranch> show configuration interfaces | display set
set interfaces fe-0/0/2 unit 0 family inet address 198.18.3.254/24
set interfaces fe-0/0/3 unit 0 family inet address 192.168.3.1/24
root@SouthBranch>For the example, we simply defined one IPv4 address for each
interface. We then can check that this was correctly configured from the
command show interfaces terse. Using
the terse option will minimize the output, as all we want to verify is
that the IP addresses are configured on the interfaces.
root@SouthBranch> show interfaces terse
Interface Admin Link Proto Local Remote
fe-0/0/0 up down
gr-0/0/0 up up
ip-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16
10.0.0.6 --> 0/0
128.0.0.1 --> 128.0.1.16
128.0.0.6 --> 0/0
fe-0/0/1 up down
fe-0/0/2 up up
fe-0/0/2.0 up up inet 198.18.3.254/24
fe-0/0/3 up up
fe-0/0/3.0 up up inet 192.168.3.1/24
fe-0/0/4 up down
fe-0/0/5 up down
fe-0/0/6 up down
fe-0/0/7 up down
gre up up
ipip up up
irb up up
lo0 up up
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet 10.0.0.1 --> 0/0
10.0.0.16 --> 0/0
128.0.0.1 --> 0/0
128.0.0.4 --> 0/0
128.0.1.16 --> 0/0
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
ppd0 up up
ppe0 up up
st0 up up
tap up up
vlan up up
root@SouthBranch>The last element needed is the static route that can point us out to the Internet. This will allow us to talk with the other devices in the topology and the rest of the Internet.
root@SouthBranch> show configuration routing-options
static {
route 0.0.0.0/0 next-hop 198.18.3.1;
}
root@SouthBranch> show configuration routing-options | display set
set routing-options static route 0.0.0.0/0 next-hop 198.18.3.1
root@SouthBranch>Adding the static route is simple and it only takes one command. Finally, for our sample deployment, we will validate that the route is correctly configured.
root@SouthBranch> show route inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:00:05 > to 198.18.3.1 via fe-0/0/2.0 192.168.3.0/24 *[Direct/0] 00:00:05 > via fe-0/0/3.0 192.168.3.1/32 *[Local/0] 00:08:44 Local via fe-0/0/3.0 198.18.3.0/24 *[Direct/0] 00:00:05 > via fe-0/0/2.0 198.18.3.254/32 *[Local/0] 00:08:44 Local via fe-0/0/2.0 root@SouthBranch>
Our configured default route is shown in bold text. The remaining routes come from two built-in sources, one being the directly connected networks as defined by being a type Direct route. The other route displayed is called a local route. This route means that the address is defined on that specified logical interface.
Summary
This chapter covered the basic networking capabilities of an SRX. Because an SRX runs Junos, it contains more networking capabilities than the majority of security devices today. This is both a blessing and a curse. It is a blessing because it allows the administrator to control the transmission of traffic on an SRX in extremely powerful ways. At Juniper Networks, we are constantly amazed at how the SRX is deployed. The typical deployment uses just a few interfaces and a couple of routes. Some deployments can be much more complex, using dozens of protocols, thousands of routing instances, and hundreds of thousands of routes.
Because the typical deployment does not utilize the majority of these networking features, the book’s focus has been shifted to the security side of the configuration. Throughout the chapter there are callouts specifying where to go to get the best descriptions of the more advanced networking features if you feel that they are needed in your deployment. It is best to consult with a Junos expert or send a query out on the J-Net community forums if you are unsure of how to best implement your SRX. The best practice is always to keep your design as simple as possible by using the minimal set of options that are needed to accomplish your goal. Designs that are needlessly complex can lead to difficult troubleshooting sessions or behavior that can be confusing to less advanced users. The rule of thumb is to only deploy what the average person on your operations staff can understand. Networking mistakes are often the cause of security breaches. Don’t become a victim; keep your configuration as simple as possible.
Study Questions
- Questions
What is an IFD?
What is the name of a physical management interface on an SRX?
What are virtual interfaces used for?
What is a logical interface?
State the two ways that a logical interface can be specified during its creation.
What protocol can be used to negotiate aggregate interfaces?
What identifier is used to bind a transparent interface to a bridge domain?
Zones are used in the creation of security policies on an SRX. What is the point of a zone?
There are many different types of routing instances. What is the one that is most commonly used on an SRX?
What is the best type of network design to use on an SRX?
- Answers
An IFD represents a physical interface or interface device. This is often the term used in Junos documentation for a physical interface.
A physical management interface that is dedicated to the management of the device is called fxp0.
Virtual interfaces provide a logical construct that Junos can use to pass traffic which contains certain properties. Typically, these are used for encapsulation or decapsulation of traffic such as an IPsec VPN.
A logical interface is represented as a unit. It can also be called an IFL in Junos documentation. A unit is used for configuring any logical properties such as supported protocol families and protocol addresses.
The term unit can be used when specifying a logical interface during its creation or modification (set interfaces fe-0/0/0 unit 0). A period can also be used as a shortened form to define a logical interface (set interfaces fe-0/0/0.0).
The LACP protocol can be utilized to assist in the negotiation of aggregate interfaces to the remote device.
Specifying a VLAN ID will bind a transparent interface to a bridge domain.
A zone provides a logical construct to which an interface or interfaces can be bound. It simplifies both the policy creation and lookup process. Zones also can be used to specify the inbound traffic allowed into the SRX.
The routing instance type virtual router is the most commonly used instance on an SRX. It offers both routing tables and forwarding tables. It is similar to a Cisco VRF.
The best type of networking design is a simple design. A misconfigured network is often the cause of security breaches. A simple misconfiguration can lead to unauthorized network access.
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.
