Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Protocol Family and Interface Address Properties

This section discusses on how to configure protocol family and interface address properties.

Configure the Protocol Family

A protocol family is a group of logical properties within an interface configuration. Protocol families include all the protocols that make up a protocol suite. To use a protocol within a particular suite, you must configure the entire protocol family as a logical property for an interface.

Protocol families include the following common protocol suites:

  • Inet—Supports IP protocol traffic, including OSPF, BGP, and Internet Control Message Protocol (ICMP).

  • Inet6—Supports IPv6 protocol traffic, including RIP for IPv6 (RIPng), IS-IS, and BGP.

  • ISO—Supports IS-IS traffic.

  • MPLS—Supports MPLS.

In addition to the common protocol suites, Junos OS protocol families sometimes use the following protocol suites. For more information, see family.

To configure the protocol family for the logical interface, include the family statement, specifying the selected family.

To configure the protocol family, complete the minimum configuration tasks under the [edit interfaces interface-name unit logical-unit-number family family] hierarchy.

Table 1: Protocol Family Configuration Tasks

Task

Find Details Here

Configure MTU.

Configuring the Media MTU

Configure the unit and family so that the interface can transmit and receive multicast traffic only.

Restricting Tunnels to Multicast Traffic

Disable the sending of redirect messages by the router.

Protocol Redirect Messages

Assign an address to an interface.

Configuring the Interface Address

Assign the Interface Address

You assign an address to an interface by specifying the address when configuring the protocol family. For the inet or inet6 family, configure the interface IP address. For the iso family, configure one or more addresses for the loopback interface. For the ccc, ethernet-switching, tcc, mpls, tnp, and vpls families, you never configure an address.

Note:

The Point-to-Point Protocol (PPP) address is taken from the loopback interface address that has the primary attribute. When the loopback interface is configured as an unnumbered interface, it takes the primary address from the donor interface.

To assign an address to an interface, perform the following steps:

  1. Configure the interface address at the [edit interfaces interface-name unit logical-unit-number family family] hierarchy level.
    • To configure an IP version 4 (IPv4) address on routers and switches, use the interface interface-name unit number family inet address a.b.c.d/nn statement at the [edit interfaces] hierarchy level.

      You can also assign multiple IPv4 addresses on the same interface.

      Note:
      • Juniper Networks routers and switches support /31 destination prefixes when used in point-to-point Ethernet configurations; however, they are not supported by many other devices, such as hosts, hubs, routers, or switches. You must determine if the peer system also supports /31 destination prefixes before configuration.

      • You can configure the same IPv4 address on multiple physical interfaces. When you assign the same IPv4 address to multiple physical interfaces, the operational behavior of those interfaces differs, depending on whether they are implicitly or explicitly point-to-point.

      • By default, all interfaces are assumed to be point-to-point (PPP) interfaces. For all interfaces except aggregated Ethernet, Fast Ethernet, and Gigabit Ethernet, you can explicitly configure an interface to be a point-to-point connection.

      • If you configure the same IP address on multiple interfaces in the same routing instance, Junos OS applies the configuration randomly on one of the interfaces. The other interfaces will remain without an IP address.

    • To configure an IP version 6 (IPv6) address on routers and switches, use the interface interface-name unit number family inet6 address aaaa:bbbb:...:zzzz/nn statement at the [edit interfaces] hierarchy level.

      Note:
      • You represent IPv6 addresses in hexadecimal notation using a colon-separated list of 16-bit values. The double colon (::) represents all bits set to 0.

      • You must manually configure the router or switch advertisement and advertise the default prefix for autoconfiguration to work on a specific interface.

  2. [Optional] Set the broadcast address on the network or subnet.
    Note:

    The broadcast address must have a host portion of either all ones or all zeros. You cannot specify the addresses 0.0.0.0 or 255.255.255.255.

  3. [Optional] specify the remote address of the connection for the encrypted, PPP-encapsulated, and tunnel interfaces.

Configure Default, Primary, and Preferred Addresses and Interfaces

The following sections describe how to configure default, primary, and preferred addresses and interfaces.

Default, Primary, and Preferred Addresses and Interfaces

The router has a default address and a primary interface; and interfaces have primary and preferred addresses.

The default address of the router is used as the source address on unnumbered interfaces. The routing protocol process tries to select the default address as the router ID, which is used by protocols, including OSPF and internal BGP (IBGP).

The primary interface for the router is the interface that packets go out when no interface name is specified and when the destination address does not imply a particular outgoing interface.

An interface’s primary address is used by default as the local address for broadcast and multicast packets sourced locally and sent out the interface. An interface’s preferred address is the default local address used for packets sourced by the local router to destinations on the subnet.

Note:

You can explicitly mark an interface's IP as primary and preferred using a configuration statement. If an interface is only assigned a single IP that address is considered the primary and preferred address by default. When assigned multiple IP addresses, none of which are explicitly configured as primary, the numerically lowest IP address is uses as the primary address on that interface.

