7.2 Ethernet, Fast Ethernet, and GigE Interfaces

Ethernet is the most widely used LAN protocol. Juniper Networks routers have PICs that support both Ethernet at 10Mbps and Fast Ethernet at 100Mbps, while certain PICs only support 100Mbps. The identifier for the port is "fe" (short for Fast Ethernet), noting the speed is capable of 100Mbps and Juniper Networks' designation as Fast Ethernet, but some can be set to 10Mbps through either autonegotiation or manual configuration. In addition to different speeds, the Fast Ethernet PIC ports can autonegotiate or be manually configured for half-duplex or full-duplex operation.

Fast Ethernet PICs can be 4-, 8-, 12-, or 48-port, although the 48-port Fast Ethernet PIC is only available on the M160. The 4-port Fast Ethernet PIC has the standard RJ-45 connector for an interface. The 12-port PIC has a larger connector that must be attached to a patch panel to access the individual ports. The 8-port PIC uses an MT-RJ fiber connector for each port.

GigE operates at 1Gbps and is an optical interface. GigE PICs come in 1-, 2-, and 4-ports per PIC variation, although the 2- and 4-port variations are only available on the M160. Several different optical choices are available with the GigE card with respect to the wavelengths available: SX, LX, and LH. SX identifies interfaces for use over short distances to around 650 ft. The GigE LX interface can be used to over 6 mi. The LH version can be used to almost 50 mi. This allows great flexibility in connecting Ethernet-type LANs without having to use a WAN in between.

7.2.1 Physical Interface Configuration

Configuring Fast Ethernet and GigE interfaces is fairly easy. For a single network interface, unit 0 can be set with an IP address, as follows :

 [edit]  lab@chicago# edit interfaces fe-0/0/1 [edit interfaces fe-0/0/1]  lab@chicago# set unit 0 family inet address 192.168.20.2/24  [edit interfaces fe-0/0/1] lab@chicago# show unit 0 {     family inet {         address 192.168.20.2/24;     } } [edit interfaces fe-0/0/1] lab@chicago# 

Once the change has been committed, the show interfaces fe-0/0/1 command can be run from the CLI prompt to get a detailed view of the state and statistics of fe-0/0/1 as is shown below:

 lab@chicago> show interfaces fe-0/0/1  Physical  interface: fe-0/0/1,  Enabled  , Physical link is  Up  Interface index: 10, SNMP ifIndex: 14   Link-level type: Ethernet, MTU: 1514, Speed:  100mbps  , Loopback: Disabled,   Source filtering: Disabled, Flow control: Enabled   Device flags   : Present Running   Interface flags: SNMP-Traps   Current address: 00:90:69:9e:80:01, Hardware address: 00:90:69:9e:80:01   Input rate     : 0 bps (0 pps)   Output rate    : 0 bps (0 pps)   Active alarms  : None   Active defects : None  Logical  interface fe-0/0/1.0 (Index 7) (SNMP ifIndex 21)     Flags: SNMP-Traps Encapsulation: ENET2     Protocol inet, MTU: 1500, Flags: None       Addresses, Flags: Is-Preferred Is-Primary         Destination: 192.168.20/24, Local:  192.168.20.2  ,         Broadcast: 192.168.20.255 lab@chicago> 

Some key items are highlighted in the above output. First, note the split groups between the physical interface properties and the logical interface properties. After the physical interface properties are listed, all logical units will be listed with their configurations in unit order. Next , note that the physical interface is Enabled . If the interface were disabled by manual configuration, this field would read Administratively Down . To administratively re-enable a physical interface that has been disabled, use the command delete disable in the interface hierarchy.

To ensure connectivity and proper configuration to another connected router's interface, use the ping command from the CLI operational command prompt to ping the configured IP address on the other router as shown below:

 lab@chicago> ping 192.168.20.1  PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=0.982 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.808 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.782 ms 64 bytes from 192.168.20.1: icmp_seq=3 ttl=255 time=0.829 ms 64 bytes from 192.168.20.1: icmp_seq=4 ttl=255 time=0.789 ms 64 bytes from 192.168.20.1: icmp_seq=5 ttl=255 time=0.813 ms ^C --- 192.168.20.1 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.782/0.834/0.982/0.068 ms lab@chicago> 

