Ethernet Interfaces

Juniper Networks routers support a variety of different Fast and Gigabit Ethernet PICs. The 12- and 48-port Fast Ethernet PICs supported in the M160 are capable of performing ingress rate limiting and dual-rate (10/100 Mbps) operation at either 10Mbps or 100Mbps, but all remaining Juniper Networks Fast Ethernet PICs require 100Mbps operation and can only be rate-limited through the configuration of IP II–related policers.

M-series Ethernet interfaces support VLAN tagging, 802.3ad link aggregation, and the Virtual Router Redundancy Protocol (VRRP), which is a standards-based protocol that is similar in function to Cisco’s Hot Standby Router Protocol (HSRP). The configuration options supported by Fast and Gigabit Ethernet PICs are very similar, as are the verification mechanisms available to the operator.

This section focuses on Fast Ethernet links because they are the most common interface type found in a certification preparation lab.

Ethernet Interface Physical Configuration

The physical properties for Ethernet interfaces are set at the device and fastether-options or gigether-options portion of the configuration hierarchy, depending on the type of interface being configured. The physical options for Ethernet interfaces include the following:

  • Half/full duplex mode (Fast-E only)

  • Flow control

  • Speed (12- and 48-port Fast-E PICs only)

  • Loopback

  • 802.3ad link aggregation

  • Source address (MAC) filtering

  • Encapsulation (to support Circuit Cross Connect [CCC] applications)

  • VLAN tagging support

  • Manual MAC address assignment

  • Device MTU (Jumbo frames)

Figure 2.6 illustrates the topology used in this Ethernet configuration scenario. In this example, VLAN tagging and VRRP are required on the 10.0.5/24 subnet to which r1 and r2 attach, so your initial Fast Ethernet configuration will require that you enable VLAN tagging at the physical- device level with all other device properties remaining at their defaults.

click to expand
Figure 2.6: Ethernet configuration topology

The following command, issued on both r1 and r2, completes the necessary physical configuration of the Ethernet device to enable support of VLAN-tagged frames:

[edit interfaces fe-0/0/0] lab@r1# set vlan-tagging 

Ethernet Interface Logical Properties

The logical properties for Ethernet interfaces are configured at the logical-unit level, and will relate to the protocol family being configured. For example, the IP protocol is associated with ARP and static ARP entries can be added to a logical unit that supports the IP protocol family. You can also specify the encapsulation (Ethernet II, SNAP, LLC-SNAP) at the logical-unit level for traffic that is originated by the RE, but the default encapsulation associated with each protocol family rarely needs modification, and in some cases cannot be modified despite configuration attempts to the contrary. For example, IP and ARP always use Ethernet Version II (DIX) encapsulation, despite what may be configured under the logical unit.

Tip 

M-series and T-series routers do not perform a translation of Ethernet framing for transit traffic, so that a frame that arrives using DIX encapsulation will always be forwarded using the same encapsulation, regardless of the encapsulation specified on that logical unit. The various encapsulation options listed for Ethernet interfaces only affect traffic generated locally by the RE.

The configuration requirements for this scenario are:

  • IPv4 addressing as shown in Figure 2.6

  • VLAN and VRRP requirements

    • VLAN IDs are 520 and 530.

    • Virtual IP (VIP) addresses = 10.0.5.253 and 10.0.6.253.

    • r1 is master of VLAN 520 when operational.

    • r2 is master of VLAN 530 when operational.

    • Ensure that the VIP is pingable on each VLAN.

r1’s VLAN and VRRP Configuration

The following commands correctly configure r1 for this scenario:

[edit interfaces fe-0/0/0] lab@r1# set unit 520 family inet address 10.0.5.1/24 [edit interfaces fe-0/0/0] lab@r1# set unit 520 vlan-id 520 [edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.1/24] lab@r1# set vrrp-group 1 virtual-address 10.0.5.253 [edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.1/24] lab@r1# set vrrp-group 1 accept-data 

