This chapter deals with all issues and aspects of Ethernet network interface cards (NICs) with regard to the physical and data link layers. It discusses card-specific aspects such as Media Access Control (MAC) address modification, cabling issues, hardware virtual LAN (VLAN) support, as well as aspects of the OS-specific IP stacks such as IP aliases, 802.1Q VLAN support, and bridging modes of operation.
The second half of this chapter investigates the capabilities of these interfaces when connected to switches, routers, or other UNIX gateways. The chapter concludes with a discussion of bridge and VLAN security, Ethernet channel bonding, and some hands-on labs.
Ethernet NICs
Modern Ethernet NICs are cheap and available in many different flavors. I strongly recommend not relying on the cheapest NICs for production applications, because of the limitations of the chipsets used. A sufficient onboard buffer is also essential for TCP performance.
Note that similar to Cisco router interfaces, the adapters need configuration in terms of speed, duplex settings, and maximum transfer unit (MTU). All the necessary parameters can be set with the UNIX ifconfig command, available on virtually all UNIX platforms.
On Linux systems, the ifconfig tool has evolved into the ip utility (which is part of the iproute2 package). Consult the ifconfig manual pages and the iproute2-HOWTO for details. We will also use this utility for alias and VLAN configuration. I am well aware that iproute2 has superseded many Linux tools such as ifconfig and route, but these are available on all UNIX systems (whereas iproute2 is specific to Linux only).
Autonegotiation of speed and duplex settings has not proven reliable under many circumstances (IEEE 802.3U). The MAC address of some adapters can be changed with a user-space utility provided either by the vendor or the open-source community. This is not possible for all types of NICs. In the worst case, you can use a DOS boot disk with the appropriate utilities. Most vendors also provide firmware upgrades for their products.
NOTE
Exercise care with features such as Wake-On-LAN.
I strongly suggest reading the hardware compatibility notes of your OS releases to ensure proper operation of hardware VLAN support, multicasting, and special features. I also recommend using the same brand of adapters throughout your topology. This makes replacements and driver deployment much easier and does not require kernel recompilation.
Hubs, Bridges, and Multilayer Switches
Because this is not an introductory text, I do not discuss the operation theory of bridges, switches, and hubs. I just want to mention that I am using hubs in my lab setup for the ease of packet sniffing without the need to configure analyzer ports on a switch, which are easily overwhelmed with the traffic of an entire VLAN. This feature is called Switch Port Analyzer (SPAN) on Cisco switches. Besides, I do not own enough switches to build an interesting spanning-tree lab. Therefore, you will find just two limited spanning-tree labs at the end of this chapter so that you can look at the bridge protocol data units (BPDUs) going back and forth between a Linux bridge and a Cisco switch for demonstration purposes.
Of course, I once again warn you about the limited or missing loop-detection mechanisms of some UNIX bridge modes. Take the appropriate topological steps to avoid loops and do not emulate switch functionality with UNIX gateways. Linux, NetBSD, and OpenBSD implement the IEEE 802.1D STP (Spanning-Tree Protocol), which is in charge of loop prevention in switched/bridged topologies in only a crude and limited way.
Instabilities in STP behavior represent the single most severe threat to switched LAN environments with multiple switches and bridges because of the timers involved and the high-performance characteristic of modern switch fabrics. When STP fails, frames might not just circle infinitely; they might multiply (to make the matter even worse). Nevertheless, UNIX bridging modes have their merits in terms of trunk filtering, traffic shaping, and transparent firewalls. Just remember that they are not intended to emulate or replace dedicated switches
Access Ports, Uplinks, Trunks, and EtherChannel Port Groups
A switch's port can either be a simple access port, an up/downlink to a switch or hub, a trunk port for VLAN transport, or a member of a Fast/Giga EtherChannel port group. A UNIX gateway can be connected to another one via a crossover link, can be connected to a switch, can form a VLAN trunk to another trunking-capable neighbor, or can form high-bandwidth multiport EtherChannel connections.
EtherChannels are often constructed with dedicated dual or quad Fast Ethernet NICs and are able to transport and trunk VLANs. At the time of this writing, they offer an alternative to Gigabit Ethernet NICs, especially with low-end 32-bit servers that might have difficulties feeding Gigabit Ethernet. Nevertheless, it is perfectly feasible to use four isolated NICs of good quality. The only requirement is that the other side of the link is EtherChannel-capable as well. As time passes, we will see a similar feature for Gigabit Ethernet gaining momentum. In general, you will come across one of the following EtherChannel or EtherChannel-like implementations:
FreeBSD EtherChannel kernel patch, which supports Cisco Fast EtherChannel (via the Netgraph facility). Two or four ports can be combined into a single aggregate interface.
Linux Ethernet channel bonding.
Cisco Proprietary Fast EtherChannel (featuring PAgP, or Port Aggregation Protocol).
The IEEE 802.3AD link aggregation standard (featuring LACP, or Link Aggregate Control Protocol).
Solaris Ethernet trunking.
Proprietary drivers for dedicated dual and quad interfaces with configuration utilities.
Useful EtherChannel-related links are presented in the "Recommended Reading" section at the end of this chapter.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
