Configuring Interfaces on the Router


From the point of view of the JUNOS software, interface properties belong to the following groups:

  • Physical interface properties, which are properties of the media type that apply to the interface device itself. You configure physical interface properties at the [edit interfaces interface- name ] hierarchy level.

  • Logical interface properties, which include the protocol family and other properties that vary by PIC and encapsulation type, including the IP address of the interface, whether the interface supports multicast traffic, DLCIs, VCIs and VPIs, and traffic shaping. You configure logical interface properties at the [edit interfaces interface-name unit logical-unit-number ] hierarchy level.

  • Family interface properties, which define the protocols supported on the interface. You configure these properties at the [edit interfaces interface-name unit logical-unit-number family family ] hierarchy level.

  • Address interface properties, which configure the IP and other addresses associated with the interface. You configure these properties at the [edit interfaces interface-name unit logical-unit-number address address ] hierarchy level.

This section describes some of the more important physical, logical, family, and address interface properties. The remainder of this chapter describes how to configure the interfaces corresponding to specific PIC types.

Configuring Physical Interface Properties

For each network media type, the software driver for that media sets reasonable default values for general interface properties, such as the interface's MTU size, receive and transmit leaky bucket properties, link operational mode, and clock source. To modify any of the default general interface properties, include one or more of the following statements:

 [edit interfaces  interface-name  ]  access-profile  name  ; clocking  clock-source  ; dce; disable; description  text  ; encapsulation  type  ; hold-time up  milliseconds  down  milliseconds  ; keepalives <down-count  number  > <interval  seconds  >   <up-count  number  >; link-mode  mode  ; mac  mac-address  ; mtu  bytes  ; no-keepalives; no-traps; ppp-options {   chap {     access-profile  name  ;     local-name  name  ;     passive;   } } receive-bucket {   overflow (tag  discard);   rate  percentage  ;   threshold  number  ; } speed (10m  100m); transmit-bucket {   overflow (discard);   rate  percentage  ;   threshold  number  ; } 

To configure the interface name, specify it:

 [edit interfaces]  interface-name  {   ... } 

You can include a text description of each physical interface in the configuration file. Any descriptive text you include is displayed in the output of the show interfaces commands but has no impact on the interface's configuration. To add a text description, include the description statement:

 [edit interfaces  interface-name  ]  description  text  ; 

The default media MTU size used on a physical interface depends on the encapsulation being used on that interface. Table 6.2, Table 6.3, and Table 6.4 list the media MTU size by interface type, whereas Table 6.5 lists the encapsulation overhead by encapsulation type. Note that the physical MTU for Ethernet interfaces does not include the 4-byte FCS field of the Ethernet frame.

Table 6.2. Media MTU Sizes by Interface Type for M5, M10, M20, and M40 Routers
Interface Type Default Media MTU (Bytes) Maximum MTU (Bytes) Default IP Protocol MTU (Bytes)
ATM 4,482 9,192 4,470
E1/T1 1,504 9,192 1,500
E3/T3 4,474 9,192 4,470
Fast Ethernet 1,514 9,192

1,500 (IPv4)

1,497 (ISO)

Gigabit Ethernet 1,514 9,192

1,500 (IPv4)

1,497 (ISO)

SONET/SDH 4,474 9,192 4,470
Table 6.3. Media MTU Sizes by Interface Type for M40e and M160 Routers
Interface Type Default Media MTU (Bytes) MaximumMTU (Bytes) Default IP Protocol MTU (Bytes)
ATM 4,482 9,192 4,470
E1/T1 1,504 4,500 1,500
E3/T3 4,474 4,500 4,470
Fast Ethernet 1,514 4,500

1,500 (IPv4)

1,497 (ISO)

Gigabit Ethernet 1,514

9,192 (1- or 2-port PICs)

4,500 (4-port PICs)

1,500 (IPv4)

1,497 (ISO)

SONET/SDH 4,474 4,500 4,470
Table 6.4. Media MTU Sizes by Interface Type for T-series Platforms
Interface Type Default Media MTU (Bytes) Maximum MTU (Bytes) Default IP Protocol MTU (Bytes)
48-port Fast Ethernet 1,514 1,532

1,500 (IPv4)

1,497 (ISO)

Gigabit Ethernet

1- or 2-port