These commands configured r1 to associate VLAN tag 520 with logical unit 520 on its fe-0/0/0 interface, assigned its IP address, and created VRRP group 1 that will use a VIP address of 10.0.5.253. The accept-data option tells the router to "violate" the VRRP specification by allowing it to respond to ICMP echo requests sent to the VIP address. According to the VRRP specification, the VIP master can only respond to ARP requests unless the current VIP is assigned to one of the master router’s interfaces, in which case the VRRP master may respond to all traffic addressed to the VIP. This particular scenario does not require that there be any correlation between the logical unit number and the VLAN ID, but in this example the values have been matched.

Note 

The VLAN assignments used in the previous example will conflict with the VLAN ID range of 512–4094 reserved for VLAN-CCC applications. Because this configuration example does not involve the use of VLAN-CCC encapsulation, these VLAN ID assignments are perfectly valid.

Tip 

Technicians are often confused by the default VRRP behavior of not allowing the VIP address to be pinged, most likely because they have become accustomed to being able to ping the VIP address used by Cisco’s proprietary HSRP protocol. Without the accept-data option, you will not be able to test the VIP address by issuing pings. This behavior has been known to cause JNCIP candidates to engage in troubleshooting procedures to isolate a problem that does not even exist.

The VLAN 520 configuration in r1 is shown next:

lab@r1# show vlan-tagging; unit 520 {    vlan-id 520;    family inet {       address 10.0.5.1/24 {          vrrp-group 1 {             virtual-address 10.0.5.253;             accept-data;          }       }    }  }

Because no priority value has been specified for VRRP group 1, the default value of 100 will be in effect. You will now add the configuration for VLAN 530 to r1, being careful to adjust priorities so that the correct VRRP mastership is achieved when r2 is later brought online:

[edit interfaces fe-0/0/0] lab@r1# set unit 530 family inet address 10.0.6.1/24 [edit interfaces fe-0/0/0] lab@r1# set unit 530 vlan-id 530 [edit interfaces fe-0/0/0] lab@r1# edit unit 530 family inet address 10.0.6.1/24 [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.6.1/24] lab@r1# set vrrp-group 2 virtual-address 10.0.6.253 [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.6.1/24] lab@r1# set vrrp-group 2 accept-data [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.6.1/24] lab@r1# set vrrp-group 2 priority 80 

Because the priority setting for r1’s VRRP group 2 (80) is lower than the default value of 100, the default priority setting in r2 will ensure that it becomes the master of VRRP group 2 when operational. The complete VLAN tagging and VRRP configuration for r1 is shown next:

 [edit interfaces fe-0/0/0] lab@r1# show vlan-tagging; unit 520 {    vlan-id 520;    family inet {       address 10.0.5.1/24 {          vrrp-group 1 {             virtual-address 10.0.5.253;             accept-data;          }       }    }  }  unit 530 {    vlan-id 530;    family inet {       address 10.0.6.1/24 {          vrrp-group 2 {             virtual-address 10.0.6.253;             priority 80;             accept-data;          }       }    }  }

Because r2 has not yet been configured in this example, we expect to see that r1 is currently master of both VRRP groups. The following command verifies that this is the case:

lab@r1> show vrrp summary Interface  Unit  Group Type Address   Int state  VR state fe-0/0/0   520   1     lcl  10.0.5.1    up       master                        vip  10.0.5.253 fe-0/0/0   530   2     lcl  10.0.6.1    up       master                        vip  10.0.6.253

r2’s VLAN and VRRP Configuration

The following commands correctly configure r2 for this scenario:

[edit interfaces fe-0/0/0] lab@r2# set unit 520 family inet address 10.0.5.2/24 [edit interfaces fe-0/0/0] lab@r2# set unit 520 vlan-id 520 [edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.2/24] lab@r2# set vrrp-group 1 virtual-address 10.0.5.253 [edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.2/24] lab@r2# set vrrp-group 1 accept-data [edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.2/24] lab@r2# set vrrp-group 1 priority 80 

These commands configured r2 to associate VLAN tag 520 with its logical unit 520, assigned the interface’s IP address, and configured VRRP group 1 to use the correct Virtual IP address of 10.0.5.253. Worthy of note is the fact that r2 has the priority of VRRP group 1 set to 80, which is lower than the default value of 100 in place on r1. This will ensure that r1 is master of VRRP group 1 when it is operational.