The interface is now up and configured. On occasion, autonegotiation of speed and duplex mode can fail. This can be more prevalent in older Ethernet implementations . In cases where the two connected interfaces cannot decide on an agreeable configuration, it is necessary to manually configure, or "nail up," the link to a particular speed and mode. The following physical interface is set to full-duplex, and the speed to 100Mbps:

 [edit interfaces fe-0/0/1]  lab@chicago# set speed 100m [edit interfaces fe-0/0/1] lab@chicago# set link-mode ? Possible completions:   full-duplex          Full-duplex operation   half-duplex          Half-duplex operation [edit interfaces fe-0/0/1]  lab@chicago# set link-mode full-duplex  [edit interfaces fe-0/0/1] lab@chicago# show speed 100m; link-mode full-duplex; unit 0 {     family inet {         address 192.168.20.2/24;     } } [edit interfaces fe-0/0/1] lab@chicago# 

To remove the speed or mode and return to autonegotiation, use the delete command.

7.2.2 VLAN and Logical Interface Configuration

Setting up VLAN configuration on Fast Ethernet or GigE requires using logical units. Using logical units allows different IP networks to be assigned to the different VLANs. For the following configuration example, refer to Figure 7-5.

Figure 7-5. VLAN Configuration

Router New York is directly connected to a VLAN-capable switch and needs to be configured to talk to Chicago on one subnet and Boston on another over the same Fast Ethernet port. The first step in configuring VLANs is to enable VLAN tagging on the physical interface, as shown below:

 [edit interfaces fe-0/0/1]  lab@newyork# set vlan-tagging [edit interfaces fe-0/0/1] lab@newyork# show vlan-tagging; speed 100m; link-mode full-duplex; [edit interfaces fe-0/0/1] lab@newyork# 

The next steps are to create the units, assign the units to the appropriate VLAN, and then configure the IP addresses in the units. Since the scenario has VLANs 20 and 30, we can use those numbers for simplicity, but the unit number, as we have discussed, is up to the network administrator. It does make sense, however, to give the unit number some kind of significance for ease of use.

 [edit interfaces fe-0/0/1]  lab@newyork# set unit 20 vlan-id 20 [edit interfaces fe-0/0/1] lab@newyork# set unit 20 family inet address 192.168.20.2/24 [edit interfaces fe-0/0/1] lab@newyork# set unit 30 vlan-id 30 family inet address 192.168.30.3/24 [edit interfaces fe-0/0/1] lab@newyork# show vlan-tagging; speed 100m; link-mode full-duplex; unit 20 {     vlan-id 20;     family inet {         address 192.168.20.2/24;     } } unit 30 {     vlan-id 30;     family inet {         address 192.168.30.3/24;     } } [edit interfaces fe-0/0/1] lab@newyork# 

Fast Ethernet 0/0/1 now has two logical units configured in VLANs on unit 20 and unit 30. To check the connectivity and operation of the VLANs, ping the interfaces of routers Chicago and Boston.

 lab@newyork> ping 192.168.20.1  PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=0.965 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.788 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.763 ms 64 bytes from 192.168.20.1: icmp_seq=3 ttl=255 time=0.783 ms ^C --- 192.168.20.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.763/0.825/0.965/0.082 ms lab@newyork> ping 192.168.30.1 PING 192.168.30.1 (192.168.30.1): 56 data bytes 64 bytes from 192.168.30.1: icmp_seq=0 ttl=255 time=0.951 ms 64 bytes from 192.168.30.1: icmp_seq=1 ttl=255 time=0.784 ms 64 bytes from 192.168.30.1: icmp_seq=2 ttl=255 time=0.798 ms ^C --- 192.168.30.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.776/0.808/0.951/0.055 ms lab@newyork> 