4-port

10-gigabit

1,514

9,192

4,500

9,192

1,500 (IPv4)

1,497 (ISO)

SONET/SDH 4,474 9,192 4,470
Table 6.5. Encapsulation Overhead by Encapsulation Type
Interface Encapsulation Encapsulation Overhead (Bytes)
ATM PVC 12
Cisco HDLC 4
Ethernet Version 2 14
Ethernet 802.3 17
802.1Q/Ethernet Version 2 18
802.1Q/Ethernet 802.3 21
Ethernet SNAP 22
802.1Q/Ethernet SNAP 26
Frame Relay 4
Point-to-Point Protocol 4

The default media MTU is calculated as follows :

Default media MTU = Default IP MTU + encapsulation overhead

When you are configuring point-to-point connections, the MTU sizes on both sides of the connections must be the same. Also, when you are configuring point-to-multipoint connections, all interfaces in the subnet must use the same MTU size. The actual frames transmitted also contain cyclic redundancy check (CRC) bits, which are not part of the media MTU. For example, the media MTU for a Gigabit Ethernet interface is specified as 1,500 bytes, but the largest possible frame size is actually 1,504 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

To modify the default media MTU size for a physical interface, include the mtu statement:

 [edit interfaces  interface-name  ]  mtu  bytes  ; 

For more information about protocol MTUs, see page 205.

If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead. You configure the protocol MTU by including the mtu statement at the [edit interfaces interface-name unit logical-unit-number family family ] hierarchy level.

Point-to-Point Protocol (PPP) encapsulation is the default encapsulation type for physical interfaces. You need not configure encapsulation for any physical interfaces that support PPP encapsulation. If you do not configure encapsulation, PPP is used by default. For physical interfaces that do not support PPP encapsulation, you must configure an encapsulation to use for packets transmitted on the interface. You can optionally configure an encapsulation on a logical interface, which is the encapsulation used within certain packet types.

Defined in RFC 1331, The Point-to-Point Protocol (PPP) for the Transmission of Multiprotocol Datagrams over Point-to-Point Links .

The physical interface encapsulation can be one of the following:

  • Point-to-Point Protocol (PPP) ”PPP is the default encapsulation type for physical interfaces. E1, E3, SONET, T1, and T3 interfaces can use PPP encapsulation. Two related versions are supported:

    • Circuit cross-connect (CCC) version ( ppp-ccc ) ”The logical interfaces do not require an encapsulation statement, but they cannot have families.

    • Translational cross-connect (TCC) version ( ppp-tcc ) ”Similar to CCC and having the same configuration restrictions, but used for circuits with different media on either side of the connection.

  • ATM cell relay ”Connects two remote virtual circuits or ATM physical interfaces with a label-switched path (LSP). Traffic on the circuit is ATM cells .

Defined in RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5 .

  • ATM PVC ”When you configure physical ATM interfaces with ATM PVC encapsulation, you can configure the logical interfaces with any ATM encapsulation.

  • Cisco HDLC ”E1, E3, SONET, T1, and T3 interfaces can use Cisco HDLC encapsulation. Two related versions are supported:

    • CCC version ( cisco-hdlc-ccc ) ”The logical interfaces do not require an encapsulation statement, but they cannot have families.

    • TCC version ( cisco-hdlc-tcc ) ”Similar to CCC and having the same configuration restrictions, but used for circuits with different media on either side of the connection.

  • Ethernet circuit cross-connect (CCC) ”Untagged Ethernet interfaces can use Ethernet CCC encapsulation. This encapsulation type is supported only on the four-port Fast Ethernet PIC.

Defined in RFC 1490, Multiprotocol Interconnect over Frame Relay .

  • Frame Relay ”E1, E3, SONET, T1, and T3 interfaces can use Frame Relay encapsulation. Two related versions are supported:

    • CCC version ( frame-relay-ccc ) ”The same as standard Frame Relay for DLCIs 0 through 511. DLCIs 512 through 1,022 are dedicated to CCC, and the logical interface must also use Frame Relay CCC encapsulation.

    • TCC version ( frame-relay-tcc ) ”Similar to Frame Relay CCC and having the same configuration restrictions, but used for circuits with different media on either side of the connection.

  • VLAN circuit cross-connect (CCC) ”Ethernet interfaces with Virtual Local Area Network (VLAN) tagging enabled can use VLAN CCC encapsulation.