We next add the configuration for VLAN 530 to r2 using the same set of commands used to configure VRRP group 1. The priority of VRRP group 2 is left at the default value of 100 in this case, to ensure that r2 is the master of VRRP group 2 when operational. The completed r2 VRRP/VLAN configuration is shown next:

[edit] lab@r2# show interfaces fe-0/0/0  vlan-tagging; unit 520 {    vlan-id 520;    family inet {       address 10.0.5.2/24 {          vrrp-group 1 {             virtual-address 10.0.5.253;             priority 80;             accept-data;          }       }    }  }  unit 530 {    vlan-id 530;    family inet {       address 10.0.6.2/24 {          vrrp-group 2 {             virtual-address 10.0.6.253;             accept-data;          }       }    }  } 

Verify Basic VRRP Operation

With both r1 and r2 configured as described earlier, we should see that r1 is master of VRRP group 1 while r2 is master of VRRP group 2. Furthermore, either router should take over mastership if the current master fails. The following steps confirm that this is the case:

lab@r1> show vrrp summary Interface   Unit  Group Type  Address   Int state  VR state fe-0/0/0    520   1      lcl  10.0.5.1    up       master                          vip  10.0.5.253 fe-0/0/0    530   2      lcl  10.0.6.1    up       backup                          vip  10.0.6.253

Very good, just as we had expected: r1 is heading the charge for VRRP group 1 and is functioning as a backup for VRRP group 2. To verify that r1 will take over for VRRP group 2, we disable r2’s fe-0/0/0 interface and redisplay VRRP status on r1:

[edit] lab@r2# set interfaces fe-0/0/0 disable  [edit] lab@r2# commit  lab@r1> show vrrp summary Interface   Unit  Group Type  Address   Int state  VR state fe-0/0/0    520    1    lcl   10.0.5.1     up      master                         vip   10.0.5.253 fe-0/0/0    530    2    lcl   10.0.6.1     up      master                         vip   10.0.6.253 

As expected, r1 has become master for both VRRP groups, which confirms that basic VRRP functionality is working as desired. Be sure to re-enable the fe-0/0/0 interface on r2 before proceeding. A thorough operator will perform a similar check for mastership switchover on r2 as well.

VRRP Authentication and Interface Tracking

With basic VRRP functionality working as planned, we will enhance the configuration by adding MD5 authentication and upstream interface tracking. Interface tracking is used to lower the priority of the current VRRP master should its upstream interface become inoperable. Based on Figure 2.6, we can see that both r1 and r2 should track the status of their respective fe-0/0/1 interfaces as these interfaces connect each of them to the upstream router r3.

The following commands add MD5 authentication to both VRRP groups; they must be entered on both r1 and r2 for proper operation. The authentication key value will be set to jni in this example:

[edit interfaces fe-0/0/0 unit 530 family inet address 10.0.5.1/24] lab@r1# set vrrp-group 1 authentication-type md5 [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.5.1/24] lab@r1# set vrrp-group 1 authentication-key jni [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.6.1/24] lab@r1# set vrrp-group 2 authentication-type md5 [edit interfaces fe-0/0/0 unit 530 family inet address 10.0.6.1/24] lab@r1# set vrrp-group 2 authentication-key jni 

The next set of commands instructs the router to deduct 30 from its current priority level (100 by default) should its fe-0/0/1 interface become inoperable. For r2, this command will need to be entered under VRRP group 2:

[edit interfaces fe-0/0/0 unit 520 family inet address 10.0.5.1/24 vrrp-group 1] lab@r1# set track interface fe-0/0/1 priority-cost 30 

The Fast Ethernet configuration for r1 is shown in Listing 2.1, including the configuration of its fe-0/0/1 interface that is now being tracked by VRRP group 1:

Listing 2.1: VRRP Configuration for r1