All of the pings were successful, thus showing us that the VLANs are working. Check the interface using the CLI show interfaces command to see the specifics of what is occurring on the interface.

 lab@newyork> show interfaces fe-0/0/1  Physical interface: fe-0/0/1, Enabled, Physical link is Up   Interface index: 10, SNMP ifIndex: 14   Link-level type: Ethernet, MTU: 1518, Speed: 100mbps, Loopback: Disabled,   Source filtering: Disabled, Flow control: Enabled   Device flags   : Present Running   Interface flags: SNMP-Traps   Current address: 00:90:69:9e:80:01, Hardware address: 00:90:69:9e:80:01   Input rate     : 0 bps (0 pps)   Output rate    : 0 bps (0 pps)   Active alarms  : None   Active defects : None   Logical interface fe-0/0/1.20 (Index 13) (SNMP ifIndex 34)     Flags: SNMP-Traps  VLAN 20  Encapsulation: ENET2  Input packets : 4   Output packets: 4  Protocol inet, MTU: 1500, Flags: None       Addresses, Flags: Is-Preferred Is-Primary         Destination: 192.168.20/24, Local: 192.168.20.2,         Broadcast: 192.168.20.255   Logical interface fe-0/0/1.30 (Index 14) (SNMP ifIndex 35)     Flags: SNMP-Traps  VLAN 30  Encapsulation: ENET2  Input packets : 3   Output packets: 3  Protocol inet, MTU: 1500, Flags: None       Addresses, Flags: Is-Preferred Is-Primary         Destination: 192.168.30/24, Local: 192.168.30.3,         Broadcast: 192.168.30.255 lab@newyork> 

Two things to note in the output above: the VLAN ID for the logical unit and the packet counters. Each logical unit counts packets that have been sent and received.

7.2.3 MAC Address Filtering

MAC address filtering enables an administrator to determine which devices attached to the Ethernet port are allowed to communicate through or with the router. MAC filtering accomplishes this by only accepting packets from the administratively designated MAC addresses of the directly connected devices.

Note

This is done on the physical interface and will stop all nonassigned devices from being received even on logical interfaces.

For this scenario, the previous VLAN configuration is used. The first step is to enable source filtering on the physical interface in the [edit interfaces fe-0/0/1 fastether-options] hierarchy as shown below:

 [edit interfaces fe-0/0/1]  lab@newyork# edit fastether-options [edit interfaces fe-0/0/1 fastether-options] lab@newyork# set source-filtering [edit interfaces fe-0/0/1 fastether-options] lab@newyork# 

Now try to ping either Chicago or Boston. The ping packets will be sent to them, but their replies will be ignored because there is not an allowed MAC address list defined yet. This action is such that the router will implicitly deny all unless told to permit something.

 [edit interfaces fe-0/0/1 fastether-options]  lab@newyork# run ping 192.168.20.1 PING 192.168.20.1 (192.168.20.1): 56 data bytes ^C --- 192.168.20.1 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss [edit interfaces fe-0/0/1 fastether-options] lab@newyork# 

The next step is to assign in a list the MAC addresses that are to be permitted access. Only those listed devices that have permission to be received by router New York on that particular interface will have their packets flow through the router. This list is created in the [edit interfaces fe-0/0/1 fastether-options] hierarchy. Use the set source-address-filter (MAC address) command to add MAC addresses to the list. Router Chicago's MAC address, 00:90:69:a4:d8:01 , will be added.

 [edit interfaces fe-0/0/1 fastether-options]  lab@newyork# set source-address-filter 00:90:69:a4:d8:01  lab@newyork> ping 192.168.20.1 PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=1.661 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.801 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.785 ms ^C --- 192.168.20.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.785/1.082/1.661/0.409 ms lab@newyork> ping 192.168.30.1 PING 192.168.30.1 (192.168.30.1): 56 data bytes ^C --- 192.168.30.1 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss 

Router New York can now receive ping replies from Chicago, but not from Boston because Boston's MAC address was not added to the list of accepted addresses.