To configure the encapsulation on a physical interface, include the encapsulation statement:

 [edit interfaces  interface-name  ]  encapsulation (atm-ccc-cell-relay  atm-pvc  cisco-hdlc      cisco-hdlc-ccc  cisco-hdlc-tcc  ethernet-ccc      frame-relay  frame-relay-ccc  frame-relay-tcc  ppp      ppp-ccc  ppp-tcc  vlan-ccc); 

When you configure a point-to-point encapsulation (such as PPP or Cisco HDLC) on a physical interface, the physical interface can have only one logical interface (that is, only one unit statement) associated with it. When you configure a multipoint encapsulation (such as Frame Relay), the physical interface can have multiple logical units, and the units can be either point-to-point or multipoint.

Ethernet interfaces in VLAN mode can have multiple logical interfaces, but in CCC mode VLAN IDs from 0 through 511 are reserved for normal VLANs, and VLAN IDs from 512 through 4,095 are reserved for CCC VLANs.

When you configure a TCC encapsulation, some modifications are needed to handle VPN connections over unlike Layer 2 links and terminate the Layer 2 protocol locally. The router performs the following media-specific changes:

  • ATM ”Operation, Administration, and Maintenance (OAM) and Interim Local Management Interface (ILMI) processing is terminated at the router. Cell relay is not supported. The JUNOS software strips all ATM encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to ATM encapsulation.

  • Cisco HDLC TCC ”Keepalive processing is terminated on the router. The JUNOS software strips all Cisco HDLC encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to Cisco HDLC encapsulation.

  • Frame Relay TCC ”All Local Management Interface (LMI) processing is terminated on the router. The JUNOS software strips all Frame Relay encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to Frame Relay encapsulation.

  • PPP TCC ”Both Link Control Protocol (LCP) and Network Control Protocol (NCP) are terminated on the router. Internet Protocol Control Protocol (IPCP) IP address negotiation is not supported. The JUNOS software strips all PPP encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to PPP encapsulation.

The ATM encapsulations are defined in RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5 .

Generally, you configure an interface's encapsulation at the [edit interfaces interface-name ] hierarchy level. However, for some encapsulation types, such as Frame Relay, ATM, and Ethernet VLAN, you also can configure the encapsulation type that is used inside the Frame Relay, ATM, or VLAN circuit itself. To do this, include the encapsulation statement when configuring the logical interface:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  encapsulation (atm-ccc-cell-relay  atm-nlpid  atm-cisco-     nlpid  atm-snap  atm-vc-mux  atm-ccc-vc-mux      frame-relay-ccc  multilink-framerelay  multilink-ppp      vlan-ccc); 

With the atm-nlpid , atm-cisco-nlpid , and atm-vc-mux encapsulations, you can configure the family inet only. With the circuit cross-connect (CCC) encapsulations, you cannot configure a family on the logical interface. A logical interface cannot have frame-relay-ccc encapsulation unless the physical device also has frame-relay-ccc encapsulation. In addition, you must assign this logical interface a DLCI in the range 512 through 1,022 and configure it as point-to-point.

A logical interface cannot have vlan-ccc encapsulation unless the physical device also has vlan-ccc encapsulation. You must also assign this logical interface a VLAN ID in the range 512 through 1,023; if the VLAN ID is 511 or lower, it is subject to the normal destination filter lookups in addition to source address filtering.

You can create an ATM cell relay circuit by configuring an entire ATM physical device or an individual virtual circuit (VC). When you configure an entire device, only cell relay encapsulation is allowed on the logical interfaces; you control the number and location of VCs using the atm-options statement. Allowed VCs on both ingress and egress ATM interfaces should be the same. You can define a maximum of 4,090 VCs per interface.

If you are dedicating the entire device to a cell relay circuit, include the allow_any_vci statement under unit 0 as shown in the following example. After you enter this statement, you cannot configure other logical interfaces in the same physical interface.

 [edit interfaces at-1/2/0]  encapsulation atm-ccc-cell-relay; atm-options {   vpi 0 maximum-vcs 256; } unit 0 {   point-to-point;   encapsulation atm-ccc-cell-relay;   allow_any_vci; } 

