Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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.

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

When configuring the protocol family, complete the following tasks under the [edit interfaces interface-name unit logical-unit-number family family] hierarchy.

  • Configure MTU.

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

  • Disable the sending of redirect messages by the router.

  • Assign an address to an interface.

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.

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.

    • 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] For interfaces that carry IPv6 traffic, configure the host to assign itself a unique 64-Bit IP Version 6 interface identifier (EUI-64).

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.

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

You can include this statement at the following hierarchy level:

[edit 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 et-0/0/0.0 255.255.255.255 command is the primary address on interface et-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]

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]

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.

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 following sample output (for the preceding configuration) reveals that only et-0/1/0.0 was assigned the same IPv4 address 203.0.113.1/24 and its link state was up, while et-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 et-0/0/0.0 and et-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 interfaces is up at any given time (following a redundancy scheme outside of the Junos OS Evolved 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 interfaces gets successfully configured on P2P interfaces when you try to configure the same IPv4 address for multiple instance of different interfaces.

    show interfaces terse

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:

  • 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 therefore 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 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.

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.

  • 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:

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 —et-1/0/0

  • Donor interface —et-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.

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 —et-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 et-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 —et-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 et-0/0/0.0.

Meaning

In this example, et-0/0/0 is the unnumbered interface. A loopback interface, lo0, is the donor interface from which et-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 et-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 Evolved 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.

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.

Disable the Removal of Address and Control Bytes

For some 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]

See Also

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 level:

[edit 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]

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.

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]

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:

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

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.

If you apply the filter to interface lo0, it is applied to packets received or transmitted by the Routing Engine.

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

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 et-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 et-0/0/3.0.

  3. The output filter installed at et-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 et-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)]

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

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.

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.

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 et-0/0/2 in the OSPF process.


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

  4. 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 et-0/0/4 in the OSPF process.

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

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

    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.

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

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.

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 et-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 et-2/0/0, the unit value is set to 0, and the protocol family is set to inet.