7.2.4 VRRP

In networking design, one of the most important things to consider is reliability of the network. One way to increase reliability is through redundancy, the availability of a backup device in case the primary device becomes nonfunctional. A router could become nonfunctional due to a hardware component failure, a software process failure, or scheduled downtime for maintenance, for example.

Juniper Networks routers can have redundant items in the chassis, but what if the entire router were to fail or had to be taken offline? The Ethernet (also Fast Ethernet and GigE) protocol uses ARP to bind a MAC address to an IP address. Devices on the Ethernet link keep ARP tables so that they know the MAC address of the default gateway, which is typically the router.

Redundancy is introduced when we connect another router to the Ethernet segment. The question then becomes how to create a redundant network that is transparent to our hosts on the Ethernet segment? To enable full router redundancy, a virtual IP address and MAC address can be created and then shared by more than one router on an Ethernet network. If one router fails, another router can receive Ethernet frames to that virtual MAC address to ensure that the data still gets forwarded. This allows for transparent and redundant connectivity for the hosts on the LAN.

VRRP is an IETF standard (RFC 2338) used to provide router redundancy on Ethernet. VRRP defines a relationship between a group of routers, one of which will answer for a specific IP address. This VRRP group of routers creates a virtual router because more than one device (though only one at a time) is capable of receiving the Ethernet frames that a sending device thinks it is sending to a single router. There could actually be no physical device with that intended address, just several routers answering for that address. Normally, when a device sends packets to an address, that address is unique in a network. In a VRRP group of routers, one router answers for an IP address (this router is called the master ), and the other routers stay quiet for that particular address until the master fails. The master is the "owner" of the virtual IP address and answers for it, until it fails. Then the next backup router in line takes over for that virtual router address as the master.

Dynamic routing protocols enable the rerouting of data to other routers along the path (if they are configured to be in that dynamic protocol) in the event of a failure of a router. There are instances, however, in which dynamic routing protocols will not work. If static routes are used or host devices have only a single static default gateway configured in their IP configurations, there will be no way out if the default gateway router fails. Even with the use of dynamic routing protocols, certain hold timers and dead timers will have to expire before the other routers on the link consider the failed router no longer to be a viable path. VRRP allows statically configured Ethernet devices to use backup routers in the event the primary fails.

In Figure 7-6 New York and Chicago both support the virtual router with the IP address 192.168.30.1 . New York is the master for that virtual router. If the hosts have a static default route or gateway configured as 192.168.30.1 when they send data through that IP address, New York will receive it and forward the data. If New York goes offline, Chicago will take over receiving data for the virtual IP address.

Figure 7-6. VRRP Operation

Even though we have described the VRRP IP address as being independent of a single router, the virtual IP address could actually be an interface address of one of the participating VRRP routers. If that is the case, then the router that has the interface address is known as the IP address owner. An IP address owner has to be configured as the master for that virtual router anytime it is online.

What happens when multiple routers are all trying to be the one in charge of the virtual addresses? VRRP is a state and election-process protocol. The state is whether or not a device is up; the election process defines which is the master router to answer for the virtual group. A priority can be defined among routers to determine who is the master router and in which order the backup routers will take over for a particular virtual router IP. Priority ranges from 0 to 255. The router with the highest priority is elected as the master. Priority on Juniper Networks routers defaults to 100. If a router is an IP address owner, it must be configured with a priority of 255, ensuring that it is master for that virtual router group. In addition, the IP address owner has to be configured for preemption.

Preemption refers to the taking over of a master from another master. If a router with a priority of 125 for a certain VRRP group is master, and a router is brought online into that same group with a priority of 135, a decision has to be made. Should the router with the higher priority take away masterhood of the virtual router from the current master when everything is working just fine? This decision is left to the administrator's discretion except in the case of the IP address owner. A router that is an IP address owner must be able to preempt any router acting as master for that virtual address because for the IP address owner that address is real.

7.2.4.1 Balancing Bandwidth