The default address of the router is chosen using the following sequence:

  1. The primary address on the loopback interface lo0 that is not 127.0.0.1 is used.

  2. The primary address on the primary interface is used.

  3. When there are multiple interfaces with "primary" and "preferred" addresses, the interface with the lowest interface index is selected, and the primary address is used. In the case that none of the interface's IP addresses are explicitly marked with the primary statement, the numerically lowest address on that interface is used as the system default address.

  4. Any remaining interface with an IP address may be selected. This includes the router's management or internal interfaces. For this reason, it's recommended that you assign a loopback address, or explicitly configure a primary interface, to control default address selection.

Configure the Primary Interface for the Router

The primary interface for the router has the following characteristics:

  • It is the interface that packets go out when you type a command such as ping 255.255.255.255—that is, a command that does not include an interface name (there is no interface type-0/0/0.0 qualifier) and where the destination address does not imply any particular outgoing interface.

  • It is the interface on which multicast applications running locally on the router, such as Session Announcement Protocol (SAP), do group joins by default.

  • It is the interface from which the default local address is derived for packets sourced out an unnumbered interface if there are no non-127 addresses configured on the loopback interface, lo0.

By default, the multicast-capable interface with the lowest-index address is chosen as the primary interface.

If there is no such interface, the point-to-point interface with the lowest index address is chosen. Otherwise, any interface with an address could be selected. In practice, this means that, on the router, the fxp0 or em0 interface is selected by default.

To configure a different interface to be the primary interface, include the primary statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

Configure the Primary Address for an Interface

The primary address on an interface is the address that is used by default as the local address for broadcast and multicast packets sourced locally and sent out the interface. For example, the local address in the packets sent by a ping interface so-0/0/0.0 255.255.255.255 command is the primary address on interface so-0/0/0.0. The primary address flag can also be useful for selecting the local address used for packets sent out unnumbered interfaces when multiple non-127 addresses are configured on the loopback interface, lo0. By default, the primary address on an interface is selected as the numerically lowest local address configured on the interface.

To set a different primary address, include the primary statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family address address]

Configure the Preferred Address for an Interface

The preferred address on an interface is the default local address used for packets sourced by the local router to destinations on the subnet. By default, the numerically lowest local address is chosen. For example, if the addresses 172.16.1.1/12, 172.16.1.2/12, and 172.16.1.3/12 are configured on the same interface, the preferred address on the subnet (by default, 172.16.1.1) is used as a local address when you issue a ping 172.16.1.5 command.

To set a different preferred address for the subnet, include the preferred statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family address address]

Operational Behavior of Interfaces with the Same IPv4 Address

You can configure the same IP version 4 (IPv4) address on multiple physical interfaces. When you assign the same IPv4 address to multiple physical interfaces, the operational behavior of those interfaces differs, depending on whether they are (implicitly) point-to-point or not.

Note:

For all interfaces, except aggregated Ethernet, Fast Ethernet, and Gigabit Ethernet, you can explicitly configure an interface to be a point-to-point connection.

If you configure the same IP address on multiple interfaces in the same routing instance, the operating system applies the configuration randomly on one of the interfaces. The other interfaces will remain without an IP address.

The following examples show the sample configuration of assigning the same IPv4 address to interfaces that are implicitly and explicitly point-to-point interfaces. The examples also show the show interfaces terse command outputs that correspond to the implicit and explicit point-to-point interfaces to display their operational status.

  1. Configuring the same IPv4 address on two non-P2P interfaces:

    The sample output shown below for the above configuration reveals that only ge-0/1/0.0 was assigned the same IPv4 address 203.0.113.1/24 and its link state was up, while ge-3/0/1.0 was not assigned the IPv4 address, although its link state was up, which means that it will be operational only when it gets a unique IPv4 address other than 203.0.113.1/24.

    show interfaces terse

  2. Configuring the same IPv4 address on (implicit) P2P interfaces:

    The following sample output (for the preceding configuration) reveals that both so-0/0/0.0 and so-0/0/3.0 were assigned the same IPv4 address 203.0.113.1/24 and that their link states were down. The interfaces are down due to an issue with the link and not because the same IPv4 address is assigned to both the interfaces. It is expected that not more than one of the interface is up at any given time (following a redundancy scheme outside of the Junos OS devices scope), because both being up may cause adverse effects.

    show interfaces terse

  3. Configuring the same IPv4 address in multiple instances of a non-P2P interface:

    On a non-P2P interface, you cannot configure the same local address on different units of different interfaces. If you do, a commit error will be thrown and the configuration will fail.

  4. Configuring the same IPv4 address in multiple instances of the same P2P interface:

    The following sample output (for the preceding configuration) reveals that only one interface gets successfully configured on P2P interfaces when you try to configure the same IPv4 address for multiple instances of different interfaces.

    show interfaces terse

Configure IPCP Options for Interfaces with PPP Encapsulation

For interfaces with PPP encapsulation, you can configure IPCP to negotiate IP address assignments and to pass network-related information such as Windows Name Service (WINS) and Domain Name System (DNS) servers, as defined in RFC 1877, PPP Internet Protocol Control Protocol Extensions for Name Server Addresses.

When you enable a PPP interface, you can configure an IP address, enable the interface to negotiate an IP address assignment from the remote end, or allow the interface to be unnumbered. You can also assign a destination profile to the remote end. The destination profile includes PPP properties, such as primary and secondary DNS and NetBIOS Name Servers (NBNSs). These options are described in the following sections:

Note:

The Junos OS does not request name servers from the remote end; the software does, however, send name servers to the remote end if requested.

Before you begin

You must configure the PPP encapsulation on the interface before configuring the IPCP option. The following PPP encapsulation types are supported on the logical interface:

  • atm-mlppp-llc

  • atm-ppp-llc

  • atm-ppp-vc-mux

  • multilink-ppp

For more information about PPP encapsulation, see Configuring Interface Encapsulation on Logical Interfaces and Configuring ATM Interface Encapsulation

  • To configure an IP address for the interface, include the address statement in the configuration. For more information, see Configuring the Interface Address.

    If you include the address statement in the configuration, you cannot include the negotiate-address or unnumbered-address statement in the configuration.

    When you include the address statement in the interface configuration, you can assign PPP properties to the remote end.

    Note:

    The option to negotiate an IP address is not allowed in MLFR and MFR encapsulations.

  • To enable the interface to obtain an IP address from the remote end, include the negotiate-address statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level.

    Note:

    If you include the negotiate-address statement in the configuration, you cannot include the address or unnumbered-address statement in the configuration.

  • To configure an interface to be unnumbered, include the unnumbered-address and destination statements in the configuration.

    Note:
    • The unnumbered-address statement enables the local address to be derived from the specified interface. The interface name must include a logical unit number and must have a configured address (see Configuring the Interface Address). Specify the IP address of the remote interface with the destination statement.

    • If you include the unnumbered-address statement in the configuration, you cannot include the address or negotiate-address statement in the interface configuration.

  • To assign PPP properties to the remote end include the destination-profile statement:

    Note:
    • You can assign PPP properties to the remote end, after you include the address or unnumbered-address statement in the interface configuration.

    • You define the profile at the [edit access group-profile name ppp] hierarchy level. For more information, see Configuring the Group Profile for L2TP and PPP.

Configure Unnumbered Interfaces: Overview

Overview of Unnumbered Interfaces

When you need to conserve IP addresses, you can configure unnumbered interfaces. Setting up an unnumbered interface enables IP processing on the interface without assigning an explicit IP address to the interface. For IP version 6 (IPv6), in which conserving addresses is not a major concern, you can configure unnumbered interfaces to share the same subnet across multiple interfaces.

The IPv6 unnumbered interfaces are supported only on Ethernet interfaces. The statements you use to configure an unnumbered interface depend on the type of interface you are configuring: a point-to-point interface or an Ethernet interface:

Configure an Unnumbered Point-to-Point Interface

To configure an unnumbered point-to-point interface:

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
  2. Configure the protocol family, but do not include the address statement.
Note:
  • For interfaces with Point-to-Point Protocol (PPP) encapsulation, you can configure an unnumbered interface by including the unnumbered-interface statement in the configuration. For more information, see Configuring IPCP Options for Interfaces with PPP Encapsulation.

  • When configuring unnumbered interfaces, you must ensure that a source address is configured on an interface in the router. This address is the default address. We recommend that you do this by assigning an address to the loopback interface (lo0), as described in Loopback Interface Configuration.

    When you configure a routable address on the lo0 interface, that address is always the default address. This is ideal because the loopback interface is independent of any physical interfaces and therefore is always accessible.

Configure an Unnumbered Ethernet or Demux Interface

To configure an unnumbered Ethernet or demultiplexing (demux) interface:

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number family family-name] hierarchy level.
  2. To configure an unnumbered Ethernet or demux interface, include the unnumbered-address statement in the configuration.
  3. (Optional) To specify the unnumbered Ethernet interface as the next-hop interface for a configured static route, include the qualified-next-hop statement at the [edit routing-options static route destination-prefix] hierarchy level. This feature enables you to specify independent preferences and metrics for static routes on a next-hop basis.
Note:
  • The unnumbered-address statement currently supports configuration of unnumbered demux interfaces only for the IP version 4 (IPv4) address family. You can configure unnumbered Ethernet interfaces for both IPv4 and IPv6 address families.

  • The interface that you configure to be unnumbered borrows an assigned IP address from another interface and is referred to as the borrower interface. The interface from which the IP address is borrowed is referred to as the donor interface. In the unnumbered-address statement, interface-name specifies the donor interface. For an unnumbered Ethernet interface, the donor interface can be an Ethernet, ATM, SONET, or loopback interface that has a logical unit number and configured IP address and is not itself an unnumbered interface. For an unnumbered IP demux interface, the donor interface can be an Ethernet or loopback interface that has a logical unit number and configured IP address and is not itself an unnumbered interface. In addition, for either Ethernet or demux, the donor interface and the borrower interface must be members of the same routing instance and the same logical system.

  • When you configure an unnumbered Ethernet or demux interface, the IP address of the donor interface becomes the source address in packets generated by the unnumbered interface.

  • You can configure a host route that points to an unnumbered Ethernet or demux interface.

  • For information about host routes, see the MPLS Applications User Guide.

Configure a Secondary Address as a Preferred Source Address for Unnumbered Ethernet or Demux Interfaces