start example
[edit] lab@r1# show interfaces fxp0 {    unit 0 {       family inet {          address 10.0.1.1/24;       }    }  }  fe-0/0/0 {    vlan-tagging;    unit 520 {       vlan-id 520;       family inet {          address 10.0.5.1/24 {             vrrp-group 1 {                virtual-address 10.0.5.253;                accept-data;                authentication-type md5;                authentication-key "$9$3BYX/A0vMX7-w"; # SECRET-DATA                track {                   interface fe-0/0/1.0 priority-cost 30;                }             }          }       }     }    unit 530 {       vlan-id 530;       family inet {          address 10.0.6.1/24 {             vrrp-group 2 {                virtual-address 10.0.6.253;                priority 80;                accept-data;                authentication-type md5;                authentication-key "$9$rhkKWxJZjHqf"; # SECRET-DATA             }          }       }    }  }  fe-0/0/1 {    unit 0 {       family inet {          address 10.0.4.1/24;       }    } } 
end example

Verify VRRP Interface Tracking

Once the configurations of r1 and r2 have been modified with the authentication and interface tracking–related configuration, you can verify that tracking is working by deactivating the tracked interface and confirming that the expected change in VRRP group mastership occurs. For this example, we will monitor the VRRP state on r2, both before and after r1’s fe-0/0/1 interface is deactivated:

lab@r2> show vrrp summary Interface   Unit Group Type Address   Int state VR state fe-0/0/0    520  1     lcl  10.0.5.2    up      backup                        vip  10.0.5.253 fe-0/0/0    530  2     lcl  10.0.6.2    up      master                        vip  10.0.6.253

Now we disconnect, disable, or deactivate the tracked interface on r1 (fe-0/0/1), and verify that r2 becomes master for both VRRP groups:

lab@r2> show vrrp summary Interface   Unit Group Type Address   Int state VR state fe-0/0/0    520   1    lcl  10.0.5.2    up      master                        vip  10.0.5.253 fe-0/0/0    530   2    lcl  10.0.6.2    up      master                        vip  10.0.6.253

It would appear that both the MD5 authentication and interface tracking aspects of your VRRP configuration are working as designed. When interface-tracking issues are suspected, you can obtain detailed information on the status of tracking using this command:

lab@r1> show vrrp track Track if State Cost Interface    Group Cfg Run VR State fe-0/0/1.0 down 30  fe-0/0/0.520   1   100 70   backup

This display confirms that r1 is tracking the state of its fe-0/0/1.0 interface and that it will deduct 30 from the VRRP priority of interface fe-0/0/0.520 when the tracked interface’s state is other than up. You can also see the VRRP group’s configured priority (the default 100 in this case) as well as its current running priority, which is now 70, due to the tracked interface being down. This display confirms that all is working with your final VRRP configuration.

When all else fails and your VRRP configuration is not working, you should enable VRRP tracing and monitor the trace file for real-time debug output. A typical VRRP-tracing configuration and some of the output generated by unplugging r1’s tracked interface are shown in the following, with key information highlighted:

Tip 

In this example, the tracked interface was entered as fe-0/0/1, which resulted in the default logical unit (0) being tracked on this interface. You should always explicitly enter a unit number when unit values other than the default are in use. VRRP-tracking problems will result when the default unit number is inadvertently tracked on an interface that is not using unit number 0.

[edit] lab@r1# show protocols vrrp traceoptions {   file vrrp;   flag state;   flag general;  }

This tracing configuration causes VRRP state and general activities to be logged to a file called vrrp. We now monitor the file as r1’s tracked interface is disconnected:

lab@r1> monitor start vrrp *** vrrp *** Apr 10 23:50:38 vrrpd_rts_async_ifd_msg, Received Async message for: fe-0/0/1 Apr 10 23:50:38 vrrpd_update_track_if_entry Apr 10 23:50:38 vrrpd_update_track_if_entry : fe-0/0/1.0 : fe-0/0/ 0.002.008.010.000.005.001.001 Apr 10 23:50:38 vrrpd_rts_update_track_if for fe-0/0/1.0 Apr 10 23:50:38 vrrpd_rts_get_track_if_state for fe-0/0/1.0 Apr 10 23:50:38 Interface fe-0/0/1 ifindex: 3 flags 0x8001 Apr 10 23:50:38 Interface fe-0/0/1 ifl ifindex: 4 flags 0x8000 Apr 10 23:50:38 vrrpd_rts_get_track_if_state : fe-0/0/1.0 : down Apr 10 23:50:38 vrrpd_update_track_priority : 100 Apr 10 23:50:38 vrrpd_update_track_priority: 70 Apr 10 23:50:39 vrrp_fsm_update IFD: fe-0/0/0.002.008.010.000.005.001.001 event:   backup Apr 10 23:50:39 vrrp_fsm_backup: fe-0/0/0.002.008.010.000.005.001.001 state   from: master Apr 10 23:50:39 Signalled dcd (PID 1672) to reconfig

