Protocol Family and Interface Address Properties

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.

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.

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

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

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

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

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

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

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

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

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

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

• Purpose
• Action
• Meaning

• Purpose
• Action
• Meaning

• Purpose
• Action
• Meaning

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]

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.

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.

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

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

direction can be one of the following:

• input—Configure at least one expected ingress point.

• output—Configure at least one expected egress point.

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

You can include these statements at the following hierarchy levels:

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

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

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

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

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

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

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

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

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

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

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

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

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.

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