When a loopback interface with multiple secondary IP addresses is configured as the donor interface for an unnumbered Ethernet or demultiplexing (demux) interface, you can optionally specify any one of the loopback interface’s secondary addresses as the preferred source address for the unnumbered Ethernet or demux interface. This feature enables you to use an IP address other than the primary IP address on some of the unnumbered Ethernet or demux interfaces in your network.

To configure a secondary address on a loopback donor interface as the preferred source address for unnumbered Ethernet or demux interfaces:

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number family family-name] hierarchy level.
  2. Include the preferred-source-address option in the unnumbered-address statement:
Note:

The following considerations apply when you configure a preferred source address on an unnumbered Ethernet or demux interface:

  • The unnumbered-address statement currently supports the configuration of a preferred source address only for the IP version 4 (IPv4) address family for demux interfaces, and for IPv4 and IP version 6 (IPv6) address families for Ethernet interfaces.

  • If you do not specify the preferred source address, the router uses the default primary IP address of the donor interface.

  • You cannot delete an address on a donor loopback interface while it is being used as the preferred source address for an unnumbered Ethernet or demux interface.

Restrictions for Unnumbered Ethernet Interface Configurations

The following requirements and restrictions apply when you configure unnumbered Ethernet interfaces:

  • The unnumbered-address statement currently supports the configuration of unnumbered Ethernet interfaces for IP version 4 (IPv4) and IP version 6 (IPv6) address families.

  • You can assign an IP address only to an Ethernet interface that is not already configured as an unnumbered interface.

  • You must configure one or more IP addresses on the donor interface for an unnumbered Ethernet interface.

  • You cannot configure the donor interface for an unnumbered Ethernet interface as unnumbered.

  • An unnumbered Ethernet interface does not support configuration of the following address statement options: arp, broadcast, primary, preferred, or vrrp-group.

    For information about these statement options, see Configuring the Interface Address.

  • You can run Internet Group Management Protocol (IGMP) and Physical Interface Module (PIM) only on unnumbered Ethernet interfaces that directly face the host and have no downstream PIM neighbors. You cannot run either IGMP or PIM on unnumbered Ethernet interfaces that act as upstream interfaces in a PIM topology.

  • You can run OSPF over unnumbered Ethernet interfaces configured as a point-to-point (P2P) connection. However, you cannot run OSPF or IS-IS on unnumbered Ethernet interfaces that are not configured as P2P.

    For link-state distribution using an interior gateway protocol (IGP), ensure that OSPF is enabled on the donor interface for an unnumbered interface configuration so that the donor IP address is reachable to establish OSPF sessions.

Note:

If you configure the same address on multiple interfaces in the same routing instance, the operating system uses only the first configuration. In this scenario, the remaining address configurations are ignored and can leave interfaces without an address. An interface that does not have an assigned address cannot be used as a donor interface for an unnumbered Ethernet interface.

For example, in the following configuration the address configuration of interface et-0/0/1.0 is ignored:

For more information about configuring the same address on multiple interfaces, see Configuring the Interface Address.

Example: Display the Unnumbered Ethernet Interface Configuration

Purpose

To display the configured unnumbered interface at the [edit interfaces interface-name unit logical-unit-number] hierarchy level:

  • Unnumbered interface —ge-1/0/0

  • Donor interface —ge-0/0/0

  • Donor interface address —4.4.4.1/24

The unnumbered interface “borrows” an IP address from the donor interface.

Action

  • Run the show command at the [edit] hierarchy level.

Meaning

The sample configuration works correctly on M and T Series routers. For unnumbered interfaces on MX Series routers, you must also configure static routes on an unnumbered Ethernet interface by including the qualified-next-hop statement at the [edit routing-options static route destination-prefix] hierarchy level to specify the unnumbered Ethernet interface as the next-hop interface for a configured static route.

Example: Display the Configured Preferred Source Address for an Unnumbered Ethernet Interface

Purpose

To display the configuration of preferred source address for an unnumbered interface at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level:

  • Unnumbered interface —ge-4/0/0

  • Donor interface —lo0

  • Donor interface primary address—2.2.2.1/32

  • Donor interface secondary address—3.3.3.1/32

Action

  • Run the show command at the [edit] hierarchy level.

Meaning

The loopback interface lo0 is the donor interface from which an unnumbered Ethernet interface ge-4/0/0 “borrows” an IP address.

The example shows one of the loopback interface’s secondary addresses, 3.3.3.1, as the preferred source address for the unnumbered Ethernet interface.

Example: Display the Configuration for the Unnumbered Ethernet Interface as the Next Hop for a Static Route

Purpose

To display the unnumbered interface configured as the next hop for the static route at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level:

  • Unnumbered interface —ge-0/0/0

  • Donor interface —lo0

  • Donor interface primary address—5.5.5.1/32

  • Donor interface secondary address—6.6.6.1/32

  • Static route—7.7.7.1/32

Action

  • Run the show command at the [edit] hierarchy level.

  • The following configuration enables the kernel to install a static route to address 7.7.7.1/32 with a next hop through unnumbered interface ge-0/0/0.0.

Meaning

