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.

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

Junos OS 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 protocol families sometimes use the following protocol suites. For more information see, family.

To configure the logical interface’s protocol family, include the family statement, specifying the selected family. To configure the protocol family, following are 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

See also

Configuring 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 (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 IPv4 address on routers and switches running Junos OS, 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 IPv6 address on routers and switches running Junos OS, use the interface interface-name unit number family inet6 address aaaa:bbbb:...:zzzz/nn statement at the [edit interfaces] hierarchy level.

      Note
      • You represent IP version 6 (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.
  4. [Optional] For interfaces that carry IP version 6 (IPv6) traffic, configure the host to assign iteslf a unique 64-Bit IP Version 6 interface identifier (EUI-64).

Configuring 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 pick 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.

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.

Configuring 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 picked. In practice, this means that, on the router, the fxp0 or em0 interface is picked 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]

Configuring 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 also can 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]

Configuring 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) would be 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 When the Same IPv4 Address Is Assigned to Them

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) 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, Junos OS 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 implicitly and explicitly point-to-point interfaces, and their corresponding show interfaces terse command outputs to see their operational status.

  • Configuring 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 200.1.1.1/24 and its link state was up, while ge-3/0/1.0 was not assigned the IPv4 address, though its link state was up, which means that it will be operational only when it gets a unique IPv4 address other than 200.1.1.1/24.

    show interfaces terse

    user@host> show interfaces terse ge*
  • Configuring same IPv4 address on (implicit) p2p interfaces:

    The sample output shown below for the above configuration reveals that both so-0/0/0.0 and so-0/0/3.0 were assigned the same IPv4 address 200.1.1.1/24 and that their link states were down. The interfaces are down due to an issue with the link and not because 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 devices scope) as both being up may cause adverse effects.

    show interfaces terse

    user@host> show interfaces terse so*
  • Configuring 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. In this case, commit error will be thrown and the configuration will not be successful.

  • Configuring same IPv4 address in multiple instances of the same p2p interface

    The sample output shown below for the above configuration reveals that only one interfaces gets successfully configured on P2P interfaces, when you try to configure same IPv4 address for multiple instance of different interfaces.

    show interfaces terse

    user@host> show interfaces terse | match 1.2.2.2

Configuring 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. On the logical interface, the following PPP encapsulation types are supported:

  • 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 Example: PPP MP for L2TP

Configuring an Unnumbered Interface

This topic includes the following information:

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 IPv6, in which conserving addresses is not a major concern, you can configure unnumbered interfaces to share the same subnet across multiple interfaces. IPv6 unnumbered interfaces are only supported 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:

Configuring an Unnumbered Point-to-Point Interface

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
  2. To configure an unnumbered point-to-point interface, configure the protocol family, but do not include the address statement.
Note
  • For interfaces with 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 some 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. If you configure an address (other than a martian) on the lo0 interface, that address is always the default address, which is preferable because the loopback interface is independent of any physical interfaces and therefore is always accessible.

Configuring an Unnumbered Ethernet or 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 demultiplexing 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 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 demultiplexing 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.

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

  1. In configuration mode, go to the [edit interfaces interface-name unit logical-unit-number family family-name] hierarchy level.
  2. To configure a secondary address on a loopback donor interface as the preferred source address for an unnumbered Ethernet or demux interface, 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 IPv4 address family for demux interfaces, and for IPv4 and 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 Configuring Unnumbered Ethernet Interfaces

The following restrictions apply when you configure unnumbered Ethernet interfaces:

  • The unnumbered-address statement currently supports the configuration of unnumbered Ethernet interfaces for IPv4 and IPv6 address families.

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

  • The donor interface for an unnumbered Ethernet interface must have one or more configured IP addresses.

  • The donor interface for an unnumbered Ethernet interfaced cannot be configured as unnumbered.

  • An unnumbered Ethernet interface does not support configuration of the following address statement options: arp, broadcast, primary, preferred, and vrrp-group. For information about these options, see Configuring the Interface Address.

  • Running IGMP and PIM are supported only on unnumbered Ethernet interfaces that directly face the host and have no downstream PIM neighbors. IGMP and PIM are not supported on unnumbered Ethernet interfaces that act as upstream interfaces in a PIM topology.

  • Running OSPF and IS-IS on unnumbered Ethernet interfaces is not supported. However, you can run OSPF over unnumbered Ethernet interfaces configured as a Point-to-Point connection.

    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 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, Junos OS uses only the first configuration, the remaining address configurations are ignored and can leave interfaces without an address. Interfaces that do 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 xe-0/0/1.0 is ignored:

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