The trace output shown here displays the change in r1’s priority due to the state change interface fe-0/0/1, and also shows the loss of VRRP group mastership that results from the reduction in priority.

MAC Address Filtering

By default, Fast and Gigabit Ethernet interfaces will accept frames from all source MAC addresses. You can limit frame acceptance based on the source MAC address by using the source-filtering option and a corresponding list of MAC addresses that can be accepted. To demonstrate this feature, we will continue to use the topology illustrated in Figure 2.6 and configure r3’s fe-0/0/0 interface to meet the following criterion:

  • Only accept frames sent from r1’s fe-0/0/1 interface.

The following configuration on r3 correctly configures the source address filtering requirements of this configuration example. To obtain the MAC address being used by r1’s fe-0/0/1 interface, you can either examine the ARP cache on r3 or show the fe-0/0/1 interface on r1. This example demonstrates the ARP cache examination approach:

lab@r3# run ping 10.0.4.1 count 1 PING 10.0.4.1 (10.0.4.1): 56 data bytes 64 bytes from 10.0.4.1: icmp_seq=0 ttl=255 time=0.635 ms --- 10.0.4.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.635/0.635/0.635/0.000 ms

The ARP cache is now examined to obtain the MAC address for address 10.0.4.1:

[edit] lab@r3# run show arp MAC Address       Address     Interface 00:b0:d0:10:73:2f 10.0.1.100  fxp0.0 00:a0:c9:b2:f8:cb 10.0.3.2    fe-0/0/1.0 00:a0:c9:6f:7b:3e 10.0.4.1    fe-0/0/0.0 Total entries: 3

We now know that r1’s fe-0/0/1 interface will be using MAC address 00:a0:c9:6f:7b:3e. Armed with this information, we can proceed with the source address filter configuration on r3:

[edit interfaces fe-0/0/0 fastether-options] lab@r3# set source-filtering [edit interfaces fe-0/0/0 fastether-options] lab@r3# set source-address-filter 00:a0:c9:6f:7b:3e [edit interfaces fe-0/0/0 fastether-options] lab@r3# up 

The resulting configuration is:

[edit interfaces fe-0/0/0] lab@r3# show fastether-options {    source-filtering;    source-address-filter {      00:a0:c9:6f:7b:3e;    } }  unit 0 {    family inet {       address 10.0.4.3/24;    }  } 

The resulting configuration on r3 will cause it to reject any frames received on its fe-0/0/0 interface that do not contain a source MAC address of 00:a0:c9:6f:7b:3e.

Verify MAC Address Filtering

To confirm that the MAC address filter is working, we first ping r3 using r1’s burned-in MAC address, and then retry the ping after manually setting a new MAC address on r1’s fe-0/0/1 interface:

[edit interfaces fe-0/0/1] lab@r1# run ping 10.0.4.3 count 1 PING 10.0.4.3 (10.0.4.3): 56 data bytes 64 bytes from 10.0.4.3: icmp_seq=0 ttl=255 time=0.568 ms --- 10.0.4.3 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.568/0.568/0.568/0.000 ms

The pings using the burned-in MAC address work as expected. We now assign a new MAC address to r1’s fe-0/0/1 interface:

[edit interfaces fe-0/0/1] lab@r1# set mac 00:a0:c9:6f:7b:3d [edit interfaces fe-0/0/1] lab@r1# commit commit complete [edit interfaces fe-0/0/1] lab@r1# run ping 10.0.4.3 count 1 PING 10.0.4.3 (10.0.4.3): 56 data bytes  ^C --- 10.0.4.3 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss

Great—packets sent to r4 with the new MAC address fail as expected. This behavior confirms that the source address filter is working as intended.

Ethernet Interface Summary

This section provided typical JNCIP-level Ethernet configuration examples and common verification techniques. Using several examples, we detailed a typical VRRP configuration scenario that used both authentication and interface tracking and provided examples of source address filtering.




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

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