In this example, ge-0/0/0 is the unnumbered interface. A loopback interface, lo0, is the donor interface from which ge-0/0/0 “borrows” an IP address. The example also configures a static route to 7.7.7.1/32 with a next hop through unnumbered interface ge-0/0/0.0.

Protocol MTU

Overview

The default protocol MTU depends on your device and the interface type. When you initially configure an interface, the protocol MTU is calculated automatically. If you subsequently change the media MTU, the protocol MTU on existing address families automatically changes.

If you reduce the media MTU size but one or more address families are already configured and active on the interface, you must also reduce the protocol MTU size. If you increase the size of the protocol MTU, you must ensure that the size of the media MTU is equal to or greater than the sum of the protocol MTU and the encapsulation overhead.

If you do not configure an MPLS MTU, Junos OS derives the MPLS MTU from the physical interface MTU. From this value, the software subtracts the encapsulation-specific overhead and space for the maximum number of labels that might be pushed in the Packet Forwarding Engine. The software provides for three labels of four bytes each, for a total of 12 bytes.

In other words, the formula used to determine the MPLS MTU is as follows:

You can configure the protocol MTU on all tunnel interfaces except virtual tunnel (VT) interfaces. Junos OS sets the MTU size for VT interfaces to unlimited by default.

Configure the Protocol MTU

Note:

Changing the media MTU or protocol MTU causes an interface to be deleted and added again. This causes the link to flap.

To configure the protocol MTU:

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
  2. Include the mtu statement for each family you want to configure with a non-default MTU value.

    If you configure the protocol MTU for any family, the configured value is applied to all families that are configured on the logical interface.

    Note:

    If you are configuring the protocol MTU for both inet and inet6 families on the same logical interface, you must configure the same value for both families. We do not recommend configuring different MTU size values for inet and inet6 families that are configured on the same logical interface.

  3. (Optional) On some devices, you can also configure the protocol MTU at the logical systems hierarchy:

Disable the Removal of Address and Control Bytes

For Point-to-Point Protocol (PPP) CCC-encapsulated interfaces, the address and control bytes are removed by default before the packet is encapsulated into a tunnel.

However, you can disable the removal of address and control bytes.

To disable the removal of address and control bytes, include the keep-address-and-control statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family ccc]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family ccc]

Disable the Transmission of Redirect Messages on an Interface

By default, the interface sends protocol redirect messages. To disable the sending of these messages on an interface, include the no-redirects statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

To disable the sending of protocol redirect messages for the entire router or switch, include the no-redirects statement at the [edit system] hierarchy level.

Apply a Filter to an Interface

Define Interface Groups in Firewall Filters

When applying a firewall filter, you can define an interface to be part of an interface group. Packets received on that interface are tagged as being part of the group. You can then match these packets using the interface-group match statement, as described in the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

To define the interface to be part of an interface group, include the group statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family filter]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family filter]

Note:

The number 0 is not a valid interface group number.

Filter-Based Forwarding on the Output Interface

If port-mirrored packets are to be distributed to multiple monitoring or collection interfaces, based on the patterns in packet headers, it is helpful to configure a filter-based forwarding (FBF) filter on the port-mirroring egress interface.

When an FBF filter is installed as an output filter, a packet that is forwarded to the filter has already undergone at least one route lookup. After the packet is classified at the egress interface by the FBF filter, it is redirected to another routing table for additional route lookup. To avoid packet looping inside the Packet Forwarding Engine, the route lookup in the latter routing table (designated by an FBF routing instance) must result in a different next hop from any next hop specified in a table that has already been applied to the packet.

If an input interface is configured for FBF, the source lookup is disabled for those packets heading to a different routing instance, since the routing table is not set up to handle the source lookup.

For more information about FBF configuration, see the Junos OS Routing Protocols Library for Routing Devices. For more information about port mirroring, see the Junos OS Services Interfaces Library for Routing Devices.

Apply a Filter to an Interface

To apply firewall filters to an interface, include the filter statement:

To apply a single filter, include the input statement:

To apply a list of filters to evaluate packets received on an interface, include the input-list statement.

You can include up to 16 filter names in an input list.

To apply a list of filters to evaluate packets transmitted on an interface, include the output-list statement.

When you apply filters using the input-list statement or the output-list statement, a new filter is created with the name <interface-name>.<unit-direction>. This filter is exclusively interface specific.

You can include these statements at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

In the family statement, the protocol family can be ccc, inet, inet6, mpls, or vpls.

In the group statement, specify the interface group number to associate with the filter.

In the input statement, list the name of one firewall filter to be evaluated when packets are received on the interface.

In the input-list statement, list the names of filters to evaluate when packets are received on the interface. You can include up to 16 filter names.

In the output statement, list the name of one firewall filter to be evaluated when packets are transmitted on the interface.

Note:

Output filters do not work for broadcast and multicast traffic, including VPLS traffic (except in MX Series routers with MPC/MIC interfaces), as shown in Apply a Filter to an Interface.

Note:

MPLS family firewall filters applied on the output interface are not supported on the PTX10003 router, due to product limitation.

Note:

On an MX Series router, you cannot apply as an output filter a firewall filter configured at the [edit firewall filter family ccc] hierarchy level. You can apply firewall filters configured for the family ccc statement as input filters only.