Besides redundancy, another reason to have more than one router on a path out of a network is to have another router share in the traffic forwarding. If groups of hosts or routers have different routers on the network manually set as the default gateway, the traffic-forwarding load can be shared. But this is a labor- intensive process and does not protect the network if one router goes down because, then, half the hosts would not be able to access the network. Thus, with VRRP you can create that single virtual IP address that everyone can use and have the routers load-balance traffic for more effective use of them. By default, in VRRP all the statically configured hosts will send traffic to the single master router for a given virtual IP. Truer load balancing can be achieved through the use of multiple groups.

VRRP allows more than one group to be configured for a network. This will enable different routers to act as master and backup for different virtual IP address. In Figure 7-7, router New York is master for 192.168.30 . 1 and backup for 192.168.30 . 2 . Router Chicago is master for 192.168.30 . 2 and backup for 192.168.30 . 1 .

Figure 7-7. VRRP Multiple Groups

To enable multiple virtual IP addresses with differing priorities and such, separate groups can be configured on the network interface. Each of these VRRP groups can have different settings for virtual IP addresses, priority, preemption, and so forth, based on the desired default and fail-over forwarding. How do backup routers know when a master has failed?

Master routers send out advertisements to other routers in the group to let them know of the master's status. These advertisements are sent, by default, once per second. The advertisements contain such information as the group ID, virtual IP addresses of this group, the master's priority, the group's advertisement interval, and any authentication information used between VRRP-enabled routers in a group.

Since devices have unique MAC addresses on a network, a virtual MAC address is also needed to allow different routers to answer for the virtual IP address. This virtual MAC address comes from a range that is specified in RFC 2338. The address range is 00:00:5e:00:01:00-ff . The virtual MAC address is created when the VRRP group is created. The last byte of two hexadecimal places has a decimal range of 0 to 255, which is the same range of configurable VRRP group ID numbers. The last byte of the virtual MAC address will match the VRRP group ID. This is extremely important to know if MAC address filtering is implemented. The virtual MAC address for each VRRP group must be added to the lists of accepted devices.

7.2.4.2 VRRP Configuration