Alternatively, to configure an individual VC on a specific logical interface, include statements similar to the following example:

 [edit interfaces at-1/1/0]  encapsulation atm-ccc-cell-relay; atm-options {   vpi 0 maximum-vcs 256; } unit 120 {   encapsulation atm-ccc-cell-relay;   vci 0.120; } 

When you use ATM CCC cell relay encapsulation, you must configure both the physical and logical encapsulation with atm-ccc-cell-relay encapsulation. You cannot mix different logical encapsulation types on an interface that you have configured with ATM CCC cell relay physical encapsulation.

You can configure interfaces to support PPP Challenge Handshake Authentication Protocol (CHAP), as defined in RFC 1994. When CHAP is enabled, an interface with PPP encapsulation can authenticate its peer and can be authenticated by its peer. By default, PPP CHAP is disabled. If CHAP is not explicitly enabled, the interface makes no CHAP challenges and denies all incoming CHAP challenges. To enable CHAP on links with PPP encapsulation, you must create a global mapping of link names and authentication data associated with those links, and you must create a per-interface configuration.

See RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP) .

To create a global mapping of link names and authentication data, you configure access profiles using statements in the access hierarchy; The per-interface configuration includes a reference to an access profile. When a given interface receives CHAP challenges and responses, the named access profile in the packet is used to look up the shared secret.

To configure PPP CHAP on an interface with PPP encapsulation, include the chap statement:

 [edit interfaces  interface-name  ppp-options]  chap {   access-profile  name  ;   local-name  name  ;   passive; } 

The CHAP authentication method depends on a "secret" known only to the authenticator and that peer. The secret is not sent over the link. An access profile is a map between peer names (or " clients ") and the secrets associated with their respective links. When an interface receives CHAP challenges and responses, the value of the access profile is extracted from the packets. This value is the identity of the peer for a given interface. To assign an access profile to an interface, include the access-profile statement:

 [edit interfaces  interface-name  ppp-options chap]  access-profile  name  ; 

You can configure the value sent in CHAP challenge and response packets on a per-interface basis. By default, each interface uses the router's system hostname as the name sent in CHAP challenge and response packets. To configure the name sent in CHAP challenge and response packets, include the local-name statement:

 [edit interfaces  interface-name  ppp-options chap]  local-name  name  ; 

By default, when the chap statement is configured, the interface always challenges its peer and responds to challenges from its peer. You can configure the interface not to challenge its peer, and only respond when challenged. To configure the interface not to challenge its peer, include the passive statement:

 [edit interfaces  interface-name  ppp-options chap]  passive; 

By default, SNMP notifications are sent when the interface or connection state changes. To disable this notification on the physical interface, include the no-traps statement:

 [edit interfaces  interface-name  ]  no-traps; 

Configuring Logical Interface Properties

To configure logical interface properties, include the unit statement and one or more of the statements in its hierarchy:

 [edit interfaces  interface-name  ]  unit  logical-unit-number  {   access-profile  name  ;   disable;   dlci  dlci-identifier  ;   drop-timeout  milliseconds  ;   encapsulation  type  ;   fragment-threshold  bytes  ;   inverse-arp;   mrru  bytes  ;   multicast-dlci  dlci-identifier  ;   multicast-vci  vpi-identifier.   vci-identifier  ;   multipoint;   no-traps;   oam-liveness {     up-count  cells  ;     down-count  cells  ;   }   oam-period (disable  seconds );   point-to-point;   shaping {     (cbr  rate  vbr peak  rate  sustained  rate  burst  length  );     queue-length  number  ;   }   short-sequence;   tunnel {     source  source-address  ;     destination  destination-address  ;     routing-instance {     destination  routing-instance-name  ;     }     ttl  number  ;   }   vci  vpi-identifier.  vci-identifier;   vlan-id  number  ; } 

Each logical interface must have a logical unit number. The logical unit number corresponds to the logical unit part of the interface name. PPP and Cisco HDLC encapsulations support only a single logical interface, whose logical unit number must be 0. Frame Relay and ATM encapsulations support multiple logical interfaces, so you can configure one or more logical unit numbers .You specify the logical unit number in the unit statement. The logical unit number can range from 0 through 16,384.

 [edit interfaces]  interface-name  {   unit 0 {     ...   } } 