In the output-list statement, list the names of filters to evaluate when packets are transmitted on the interface. You can include up to 16 filter names.

You can use the same filter one or more times. On M Series routers (except the M320 and M120 routers), if you apply a firewall filter or policer to multiple interfaces, the filter or policer acts on the sum of traffic entering or exiting those interfaces.

On T Series, M120, and M320 routers, interfaces are distributed among multiple packet forwarding components. Therefore, on these routers, if you apply a firewall filter or policer to multiple interfaces, the filter or policer acts on the traffic stream entering or exiting each interface, regardless of the sum of traffic on the multiple interfaces.

For more information on Understanding Ethernet Frame Statistics, see the MX Series Layer 2 Configuration Guide.

If you apply the filter to interface lo0, it is applied to packets received or transmitted by the Routing Engine. You cannot apply MPLS filters to the management interface (fxp0 or em0) or the loopback interface (lo0).

Filters applied at the [set interfaces lo0 unit 0 family any filter input] hierarchy level are not installed on T4000 Type 5 FPCs.

For more information about firewall filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. For more information about MPLS filters, see the MPLS Applications User Guide.

Example: Input Filter for VPLS Traffic

For M Series and T Series routers only, apply an input filter to VPLS traffic. Output filters do not work for broadcast and multicast traffic, including VPLS traffic.

Note that on MX Series routers with MPC/MIC interfaces, the VPLS filters on the egress route is applicable to broadcast, multicast, and unknown unicast traffic.

Example: Filter-Based Forwarding at the Output Interface

The following example illustrates the configuration of filter-based forwarding at the output interface. In this example, the packet flow follows this path:

  1. A packet arrives at interface fe-1/2/0.0 with source and destination addresses 10.50.200.1 and 10.50.100.1, respectively.

  2. The route lookup in routing table inet.0 points to egress interface so-0/0/3.0.

  3. The output filter installed at so-0/0/3.0 redirects the packet to routing table fbf.inet.0.

  4. The packet matches entry 10.50.100.0/25 in the fbf.inet.0 table, and the packet finally leaves the router from interface so-2/0/0.0.

Enable Source Class and Destination Class Usage

Source Class and Destination Class Usage Overview

For interfaces that carry IP version 4 (IPv4), IP version 6 (IPv6), MPLS, or peer AS billing traffic, you can maintain packet counts based on the entry and exit points for traffic passing through your network. Entry and exit points are identified by source and destination prefixes grouped into disjoint sets defined as source classes and destination classes. You can define classes based on a variety of parameters, such as routing neighbors, autonomous systems, and route filters.

Source class usage (SCU) accounting counts packets sent to customers by performing lookup on the IP source address. SCU makes it possible to track traffic originating from specific prefixes on the provider core and destined for specific prefixes on the customer edge. You must enable SCU accounting on both the inbound and outbound physical interfaces, and the route for the source of the packet must be located in the forwarding table.

Note:

Neither SCU nor destination class usage (DCU) accounting works with directly connected interface routes. Source class usage does not count packets coming from sources with direct routes in the forwarding table, because of software architecture limitations.

Destination class usage (DCU) counts packets from customers by performing lookup of the IP destination address. DCU makes it possible to track traffic originating from the customer edge and destined for specific prefixes on the provider core router.

Note:

We recommend that you stop the network traffic on an interface before you modify the DCU or SCU configuration for that interface. Modifying the DCU or SCU configuration without stopping the traffic might corrupt the DCU or SCU statistics. Before you restart the traffic after modifying the configuration, enter the clear interfaces statistics command.

Figure 1 illustrates an ISP network. In this topology, you can use DCU to count packets customers send to specific prefixes. For example, you can have three counters, one per customer, that count the packets destined for prefix 210.210/16 and 220.220/16.

You can use SCU to count packets the provider sends from specific prefixes. For example, you can count the packets that are sent from prefix 210.210/16 and 215.215/16 and that are transmitted on a specific output interface.

Figure 1: Prefix Accounting with Source and Destination ClassesPrefix Accounting with Source and Destination Classes

You can configure up to 126 source classes and 126 destination classes. For each interface on which you enable destination class usage and source class usage, the operating system maintains an interface-specific counter for each corresponding class up to the 126-class limit.

Note:

For transit packets exiting the router through the tunnel, forwarding path features such as RPF, forwarding table filtering, source class usage, and destination class usage are not supported on the interfaces you configure as the output interface for tunnel traffic. For firewall filtering, you must allow the output tunnel packets through the firewall filter applied to input traffic on the interface that is the next-hop interface towards the tunnel destination.

Note:

Performing DCU accounting when an output service is enabled produces inconsistent behavior in the following configuration:

  • Both SCU input and DCU are configured on the packet input interface.

  • SCU output is configured on the packet output interface.

  • Interface services is enabled on the output interface.

For an incoming packet with source and destination prefixes matching the SCU and DCU classes configured in the router, both SCU and DCU counters will be incremented. This behavior is not harmful or negative. However, it is inconsistent with non-serviced packets, in that only the SCU count will be incremented (because the SCU class ID will override the DCU class ID in this case).

