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.

Table 4-1. Interface media types

Name

Media type

fe

Fast Ethernet 10/100

ge

Gigabit Ethernet 1000

xe

10 gigabit Ethernet

t1

T1 interface

vlan

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”.

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 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
> 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 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 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                 Remote
fe-0/0/0          up    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/0
fe-0/0/1          up    up
fe-0/0/1.0        up    up   eth-switch
fe-0/0/2          up    up
fe-0/0/2.0        up    up   eth-switch
fe-0/0/3          up    up
fe-0/0/3.0        up    up   eth-switch
fe-0/0/4          up    down
fe-0/0/4.0        up    down eth-switch
fe-0/0/5          up    down
fe-0/0/5.0        up    down eth-switch
fe-0/0/6          up    down
fe-0/0/6.0        up    down eth-switch
fe-0/0/7          up    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, * = Both

0.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.0
10.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 Netif
default          user     2 10.102.1.254   hold   602     6 xe-1/0/0.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     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 70
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
-- 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.

Table 4-2. Interface media types

Name

Media type

st0

Secure tunnel interface (IPsec VPNs)

ip

IP in IP tunneling (6in4 tunneling)

gr

Generic router encapsulation

ppd

Protocol independent multicast

pimd

PIM decapsulation

pime

PIM encapsulation

lte

Logical tunnel interface

lo0

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.

Table 4-3. Interface family types

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 interfaces vlan unit 0

[edit]
root@SRXEdge# set interfaces vlan.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# show
unit 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 vlan
unit 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.0
family 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

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# show
interfaces {
    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.

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# show
interfaces {
    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 destination
  next-table           Next hop to another table
  no-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 destination
  reject               Drop packets to destination; send ICMP unreachables
  resolve              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.

Table 4-4. Routing protocol preferences

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.0

Additional 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: I

Finally, 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.

Route decision process
Figure 4-1. Route decision process

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.

Switching loop example
Figure 4-2. Switching loop example

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.

Spanning tree stops loops
Figure 4-3. Spanning tree stops loops

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.

MSTP topology
Figure 4-4. 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.

Logical example showing best practice
Figure 4-5. Logical example showing best practice

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#s

Now 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 instance example
Figure 4-6. Routing instance example

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
> inet6                Family IPv6
> iso                  Family ISO
> mpls                 Family 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.

South Branch SRX100 sample topology
Figure 4-7. South Branch SRX100 sample topology

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

  1. What is an IFD?

  2. What is the name of a physical management interface on an SRX?

  3. What are virtual interfaces used for?

  4. What is a logical interface?

  5. State the two ways that a logical interface can be specified during its creation.

  6. What protocol can be used to negotiate aggregate interfaces?

  7. What identifier is used to bind a transparent interface to a bridge domain?

  8. Zones are used in the creation of security policies on an SRX. What is the point of a zone?

  9. There are many different types of routing instances. What is the one that is most commonly used on an SRX?

  10. What is the best type of network design to use on an SRX?

Answers

  1. An IFD represents a physical interface or interface device. This is often the term used in Junos documentation for a physical interface.

  2. A physical management interface that is dedicated to the management of the device is called fxp0.

  3. 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.

  4. 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.

  5. 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).

  6. The LACP protocol can be utilized to assist in the negotiation of aggregate interfaces to the remote device.

  7. Specifying a VLAN ID will bind a transparent interface to a bridge domain.

  8. 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.

  9. 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.

  10. 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.