By default, all interfaces are assumed to be point-to-point connections. You must ensure that the MTU sizes on both sides of the connection are the same. Optionally, you can explicitly configure an interface to be a point-to-point connection by including the point-to-point statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  point-to-point; 

To configure an interface to be a multipoint connection, include the multipoint statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  multipoint; 

By default, SNMP notifications are sent when the state of an interface or a connection changes. To disable these notifications on the logical interface, include the no-traps statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  no-traps; 

Configuring Family and Address Interface Properties

For each logical interface, you must configure one or more protocol families, and you can configure interface address properties. To do this, include one or more of the following statements:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  family  family  {   bundle ml-  fpc/pic/port  ;   destination-class-usage;   filter {     input  filter-name  ;     output  filter-name  ;     group  filter-group-number  ;   }   ipsec-sa  sa-name  ;   mtu  bytes  ;   multicasts-only;   no-redirects;   primary;   address  address  {     arp  ip-address  (mac  multicast-mac)  mac-address  <publish>;     destination  destination-address  ;     broadcast  address  ;     multipoint-destination  destination-address  (dlci  dlci-identifier  vci  vci-identifier  );     multipoint-destination  destination-address  {       inverse-arp;       oam-liveness {         up-count  cells  ;         down-count  cells  ;       }       oam-period  seconds  ;       shaping {         (cbr rate  vbr peak  rate  sustained  rate  burst  length  );         queue-length  number  ;       }       vci  vpi-identifier.   vci-identifier  ;     }     preferred;     primary;     vrrp-group  group-number  {       virtual-address [  addresses  ];       priority  number  ;       (accept-data  no-accept-data);       advertise-interval  seconds  ;       authentication-type  authentication  ;       authentication-key  key  ;       (preempt  no-preempt);       track {         interface  interface-name  priority-cost  cost  ;  }     }   } } 

To configure the logical interface's protocol family, include the family statement, specifying the selected family. To configure more than one protocol family on a logical interface, include multiple family statements. Following is the minimum configuration:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  family  family  {   mtu  size  ;   multicasts-only ;   no-redirects;   primary;   address  address  {     destination  address  ;     broadcast address ;     primary;     preferred;   } } 

For each logical interface, you can configure one or more of the following protocol families to run on the interface:

  • inet ” IP (Internet Protocol). You must configure this protocol family for the logical interface to support IP protocol traffic, including OSPF, BGP, and ICMP.

  • iso ” ISO. You must configure this protocol family for the logical interface to support IS-IS traffic.

  • mlfr ” Multilink Frame Relay (MLFR). You must configure this protocol (or MLPPP) for the logical interface to support multilink bundling.

  • multilink-ppp ” Multilink Point-to-Point Protocol (MLPPP). You must configure this protocol (or MLFR) for the logical interface to support multilink bundling.

  • mpls ” Multiprotocol Label Switching (MPLS). You must configure this protocol family for the logical interface to participate in an MPLS path.

  • tnp ” Trivial Network Protocol (TNP). This protocol is used to communicate between the Routing Engine and the System Control Board (SCB), System and Switch Board (SSB), Forwarding Engine Board (FEB), or System and Forwarding Module (SFM), depending on router model, in the router's Packet Forwarding Engine. The JUNOS software automatically configures this protocol family on the router's internal interfaces.

You assign an address to an interface by specifying the address in the address statement when configuring the protocol family. For the inet family, you configure the interface's IP address. For the iso family, you configure an address for the loopback interface. For the mpls and tnp families, you never configure an address. The JUNOS software also supports IS-IS addresses on interfaces other than lo0 , such as ATM, Fast Ethernet, SONET/SDH, T1, and T3 interfaces. This can be useful when you are running multiple instances of IS-IS.

To configure the address of the remote side of the connection (for point-to-point interfaces only), include the destination statement.

To configure the broadcast address for the interface's subnet, include the broadcast statement. This statement applies only to Ethernet interfaces, such as the management interface fxp0 , the Fast Ethernet interface, and the Gigabit Ethernet interface.

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 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. Otherwise, the primary address on the primary interface is used.

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 statement) 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 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 the fxp0 interface is picked by default. To configure a different interface to be the primary interface, include the primary statement:

 [edit interfaces  interface-name  unit  logical-unit-number  family  family  ] primary; 

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

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

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 128.100.1.1/24 , 128.100.1.2/24 , and 128.100.1.3/24 are configured on the same interface, the preferred address on the subnet (by default, 128.100.1.1 ) would be used as a local address when you issue a ping 128.100.1.5 command. To set a different preferred address for the subnet, include the preferred statement:

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