Displaying 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 that is described works correctly on M and T Series routers. For unnumbered interfaces on MX Series routers, you must additionally 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.

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

Displaying the Configuration for 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 and 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.

Setting the Protocol MTU

When you initially configure an interface, the protocol maximum transmission unit (MTU) is calculated automatically. If you subsequently change the media MTU, the protocol MTU on existing address families automatically changes.

For a list of default protocol MTU values, see Media MTU Sizes by Interface Type.

To modify the MTU for a particular protocol family, include the mtu 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]

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. For a list of encapsulation overhead values, see Encapsulation Overhead by Interface Encapsulation Type. If you reduce the media MTU size, but there are already one or more address families configured and active on the interface, you must also reduce the protocol MTU size. (You configure the media MTU by including the mtu statement at the [edit interfaces interface-name] hierarchy level.)

Note

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

The maximum number of data-link connection identifiers (DLCIs) is determined by the MTU on the interface. If you have keepalives enabled, the maximum number of DLCIs is 1000, with the MTU set to 5012.

The actual frames transmitted also contain cyclic redundancy check (CRC) bits, which are not part of the MTU. For example, the default protocol MTU for a Gigabit Ethernet interface is 1500 bytes, but the largest possible frame size is actually 1504 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

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

You can disable the removal of address and control bytes. To do this, 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]

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

See also

Applying a Filter to an Interface

Defining 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 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 headings 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 more information about port mirroring, see the Junos OS Services Interfaces Library for Routing Devices.

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

Up to 16 filter names can be included 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 Applying 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. Firewall filters configured for the family ccc statement can be applied only as input filters.

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 the 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 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 the 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 the entry 10.50.100.0/25 in the fbf.inet.0 table, and finally leaves the router from interface so-2/0/0.0.

Enabling Source Class and Destination Class Usage

Source Class and Destination Class Usage

For interfaces that carry IPv4, 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) 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 in located in the forwarding table.

Note

SCU and DCU accounting do not work 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 Internet service provider (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 sent from prefix 210.210/16 and 215.215/16 and transmitted on a specific output interface.

Figure 1: Prefix Accounting with Source and Destination Classes
Prefix 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 Junos OS 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 respectively 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 MPC/MIC interfaces , a single incoming packet is counted for both SCU and DCU accounting if both SCU and DCU are configured. To ensure 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 Junos OS 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.

Once you enable accounting on an interface, the Junos OS 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

DCU counters cannot be enabled 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 Network Management and Monitoring Guide. For more information about MPLS, see the MPLS Applications User Guide.

Enabling Source Class and Destination Class Usage

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

Configure DCU and SCU output on one interface:

  1. Complete 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. Router A

  3. Router SCU

    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.

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

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

  5. Enabling Packet Counting for Layer 3 VPNs

    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:

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

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

  7. 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. 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. The IP packets are then translated into broadcast IP packets which flood the target subnet only through the LAN interface (if there is no LAN interface, the packets are discarded), and all hosts on the target subnet receive the IP packets. 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.

Targeted broadcast can be configured to forward the IP packets only to an egress interface, which is helpful when the router is flooded with packets to process, or to both an egress interface and the Routing Engine.

Note

Targeted broadcast does not work when the targeted broadcast option forward-and-send-to-re and the traffic sampling option sampling are configured on the same egress interface of an M320 router, a T640 router, or an MX960 router. To overcome this scenario, you must either disable one of the these options or enable the sampling option with the targeted broadcast option forward-only on the egress interface. For information about traffic sampling, see Configuring Traffic Sampling.

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 and not as local next hop traffic, and you can only apply a firewall filter to local next hop routes for traffic directed towards the Routing Engine.

Configuring Targeted Broadcast

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

Configuring Targeted Broadcast and Its Options

You can configure targeted broadcast on an egress interface with different options. You can either 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 or 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. Specify one of the following options as per requirement:
    • To allow 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.

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

Note

Targeted broadcast does not work when the targeted broadcast option forward-and-send-to-re and the traffic sampling option sampling are configured on the same egress interface of an M320 router, a T640 router, or an MX960 router. To overcome this scenario, you must either disable one of the these options or enable the sampling option with the targeted broadcast option forward-only on the egress interface. For information about traffic sampling, see Configuring Traffic Sampling.

Display Targeted Broadcast Configuration Options

The following topics display targeted broadcast configuration with its various options:

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, the protocol family is set to inet.

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, the protocol family is set to inet.