To enable packet counting on an interface, include the accounting statement:

direction can be one of the following:

  • input—Configure at least one expected ingress point.

  • output—Configure at least one expected egress point.

  • input output—On a single interface, configure at least one expected ingress point and one expected egress point.

You can include these statements at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6 | mpls)]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6 | mpls)]

For SCU to work, you must configure at least one input interface and at least one output interface.

The ability to count a single packet for both SCU and DCU accounting depends on the underlying physical interface.

  • For traffic over Modular Port Concentrator/Modular Interface Card (MPC/MIC) interfaces, a single incoming packet is counted for both SCU and DCU accounting if both SCU and DCU are configured. To ensure that the outgoing packet is counted, include the source-class-usage output statements in the configuration of the outgoing interface.

  • For traffic over DPC interfaces, an incoming packet is counted only once, and SCU takes priority over DCU. This means that when a packet arrives on an interface on which you include the source-class-usage input and destination-class-usage statements in the configuration, and when the source and destination both match accounting prefixes, the operating system associates the packet with the source class only.

For traffic over MPC interfaces, SCU and DCU accounting is performed after output filters are evaluated. If a packet matches a firewall filter match condition, the packet is included in SCU or DCU accounting except in the case where the action of the matched term is discard.

On T Series, M120, and M320 routers, the source class and destination classes are not carried across the router fabric. The implications of this are as follows:

  • On T Series, M120, and M320 routers, SCU and DCU accounting is performed before the packet enters the fabric.

  • On M7i, M10i, M120, and M320 routers, on MX Series routers with non-MPC, and on T Series routers, SCU and DCU accounting is performed before output filters are evaluated. Consequently, if a packet matches a firewall filter match condition, the packet is included in SCU or DCU accounting; the packet is counted for any term action (including the discard action).

  • On M120, M320, and T Series routers, the destination-class and source-class statements are supported at the [edit firewall family family-name filter filter-name term term-name from] hierarchy level only for the filter applied to the forwarding table. On M7i, M10i, and MX Series routers, these statements are supported.

After you enable accounting on an interface, the operating system maintains packet counters for that interface, with separate counters for inet, inet6, and mpls protocol families. You must then configure the source class and destination class attributes in policy action statements, which must be included in forwarding-table export policies.

Note:

When configuring policy action statements, you can configure only one source class for each matching route. In other words, more than one source class cannot be applied to the same route.

In Junos OS Release 9.3 and later, you can configure SCU accounting for Layer 3 VPNs configured with the vrf-table-label statement. Include the source-class-usage statement at the [edit routing-instances routing-instance-name vrf-table-label] hierarchy level. The source-class-usage statement at this hierarchy level is supported only for the virtual routing and forwarding (VRF) instance type.

Note:

You cannot enable DCU counters on the label-switched interface (LSI) that is created dynamically when the vrf-table-label statement is configured within a VRF. For more information, see the Junos OS VPNs Library for Routing Devices.

For a complete discussion about source and destination class accounting profiles, see the Junos OS Network Management Administration Guide for Routing Devices. For more information about MPLS, see the MPLS Applications User Guide.

Enable Source Class and Destination Class Usage

Figure 2: Prefix Accounting with Source and Destination ClassesPrefix Accounting with Source and Destination Classes

Before you can enable source class usage (SCU) and destination class usage (DCU), you must configure DCU and SCU output on one interface:

To enable source class and destination class usage:

  1. Complete the SCU Configuration

    Source routers A and B use loopback addresses as the prefixes to be monitored. Most of the configuration tasks and actual monitoring occur on transit Router SCU.

    The loopback address on Router A contains the origin of the prefix that is to be assigned to source class A on Router SCU. However, no SCU processing happens on this router. Therefore, configure Router A for basic OSPF routing and include your loopback interface and interface so-0/0/2 in the OSPF process.


  2. Apply the policy to the forwarding table, configuring a route filter policy statement that matches the prefixes of the loopback addresses from routers A and B.

    Last, apply the policy to the forwarding table.

    Router SCU handles the bulk of the activity in this example. On Router SCU, enable source class usage on the inbound and outbound interfaces at the [edit interfaces interface-name unit unit-number family inet accounting] hierarchy level. Make sure you specify the expected traffic: input, output, or, in this case, both.

    When you configure a route filter policy statement that matches the prefixes of the loopback addresses from routers A and B. Include statements in the policy that classify packets from Router A in one group named scu-class-a and packets from Router B in a second class named scu-class-b. Notice the efficient use of a single policy containing multiple terms.

  3. Configure Router B.

    Just as Router A provides a source prefix, Router B's loopback address matches the prefix assigned to scu-class-b on Router SCU. Again, no SCU processing happens on this router, so configure Router B for basic OSPF routing and include your loopback interface and interface so-0/0/4 in the OSPF process.

  4. Configure a virtual loopback tunnel interface on a provider edge router equipped with a tunnel PIC.

    You can use SCU and DCU to count packets on Layer 3 VPNs. To enable packet counting for Layer 3 VPN implementations at the egress point of the MPLS tunnel, you must configure a virtual loopback tunnel interface (vt) on the PE router, map the virtual routing and forwarding (VRF) instance type to the virtual loopback tunnel interface, and send the traffic received from the VPN out the source class output interface, as shown in the following example:

  5. Map the VRF instance type to the virtual loopback tunnel interface.

    In Junos OS Release 9.3 and later, you can configure SCU accounting for Layer 3 VPNs configured with the vrf-table-label statement. Include the source-class-usage statement at the [edit routing-instances routing-instance-name vrf-table-label] hierarchy level. The source-class-usage statement at this hierarchy level is supported only for the virtual routing and forwarding (VRF) instance type. DCU is not supported when the vrf-table-label statement is configured. For more information, see the Junos OS VPNs Library for Routing Devices.

  6. Send traffic received from the VPN out the source class output interface.

    For more information about VPNs, see the Junos OS VPNs Library for Routing Devices. For more information about virtual loopback tunnel interfaces, see the Junos OS Services Interfaces Library for Routing Devices.