When you need to conserve IP addresses, you can configure unnumbered interfaces. To do this, configure the protocol family, but do not include the address statement:

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

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

For each interface, you can configure an interface-specific MTU by including the mtu statement at the [edit interfaces interface-name ] hierarchy level. To modify this MTU for a particular protocol family, include the mtu statement:

 [edit interfaces  interface-name  unit  logical-unit-number  family  family  ] mtu  mtu  ; 

For more information about MTUs, see Tables 6.2, 6.3 and 6.4 beginning on page 191.

The default protocol MTU is 4,470 bytes for ATM PVC, Cisco HDLC, Frame Relay, and PPP encapsulations. For Ethernet encapsulation on IPv4, the default protocol MTU is 1,500 bytes. For Ethernet encapsulation on ISO, the default protocol MTU is 1,497 bytes. When you initially configure an interface, the protocol MTU is calculated automatically. However, if you subsequently change the media MTU, the protocol MTU on existing address families does not automatically adjust. 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 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.)

For Ethernet encapsulation when the family is mpls , the default protocol MTU is 1,488 bytes. MPLS packets are 1,500 bytes and have 4 to 12 bytes of overhead. The maximum number of DCLIs is determined by the MTU on the interface. If you have keepalives enabled, the maximum number of DLCIs is 1,000, with the MTU set to 5,012. 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 specified as 1,500 bytes, but the largest possible frame size is actually 1,504 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

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

 [edit interfaces  interface-name  unit  logical-unit-number  family  family  ] no-redirects; 

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

See Chapter 8, "Routing Policy and Firewall Filters," on page 301.

To apply firewall filters to an interface, include the filter statement. 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 output statement, list the name of one firewall filter to be evaluated when packets are transmitted on the interface. You can use the same filter one or more times. If you apply the filter to the lo0 interface, it is applied to packets received or transmitted by the Routing Engine.

 [edit interfaces interfaces  interface-name  unit  logical-   unit-number  ] family inet {   filter {     group  group-number  ;     input  filter-name  ;     output  filter-name  ;   } } 

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. To define the interface to be part of an interface group, include the group statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  family inet {   filter {     group  group-number  ;   } } 

You can maintain packet counts based on the entry and exit points for traffic passing through your network. The entry point is identified by the input interface. Exit points are identified by destination prefixes grouped into one or more disjoint sets defined as a destination class. You can set up one counter per interface per destination class, up to a maximum of 16 counters per interface. You can configure multiple destination classes, up to a global limit of 16 destination classes in a configuration. To configure destination-class usage, your router must be equipped with the Internet Processor II ASIC. To enable packet counting on an interface, include the destination-class-usage statement:

 [edit interfaces  interface-name  unit  logical-unit-number  family inet] destination-class-usage; 

See "Configuring Routing Policy," on page 326.

After you enable accounting on an interface, the software maintains packet counters for that interface. You must then configure the destination-class attribute in a policy action statement, which must be included in a forwarding-table export policy.

To use IPSec security services, you create a security association (SA) between hosts. An SA is a simplex connection that allows two hosts to communicate with each other securely by means of IPSec. You can configure two types of SAs:

  • Manual ”Requires no negotiation; all values, including the keys, are static and specified in the configuration. As a result, each peer must have the same configured options for communication to take place.

  • Dynamic ”Specifies proposals to be negotiated with the tunnel peer. The keys are generated as part of the negotiation and therefore do not need to be specified in the configuration. The dynamic SA includes one or more proposal statements, which allow you to prioritize a list of protocols and algorithms to be negotiated with the peer.

To configure an SA for IPSec, include the security-association statement:

 [edit security ipsec]  security-association  name  ; 

To configure encryption interfaces, you associate the security profile with the interface by including the ipsec-sa sa-name statement:

 [edit interfaces es-  fpc/pic/port  unit  logical-unit-number  family inet] ipsec-sa  sa-name  ; 


Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net