VRRP configuration on a Juniper Networks router takes place at the [edit interfaces (int#) unit (#) family inet address (addr)] hierarchy level. Due to the fact that logical units are on different networks and each logical unit can have multiple IP addresses, the VRRP group is defined under a specific IP address. The virtual IP address or addresses for the group should fall within the same subnet as the address of the logical unit.

You first create the VRRP group; then, the virtual IP address is assigned. In Figure 7-8, routers New York and Chicago have two VRRP groups configured. Router New York is the master of virtual IP address for Group 10, while router Chicago is the master of Group 20.

Figure 7-8. VRRP Group Configuration

Refer to Figure 7-8 as you read through the following configuration example. The Fast Ethernet interfaces are already configured on New York and Chicago, as is shown in the output below:

 Router New York  [edit interfaces fe-0/0/1] lab@newyork# show speed 100m; link-mode full-duplex; unit 0 {     family inet {         address 192.168.30.3/24;     } } [edit interfaces fe-0/0/1] lab@newyork# Router Chicago [edit interfaces fe-0/0/1] lab@chicago# show speed 100m; link-mode full-duplex; unit 0 {     family inet {         address 192.168.30.4/24;     } } [edit interfaces fe-0/0/1] lab@chicago# 

The VRRP groups will be configured under the IP address of unit 0 on both routers. First, router New York will have a configured priority of 110 for VRRP Group 10 for the virtual IP address of 192.168.30.1 and a priority of 90 for 192.168.30.2 in VRRP Group 20. The purpose is to create router New York as the master for Group 10 and the backup for Group 20, thus balancing the load.

 [edit interfaces fe-0/0/1]  lab@newyork# edit unit 0 family inet address 192.168.30.3/24 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24] lab@newyork# set vrrp-group 10 virtual-address 192.168.30.1 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24] lab@newyork# edit vrrp-group 10 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp- group 10] lab@newyork#  set priority 110  [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp- group 10] lab@newyork# up [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24] lab@newyork# set vrrp-group 20 virtual-address 192.168.30.2 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24] lab@newyork# edit vrrp-group 20 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp- group 20] lab@newyork#  set priority 90  

New York's interface configuration looks as follows when completed:

 [edit interfaces fe-0/0/1 unit 0 family inet]  lab@newyork# show address 192.168.30.3/24 {     vrrp-group 10 {         virtual-address 192.168.30.1;         priority 110;     }     vrrp-group 20 {         virtual-address 192.168.30.2;         priority 90;     } } [edit interfaces fe-0/0/1 unit 0 family inet] lab@newyork# 

Router New York will be master for and virtual IP addresses for VRRP Group 10 and a backup for VRRP Group 20. Using the show vrrp command allows us to see what groups are set on interfaces and their states.

 lab@newyork> show vrrp  Interface   Unit  Group  Type  Address          Int state    VR state   Timer fe-0/0/1    0     10     lcl   192.168.30.3     up           master     A 0.620                          vip   192.168.30.1 fe-0/0/1    0     20     lcl   192.168.30.3     up           master     A 0.290                          vip   192.168.30.2 lab@newyork> 

Router New York has two VRRP groups enabled on fe-0/0/1 unit . The local unit IP address is shown along with the virtual IP address for that group. Currently, router New York is master for both groups because Chicago has not yet been configured.

Note

If the no-preempt option is to be used, then configure the groups by master router first. If the groups are all configured on one router at a time, the first router configured will be master for all the groups. None of the other routers with higher priorities for those groups will be able to take over as intended because they are not allowed to preempt the master, even if they have a higher priority. Only if the master were to fail would an election take place for each group. In this example, if you were to use the no-preempt option, you would configure router New York's VRRP Group 10 and then router Chicago's Group 20. Then New York and Chicago can be configured for their backup groups.

Router Chicago will get the opposite configuration as New York, meaning that by design router Chicago will be the backup for the group in which router New York is master, while Chicago is the master for the group in which router New York is the backup. In this manner, the routers can split the duties and the work of being masters of the VRRP groups.

 [edit interfaces fe-0/0/1]  lab@chicago# edit unit 0 family inet address 192.168.30.4/24 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24] lab@chicago# set vrrp-group 10 virtual-address 192.168.30.1 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24] lab@chicago# set vrrp-group 10 priority 90 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24] lab@chicago# set vrrp-group 20 virtual-address 192.168.30.2 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24] lab@chicago# set vrrp-group 20 priority 110 [edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24] lab@chicago# up [edit interfaces fe-0/0/1 unit 0 family inet] lab@chicago# show address 192.168.30.4/24 {     vrrp-group 10 {         virtual-address 192.168.30.1;         priority 90;     }     vrrp-group 20 {         virtual-address 192.168.30.2;         priority 110;     } } [edit interfaces fe-0/0/1 unit 0 family inet] lab@chicago# 

Showing the VRRP information on New York again, router Chicago has been configured as a higher priority for VRRP Group 20 than router New York. Router Chicago takes over.

 lab@newyork> show vrrp  Interface   Unit  Group  Type  Address          Int state    VR state   Timer fe-0/0/1    0     10     lcl   192.168.30.3     up           master     A 0.890                          vip   192.168.30.1 fe-0/0/1    0     20     lcl   192.168.30.3     up  backup  D 2.768                          vip   192.168.30.2  mas   192.168.30.4  lab@newyork> 

Notice one other change in the output shown here. Another Type and Address entry has been made for Group 20 that shows who the master is for that group (using the actual interface address of Chicago) because the master is no longer router New York.

Ethernet is the most popular of the LAN technologies because it is inexpensive, easily implemented, very scalable, and available in a wide variety of interfaces, ranging from 10Mbps to 10Gbps. Although it is a broadcast-type data link protocol that has the potential for problems in large broadcast domains, newer standards allow for improvements by supporting such features as VRRP and MAC address filtering.