Understanding Targeted Broadcast

Targeted broadcast is a process of flooding a target subnet with Layer 3 broadcast IP packets originating from a different subnet. The intent of targeted broadcast is to flood the target subnet with the broadcast packets on a LAN interface without broadcasting to the entire network. Targeted broadcast is configured with various options on the egress interface of the router or switch, and the IP packets are broadcast only on the LAN (egress) interface. Targeted broadcast helps you implement remote administration tasks, such as backups and wake-on LAN (WOL) on a LAN interface, and supports virtual routing and forwarding (VRF) instances.

Regular Layer 3 broadcast IP packets originating from a subnet are broadcast within the same subnet. When these IP packets reach a different subnet, they are forwarded to the Routing Engine (to be forwarded to other applications). Because of this, remote administration tasks such as backups cannot be performed on a particular subnet through another subnet. As a workaround, you can enable targeted broadcast to forward broadcast packets that originate from a different subnet.

Layer 3 broadcast IP packets have a destination IP address that is a valid broadcast address for the target subnet. These IP packets traverse the network in the same way as unicast IP packets until they reach the destination subnet, as follows:

  1. In the destination subnet, if the receiving router has targeted broadcast enabled on the egress interface, the IP packets are forwarded to an egress interface and the Routing Engine or to an egress interface only.
  2. The IP packets are then translated into broadcast IP packets, which flood the target subnet only through the LAN interface, and all hosts on the target subnet receive the IP packets. The packets are discarded If no LAN interface exists.
  3. The final step in the sequence depends on targeted broadcast:
    • If targeted broadcast is not enabled on the receiving router, the IP packets are treated as regular Layer 3 broadcast IP packets and are forwarded to the Routing Engine.
    • If targeted broadcast is enabled without any options, the IP packets are forwarded to the Routing Engine.

You can configure targeted broadcast to forward the IP packets only to an egress interface. This is helpful when the router is flooded with packets to process, or to both an egress interface and the Routing Engine.

Note:

Any firewall filter that is configured on the Routing Engine loopback interface (lo0) cannot be applied to IP packets that are forwarded to the Routing Engine as a result of a targeted broadcast. This is because broadcast packets are forwarded as flood next-hop traffic and not as local next-hop traffic, and you can apply a firewall filter only to local next-hop routes for traffic directed towards the Routing Engine.

Configure Targeted Broadcast

The following sections explain how to configure targeted broadcast on an egress interface and its options:

Configure Targeted Broadcast and Its Options

You can configure targeted broadcast on an egress interface with different options.

Either of these configurations is acceptable:

  • You can allow the IP packets destined for a Layer 3 broadcast address to be forwarded on the egress interface and to send a copy of the IP packets to the Routing Engine.

  • You can allow the IP packets to be forwarded on the egress interface only.

Note that the packets are broadcast only if the egress interface is a LAN interface.

To configure targeted broadcast and its options:

  1. Configure the physical interface.
  2. Configure the logical unit number at the [edit interfaces interface-name hierarchy level.
  3. Configure the protocol family as inet at the [edit interfaces interface-name unit interface-unit-number hierarchy level.
  4. Configure targeted broadcast at the [edit interfaces interface-name unit interface-unit-number family inet hierarchy level.
  5. Allow IP packets to be forwarded on the egress interface only.
Note:

SRX devices do not support the targeted broadcast option forward-and-send-to-re.

Display Targeted Broadcast Configuration Options

The following example topics display targeted broadcast configuration options:

Example: Forward IP Packets on the Egress Interface and to the Routing Engine

Purpose

Display the configuration when targeted broadcast is configured on the egress interface to forward the IP packets on the egress interface and to send a copy of the IP packets to the Routing Engine.

Action

To display the configuration, run the show command at the [edit interfaces interface-name unit interface-unit-number family inet] where the interface name is ge-2/0/0, the unit value is set to 0, and the protocol family is set to inet.

Example: Forward IP Packets on the Egress Interface Only

Purpose

Display the configuration when targeted broadcast is configured on the egress interface to forward the IP packets on the egress interface only.

Action

To display the configuration, run the show command at the [edit interfaces interface-name unit interface-unit-number family inet] where the interface name is ge-2/0/0, the unit value is set to 0, and the protocol family is set to inet.