Before the explosion of routing tables and of forwarded traffic, the classic routing paradigm constituted routing table lookups in increasingly complex routing tables. These tables were populated by more or less scalable and fast-converging dynamic routing protocols together with connected routes and static routes.
Showing posts with label Article. Show all posts
Showing posts with label Article. Show all posts
Cisco IOS Software
Cisco IOS Software has been around for quite some time. The original intention of the developers was to provide a small embedded system for limited-memory and speed-critical packet-switching routing appliances. Speed requirements within embedded systems are usually met by design simplicity and removal of unnecessary features. Cisco IOS Software has a cooperative multitasking kernel architecture featuring several processes and "resembles a loose collection of components and functions linked with the rest of IOS. Everything including the kernel runs in user mode on the CPU and has full access to systems resources."[1]
Linux
This UNIX-like operating system is based on the work of Linus Torvalds and was inspired to some extent by Andrew Tanenbaum's Minix operating system. However, Torvalds also had in mind to overcome the limitations of Minix and abandon its microkernel concept for the sake of a modular kernel. Over the recent years, it has grown to a huge collaborative effort with thousands of developers.
Chapter 2. User-Space Routing Software
As described in Chapter 1, "Operating System Issues and Features—The Big Picture," user-space routing tools run as one single process (monolithic architectures) or as a set of daemons external to the kernel routines, either single-threaded or multithreaded. As long as these daemons are alive, routing information—signaling information to be more precise—can be exchanged or withdrawn and eventually populate the gateway's routing table.
The GNU Zebra Routing Software
GNU Zebra is a free and mature software package that manages TCP/IP-based routing protocols. Zebra's unique architectural foundation is based on the concept of one single process for each signaling routing protocol. Each module can run, be restarted, or be upgraded independently of the others, which greatly increases the stability of the entire system. In addition, the protocol daemons can be run just to exchange signaling information or populate the system's forwarding table via the Zebra master daemon (zebra). Particularly popular applications that use signaling information are route servers and route reflectors that distribute Border Gateway Protocol (BGP) reachability information. Chapter 10, "ISP Connectivity with BGP4: An Exterior Gateway Path-Vector Routing Protocol for Interdomain Routing," discusses these applications in depth. GNU Zebra does not support or make use of threads yet—it has its own internal cooperative user-space thread model (not really multithreaded). Zebra code constitutes the development foundation for IP Infusion's commercial ZebOS. The following list presents some useful details about the software:
MRT (Multithreaded Routing Toolkit)
The MRT Project is a monolithic multithreaded routing engine (MRTd) that was developed under a research grant at the University of Michigan. It contains multiprotocol IPv4/IPv6 routing daemons and accompanying analysis and simulation tools. The following list presents some useful details about the software:
Chapter 3. Kernel Requirements for a Full-Featured Lab
This chapter discusses various important aspects of networking-related kernel configurations on which we will rely heavily as we advance throughout this book. Some of these features need to be enabled at kernel compile time, some utilize loadable kernel modules, and others require user-space configuration tools and utilities such as the firewall or virtual local-area network (VLAN) configuration tasks. In the context of kernel parameters, the sysctl utility is introduced and thoroughly discussed.
Chapter 4. Gateway WAN/Metro Interfaces
This chapter discusses WAN and metropolitan-access approaches that differ from native switched Ethernet LAN infrastructures. You need to learn about these approaches because the majority of UNIX administrators are aware only of Ethernet network interfaces for connectivity of their beloved systems.
Note that the network access layer delivered to homes and business premises via access/edge metro architectures is either based (generally) on copper cabling or optical cables. In rural areas, the most commercially feasible solutions are dial/wireless access with rapid deployment of digital subscriber line (DSL) infrastructures operated by smaller regional Internet service providers (ISPs) and occasionally local cable networks. The information in this chapter is presented from the customer's (CPE = Customer Premises Equipment) point of view. This discussion considers CPE gateway functionality and not directly connected isolated clients.
In today's metropolitan areas, the following access solutions can be provided to customers:
Dial services (analog/ISDN)
Wireless solutions (laser, microwave, 802.11, GSM, GPRS, UMTS, satellite)
Plain Ethernet services
Metro cable access (Ethernet interfaces)
Synchronous serial digital leased lines (DLLs)
SDH/SONET links
ATM or Frame Relay services
Different flavors of DSL services
Fiber/UTP/STP to the home (Ethernet offerings up to Gbps or shaped transmission rates)
Ethernet via existing PSTN cabling with integrated telephony (LRE = Long Reach Ethernet)
Powerline communications (Internet access via power lines)
Dial-on-Demand Routing: Analog and ISDN Dialup
State-of-the-art digital modems and ISP remote-access platforms support the new ITU V.92 and V.44 standards with features such as better compression, modem-on-hold, quick-connect, and improved upstream performance. However, only time will tell whether ISPs will rush to migrate to these new standards given the development of alternative access technologies with better margin, the risk of introducing instabilities in stable access networks, and the questionable commercial feasibility of upgrading existing equipment, firmware, or software. All modern modems support at least V.90/V.34/V.42bis.
ISDN is available in the form of Basic Rate Interfaces (BRIs) and Primary Rate Interfaces (PRIs) with the capabilities of channel bundling. ISDN is often used for backup scenarios (dial-on-demand routing) and call aggregation, whereas analog modems are often deployed for remote management of network equipment.
In spite of the positive aspects, ISDN backup scenarios are often plagued by the following problems and restrictions:
Backup for at least 50 percent of business bandwidth is not commercially feasible and essentially means deployment of an access server with one or more PRIs.
Deployment results in complicated policy routing configurations. For example, what kind of traffic triggers a dial connect? What is the definition of timeouts, of thresholds? What condition triggers teardown of a dial line? Flapping interfaces, Network Address Translation (NAT) scenarios, and IP Security (IPSec) backups further complicate the matter.
To carriers and service providers, AAA (authentication, authorization and accounting) is a fundamental issue. The effort regarding authentication, IP address allocation, and assignment is considerable for backup scenarios.
Experience has proven that often carrier DLLs as well as the PSTN use the same trunks originating in the same central office. This defeats the purpose of dial backups and presents a treacherous picture of safety, especially at the edge of these infrastructures, where redundant trunks are rare.
Businesses tend to favor dual-homed Internet access with their own autonomous system (AS), provider-independent (PI) address block, and flexible Border Gateway Protocol (BGP) routing. This makes ISDN backup scenarios obsolete to a large extent. However, with the maturity of DSL, wireless, and cable networks, these technologies could be used for backup scenarios as well, even in concert with BGP routing. One has to consider slightly different service-level agreements (SLAs) and the issue of availability in the region, though.
Analog modem adapters, ISDN cards, single-chip solutions, and PRI/channelized PCI or ISA adapters are available in many variants. For a small number of PRI adapters, proprietary UNIX drivers are available and complemented by some open-driver initiatives. A discussion of channelized interfaces goes beyond the scope of this book
Note that the network access layer delivered to homes and business premises via access/edge metro architectures is either based (generally) on copper cabling or optical cables. In rural areas, the most commercially feasible solutions are dial/wireless access with rapid deployment of digital subscriber line (DSL) infrastructures operated by smaller regional Internet service providers (ISPs) and occasionally local cable networks. The information in this chapter is presented from the customer's (CPE = Customer Premises Equipment) point of view. This discussion considers CPE gateway functionality and not directly connected isolated clients.
In today's metropolitan areas, the following access solutions can be provided to customers:
Dial services (analog/ISDN)
Wireless solutions (laser, microwave, 802.11, GSM, GPRS, UMTS, satellite)
Plain Ethernet services
Metro cable access (Ethernet interfaces)
Synchronous serial digital leased lines (DLLs)
SDH/SONET links
ATM or Frame Relay services
Different flavors of DSL services
Fiber/UTP/STP to the home (Ethernet offerings up to Gbps or shaped transmission rates)
Ethernet via existing PSTN cabling with integrated telephony (LRE = Long Reach Ethernet)
Powerline communications (Internet access via power lines)
Dial-on-Demand Routing: Analog and ISDN Dialup
State-of-the-art digital modems and ISP remote-access platforms support the new ITU V.92 and V.44 standards with features such as better compression, modem-on-hold, quick-connect, and improved upstream performance. However, only time will tell whether ISPs will rush to migrate to these new standards given the development of alternative access technologies with better margin, the risk of introducing instabilities in stable access networks, and the questionable commercial feasibility of upgrading existing equipment, firmware, or software. All modern modems support at least V.90/V.34/V.42bis.
ISDN is available in the form of Basic Rate Interfaces (BRIs) and Primary Rate Interfaces (PRIs) with the capabilities of channel bundling. ISDN is often used for backup scenarios (dial-on-demand routing) and call aggregation, whereas analog modems are often deployed for remote management of network equipment.
In spite of the positive aspects, ISDN backup scenarios are often plagued by the following problems and restrictions:
Backup for at least 50 percent of business bandwidth is not commercially feasible and essentially means deployment of an access server with one or more PRIs.
Deployment results in complicated policy routing configurations. For example, what kind of traffic triggers a dial connect? What is the definition of timeouts, of thresholds? What condition triggers teardown of a dial line? Flapping interfaces, Network Address Translation (NAT) scenarios, and IP Security (IPSec) backups further complicate the matter.
To carriers and service providers, AAA (authentication, authorization and accounting) is a fundamental issue. The effort regarding authentication, IP address allocation, and assignment is considerable for backup scenarios.
Experience has proven that often carrier DLLs as well as the PSTN use the same trunks originating in the same central office. This defeats the purpose of dial backups and presents a treacherous picture of safety, especially at the edge of these infrastructures, where redundant trunks are rare.
Businesses tend to favor dual-homed Internet access with their own autonomous system (AS), provider-independent (PI) address block, and flexible Border Gateway Protocol (BGP) routing. This makes ISDN backup scenarios obsolete to a large extent. However, with the maturity of DSL, wireless, and cable networks, these technologies could be used for backup scenarios as well, even in concert with BGP routing. One has to consider slightly different service-level agreements (SLAs) and the issue of availability in the region, though.
Analog modem adapters, ISDN cards, single-chip solutions, and PRI/channelized PCI or ISA adapters are available in many variants. For a small number of PRI adapters, proprietary UNIX drivers are available and complemented by some open-driver initiatives. A discussion of channelized interfaces goes beyond the scope of this book
Wireless Technologies
Wireless adapter cards and access points for 802.11A/B/G networks are available and have become popular.
Already UNIX kernels support a vast number of different vendor products, with 802.11G drivers catching up. Unfortunately, the Wired Equivalent Privacy (WEP) used for link-layer security is inadequate for modern requirements and can be compromised easily. The successor security architecture (IEEE 802.11I) should be ready by the end of 2004. Several vendors have already started to implement the draft of this standard.
802.11-based networks are plagued by uninvited guests who either connect for free Internet access or for the purpose of sniffing with roaming adapter cards. Therefore, it is highly recommended to add IPSec (3DES/AES) on top of wireless 802.11 networks for transparent encryption, eventually accompanied by measures such as SSH or SSL. Alternative user-space crypto tunnels can be deployed, too. In addition, strong and encrypted authentication is necessary, because MAC-address-based accounting is of limited use, due to the fact that these addresses can be easily changed/spoofed and are tedious to deploy in a vast network of access points. IEEE 802.1X addresses some of these issues.
802.11 is not the only wireless technology available, just the youngest one. Microwave links, satellite links, and laser links will still be available for a long time. The use of GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications System) is on the rise.
SDH/SONET
Customers can rent Synchronous Digital Hierarchy/Synchronous Optical Network (SDH/SONET) links from carriers and provide their Layer 2 protocol/encapsulation of choice or directly deploy PoS (Packet over SDH/SONET). These links can be acquired either protected (spare port) or unprotected.
For larger enterprise customers, the carriers usually deploy add/drop multiplexers to deliver fractional STM1/OC3 bandwidth. Depending on the linecards of these multiplexers, channels as small as 56/64 kbps could be extracted/injected (added/dropped in multiplexer lingo). T1/E1 fractions are the most common when looking at the total number of deployed units, most of them at carrier edge facilities. Due to the increasing bandwidth needs of larger enterprises, such trunks are normally sold as multiples of full T1/E1 rates. In carrier backbones, state-of-the art photonic networks based on optical cross-connects and dense wavelength-division multiplexing (DWDM) technology transport aggregated traffic of multiple 10 to 100 Gbps
Powerline Communications
Deployment of powerline systems (low-voltage communication) for WAN access requires new equipment at every electrical substation of the energy supplier. The subscriber must be within the rather short and tight distance restrictions of a few hundred meters. Powerline intrinsically is a shared-access technology as well and delivers an Ethernet/USB interface as a demarcation point.
Powerline itself, although initially difficult to deploy, offers the opportunity of new and exciting services: LAN-only powerline in-house cabling, energy management, and remote control of electrical home equipment, just to mention a few.
NOTE
Deployment of T1/E1 symmetrical bandwidth is common. For a technology overview, go to http://www.ipcf.org/powerlineintro.html.
Ethernet to the Home/Premises
With the advances and widespread availability of long- and ultra-long-reach photonic networks, carriers can now provide 10/100/1000-Mbps Ethernet or shaped bandwidths to metropolitan customers, delivering Ethernet demarcation points (optical or copper ports). These services are offered transparently or via virtual LAN (VLAN) or Multiprotocol Label Switching (MPLS) architectures.
Cisco Long-Reach Ethernet (LRE)
Cisco LRE delivers speeds of 5 Mbps to 15 Mbps over legacy category 1/2/3 wiring over several thousand meters. LRE is an extension to the IEEE 802.3 Ethernet standard for single-pair wiring. This requires special switch ports on one end and CPE devices for the office ports on the other end to simultaneously use Plain Old Telephone System (POTS) and Integrated Services Digital Network (ISDN). This is achieved via a sophisticated modulation approach: quadrature amplitude modulation (QAM). Cisco provides a solution that consists of switches, CPE devices, and a POTS splitter for simultaneous use of existing private branch exchange (PBX) equipment.
NOTE
The LRE architecture can coexist with DSL on the same wire bundle facilitating frequency-division multiplexing (FDM).
Already UNIX kernels support a vast number of different vendor products, with 802.11G drivers catching up. Unfortunately, the Wired Equivalent Privacy (WEP) used for link-layer security is inadequate for modern requirements and can be compromised easily. The successor security architecture (IEEE 802.11I) should be ready by the end of 2004. Several vendors have already started to implement the draft of this standard.
802.11-based networks are plagued by uninvited guests who either connect for free Internet access or for the purpose of sniffing with roaming adapter cards. Therefore, it is highly recommended to add IPSec (3DES/AES) on top of wireless 802.11 networks for transparent encryption, eventually accompanied by measures such as SSH or SSL. Alternative user-space crypto tunnels can be deployed, too. In addition, strong and encrypted authentication is necessary, because MAC-address-based accounting is of limited use, due to the fact that these addresses can be easily changed/spoofed and are tedious to deploy in a vast network of access points. IEEE 802.1X addresses some of these issues.
802.11 is not the only wireless technology available, just the youngest one. Microwave links, satellite links, and laser links will still be available for a long time. The use of GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications System) is on the rise.
SDH/SONET
Customers can rent Synchronous Digital Hierarchy/Synchronous Optical Network (SDH/SONET) links from carriers and provide their Layer 2 protocol/encapsulation of choice or directly deploy PoS (Packet over SDH/SONET). These links can be acquired either protected (spare port) or unprotected.
For larger enterprise customers, the carriers usually deploy add/drop multiplexers to deliver fractional STM1/OC3 bandwidth. Depending on the linecards of these multiplexers, channels as small as 56/64 kbps could be extracted/injected (added/dropped in multiplexer lingo). T1/E1 fractions are the most common when looking at the total number of deployed units, most of them at carrier edge facilities. Due to the increasing bandwidth needs of larger enterprises, such trunks are normally sold as multiples of full T1/E1 rates. In carrier backbones, state-of-the art photonic networks based on optical cross-connects and dense wavelength-division multiplexing (DWDM) technology transport aggregated traffic of multiple 10 to 100 Gbps
Powerline Communications
Deployment of powerline systems (low-voltage communication) for WAN access requires new equipment at every electrical substation of the energy supplier. The subscriber must be within the rather short and tight distance restrictions of a few hundred meters. Powerline intrinsically is a shared-access technology as well and delivers an Ethernet/USB interface as a demarcation point.
Powerline itself, although initially difficult to deploy, offers the opportunity of new and exciting services: LAN-only powerline in-house cabling, energy management, and remote control of electrical home equipment, just to mention a few.
NOTE
Deployment of T1/E1 symmetrical bandwidth is common. For a technology overview, go to http://www.ipcf.org/powerlineintro.html.
Ethernet to the Home/Premises
With the advances and widespread availability of long- and ultra-long-reach photonic networks, carriers can now provide 10/100/1000-Mbps Ethernet or shaped bandwidths to metropolitan customers, delivering Ethernet demarcation points (optical or copper ports). These services are offered transparently or via virtual LAN (VLAN) or Multiprotocol Label Switching (MPLS) architectures.
Cisco Long-Reach Ethernet (LRE)
Cisco LRE delivers speeds of 5 Mbps to 15 Mbps over legacy category 1/2/3 wiring over several thousand meters. LRE is an extension to the IEEE 802.3 Ethernet standard for single-pair wiring. This requires special switch ports on one end and CPE devices for the office ports on the other end to simultaneously use Plain Old Telephone System (POTS) and Integrated Services Digital Network (ISDN). This is achieved via a sophisticated modulation approach: quadrature amplitude modulation (QAM). Cisco provides a solution that consists of switches, CPE devices, and a POTS splitter for simultaneous use of existing private branch exchange (PBX) equipment.
NOTE
The LRE architecture can coexist with DSL on the same wire bundle facilitating frequency-division multiplexing (FDM).
Synchronous Serial Interface and PRIs
UNIX systems provide excellent support for high-performance T1/E1 and some T3/E3 interface cards, as well as for some High-Speed Serial Interface (HSSI) adapters (up to 52 Mbps) and PRIs. Several vendors provide dedicated drivers and management software for open-source Unices. The NICs integrate nicely into a Cisco WAN network and provide varying telecommunication characteristics:
Clear-channel/channelized/fractional operation
Multiple ports
Physical interfaces: V.35, V.36, X.21, RS-232
With or without integrated CSU/DSU
RAS option: with or without integrated digital modems (DSPs)
PRI signaling
Internal/external clocking
Almost all synchronous serial NICs support the following Layer 2 encapsulation formats:
LAPB (X.25 Layer2)
Frame Relay
Cisco HDLC
Synchronous PPP
Frame Relay services are deployed by carriers up to T3 bandwidth in the United States and up to E1 bandwidth in Europe and most other countries in 56/64-kbps or sometimes even smaller increments (subrates/derived channels). Configuration of X.25 or Frame Relay is similar to Cisco configurations with regard to virtual/subinterface concepts and topology (point to point, point to multipoint, and so on).
ATM Interfaces
Some vendors sell PCI ATM interface cards for ATM25 DSL interfaces, 155-Mbps STM-1/OC3, as well as "exotic" 622-Mbps STM-4/OC12 NICs, featuring both optical and electrical RJ-45 interfaces.
OpenBSD, Linux, and FreeBSD provide an ATM stack, but only a limited family of adapters is supported. This family unfortunately includes almost no state-of-the-art models. The best support available for ATM adapters is provided for Marconi ForeRunner and Efficient Networks chipsets. Consult the hardware compatibility list of the respective operating systems for further details.
As far as I have researched the matter, it would be interesting to deploy ATM25 adapter cards for UNIX gateway devices. Unfortunately, few vendors supply PCI models; almost all development effort appears to go into embedded systems for deployment in integrated access devices (IADs). ATM25 supports approximately 10.5-Mbps high-speed, 8-Mbps full-rate, and 4-Mbps or G.Lite downstream speeds and can accommodate ADSL, SDSL, VDSL, and G.SHDSL.
Because I do not own ATM-PCI adapters, no lab is provided in this section. The following sections discuss the Linux and FreeBSD ATM stack and configuration tools in detail. If you own two ATM interfaces cards, you can use an optical crossover cable pair for a nice lab or connect them to an ATM switch for ILMI testing. For RJ-45 crossovers, consult the pin assignments of the vendor's adapter manual.
Linux ATM Support
Unfortunately, there appears to be no further development going on with regard to the Linux ATM Project (http://linux-atm.sourceforge.net), which, of course, does not mean that it is not stable or useful. The drivers are included in up-to-date kernels. In addition, you still need to download the ATM support tools from http://linux-atm.sourceforge.net. Linux ATM implements several ATM-related daemons: atmsigd, ilmid, and atmarpd, as well as several ancillary tools.
Example 4-1 presents configuration of ATM PVC/SVC pairs under Linux. Remember, ATM PVCs are point-to-point abstractions.
To configure the atm0 interface as 10.1.1.1/30 and build a PVC on PHY 0, VPI 0, VCI 51 (emphasized by the shaded text) to the far-end 10.1.1.2/30, type the commands in the order presented in Example 4-1.
Example 4-1. Simple Linux ATM Interface and PVC Configuration
[root@callisto~#] atmarp -c atm0
[root@callisto~#] ifconfig atm0 10.1.1.1 netmask 255.255.255.252 mtu 4470
[root@callisto~#] atmarp -s 10.1.1.2 0.0.51
For an in-depth discussion, consult the Linux ATM-on-Linux HOWTO.
The FreeBSD HARP ATM Subsystem
FreeBSD provides mature ATM support via the Host ATM Research Platform (HARP) software. For configuration details, consult the atm(8) man page and the links in the "Recommended Reading" section
Cable Access (Ethernet Interfaces)
Cable access can be deployed easily. The vast majority of providers deliver a CPE device (cable modem) that terminates the coax network frequency bands that carry data, TV, and telephony, and provide a standard Ethernet/POTS/ISDN interface as the demarcation point.
To get telephony out of the RF side, an additional termination unit is needed. In contrast to DSL architectures, no additional software or stack components (PPTP, PPPoA, PPPoE) are required on the attached end system or gateway. The cable modem connects via coaxial drop and trunk cables as well as signal repeaters to a carrier's cable head-end. Mixed architectures featuring optical-electrical converters for optical trunk cables are used, too. In contrast to DSL, this is a shared medium; therefore, VLAN architectures and MAC-based access control are commonly deployed and addresses delivered to the customer via Dynamic Host Configuration Protocol (DHCP)
DSL Access
Historically, DSL has been an asymmetric service (ADSL), evolving into a symmetric one (G.SHDSL) designed to replace E1 TDM circuits and provide voice, ATM, raw IP, and ISDN transport.
DSL copper cables are terminated at a central office (CO) DSLAM port (digital subscriber access line multiplexer). The DSLAM serves two purposes:
One is to physically terminate the subscriber line and separate the voice band from the data bands utilizing an integrated splitter device similar to the one on the customer end; the voice signal is delivered directly to the PSTN network on OSI Layer 1.
The second purpose is to relay the data traffic to an IP backbone, usually based on ATM or Ethernet. Aggregation and service-selection gateways constitute the distribution layer of modern DSL provider architectures.
Almost all open-source UNIX operating systems provide mature PPTP support required for the PPPoA architectures that are popular in some European countries. Linux, OpenBSD, and FreeBSD support native PPPoE. PPPoA or PPPoE support of your favorite operating system usually requires a modified/patched version of the PPP toolset. Discussion goes beyond the scope of this book, but you can find easily several cookbooks for setup via your favorite search engine or Linux repository. Several DSL NICs are also available (ATM25, splitterless operation). Some of their important characteristics are as follows:
DSL modes of operation: PPPoA, PPPoE, bridging mode
DSL flavors: ADSL, HDSL, SDSL, G.SHDSL, G.Lite, VDSL, and so on
Software requirements of DSL access: PPPoE or PPPoA stack support, PPTP (for example, via Netgraph/mpd daemon under FreeBSD)
Lab 4-1: Synchronous Serial Connection Setup
This lab (as shown in Figure 4-1) facilitates two Sangoma synchronous serial S514/ET1 PCI adapter cards, connected via an RJ-45 crossover cable for point-to-point configuration between a Linux (callisto) and FreeBSD (castor) gateway. This lab deals with Layer 1 and Layer 2 issues; later labs in following chapters add scenarios on top of the data link layer. For the pin layout of the RJ-45 crossover cable as well as the installation of the NIC drivers, consult the Sangoma website.
Clear-channel/channelized/fractional operation
Multiple ports
Physical interfaces: V.35, V.36, X.21, RS-232
With or without integrated CSU/DSU
RAS option: with or without integrated digital modems (DSPs)
PRI signaling
Internal/external clocking
Almost all synchronous serial NICs support the following Layer 2 encapsulation formats:
LAPB (X.25 Layer2)
Frame Relay
Cisco HDLC
Synchronous PPP
Frame Relay services are deployed by carriers up to T3 bandwidth in the United States and up to E1 bandwidth in Europe and most other countries in 56/64-kbps or sometimes even smaller increments (subrates/derived channels). Configuration of X.25 or Frame Relay is similar to Cisco configurations with regard to virtual/subinterface concepts and topology (point to point, point to multipoint, and so on).
ATM Interfaces
Some vendors sell PCI ATM interface cards for ATM25 DSL interfaces, 155-Mbps STM-1/OC3, as well as "exotic" 622-Mbps STM-4/OC12 NICs, featuring both optical and electrical RJ-45 interfaces.
OpenBSD, Linux, and FreeBSD provide an ATM stack, but only a limited family of adapters is supported. This family unfortunately includes almost no state-of-the-art models. The best support available for ATM adapters is provided for Marconi ForeRunner and Efficient Networks chipsets. Consult the hardware compatibility list of the respective operating systems for further details.
As far as I have researched the matter, it would be interesting to deploy ATM25 adapter cards for UNIX gateway devices. Unfortunately, few vendors supply PCI models; almost all development effort appears to go into embedded systems for deployment in integrated access devices (IADs). ATM25 supports approximately 10.5-Mbps high-speed, 8-Mbps full-rate, and 4-Mbps or G.Lite downstream speeds and can accommodate ADSL, SDSL, VDSL, and G.SHDSL.
Because I do not own ATM-PCI adapters, no lab is provided in this section. The following sections discuss the Linux and FreeBSD ATM stack and configuration tools in detail. If you own two ATM interfaces cards, you can use an optical crossover cable pair for a nice lab or connect them to an ATM switch for ILMI testing. For RJ-45 crossovers, consult the pin assignments of the vendor's adapter manual.
Linux ATM Support
Unfortunately, there appears to be no further development going on with regard to the Linux ATM Project (http://linux-atm.sourceforge.net), which, of course, does not mean that it is not stable or useful. The drivers are included in up-to-date kernels. In addition, you still need to download the ATM support tools from http://linux-atm.sourceforge.net. Linux ATM implements several ATM-related daemons: atmsigd, ilmid, and atmarpd, as well as several ancillary tools.
Example 4-1 presents configuration of ATM PVC/SVC pairs under Linux. Remember, ATM PVCs are point-to-point abstractions.
To configure the atm0 interface as 10.1.1.1/30 and build a PVC on PHY 0, VPI 0, VCI 51 (emphasized by the shaded text) to the far-end 10.1.1.2/30, type the commands in the order presented in Example 4-1.
Example 4-1. Simple Linux ATM Interface and PVC Configuration
[root@callisto~#] atmarp -c atm0
[root@callisto~#] ifconfig atm0 10.1.1.1 netmask 255.255.255.252 mtu 4470
[root@callisto~#] atmarp -s 10.1.1.2 0.0.51
For an in-depth discussion, consult the Linux ATM-on-Linux HOWTO.
The FreeBSD HARP ATM Subsystem
FreeBSD provides mature ATM support via the Host ATM Research Platform (HARP) software. For configuration details, consult the atm(8) man page and the links in the "Recommended Reading" section
Cable Access (Ethernet Interfaces)
Cable access can be deployed easily. The vast majority of providers deliver a CPE device (cable modem) that terminates the coax network frequency bands that carry data, TV, and telephony, and provide a standard Ethernet/POTS/ISDN interface as the demarcation point.
To get telephony out of the RF side, an additional termination unit is needed. In contrast to DSL architectures, no additional software or stack components (PPTP, PPPoA, PPPoE) are required on the attached end system or gateway. The cable modem connects via coaxial drop and trunk cables as well as signal repeaters to a carrier's cable head-end. Mixed architectures featuring optical-electrical converters for optical trunk cables are used, too. In contrast to DSL, this is a shared medium; therefore, VLAN architectures and MAC-based access control are commonly deployed and addresses delivered to the customer via Dynamic Host Configuration Protocol (DHCP)
DSL Access
Historically, DSL has been an asymmetric service (ADSL), evolving into a symmetric one (G.SHDSL) designed to replace E1 TDM circuits and provide voice, ATM, raw IP, and ISDN transport.
DSL copper cables are terminated at a central office (CO) DSLAM port (digital subscriber access line multiplexer). The DSLAM serves two purposes:
One is to physically terminate the subscriber line and separate the voice band from the data bands utilizing an integrated splitter device similar to the one on the customer end; the voice signal is delivered directly to the PSTN network on OSI Layer 1.
The second purpose is to relay the data traffic to an IP backbone, usually based on ATM or Ethernet. Aggregation and service-selection gateways constitute the distribution layer of modern DSL provider architectures.
Almost all open-source UNIX operating systems provide mature PPTP support required for the PPPoA architectures that are popular in some European countries. Linux, OpenBSD, and FreeBSD support native PPPoE. PPPoA or PPPoE support of your favorite operating system usually requires a modified/patched version of the PPP toolset. Discussion goes beyond the scope of this book, but you can find easily several cookbooks for setup via your favorite search engine or Linux repository. Several DSL NICs are also available (ATM25, splitterless operation). Some of their important characteristics are as follows:
DSL modes of operation: PPPoA, PPPoE, bridging mode
DSL flavors: ADSL, HDSL, SDSL, G.SHDSL, G.Lite, VDSL, and so on
Software requirements of DSL access: PPPoE or PPPoA stack support, PPTP (for example, via Netgraph/mpd daemon under FreeBSD)
Lab 4-1: Synchronous Serial Connection Setup
This lab (as shown in Figure 4-1) facilitates two Sangoma synchronous serial S514/ET1 PCI adapter cards, connected via an RJ-45 crossover cable for point-to-point configuration between a Linux (callisto) and FreeBSD (castor) gateway. This lab deals with Layer 1 and Layer 2 issues; later labs in following chapters add scenarios on top of the data link layer. For the pin layout of the RJ-45 crossover cable as well as the installation of the NIC drivers, consult the Sangoma website.
Chapter 5. Ethernet and VLANs
Chapter 5. Ethernet and VLANs
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.
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.
Alias Interfaces
As mentioned in Chapter 3, "Kernel Requirements for a Full-Featured Lab," alias interfaces provide a way to assign multiple IP addresses to one physical interface. These addresses can either be from the same network broadcast domain or a different address range. However, they do not provide Layer 2 separation as VLAN tagging does.
You will learn in Chapter 9, "Dynamic Routing Protocols—Interior Gateway Protocols," and Chapter 10, "ISP Connectivity with BGP4: An Exterior Gateway Path-Vector Routing Protocol for Interdomain Routing," how alias information can be transported via dynamic routing protocols and used for virtual servers, redundancy, and Dynamic Name Service (DNS) round-robin configurations. Examples 5-1, 5-2, and 5-3 show the configuration of alias/secondary interfaces on Linux, OpenBSD, and FreeBSD systems; the corresponding statistics; and their representation in the Address Resolution Protocol (ARP) and routing tables. Keep in mind that the "colon" notation (shaded text) of Linux interfaces in general is not exactly equivalent to Cisco IOS subinterfaces.
Example 5-1. Linux Alias Interface Example
[root@callisto:~#] ifconfig eth1:1 192.168.45.1
[root@callisto:~#] ifconfig eth0:0 192.168.14.14
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1485 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:122180 (119.3 Kb)
Interrupt:5 Base address:0xd800
eth0:0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.14 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2604 errors:0 dropped:0 overruns:0 frame:0
TX packets:3166 errors:0 dropped:0 overruns:0 carrier:0
collisions:7 txqueuelen:100
RX bytes:691838 (675.6 Kb) TX bytes:307948 (300.7 Kb)
Interrupt:9 Base address:0xd400
eth1:1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.45.1 Bcast:192.168.45.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:9 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:489 errors:0 dropped:0 overruns:0 frame:0
TX packets:489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54587 (53.3 Kb) TX bytes:54587 (53.3 Kb)
[root@callisto:~#] arp -an
? (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1
? (192.168.14.254) at 00:60:47:1E:AD:B5 [ether] on eth0
? (192.168.45.254) at 48:54:E8:8C:0A:3F [ether] on eth1
[root@callisto:~#] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
############################################################################
# Alternative configuration via the Linux "ip" utility #
# Note that "ip" differentiates between "secondary" and "alias" addresses #
############################################################################
[root@callisto:~#] ip address add 192.168.14.14/24 broadcast 255.255.255.0 label eth0:0
dev eth0
[root@callisto:~#] ip address show eth0
2: eth0: mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:10:5a:d7:93:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.14.1/24 brd 192.168.14.255 scope global eth0
inet 192.168.14.14/24 brd 255.255.255.0 scope global secondary eth0:0
[root@callisto:~#] ip address add 192.168.45.1/24 broadcast 255.255.255.0 label eth1:1
dev eth1
[root@callisto:~#] ip address show eth1
3: eth1: mtu 1500 qdisc pfifo_fast qlen 100
link/ether 52:54:05:e3:51:87 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1
inet 192.168.45.1/24 brd 192.168.45.255 scope global eth1:1
[root@callisto:~#] ip route show
192.168.1.0/24 dev eth1 scope link
192.168.14.0/24 dev eth0 scope link
192.168.45.0/24 dev eth1 proto kernel scope link src 192.168.45.1
127.0.0.0/8 dev lo scope link
default via 192.168.1.254 dev eth1
Example 5-2. OpenBSD Alias Interface Example
[root@ganymed:~#] ifconfig ne3 alias 192.168.45.254 netmask 255.255.255.0
[root@ganymed:~#] ifconfig -A
lo0: flags=8049 mtu 33224
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8049 mtu 33224
inet 192.168.44.1 netmask 0xffffff00
inet6 fe80::1%lo1 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
ne3: flags=8b63
mtu 1500
media: Ethernet manual
inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::4a54:e8ff:fe8c:a3f%ne3 prefixlen 64 scopeid 0x1
inet 192.168.45.254 netmask 0xffffff00 broadcast 192.168.45.255
ne4: flags=8863 mtu 1500
media: Ethernet 10baseT full-duplex
inet 192.168.2.254 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::5054:5ff:fee3:e42f%ne4 prefixlen 64 scopeid 0x2
ne5: flags=8863 mtu 1500
media: Ethernet 10baseT full-duplex
inet 111.11.117.206 netmask 0xffffff00 broadcast 111.11.117.255
inet6 fe80::5054:5ff:fee3:5187%ne5 prefixlen 64 scopeid 0x3
ppp0: flags=8010 mtu 1500
ppp1: flags=8010 mtu 1500
tun0: flags=10 mtu 3000
tun1: flags=10 mtu 3000
enc0: flags=0<> mtu 1536
vlan0: flags=0<> mtu 1500
vlan1: flags=0<> mtu 1500
gre0: flags=8010 mtu 1450
gif0: flags=8010 mtu 1280
gif1: flags=8010 mtu 1280
gif2: flags=8010 mtu 1280
gif3: flags=8010 mtu 1280
faith0: flags=8002 mtu 1500
[root@ganymed:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 111.11.117.1 UGS 1 3570 1500 ne5
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 38 33224 lo0
192.168.1/24 link#1 UC 0 0 1500 ne3
192.168.1.1 52:54:5:e3:51:87 UHL 1 3387 1500 ne3
192.168.1.2 8:0:46:64:74:1b UHL 1 3049 1500 ne3
192.168.2/24 link#2 UC 0 0 1500 ne4
192.168.2.7 0:10:5a:c4:2c:4 UHL 0 2150 1500 ne4
192.168.44.1 192.168.44.1 UH 0 0 33224 lo1
192.168.45/24 link#1 UC 0 0 1500 ne3
111.11.117/24 link#3 UC 0 0 1500 ne5
111.11.117.1 0:5:9a:5b:23:fc UHL 1 0 1500 ne5
111.11.117.206 127.0.0.1 UGHS 0 0 33224 lo0
Example 5-3. FreeBSD Alias Interface Example
[root@castor:~#] ifconfig ed0 alias 192.168.7.77 netmask 255.255.255.255
[root@castor:~#] ifconfig
xl0: flags=8b43 mtu 1500
options=3
inet 192.168.2.7 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::210:5aff:fec4:2c04%xl0 prefixlen 64 scopeid 0x1
ether 00:10:5a:c4:2c:04
media: Ethernet autoselect (10baseT/UTP)
status: active
ed0: flags=8a43 mtu 1500
inet 192.168.7.7 netmask 0xffffff00 broadcast 192.168.7.255
inet6 fe80::5054:5ff:fee3:e488%ed0 prefixlen 64 scopeid 0x2
inet 192.168.7.77 netmask 0xffffffff broadcast 192.168.7.77
ether 52:54:05:e3:e4:88
lp0: flags=8810 mtu 1500
sl0: flags=c010 mtu 552
sl1: flags=c010 mtu 552
ds0: flags=8008 mtu 65532
stf0: flags=0<> mtu 1280
faith0: flags=8002 mtu 1500
vlan0: flags=0<> mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
vlan1: flags=0<> mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010 mtu 1500
ppp1: flags=8010 mtu 1500
[root@castor:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.254 UGSc 4 1836 xl0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.2 link#1 UC 1 0 xl0
192.168.2.254 52:54:05:e3:e4:2f UHLW 4 0 xl0 592
192.168.7 link#2 UC 0 0 ed0
192.168.7.77/32 link#2 UC 0 0 ed0
NOTE
In contrast to "real" physical interfaces (and to BSD aliases), ifconfig down does not only shut down the interface, but entirely removes it; it cannot be brought up again with a mere ifconfig up, but has to be reassigned the IP address (thus created anew). This is true for several other pseudo-interfaces as well.
Example 5-4 demonstrates a secondary address assignment under Cisco IOS Software as emphasized via the shaded text. Note that Linux differentiates between a secondary address and an interface alias, as demonstrated with the ip tool in Example 5-1 (shaded text).
Example 5-4. Cisco IOS Secondary Interface Address Example
scar# show running-config
!
...
interface Ethernet1
bandwidth 10000
ip address 192.168.14.14 255.255.255.0 secondary
ip address 192.168.14.254 255.255.255.0
no ip proxy-arp
media-type 10BaseT
!
...
scar# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.14.1 to network 0.0.0.0
C 192.168.14.0/24 is directly connected, Ethernet1
10.0.0.0/32 is subnetted, 1 subnets
C 10.0.0.1 is directly connected, Loopback0
C 192.168.7.0/24 is directly connected, Ethernet0
S* 0.0.0.0/0 [1/0] via 192.168.14.1
scar# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.14.1 0 0010.5ad7.9360 ARPA Ethernet1
Internet 192.168.14.14 - 0060.471e.adb5 ARPA Ethernet1
Internet 192.168.7.7 14 5254.05e3.e488 ARPA Ethernet0
Internet 192.168.7.254 - 0060.471e.adb2 ARPA Ethernet0
Internet 192.168.14.254 - 0060.471e.adb5 ARPA Ethernet1
VLAN Configurations
Today, two dominant VLAN tagging methods exist: the Cisco proprietary Inter-Switch Link (ISL) approach and the standardized IEEE 802.1Q method. Note also that VLAN trunks are special ports or interfaces that are capable of delivering multi-VLAN traffic to a directly connected trunk port or interface.
Cisco has developed a proprietary protocol (VTP, or VLAN Trunking Protocol) to distribute VLAN information through a vast switched network without the need to configure VLANs on every switch. The only task left to do for the administrator is to configure a VTP domain and its participants and to assign ports to specific VLANs distributed via VTP. A rather young open standard for that is available as well (see IEEE GVRP - Generic VLAN Registration Protocol).
VLAN setup itself is not difficult to configure, if you adhere to the following:
To ensure that everything is working, I recommend verifying proper operation with the arp, netstat, and ifconfig/ip commands.
In addition, check MTU issues with large IP datagrams such as FTP transfers or handcrafted ping packets. 802.1Q VLAN tagging adds 4 overhead octets between the frame header and the payload that need to be accounted for. Therefore, adjust the interface MTU size to 1496 in case that is not done automatically (as is done on BSD systems).
Keep in mind that the MTU throughout of your subnet should be consistent as well (for example, 1496 octets). Depending on the protocols involved, it might even become necessary to further decrease the MTU. This might be necessary for both the VLAN and parent interfaces.
Some NICs, such as the Intel FastEtherPro, support large frames and VLAN demultiplexing natively (in firmware) and operate well with the default MTU of 1500. Sometimes patching the drivers also helps.
Adding alias interfaces to VLAN interfaces works perfectly fine, too, exactly as with physical interfaces.
All represented platforms have no problem with the Cisco native VLAN1. The alias and VLAN limits of a platform usually can be derived only when investigating the sources.
Linux imposes a VLAN limit of 4096 VLANs per interface on 2.4.x kernels.
Remember to restart your firewall when adding/deleting interfaces! Unfortunately, a lot of ill-configured firewall gateways nowadays break two-way-path MTU discovery. Ensure that you allow the proper Internet Control Message Protocol (ICMP) packets through in both directions. (ICMP type 3/code 4 = "fragmentation needed but do not fragment bit set" in combination with the probing IP packets with DF-bit set.)
Adding frame overhead such as with Multiprotocol Label Switching (MPLS) shim headers or VLAN tagging represents in the view of many switches a so-called giant or jumbo frame, which usually is silently discarded on regular switch ports. If you encounter problems that appear to affect only large frames, check the giant counters of your switch. Most modern switches and IOS/CatOS versions can deal with this issue. As a workaround, you could configure a VLAN trunk.
Figure 5-1 shows the three VLAN topologies discussed in this chapter. Example 5-5 shows the switch VLAN configuration, and Example 5-6 shows the corresponding ARP output. Example 5-7 presents the analogous configuration for the router involved. Example 5-8 provides status information, and Example 5-9 shows the router's ARP table.
Example 5-5. Ethernet Switch VLAN Configuration (IOS)
Switch# show running-config
!
ip subnet-zero
!
interface FastEthernet0/1
switchport mode trunk
!
interface FastEthernet0/2
switchport mode trunk
!
interface FastEthernet0/3
switchport mode trunk
!
interface VLAN1
ip address 192.168.7.8 255.255.255.0
no ip directed-broadcast
no ip route-cache
!
interface VLAN8
ip address 192.168.80.2 255.255.255.0
no ip directed-broadcast
no ip route-cache
!
ip default-gateway 192.168.7.7
!
Example 5-6. VLAN-Related Switch ARP Table
Switch# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.80.1 10 5254.05e3.e488 ARPA VLAN8
Internet 192.168.80.2 - 0006.5258.5d40 ARPA VLAN8
Internet 192.168.7.8 - 0006.5258.5d40 ARPA VLAN1
Internet 192.168.80.254 8 0008.e34d.be81 ARPA VLAN8
Example 5-7. Router VLAN Configuration
mufasa# show running-config
...
!
interface FastEthernet0/1
description *** 802.1Q Trunk ***
no ip address
no ip mroute-cache
duplex auto
speed auto
!
interface FastEthernet0/1.1
encapsulation dot1Q 1 native
ip address 192.168.7.254 255.255.255.0
!
interface FastEthernet0/1.8
encapsulation dot1Q 8
ip address 192.168.80.254 255.255.255.0
!
...
Example 5-8. Router VLAN Status
mufasa# show vlans
Virtual LAN ID: 1 (IEEE 802.1Q Encapsulation)
vLAN Trunk Interface: FastEthernet0/1.1
This is configured as native Vlan for the following interface(s) :
FastEthernet0/1
Protocols Configured: Address: Received: Transmitted:
IP 192.168.7.254 0 19
Virtual LAN ID: 8 (IEEE 802.1Q Encapsulation)
vLAN Trunk Interface: FastEthernet0/1.8
Protocols Configured: Address: Received: Transmitted:
IP 192.168.80.254 20 27
Example 5-9. Router VLAN-Related ARP Table
mufasa# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.80.1 7 5254.05e3.e488 ARPA FastEthernet0/1.8
Internet 192.168.80.2 5 0006.5258.5d40 ARPA FastEthernet0/1.8
Internet 192.168.7.254 - 0008.e34d.be81 ARPA FastEthernet0/1.1
Internet 192.168.80.254 - 0008.e34d.be81 ARPA FastEthernet0/1.8
The following two subsections elaborate on VLAN capabilities of FreeBSD, OpenBSD, and Linux and discuss differences and similarities in setup and behavior.
Linux VLAN Capabilities
Late 2.4.x kernels provide 802.1Q VLAN capabilities as a native kernel module. However, one still needs to retrieve the vconfig VLAN administration utility from http://www.candelatech.com/~greear/vlan.html#setup. Most up-to-date Linux distributions already include this utility.
Recently, the capability to define MAC-based VLANs was added via the macvlan_config utility, which is included in the vconfig archive. You still have to apply a kernel patch for that extension, however. Example 5-10 shows the configuration sequence for Linux VLAN interfaces, Example 5-11 shows the resulting status, and Example 5-12 shows additional monitoring information. The shaded text emphasizes the previously mentioned warnings about MTU.
Example 5-10. Linux VLAN Interface Configuration
[root@callisto:~#] vconfig add eth0 8
[root@callisto:~#] ifconfig vlan8 192.168.80.3/24 mtu 1496
Example 5-11. Linux Interface Status After VLAN Configuration
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:124 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9246 (9.0 Kb) TX bytes:2478 (2.4 Kb)
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9007 errors:0 dropped:0 overruns:0 frame:0
TX packets:5240 errors:0 dropped:0 overruns:0 carrier:0
collisions:37 txqueuelen:100
RX bytes:1891927 (1.8 Mb) TX bytes:497578 (485.9 Kb)
Interrupt:9 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:84 errors:0 dropped:0 overruns:0 frame:0
TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6308 (6.1 Kb) TX bytes:6308 (6.1 Kb)
vlan1 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.7.10 Bcast:192.168.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1496 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vlan8 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.80.3 Bcast:192.168.80.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1496 Metric:1
RX packets:21 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1764 (1.7 Kb) TX bytes:2168 (2.1 Kb)
Example 5-12. Linux VLAN-Related Status Information
[root@callisto:~#] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.0 U 40 0 0 vlan1
192.168.80.0 0.0.0.0 255.255.255.0 U 40 0 0 vlan8
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.14.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 192.168.1.254 0.0.0.0 UG 40 0 0 eth1
[root@callisto:~#] arp -an
? (192.168.1.2) at 08:00:46:64:74:1B [ether] on eth1
? (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1
? (192.168.80.1) at 52:54:05:E3:E4:88 [ether] on vlan8
[root@callisto:~#] less /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan1 | 1 | eth0
vlan8 | 8 | eth0
[root@callisto:~#] less /proc/net/vlan/vlan8
vlan8 VID: 8 REORDER_HDR: 1 dev->priv_flags: 1
total frames received: 21
total bytes received: 1764
Broadcast/Multicast Rcvd: 0
total frames transmitted: 24
total bytes transmitted: 2168
total headroom inc: 0
total encap on xmit: 24
Device: eth0
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESSS priority Mappings:
[root@callisto:~#] less /proc/net/vlan/vlan1
vlan1 VID: 1 REORDER_HDR: 1 dev->priv_flags: 1
total frames received: 0
total bytes received: 0
Broadcast/Multicast Rcvd: 0
total frames transmitted: 0
total bytes transmitted: 0
total headroom inc: 0
total encap on xmit: 0
Device: eth0
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESSS priority Mappings:
FreeBSD/OpenBSD VLAN Capabilities
FreeBSD/OpenBSD setup is straightforward and works the same way for both operating systems. The MTU size is adjusted automatically during setup of the VLAN interfaces.
Consult the BSD vlan(4) and ifconfig(8) man pages for further details about these platforms. Example 5-13 shows the configuration steps for FreeBSD VLAN setup, Example 5-14 shows the resulting interface status, and Example 5-15 provides additional status information.
Example 5-13. BSD VLAN Configuration
[root@castor:~#] ifconfig vlan8 create
[root@castor:~#] ifconfig vlan8 vlan 8 vlandev ed0
[root@castor:~#] ifconfig vlan8 192.168.80.1/24
Example 5-14. FreeBSD Interface Status After VLAN Configuration
[root@castor:~#] ifconfig -a
xl0: flags=8b43 mtu 1500
options=3
inet 192.168.2.7 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::210:5aff:fec4:2c04%xl0 prefixlen 64 scopeid 0x1
ether 00:10:5a:c4:2c:04
media: Ethernet autoselect (10baseT/UTP)
status: active
ed0: flags=8a43 mtu 1500
inet 192.168.7.7 netmask 0xffffff00 broadcast 192.168.7.255
inet6 fe80::5054:5ff:fee3:e488%ed0 prefixlen 64 scopeid 0x2
ether 52:54:05:e3:e4:88
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
inet 127.0.0.1 netmask 0xff000000
vlan8: flags=8843 mtu 1496
inet6 fe80::210:5aff:fec4:2c04%vlan8 prefixlen 64 scopeid 0xe
inet 192.168.80.1 netmask 0xffffff00 broadcast 255.255.255.0
ether 52:54:05:e3:e4:88
vlan: 8 parent interface: ed0
...
Example 5-15. FreeBSD VLAN Status Information
[root@castor:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.254 UGSc 5 3826 xl0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.2 link#1 UC 1 0 xl0
192.168.2.254 52:54:05:e3:e4:2f UHLW 5 0 xl0 694
192.168.7 link#2 UC 1 0 ed0
192.168.7.7 52:54:05:e3:e4:88 UHLW 0 4 lo0
192.168.80 link#14 UC 1 0 vlan8
192.168.80.1 52.54.5.e3.e4.88 UHLW 0 4 lo0
[root@castor:~#] arp -an
? (192.168.2.254) at 52:54:05:e3:e4:2f on xl0 [ethernet]
? (192.168.7.7) at 52:54:05:e3:e4:88 on ed0 permanent [ethernet]
? (192.168.80.1) at 52:54:05:e3:e4:88 on vlan8 permanent [vlan]
? (192.168.80.2) at (incomplete) on vlan8 [vlan]
? (192.168.80.3) at 00:10:5a:d7:93:60 on vlan8 [vlan]
As mentioned in Chapter 3, "Kernel Requirements for a Full-Featured Lab," alias interfaces provide a way to assign multiple IP addresses to one physical interface. These addresses can either be from the same network broadcast domain or a different address range. However, they do not provide Layer 2 separation as VLAN tagging does.
You will learn in Chapter 9, "Dynamic Routing Protocols—Interior Gateway Protocols," and Chapter 10, "ISP Connectivity with BGP4: An Exterior Gateway Path-Vector Routing Protocol for Interdomain Routing," how alias information can be transported via dynamic routing protocols and used for virtual servers, redundancy, and Dynamic Name Service (DNS) round-robin configurations. Examples 5-1, 5-2, and 5-3 show the configuration of alias/secondary interfaces on Linux, OpenBSD, and FreeBSD systems; the corresponding statistics; and their representation in the Address Resolution Protocol (ARP) and routing tables. Keep in mind that the "colon" notation (shaded text) of Linux interfaces in general is not exactly equivalent to Cisco IOS subinterfaces.
Example 5-1. Linux Alias Interface Example
[root@callisto:~#] ifconfig eth1:1 192.168.45.1
[root@callisto:~#] ifconfig eth0:0 192.168.14.14
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1485 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:122180 (119.3 Kb)
Interrupt:5 Base address:0xd800
eth0:0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.14 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2604 errors:0 dropped:0 overruns:0 frame:0
TX packets:3166 errors:0 dropped:0 overruns:0 carrier:0
collisions:7 txqueuelen:100
RX bytes:691838 (675.6 Kb) TX bytes:307948 (300.7 Kb)
Interrupt:9 Base address:0xd400
eth1:1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.45.1 Bcast:192.168.45.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:9 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:489 errors:0 dropped:0 overruns:0 frame:0
TX packets:489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54587 (53.3 Kb) TX bytes:54587 (53.3 Kb)
[root@callisto:~#] arp -an
? (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1
? (192.168.14.254) at 00:60:47:1E:AD:B5 [ether] on eth0
? (192.168.45.254) at 48:54:E8:8C:0A:3F [ether] on eth1
[root@callisto:~#] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
############################################################################
# Alternative configuration via the Linux "ip" utility #
# Note that "ip" differentiates between "secondary" and "alias" addresses #
############################################################################
[root@callisto:~#] ip address add 192.168.14.14/24 broadcast 255.255.255.0 label eth0:0
dev eth0
[root@callisto:~#] ip address show eth0
2: eth0:
link/ether 00:10:5a:d7:93:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.14.1/24 brd 192.168.14.255 scope global eth0
inet 192.168.14.14/24 brd 255.255.255.0 scope global secondary eth0:0
[root@callisto:~#] ip address add 192.168.45.1/24 broadcast 255.255.255.0 label eth1:1
dev eth1
[root@callisto:~#] ip address show eth1
3: eth1:
link/ether 52:54:05:e3:51:87 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1
inet 192.168.45.1/24 brd 192.168.45.255 scope global eth1:1
[root@callisto:~#] ip route show
192.168.1.0/24 dev eth1 scope link
192.168.14.0/24 dev eth0 scope link
192.168.45.0/24 dev eth1 proto kernel scope link src 192.168.45.1
127.0.0.0/8 dev lo scope link
default via 192.168.1.254 dev eth1
Example 5-2. OpenBSD Alias Interface Example
[root@ganymed:~#] ifconfig ne3 alias 192.168.45.254 netmask 255.255.255.0
[root@ganymed:~#] ifconfig -A
lo0: flags=8049
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8049
inet 192.168.44.1 netmask 0xffffff00
inet6 fe80::1%lo1 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
ne3: flags=8b63
mtu 1500
media: Ethernet manual
inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::4a54:e8ff:fe8c:a3f%ne3 prefixlen 64 scopeid 0x1
inet 192.168.45.254 netmask 0xffffff00 broadcast 192.168.45.255
ne4: flags=8863
media: Ethernet 10baseT full-duplex
inet 192.168.2.254 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::5054:5ff:fee3:e42f%ne4 prefixlen 64 scopeid 0x2
ne5: flags=8863
media: Ethernet 10baseT full-duplex
inet 111.11.117.206 netmask 0xffffff00 broadcast 111.11.117.255
inet6 fe80::5054:5ff:fee3:5187%ne5 prefixlen 64 scopeid 0x3
ppp0: flags=8010
ppp1: flags=8010
tun0: flags=10
tun1: flags=10
enc0: flags=0<> mtu 1536
vlan0: flags=0<> mtu 1500
vlan1: flags=0<> mtu 1500
gre0: flags=8010
gif0: flags=8010
gif1: flags=8010
gif2: flags=8010
gif3: flags=8010
faith0: flags=8002
[root@ganymed:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 111.11.117.1 UGS 1 3570 1500 ne5
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 38 33224 lo0
192.168.1/24 link#1 UC 0 0 1500 ne3
192.168.1.1 52:54:5:e3:51:87 UHL 1 3387 1500 ne3
192.168.1.2 8:0:46:64:74:1b UHL 1 3049 1500 ne3
192.168.2/24 link#2 UC 0 0 1500 ne4
192.168.2.7 0:10:5a:c4:2c:4 UHL 0 2150 1500 ne4
192.168.44.1 192.168.44.1 UH 0 0 33224 lo1
192.168.45/24 link#1 UC 0 0 1500 ne3
111.11.117/24 link#3 UC 0 0 1500 ne5
111.11.117.1 0:5:9a:5b:23:fc UHL 1 0 1500 ne5
111.11.117.206 127.0.0.1 UGHS 0 0 33224 lo0
Example 5-3. FreeBSD Alias Interface Example
[root@castor:~#] ifconfig ed0 alias 192.168.7.77 netmask 255.255.255.255
[root@castor:~#] ifconfig
xl0: flags=8b43
options=3
inet 192.168.2.7 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::210:5aff:fec4:2c04%xl0 prefixlen 64 scopeid 0x1
ether 00:10:5a:c4:2c:04
media: Ethernet autoselect (10baseT/UTP)
status: active
ed0: flags=8a43
inet 192.168.7.7 netmask 0xffffff00 broadcast 192.168.7.255
inet6 fe80::5054:5ff:fee3:e488%ed0 prefixlen 64 scopeid 0x2
inet 192.168.7.77 netmask 0xffffffff broadcast 192.168.7.77
ether 52:54:05:e3:e4:88
lp0: flags=8810
sl0: flags=c010
sl1: flags=c010
ds0: flags=8008
stf0: flags=0<> mtu 1280
faith0: flags=8002
vlan0: flags=0<> mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
vlan1: flags=0<> mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
lo0: flags=8049
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010
ppp1: flags=8010
[root@castor:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.254 UGSc 4 1836 xl0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.2 link#1 UC 1 0 xl0
192.168.2.254 52:54:05:e3:e4:2f UHLW 4 0 xl0 592
192.168.7 link#2 UC 0 0 ed0
192.168.7.77/32 link#2 UC 0 0 ed0
NOTE
In contrast to "real" physical interfaces (and to BSD aliases), ifconfig down does not only shut down the interface, but entirely removes it; it cannot be brought up again with a mere ifconfig up, but has to be reassigned the IP address (thus created anew). This is true for several other pseudo-interfaces as well.
Example 5-4 demonstrates a secondary address assignment under Cisco IOS Software as emphasized via the shaded text. Note that Linux differentiates between a secondary address and an interface alias, as demonstrated with the ip tool in Example 5-1 (shaded text).
Example 5-4. Cisco IOS Secondary Interface Address Example
scar# show running-config
!
...
interface Ethernet1
bandwidth 10000
ip address 192.168.14.14 255.255.255.0 secondary
ip address 192.168.14.254 255.255.255.0
no ip proxy-arp
media-type 10BaseT
!
...
scar# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.14.1 to network 0.0.0.0
C 192.168.14.0/24 is directly connected, Ethernet1
10.0.0.0/32 is subnetted, 1 subnets
C 10.0.0.1 is directly connected, Loopback0
C 192.168.7.0/24 is directly connected, Ethernet0
S* 0.0.0.0/0 [1/0] via 192.168.14.1
scar# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.14.1 0 0010.5ad7.9360 ARPA Ethernet1
Internet 192.168.14.14 - 0060.471e.adb5 ARPA Ethernet1
Internet 192.168.7.7 14 5254.05e3.e488 ARPA Ethernet0
Internet 192.168.7.254 - 0060.471e.adb2 ARPA Ethernet0
Internet 192.168.14.254 - 0060.471e.adb5 ARPA Ethernet1
VLAN Configurations
Today, two dominant VLAN tagging methods exist: the Cisco proprietary Inter-Switch Link (ISL) approach and the standardized IEEE 802.1Q method. Note also that VLAN trunks are special ports or interfaces that are capable of delivering multi-VLAN traffic to a directly connected trunk port or interface.
Cisco has developed a proprietary protocol (VTP, or VLAN Trunking Protocol) to distribute VLAN information through a vast switched network without the need to configure VLANs on every switch. The only task left to do for the administrator is to configure a VTP domain and its participants and to assign ports to specific VLANs distributed via VTP. A rather young open standard for that is available as well (see IEEE GVRP - Generic VLAN Registration Protocol).
VLAN setup itself is not difficult to configure, if you adhere to the following:
To ensure that everything is working, I recommend verifying proper operation with the arp, netstat, and ifconfig/ip commands.
In addition, check MTU issues with large IP datagrams such as FTP transfers or handcrafted ping packets. 802.1Q VLAN tagging adds 4 overhead octets between the frame header and the payload that need to be accounted for. Therefore, adjust the interface MTU size to 1496 in case that is not done automatically (as is done on BSD systems).
Keep in mind that the MTU throughout of your subnet should be consistent as well (for example, 1496 octets). Depending on the protocols involved, it might even become necessary to further decrease the MTU. This might be necessary for both the VLAN and parent interfaces.
Some NICs, such as the Intel FastEtherPro, support large frames and VLAN demultiplexing natively (in firmware) and operate well with the default MTU of 1500. Sometimes patching the drivers also helps.
Adding alias interfaces to VLAN interfaces works perfectly fine, too, exactly as with physical interfaces.
All represented platforms have no problem with the Cisco native VLAN1. The alias and VLAN limits of a platform usually can be derived only when investigating the sources.
Linux imposes a VLAN limit of 4096 VLANs per interface on 2.4.x kernels.
Remember to restart your firewall when adding/deleting interfaces! Unfortunately, a lot of ill-configured firewall gateways nowadays break two-way-path MTU discovery. Ensure that you allow the proper Internet Control Message Protocol (ICMP) packets through in both directions. (ICMP type 3/code 4 = "fragmentation needed but do not fragment bit set" in combination with the probing IP packets with DF-bit set.)
Adding frame overhead such as with Multiprotocol Label Switching (MPLS) shim headers or VLAN tagging represents in the view of many switches a so-called giant or jumbo frame, which usually is silently discarded on regular switch ports. If you encounter problems that appear to affect only large frames, check the giant counters of your switch. Most modern switches and IOS/CatOS versions can deal with this issue. As a workaround, you could configure a VLAN trunk.
Figure 5-1 shows the three VLAN topologies discussed in this chapter. Example 5-5 shows the switch VLAN configuration, and Example 5-6 shows the corresponding ARP output. Example 5-7 presents the analogous configuration for the router involved. Example 5-8 provides status information, and Example 5-9 shows the router's ARP table.
Example 5-5. Ethernet Switch VLAN Configuration (IOS)
Switch# show running-config
!
ip subnet-zero
!
interface FastEthernet0/1
switchport mode trunk
!
interface FastEthernet0/2
switchport mode trunk
!
interface FastEthernet0/3
switchport mode trunk
!
interface VLAN1
ip address 192.168.7.8 255.255.255.0
no ip directed-broadcast
no ip route-cache
!
interface VLAN8
ip address 192.168.80.2 255.255.255.0
no ip directed-broadcast
no ip route-cache
!
ip default-gateway 192.168.7.7
!
Example 5-6. VLAN-Related Switch ARP Table
Switch# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.80.1 10 5254.05e3.e488 ARPA VLAN8
Internet 192.168.80.2 - 0006.5258.5d40 ARPA VLAN8
Internet 192.168.7.8 - 0006.5258.5d40 ARPA VLAN1
Internet 192.168.80.254 8 0008.e34d.be81 ARPA VLAN8
Example 5-7. Router VLAN Configuration
mufasa# show running-config
...
!
interface FastEthernet0/1
description *** 802.1Q Trunk ***
no ip address
no ip mroute-cache
duplex auto
speed auto
!
interface FastEthernet0/1.1
encapsulation dot1Q 1 native
ip address 192.168.7.254 255.255.255.0
!
interface FastEthernet0/1.8
encapsulation dot1Q 8
ip address 192.168.80.254 255.255.255.0
!
...
Example 5-8. Router VLAN Status
mufasa# show vlans
Virtual LAN ID: 1 (IEEE 802.1Q Encapsulation)
vLAN Trunk Interface: FastEthernet0/1.1
This is configured as native Vlan for the following interface(s) :
FastEthernet0/1
Protocols Configured: Address: Received: Transmitted:
IP 192.168.7.254 0 19
Virtual LAN ID: 8 (IEEE 802.1Q Encapsulation)
vLAN Trunk Interface: FastEthernet0/1.8
Protocols Configured: Address: Received: Transmitted:
IP 192.168.80.254 20 27
Example 5-9. Router VLAN-Related ARP Table
mufasa# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.80.1 7 5254.05e3.e488 ARPA FastEthernet0/1.8
Internet 192.168.80.2 5 0006.5258.5d40 ARPA FastEthernet0/1.8
Internet 192.168.7.254 - 0008.e34d.be81 ARPA FastEthernet0/1.1
Internet 192.168.80.254 - 0008.e34d.be81 ARPA FastEthernet0/1.8
The following two subsections elaborate on VLAN capabilities of FreeBSD, OpenBSD, and Linux and discuss differences and similarities in setup and behavior.
Linux VLAN Capabilities
Late 2.4.x kernels provide 802.1Q VLAN capabilities as a native kernel module. However, one still needs to retrieve the vconfig VLAN administration utility from http://www.candelatech.com/~greear/vlan.html#setup. Most up-to-date Linux distributions already include this utility.
Recently, the capability to define MAC-based VLANs was added via the macvlan_config utility, which is included in the vconfig archive. You still have to apply a kernel patch for that extension, however. Example 5-10 shows the configuration sequence for Linux VLAN interfaces, Example 5-11 shows the resulting status, and Example 5-12 shows additional monitoring information. The shaded text emphasizes the previously mentioned warnings about MTU.
Example 5-10. Linux VLAN Interface Configuration
[root@callisto:~#] vconfig add eth0 8
[root@callisto:~#] ifconfig vlan8 192.168.80.3/24 mtu 1496
Example 5-11. Linux Interface Status After VLAN Configuration
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:124 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9246 (9.0 Kb) TX bytes:2478 (2.4 Kb)
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9007 errors:0 dropped:0 overruns:0 frame:0
TX packets:5240 errors:0 dropped:0 overruns:0 carrier:0
collisions:37 txqueuelen:100
RX bytes:1891927 (1.8 Mb) TX bytes:497578 (485.9 Kb)
Interrupt:9 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:84 errors:0 dropped:0 overruns:0 frame:0
TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6308 (6.1 Kb) TX bytes:6308 (6.1 Kb)
vlan1 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.7.10 Bcast:192.168.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1496 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vlan8 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.80.3 Bcast:192.168.80.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1496 Metric:1
RX packets:21 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1764 (1.7 Kb) TX bytes:2168 (2.1 Kb)
Example 5-12. Linux VLAN-Related Status Information
[root@callisto:~#] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.0 U 40 0 0 vlan1
192.168.80.0 0.0.0.0 255.255.255.0 U 40 0 0 vlan8
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.14.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 192.168.1.254 0.0.0.0 UG 40 0 0 eth1
[root@callisto:~#] arp -an
? (192.168.1.2) at 08:00:46:64:74:1B [ether] on eth1
? (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1
? (192.168.80.1) at 52:54:05:E3:E4:88 [ether] on vlan8
[root@callisto:~#] less /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan1 | 1 | eth0
vlan8 | 8 | eth0
[root@callisto:~#] less /proc/net/vlan/vlan8
vlan8 VID: 8 REORDER_HDR: 1 dev->priv_flags: 1
total frames received: 21
total bytes received: 1764
Broadcast/Multicast Rcvd: 0
total frames transmitted: 24
total bytes transmitted: 2168
total headroom inc: 0
total encap on xmit: 24
Device: eth0
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESSS priority Mappings:
[root@callisto:~#] less /proc/net/vlan/vlan1
vlan1 VID: 1 REORDER_HDR: 1 dev->priv_flags: 1
total frames received: 0
total bytes received: 0
Broadcast/Multicast Rcvd: 0
total frames transmitted: 0
total bytes transmitted: 0
total headroom inc: 0
total encap on xmit: 0
Device: eth0
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESSS priority Mappings:
FreeBSD/OpenBSD VLAN Capabilities
FreeBSD/OpenBSD setup is straightforward and works the same way for both operating systems. The MTU size is adjusted automatically during setup of the VLAN interfaces.
Consult the BSD vlan(4) and ifconfig(8) man pages for further details about these platforms. Example 5-13 shows the configuration steps for FreeBSD VLAN setup, Example 5-14 shows the resulting interface status, and Example 5-15 provides additional status information.
Example 5-13. BSD VLAN Configuration
[root@castor:~#] ifconfig vlan8 create
[root@castor:~#] ifconfig vlan8 vlan 8 vlandev ed0
[root@castor:~#] ifconfig vlan8 192.168.80.1/24
Example 5-14. FreeBSD Interface Status After VLAN Configuration
[root@castor:~#] ifconfig -a
xl0: flags=8b43
options=3
inet 192.168.2.7 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::210:5aff:fec4:2c04%xl0 prefixlen 64 scopeid 0x1
ether 00:10:5a:c4:2c:04
media: Ethernet autoselect (10baseT/UTP)
status: active
ed0: flags=8a43
inet 192.168.7.7 netmask 0xffffff00 broadcast 192.168.7.255
inet6 fe80::5054:5ff:fee3:e488%ed0 prefixlen 64 scopeid 0x2
ether 52:54:05:e3:e4:88
lo0: flags=8049
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
inet 127.0.0.1 netmask 0xff000000
vlan8: flags=8843
inet6 fe80::210:5aff:fec4:2c04%vlan8 prefixlen 64 scopeid 0xe
inet 192.168.80.1 netmask 0xffffff00 broadcast 255.255.255.0
ether 52:54:05:e3:e4:88
vlan: 8 parent interface: ed0
...
Example 5-15. FreeBSD VLAN Status Information
[root@castor:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.254 UGSc 5 3826 xl0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.2 link#1 UC 1 0 xl0
192.168.2.254 52:54:05:e3:e4:2f UHLW 5 0 xl0 694
192.168.7 link#2 UC 1 0 ed0
192.168.7.7 52:54:05:e3:e4:88 UHLW 0 4 lo0
192.168.80 link#14 UC 1 0 vlan8
192.168.80.1 52.54.5.e3.e4.88 UHLW 0 4 lo0
[root@castor:~#] arp -an
? (192.168.2.254) at 52:54:05:e3:e4:2f on xl0 [ethernet]
? (192.168.7.7) at 52:54:05:e3:e4:88 on ed0 permanent [ethernet]
? (192.168.80.1) at 52:54:05:e3:e4:88 on vlan8 permanent [vlan]
? (192.168.80.2) at (incomplete) on vlan8 [vlan]
? (192.168.80.3) at 00:10:5a:d7:93:60 on vlan8 [vlan]
A Few Words on Cabling
A Few Words on Cabling
In our lab setups, we typically require several kinds of RJ-45 connections: rollover (Console), Ethernet crossover (X-over), and standard Ethernet straight-through cabling. For a reminder of the pin assignments, check Cisco.com (http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/hw_inst/cabling/marcabl.htm).
Serial X-over cables are an entirely different matter due to the variety of interfaces. Again, refer to Cisco.com for details. Optical PCI ATM adapters can be connected back to back via a simple optical X-over cable pair without the need for an ATM switch. However, you will not be able to test network-to-network interface (NNI), switched virtual circuit (SVC), or interim local management interface (ILMI) features without an intermediary
Example 5-18. FreeBSD Bridge-Cluster Setup
[root@castor:~#] sysctl net.link.ether.bridge_cfg=vlan8:34,xl0:34,vlan9:35,xl1:35
[root@castor:~#] ifconfig vlan8 create
[root@castor:~#] ifconfig vlan9 create
[root@castor:~#] ifconfig vlan8 vlan 8 vlandev ed0
[root@castor:~#] ifconfig vlan9 vlan 9 vlandev ed0
You can certainly use advanced features such as filtering and traffic shaping on bridged interfaces, VLANs, and trunks as well
Example 5-16. Plain Bridging Between Two Interfaces
[root@castor:~#] sysctl net.link.ether.bridge=1
net.link.ether.bridge: 1 -> 1
[root@castor:~#] sysctl net.link.ether.bridge_cfg=xl0:1,ed0:1
net.link.ether.bridge_cfg: xl0:1 -> xl0:1,ed0:1
Example 5-17. FreeBSD Bridging-Related Status Information
[root@castor:~#] sysctl -a | grep bridge
net.link.ether.bridge_cfg: xl0:1,ed0:1
net.link.ether.bridge: 1
net.link.ether.bridge_ipfw: 0
net.link.ether.bridge_ipfw_drop: 0
net.link.ether.bridge_ipfw_collisions: 0
The configuration in Figure 5-3 and Example 5-18 is derived from the bridge(4) man page and presents a bridge-cluster setup example involving VLANs and parent interfaces. Interface ed0 acts as a VLAN trunk interface transporting VLANs 8 and 9. The sysctl configuration statement directs packets for VLAN 8 to physical interface xl0, and packets for VLAN 9 to xl1. The logical relationship is established by the two cluster identifiers that tie VLAN 8 to xl0 (cluster ID 34) and VLAN 9 to xl1 (cluster ID 35).
Lab 5-1: FreeBSD Bridge Cluster Lab
This lab introduces the FreeBSD approach to bridging. Bridging is available on OpenBSD and Linux as well; however, FreeBSD offers a unique feature named bridge-clusters. A cluster is an independent set of connected Ethernet or VLAN interfaces uniquely identified by a cluster ID. Consult the manual pages bridge(4), ng_bridge(4), vlan(4), and netgraph(4) for further details.
Example 5-16 shows the configuration sequence for bridging between two gateway interfaces (xl0 and ed0) via (default) cluster ID 1. Before we start, we have to turn bridging on via sysctl, however. The result of this configuration is presented in Example 5-17, the general concept in Figure 5-2.
Lab 5-2: Linux Bridging and the Spanning Tree
The Linux bridge administration is done via the brctl tool. Consult the man page for details and look at the Linux Bridge-STP-HOWTO (http/www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html) and http://bridge.sourceforge.net.
The following setup (Example 5-19) bridges between the two interfaces eth0 and eth1 of the callisto Linux gateway (setup and removal). Example 5-20 provides interface status information of the bridge setup, and Example 5-21 shows a more detailed experience with the brctl tool. Finally, Example 5-22 presents a short sniffer session to capture STP packets.
Example 5-19. Linux Bridge Configuration
[root@callisto:~#] brctl addbr mybridge
[root@callisto:~#] brctl addif mybridge eth0
[root@callisto:~#] brctl addif mybridge eth1
[root@callisto:~#] ifconfig mybridge up
[root@callisto:~#] ifconfig mybridge down
[root@callisto:~#] brctl delbr mybridge
Example 5-20. Linux Bridge Configuration Interface Status
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:360 (360.0 b)
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4325 (4.2 Kb) TX bytes:3625 (3.5 Kb)
Interrupt:9 Base address:0xd400
mybridge Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Example 5-21. Linux brctl Tool
[root@callisto:~#] brctl
commands:
addbr add bridge
addif add interface to bridge
delbr delete bridge
delif delete interface from bridge
show show a list of bridges
showmacs show a list of mac addrs
showstp show bridge stp info
setageing
In our lab setups, we typically require several kinds of RJ-45 connections: rollover (Console), Ethernet crossover (X-over), and standard Ethernet straight-through cabling. For a reminder of the pin assignments, check Cisco.com (http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/hw_inst/cabling/marcabl.htm).
Serial X-over cables are an entirely different matter due to the variety of interfaces. Again, refer to Cisco.com for details. Optical PCI ATM adapters can be connected back to back via a simple optical X-over cable pair without the need for an ATM switch. However, you will not be able to test network-to-network interface (NNI), switched virtual circuit (SVC), or interim local management interface (ILMI) features without an intermediary
Example 5-18. FreeBSD Bridge-Cluster Setup
[root@castor:~#] sysctl net.link.ether.bridge_cfg=vlan8:34,xl0:34,vlan9:35,xl1:35
[root@castor:~#] ifconfig vlan8 create
[root@castor:~#] ifconfig vlan9 create
[root@castor:~#] ifconfig vlan8 vlan 8 vlandev ed0
[root@castor:~#] ifconfig vlan9 vlan 9 vlandev ed0
You can certainly use advanced features such as filtering and traffic shaping on bridged interfaces, VLANs, and trunks as well
Example 5-16. Plain Bridging Between Two Interfaces
[root@castor:~#] sysctl net.link.ether.bridge=1
net.link.ether.bridge: 1 -> 1
[root@castor:~#] sysctl net.link.ether.bridge_cfg=xl0:1,ed0:1
net.link.ether.bridge_cfg: xl0:1 -> xl0:1,ed0:1
Example 5-17. FreeBSD Bridging-Related Status Information
[root@castor:~#] sysctl -a | grep bridge
net.link.ether.bridge_cfg: xl0:1,ed0:1
net.link.ether.bridge: 1
net.link.ether.bridge_ipfw: 0
net.link.ether.bridge_ipfw_drop: 0
net.link.ether.bridge_ipfw_collisions: 0
The configuration in Figure 5-3 and Example 5-18 is derived from the bridge(4) man page and presents a bridge-cluster setup example involving VLANs and parent interfaces. Interface ed0 acts as a VLAN trunk interface transporting VLANs 8 and 9. The sysctl configuration statement directs packets for VLAN 8 to physical interface xl0, and packets for VLAN 9 to xl1. The logical relationship is established by the two cluster identifiers that tie VLAN 8 to xl0 (cluster ID 34) and VLAN 9 to xl1 (cluster ID 35).
Lab 5-1: FreeBSD Bridge Cluster Lab
This lab introduces the FreeBSD approach to bridging. Bridging is available on OpenBSD and Linux as well; however, FreeBSD offers a unique feature named bridge-clusters. A cluster is an independent set of connected Ethernet or VLAN interfaces uniquely identified by a cluster ID. Consult the manual pages bridge(4), ng_bridge(4), vlan(4), and netgraph(4) for further details.
Example 5-16 shows the configuration sequence for bridging between two gateway interfaces (xl0 and ed0) via (default) cluster ID 1. Before we start, we have to turn bridging on via sysctl, however. The result of this configuration is presented in Example 5-17, the general concept in Figure 5-2.
Lab 5-2: Linux Bridging and the Spanning Tree
The Linux bridge administration is done via the brctl tool. Consult the man page for details and look at the Linux Bridge-STP-HOWTO (http/www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html) and http://bridge.sourceforge.net.
The following setup (Example 5-19) bridges between the two interfaces eth0 and eth1 of the callisto Linux gateway (setup and removal). Example 5-20 provides interface status information of the bridge setup, and Example 5-21 shows a more detailed experience with the brctl tool. Finally, Example 5-22 presents a short sniffer session to capture STP packets.
Example 5-19. Linux Bridge Configuration
[root@callisto:~#] brctl addbr mybridge
[root@callisto:~#] brctl addif mybridge eth0
[root@callisto:~#] brctl addif mybridge eth1
[root@callisto:~#] ifconfig mybridge up
[root@callisto:~#] ifconfig mybridge down
[root@callisto:~#] brctl delbr mybridge
Example 5-20. Linux Bridge Configuration Interface Status
[root@callisto:~#] ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
inet addr:192.168.14.1 Bcast:192.168.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:360 (360.0 b)
Interrupt:5 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 52:54:05:E3:51:87
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4325 (4.2 Kb) TX bytes:3625 (3.5 Kb)
Interrupt:9 Base address:0xd400
mybridge Link encap:Ethernet HWaddr 00:10:5A:D7:93:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Example 5-21. Linux brctl Tool
[root@callisto:~#] brctl
commands:
addbr
addif
delbr
delif
show show a list of bridges
showmacs
showstp
setageing
Chapter 6. The Analyzer Toolbox, DHCP, and CDP
One of the great advantages of UNIX gateways is the availability of literally thousands of open-source tools and user space utilities. This chapter covers some of them that have proven very useful.
NOTE
This chapter intentionally does not cover security-related tools, a subject area far too vast for this book.
The tools covered in this chapter are just a selection from a personal point of view. While on the subject of sniffers, this chapter takes a thorough look at Dynamic Host Configuration Protocol (DHCP) and the Cisco Discovery Protocol (CDP). This is done in the labs that close out the chapter.
Terminal Emulation Software
Terminal emulation packages are used to connect to various external communication program interfaces, such as tn3270 and vt100, and most commonly to directly attached serial interfaces (modems, console ports). The most popular tools are as follows:
minicom (UNIX)
C-Kermit (UNIX, VMS), Kermit 95 (Windows)
TeraTerm Pro (Windows)
Hyperterm (Windows)
Figure 6-1 shows the main functions of the minicom utility.
Most of the console ports use the connection settings 9600-8-N-1 (9600 bps, 8 data bits, no parity, 1 stop bit). Some require rollover, crossover, or straight-through cabling. They can run at speeds up to 115,200 bps. Older equipment might not have the Universal Asynchronous Receivers/Transmitters (UARTs) to support that speed and hit the ceiling at 38,400 bps. Figure 6-2 shows the communications settings for TeraTerm as an example.
Secure Shell Tools
The Secure Shell protocol (SSH) is a secure replacement for telnet and rlogin. Consult http://www.openssh.org and http://www.ietf.org for everything related to SSH. The SSH protocol should not require an introduction. Three graphical tools have proven useful:
Putty (Windows and UNIX graphical user interfaces [GUIs] for SSH, see Figures 6-3 and 6-4)
These tools come with an ancillary agent that can assist you with administering automated connection-establishment based on key pairs (agent forwarding). With such, you are required to enter key passphrases only once when the agent initializes. The agent needs to remain active, though.
One of the great advantages of UNIX gateways is the availability of literally thousands of open-source tools and user space utilities. This chapter covers some of them that have proven very useful.
NOTE
This chapter intentionally does not cover security-related tools, a subject area far too vast for this book.
The tools covered in this chapter are just a selection from a personal point of view. While on the subject of sniffers, this chapter takes a thorough look at Dynamic Host Configuration Protocol (DHCP) and the Cisco Discovery Protocol (CDP). This is done in the labs that close out the chapter.
Terminal Emulation Software
Terminal emulation packages are used to connect to various external communication program interfaces, such as tn3270 and vt100, and most commonly to directly attached serial interfaces (modems, console ports). The most popular tools are as follows:
minicom (UNIX)
C-Kermit (UNIX, VMS), Kermit 95 (Windows)
TeraTerm Pro (Windows)
Hyperterm (Windows)
Figure 6-1 shows the main functions of the minicom utility.
Most of the console ports use the connection settings 9600-8-N-1 (9600 bps, 8 data bits, no parity, 1 stop bit). Some require rollover, crossover, or straight-through cabling. They can run at speeds up to 115,200 bps. Older equipment might not have the Universal Asynchronous Receivers/Transmitters (UARTs) to support that speed and hit the ceiling at 38,400 bps. Figure 6-2 shows the communications settings for TeraTerm as an example.
Secure Shell Tools
The Secure Shell protocol (SSH) is a secure replacement for telnet and rlogin. Consult http://www.openssh.org and http://www.ietf.org for everything related to SSH. The SSH protocol should not require an introduction. Three graphical tools have proven useful:
Putty (Windows and UNIX graphical user interfaces [GUIs] for SSH, see Figures 6-3 and 6-4)
These tools come with an ancillary agent that can assist you with administering automated connection-establishment based on key pairs (agent forwarding). With such, you are required to enter key passphrases only once when the agent initializes. The agent needs to remain active, though.
Protocol Analyzer
Protocol analyzers (also called sniffers) are versatile tools for a variety of tasks:
Debugging network problems
Verifying proper operation of cryptographic protocols
Diagnosing flawed protocol implementations
Identifying unwanted traffic
Replaying of stored traffic for testing purposes
Reverse-engineering protocol implementations
Performing security checks
Identifying network background noise (broadcast protocols, NetBIOS, Appletalk)
If you ever find yourself confronted with learning or reverse-engineering an unknown or unfamiliar protocol, equip yourself with a sniffer, a hex editor, test gear, and any RFCs or standard documents you can find and start investigating the behavior of the protocol, the types of headers involved, the state transitions, and so on. This is really the best way of understanding the internals of protocols, and probably the most efficient as well. If available, you can also compare your observations with open source implementations and derive additional clues from the sources. When debugging a real-life problem, it is always a good approach to start from the bottom and work your way to the top of the stack in a structured manner.
Most UNIX systems come with tcpdump installed, which is a standard text-based protocol analyzer. Several graphical front ends and ancillary tools exist for tcpdump. By the way, Solaris provides the snoop utility for sniffing. Most people's tool of choice is the ethereal graphical protocol analyzer, which also provides a text-only version called tethereal (see Figure 6-7). The ngrep tool enables you to apply the functionality of the well-known UNIX grep utility to the network layer. It is a practical tool as well
Statistical Tools
ntop, designed by Dr. Luca Deri, is an advanced graphical tool to dissect network traffic, derive statistics, and produce traffic distributions (see Figure 6-8). It is also capable of operating as a NetFlow collector/probe and runs on an embedded web server. You can download it from http://www.ntop.org
Port Scanners
Modern port scanners can probe in stealthy, patient, and subtle ways, in combination with operating system fingerprinting, which refers to the art of guessing the operating system from stack peculiarities and additional hints derived from intelligent probing. Two of the most popular tools are the nmap and strobe programs. Example 6-1 provides two examples of these tools in action. The /etc/services file on UNIX systems provides a mapping between TCD/UDP port numbers and their textual names. This list is maintained by Internet Assigned Numbers Authority (IANA, http://www.iana.org/assignments/port-numbers) and consists of three port groups:
Well-known ports (0–1023)
Registered ports (1024–49151)
Dynamic ports (49152–65535)
Example 6-1. nmap and strobe Port-Scan Examples
[root@castor:~#] nmap -p 1-4000 localhost
Starting nmap V. 2.54BETA34 ( www.insecure.org/nmap/ )
Interesting ports on localhost.nerdzone.org (127.0.0.1):
(The 3994 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
1899/tcp open unknown
2070/tcp open unknown
2410/tcp open unknown
2560/tcp open unknown
3046/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 23 seconds
[root@ganymed:~#] strobe -b 1 -e 4000 localhost
strobe 1.05 (c) 1995-1999 Julian Assange.
localhost 22 ssh Secure Shell - RSA encrypted rsh
-> SSH-2.0-OpenSSH_3.4\n
localhost 80 http www www-http World Wide Web HTTP
www World Wide Web HTTP [TXL]
socklist and netstat
socklist(8) is a useful tool for displaying open TCP/UDP sockets in an overview fashion (see Example 6-2).
Example 6-2. socklist Output
[root@callisto:~#] socklist
type port inode uid pid fd name
tcp 32768 986 29 681 6 rpc.statd
tcp 32769 1058 0 754 4 rpc.mountd
tcp 929 1042 0 749 4 rpc.rquotad
tcp 32770 1632 0 1157 6 xinetd
tcp 963 1631 0 1157 5 xinetd
tcp 139 1183 0 844 9 smbd
tcp 111 913 0 653 4 portmap
tcp 6000 1986 0 1449 1 X
tcp 10000 1924 0 1385 4 miniserv.pl
tcp 21 1636 0 1157 9 xinetd
tcp 22 1520 0 1066 3 sshd
tcp 505 2968 0 1343 4 rcd
tcp 33424 28161 500 3704 47 mozilla-bin
tcp 22 27806 0 3776 4 sshd
udp 32768 983 29 681 4 rpc.statd
udp 2049 1082 0 0 0
udp 32769 1055 0 754 3 rpc.mountd
udp 32770 1088 0 0 0
udp 137 3257 0 849 15 nmbd
udp 137 1194 0 849 10 nmbd
udp 137 1192 0 849 8 nmbd
udp 137 1189 0 849 6 nmbd
udp 138 3258 0 849 16 nmbd
udp 138 1195 0 849 11 nmbd
udp 138 1193 0 849 9 nmbd
udp 138 1190 0 849 7 nmbd
udp 10000 1925 0 1385 5 miniserv.pl
udp 926 1037 0 749 3 rpc.rquotad
udp 69 1635 0 1157 8 xinetd
udp 111 910 0 653 3 portmap
udp 500 1515 0 939 10 pluto
udp 123 1704 0 1175 7 ntpd
udp 123 1703 0 1175 6 ntpd
udp 123 1702 0 1175 5 ntpd
udp 123 1701 0 1175 4 ntpd
netstat(8) provides additional details about the UNIX network subsystem, such as network connections, routing tables, interface statistics, and multicast memberships (see Example 6-3).
Example 6-3. netstat Output
[root@callisto:~#] netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 0 0 0 0 439 0 0 0 BMRU
eth1 1500 0 10098 0 0 0 8208 0 0 0 BMRU
eth1: 1500 0 - no statistics available - BMRU
ipsec 16260 0 0 0 0 0 7096 0 129 0 ORU
lo 16436 0 64 0 0 0 64 0 0 0 LRU
[root@callisto:~#] netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:32768 *:* LISTEN
tcp 0 0 *:32769 *:* LISTEN
tcp 0 0 *:929 *:* LISTEN
tcp 0 0 localhost:32770 *:* LISTEN
tcp 0 0 *:pkcipe *:* LISTEN
tcp 0 0 *:netbios-ssn *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
tcp 0 0 *:x11 *:* LISTEN
tcp 0 0 callisto:10000 *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:505 *:* LISTEN
udp 0 0 *:32768 *:*
udp 0 0 *:nfs *:*
udp 0 0 *:32769 *:*
udp 0 0 *:32770 *:*
udp 0 0 192.168.45.2:netbios-ns *:*
udp 0 0 192.168.14.1:netbios-ns *:*
udp 0 0 callisto:netbios-ns *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 192.168.45.:netbios-dgm *:*
udp 0 0 192.168.14.:netbios-dgm *:*
udp 0 0 callisto:netbios-dgm *:*
udp 0 0 *:netbios-dgm *:*
udp 0 0 *:10000 *:*
udp 0 0 *:926 *:*
udp 0 0 *:tftp *:*
udp 0 0 *:sunrpc *:*
udp 0 0 callisto:isakmp *:*
udp 0 0 callisto:ntp *:*
udp 0 0 192.168.14.1:ntp *:*
udp 0 0 localhost:ntp *:*
udp 0 0 *:ntp *:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 2969 /var/run/rcd/rcd
unix 2 [ ACC ] STREAM LISTENING 2564 /tmp/ksocket-gschmied/kdeinit-:0
unix 2 [ ACC ] STREAM LISTENING 2569 /tmp/.ICE-unix/dcop1571-1062316048
unix 2 [ ACC ] STREAM LISTENING 2704 /tmp/.ICE-unix/1598
unix 2 [ ACC ] STREAM LISTENING 2592 /tmp/ksocket-gschmied
/klauncherKIy0fa.slave-socket
unix 2 [ ACC ] STREAM LISTENING 1404 /var/run/pluto.ctl
unix 2 [ ACC ] STREAM LISTENING 2675 /tmp/mcop-gschmied
/callisto-0631-3f51a81c
unix 2 [ ACC ] STREAM LISTENING 1987 /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 1712 /dev/gpmctl
unix 2 [ ACC ] STREAM LISTENING 1766 /tmp/.font-unix/fs7100
[root@callisto:~#] netstat -s
Ip:
11160 total packets received
0 forwarded
0 incoming packets discarded
11143 incoming packets delivered
10339 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP messages failed.
ICMP input histogram:
4 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 4
Tcp:
703 active connections openings
2 passive connection openings
0 failed connection attempts
2 connection resets received
2 connections established
10272 segments received
9535 segments sent out
37 segments retransmitted
0 bad segments received.
2 resets sent
Udp:
875 packets received
4 packets to unknown port received.
0 packet receive errors
800 packets sent
TcpExt:
ArpFilter: 0
21 TCP sockets finished time wait in fast timer
597 delayed acks sent
2 delayed acks further delayed because of locked socket
Quick ack mode was activated 30 times
3 packets directly queued to recvmsg prequeue.
1 packets directly received from prequeue
4825 packets header predicted
TCPPureAcks: 1549
TCPHPAcks: 2674
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 9
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 22
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 0
TCPDSACKOldSent: 10
TCPDSACKOfoSent: 0
TCPDSACKRecv: 1
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 0
TCPAbortOnClose: 1
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 0
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
The Linux netstat -M command sequence additionally displays masqueraded connections. netstat options can be combined with the -ev switch for extended and even more verbose output (type netstat -ev). We will extensively rely on netstat -rn (the routing table) and netstat -i. netstat -i presents interface counter statistics such as transmitted and received frames, frame errors, and dropped frames. The netstat -g multicast command sequence is discussed in detail in Chapter 14, "Multicast Architectures."
Note that netstat displays various types of sockets:
TCP
UDP
Raw
UNIX domain sockets
Protocol analyzers (also called sniffers) are versatile tools for a variety of tasks:
Debugging network problems
Verifying proper operation of cryptographic protocols
Diagnosing flawed protocol implementations
Identifying unwanted traffic
Replaying of stored traffic for testing purposes
Reverse-engineering protocol implementations
Performing security checks
Identifying network background noise (broadcast protocols, NetBIOS, Appletalk)
If you ever find yourself confronted with learning or reverse-engineering an unknown or unfamiliar protocol, equip yourself with a sniffer, a hex editor, test gear, and any RFCs or standard documents you can find and start investigating the behavior of the protocol, the types of headers involved, the state transitions, and so on. This is really the best way of understanding the internals of protocols, and probably the most efficient as well. If available, you can also compare your observations with open source implementations and derive additional clues from the sources. When debugging a real-life problem, it is always a good approach to start from the bottom and work your way to the top of the stack in a structured manner.
Most UNIX systems come with tcpdump installed, which is a standard text-based protocol analyzer. Several graphical front ends and ancillary tools exist for tcpdump. By the way, Solaris provides the snoop utility for sniffing. Most people's tool of choice is the ethereal graphical protocol analyzer, which also provides a text-only version called tethereal (see Figure 6-7). The ngrep tool enables you to apply the functionality of the well-known UNIX grep utility to the network layer. It is a practical tool as well
Statistical Tools
ntop, designed by Dr. Luca Deri, is an advanced graphical tool to dissect network traffic, derive statistics, and produce traffic distributions (see Figure 6-8). It is also capable of operating as a NetFlow collector/probe and runs on an embedded web server. You can download it from http://www.ntop.org
Port Scanners
Modern port scanners can probe in stealthy, patient, and subtle ways, in combination with operating system fingerprinting, which refers to the art of guessing the operating system from stack peculiarities and additional hints derived from intelligent probing. Two of the most popular tools are the nmap and strobe programs. Example 6-1 provides two examples of these tools in action. The /etc/services file on UNIX systems provides a mapping between TCD/UDP port numbers and their textual names. This list is maintained by Internet Assigned Numbers Authority (IANA, http://www.iana.org/assignments/port-numbers) and consists of three port groups:
Well-known ports (0–1023)
Registered ports (1024–49151)
Dynamic ports (49152–65535)
Example 6-1. nmap and strobe Port-Scan Examples
[root@castor:~#] nmap -p 1-4000 localhost
Starting nmap V. 2.54BETA34 ( www.insecure.org/nmap/ )
Interesting ports on localhost.nerdzone.org (127.0.0.1):
(The 3994 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
1899/tcp open unknown
2070/tcp open unknown
2410/tcp open unknown
2560/tcp open unknown
3046/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 23 seconds
[root@ganymed:~#] strobe -b 1 -e 4000 localhost
strobe 1.05 (c) 1995-1999 Julian Assange
localhost 22 ssh Secure Shell - RSA encrypted rsh
-> SSH-2.0-OpenSSH_3.4\n
localhost 80 http www www-http World Wide Web HTTP
www World Wide Web HTTP [TXL]
socklist and netstat
socklist(8) is a useful tool for displaying open TCP/UDP sockets in an overview fashion (see Example 6-2).
Example 6-2. socklist Output
[root@callisto:~#] socklist
type port inode uid pid fd name
tcp 32768 986 29 681 6 rpc.statd
tcp 32769 1058 0 754 4 rpc.mountd
tcp 929 1042 0 749 4 rpc.rquotad
tcp 32770 1632 0 1157 6 xinetd
tcp 963 1631 0 1157 5 xinetd
tcp 139 1183 0 844 9 smbd
tcp 111 913 0 653 4 portmap
tcp 6000 1986 0 1449 1 X
tcp 10000 1924 0 1385 4 miniserv.pl
tcp 21 1636 0 1157 9 xinetd
tcp 22 1520 0 1066 3 sshd
tcp 505 2968 0 1343 4 rcd
tcp 33424 28161 500 3704 47 mozilla-bin
tcp 22 27806 0 3776 4 sshd
udp 32768 983 29 681 4 rpc.statd
udp 2049 1082 0 0 0
udp 32769 1055 0 754 3 rpc.mountd
udp 32770 1088 0 0 0
udp 137 3257 0 849 15 nmbd
udp 137 1194 0 849 10 nmbd
udp 137 1192 0 849 8 nmbd
udp 137 1189 0 849 6 nmbd
udp 138 3258 0 849 16 nmbd
udp 138 1195 0 849 11 nmbd
udp 138 1193 0 849 9 nmbd
udp 138 1190 0 849 7 nmbd
udp 10000 1925 0 1385 5 miniserv.pl
udp 926 1037 0 749 3 rpc.rquotad
udp 69 1635 0 1157 8 xinetd
udp 111 910 0 653 3 portmap
udp 500 1515 0 939 10 pluto
udp 123 1704 0 1175 7 ntpd
udp 123 1703 0 1175 6 ntpd
udp 123 1702 0 1175 5 ntpd
udp 123 1701 0 1175 4 ntpd
netstat(8) provides additional details about the UNIX network subsystem, such as network connections, routing tables, interface statistics, and multicast memberships (see Example 6-3).
Example 6-3. netstat Output
[root@callisto:~#] netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 0 0 0 0 439 0 0 0 BMRU
eth1 1500 0 10098 0 0 0 8208 0 0 0 BMRU
eth1: 1500 0 - no statistics available - BMRU
ipsec 16260 0 0 0 0 0 7096 0 129 0 ORU
lo 16436 0 64 0 0 0 64 0 0 0 LRU
[root@callisto:~#] netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:32768 *:* LISTEN
tcp 0 0 *:32769 *:* LISTEN
tcp 0 0 *:929 *:* LISTEN
tcp 0 0 localhost:32770 *:* LISTEN
tcp 0 0 *:pkcipe *:* LISTEN
tcp 0 0 *:netbios-ssn *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
tcp 0 0 *:x11 *:* LISTEN
tcp 0 0 callisto:10000 *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:505 *:* LISTEN
udp 0 0 *:32768 *:*
udp 0 0 *:nfs *:*
udp 0 0 *:32769 *:*
udp 0 0 *:32770 *:*
udp 0 0 192.168.45.2:netbios-ns *:*
udp 0 0 192.168.14.1:netbios-ns *:*
udp 0 0 callisto:netbios-ns *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 192.168.45.:netbios-dgm *:*
udp 0 0 192.168.14.:netbios-dgm *:*
udp 0 0 callisto:netbios-dgm *:*
udp 0 0 *:netbios-dgm *:*
udp 0 0 *:10000 *:*
udp 0 0 *:926 *:*
udp 0 0 *:tftp *:*
udp 0 0 *:sunrpc *:*
udp 0 0 callisto:isakmp *:*
udp 0 0 callisto:ntp *:*
udp 0 0 192.168.14.1:ntp *:*
udp 0 0 localhost:ntp *:*
udp 0 0 *:ntp *:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 2969 /var/run/rcd/rcd
unix 2 [ ACC ] STREAM LISTENING 2564 /tmp/ksocket-gschmied/kdeinit-:0
unix 2 [ ACC ] STREAM LISTENING 2569 /tmp/.ICE-unix/dcop1571-1062316048
unix 2 [ ACC ] STREAM LISTENING 2704 /tmp/.ICE-unix/1598
unix 2 [ ACC ] STREAM LISTENING 2592 /tmp/ksocket-gschmied
/klauncherKIy0fa.slave-socket
unix 2 [ ACC ] STREAM LISTENING 1404 /var/run/pluto.ctl
unix 2 [ ACC ] STREAM LISTENING 2675 /tmp/mcop-gschmied
/callisto-0631-3f51a81c
unix 2 [ ACC ] STREAM LISTENING 1987 /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 1712 /dev/gpmctl
unix 2 [ ACC ] STREAM LISTENING 1766 /tmp/.font-unix/fs7100
[root@callisto:~#] netstat -s
Ip:
11160 total packets received
0 forwarded
0 incoming packets discarded
11143 incoming packets delivered
10339 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP messages failed.
ICMP input histogram:
4 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 4
Tcp:
703 active connections openings
2 passive connection openings
0 failed connection attempts
2 connection resets received
2 connections established
10272 segments received
9535 segments sent out
37 segments retransmitted
0 bad segments received.
2 resets sent
Udp:
875 packets received
4 packets to unknown port received.
0 packet receive errors
800 packets sent
TcpExt:
ArpFilter: 0
21 TCP sockets finished time wait in fast timer
597 delayed acks sent
2 delayed acks further delayed because of locked socket
Quick ack mode was activated 30 times
3 packets directly queued to recvmsg prequeue.
1 packets directly received from prequeue
4825 packets header predicted
TCPPureAcks: 1549
TCPHPAcks: 2674
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 9
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 22
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 0
TCPDSACKOldSent: 10
TCPDSACKOfoSent: 0
TCPDSACKRecv: 1
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 0
TCPAbortOnClose: 1
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 0
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
The Linux netstat -M command sequence additionally displays masqueraded connections. netstat options can be combined with the -ev switch for extended and even more verbose output (type netstat -ev). We will extensively rely on netstat -rn (the routing table) and netstat -i. netstat -i presents interface counter statistics such as transmitted and received frames, frame errors, and dropped frames. The netstat -g multicast command sequence is discussed in detail in Chapter 14, "Multicast Architectures."
Note that netstat displays various types of sockets:
TCP
UDP
Raw
UNIX domain sockets
Ping and Traceroute Combinations
Among the most useful tools for a network engineer's toolbox are those that combine ping, DNS lookup, and traceroute capabilities. This section introduces three of them (mtr, PingPlotter, and VisualRoute).
mtr is a command-line tool for real-time path surveillance and statistics. PingPlotter and VisualRoute are commercial graphical tools available as trial downloads that add a great deal of statistics and correlation analysis to the ping and traceroute tools and allow probing over an extended period of time. Figures 6-9 through 6-11 provide example screenshots of these tools. VisualRoute is a product of Visualware Inc. (http://www.visualware.com), and PingPlotter is a product of Nessoft, LLC (http://www.nessoft.com).
DNS Auditing Tools
DNS consists of two parts: a resolver (the client part) and Internet name server hierarchies. Consult the manual pages for operation details as well as the man page for resolver(3) or resolv.conf(5). The most widespread package is the Berkeley Internet Name Domain (BIND) toolset; however, there are alternatives and new approaches for securing name server communications and signing/hashing information exchange (DNSsec). Discussion of these tools goes beyond the scope of this book. We will use them in a limited way when discussing DNS round-robin (DNS RR) as a load-balancing approach. The standard query tools are nslookup, dig, and host (see Example 6-4).
Example 6-4. DNS Toolbox—dig, nslookup, and host
[root@callisto:~#] dig www.cisco.com
; <<>> DiG 9.2.2 <<>> www.cisco.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cisco.com. IN A ;; ANSWER SECTION: www.cisco.com. 36356 IN A 198.133.219.25 ;; AUTHORITY SECTION: cisco.com. 38430 IN NS ns1.cisco.com. cisco.com. 38430 IN NS ns2.cisco.com. ;; Query time: 9 msec ;; SERVER: 195.34.133.10#53(195.34.133.10) ;; WHEN: Sat Jan 31 10:31:42 2004 ;; MSG SIZE rcvd: 83 [root@callisto:~#] nslookup www.cisco.com Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 195.34.133.10 Address: 195.34.133.10#53 Non-authoritative answer: Name: www.cisco.com Address: 198.133.219.25 [root@callisto:~#] host www.cisco.com www.cisco.com has address 198.133.219.25 In addition, it is worth mentioning another useful tool, dnstracer; Example 6-5 shows it in use. Example 6-5. dnstracer Example Output [root@callisto:~#] dnstracer -s . www.cisco.com -o Tracing to www.cisco.com via A.ROOT-SERVERS.NET, timeout 15 seconds A.ROOT-SERVERS.NET [.] (198.41.0.4) |\___ M.GTLD-SERVERS.NET [com] (192.55.83.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) Got authoritative answer | \___ NS1.cisco.com [cisco.com] (128.107.241.185) Got authoritative answer |\___ E.GTLD-SERVERS.NET [com] (192.12.94.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ K.GTLD-SERVERS.NET [com] (192.52.178.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ J.GTLD-SERVERS.NET [com] (192.48.79.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ F.GTLD-SERVERS.NET [com] (192.35.51.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ L.GTLD-SERVERS.NET [com] (192.41.162.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ D.GTLD-SERVERS.NET [com] (192.31.80.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ B.GTLD-SERVERS.NET [com] (192.33.14.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ I.GTLD-SERVERS.NET [com] (192.43.172.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ C.GTLD-SERVERS.NET [com] (192.26.92.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ H.GTLD-SERVERS.NET [com] (192.54.112.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ G.GTLD-SERVERS.NET [com] (192.42.93.30) | |\___ ns2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ ns1.cisco.com [cisco.com] (128.107.241.185) (cached) \___ A.GTLD-SERVERS.NET [com] (192.5.6.30) |\___ ns2.cisco.com [cisco.com] (192.135.250.69) (cached) \___ ns1.cisco.com [cisco.com] (128.107.241.185) (cached) NS1.cisco.com (128.107.241.185) www.cisco.com -> 198.133.219.25
NS2.cisco.com (192.135.250.69) www.cisco.com -> 198.133.219.25
Traffic and Packet Generators
This section discusses the packet-generation capabilities of the BSD ipfilter firewall package, the Linux kernel module packet generator, and some additional tools for heavy load testing and simulated denial-of-service (DoS) patterns. This arsenal is useful to test traffic shapers, forwarding, filtering performance, network quality of service (QoS), stateful inspection, and Network Address Translation (NAT), just to name a few. Traffic generators generally are concerned with a huge amount of output, whereas packet generators typically are used as a "scalpel" to test firewalls and protocol implementations/compliance.
CAUTION
Exercise extreme care when using these facilities in real-life networks; they are extremely powerful. Check the traffic with a sniffer; you will find what is going on pretty impressive.
What You Need in a Small Toolbox
The following tools have proven useful for packet and traffic creation as well as network testing. They are quite similar in nature, and it is really up to you to decide on a favorite:
Aicmpsend
Sendip
IP Sorcery (ipmagic/magic tools)
Excalibur
Hping2
Traffic (client/server)
Scapy
Example 6-6 presents aicmpsend, sendip, and ipmagic in action. You can deploy them to test security installations and protocol behavior. See the "Recommended Reading" section at the end of this chapter for download locations of these tools.
Example 6-6. Selection of Packet-Generator Tools
[root@callisto:~#] aicmpsend -d 192.168.1.1 –E
ICMP packet: 1 TTL=64
Sending ICMP error from 127.0.0.1 to 192.168.1.1.
Data:
ICMP error: Echo
[root@callisto:~#] sendip -p ipv4 192.168.1.254
[root@callisto:~#] ipmagic -h
Usage: ipmagic [options]
IP: [-is|-id|-ih|-iv|-il|-it|-io|-id|-ip]
-is: source host or address def. 127.0.0.1
-id: source destination or address def. 127.0.0.1
-ih: IP header length def. 5
-iv: IP version def. 4
-il: Time-to-Live def. 64
-it: Type-of-Service def. 0
-io: IP frag offset [(D)on't Fragment | (M)ore Fragments | (F)ragment | (N)one]
-i: IP packet ID for fragmentation def. 0
-ip: IP protocol [TCP | UDP | ICMP | IP] def. TCP
-iO: IP options
TCP: [-ts | -td | -to | -tq | -ta | -tf | -tw | -tu]
-ts: TCP source port, def. rand()
-td: TCP destination port def. 80
-to: TCP data offset of header def. 5
-tq: TCP sequence number def. rand()
-ta: TCP ack sequence number def. 0
-tf: TCP flags [(S)yn | (A)ck | (F)in | (P)ush | (R)st | (U)rg | (N)one] def. S
-tw: TCP Window Size def. rand()
-tu: TCP urg pointer def. 0
UDP: [-us | -ud | -ul]
-us: UDP source port def. rand()
-ud: UDP destination port def. 161
-ul: UDP length
RIP: [-uR |-uRc |-uRv]
-uR: Send default RIP packet to port 520
-uRc: RIP command [RQ | RS | TN | TF | SR | TQ | TS | TA | UQ | US | UA] def. RQ
For a list of RIP commands run program with -h rip
-uRv: RIP version [1 | 2] def. 2
Note: Entry Tables should be used with response packets[RS | TS | US]
-uRa(1 | 2 | etc.): RIP Entry table Address exmp. -uRa1
-uRn(1 | 2 | etc.): RIP Entry table Netmask, exmp. -uRn2
-uRh(1 | 2 | etc.): RIP Entry table Next Hop, exmp. -uRn(num)
-uRm(1 | 2 | etc.): RIP Entry table Metric
-uRr(1 | 2 | etc.): RIP Entry table Route Tag
-uRe: Add default RIP entry table to packet
ICMP: [-ct | -cs]
-ct: ICMP type def. ECHO REQUEST
-cs: ICMP sub code def. 0
-ci: ICMP sequence ID def. 0
For list of ICMP Types and Subcodes run program with -h icmp.
IGMP:[-gt | -gc | -ga | -gn]
-gt: IGMP type [D | L | M | MT | MR | P | R1 | R2 | R3] def. M
-gc: IGMP sub code for types P and D def. 0
-gm: IGMP Max. resp. Time for Queries ie. MR
-ga: IGMP group address def. 0
-gn: IGMP no router alert or no internetwork Type-Of-Service [r | i | | ]
For list of IGMP Types and Subcodes run program with -h igmp.
OSPF:[-ov | -ot | -or | -oe | -oa | -ou]
-ov: OSPF Version
-ot: OSPF Type[(H)ello | (D)b Desc. | (R)equest | (U)pdate | (A)ck]
-or: OSPF Router ID
-oe: OSPF Area ID
-oa: OSPF Auth Type[(N)one | (P)ass | (C)rypto]
-ou : OSPF Authentication Data
-D "": for datapayload
-N: send number packets
-S: (v)erbose, (s)hort, (t)urn off packet snoop
-v: print version
The BSD ipfilter Traffic Generator
The BSD ipfilter stateful firewall package comes equipped with the following tools primarily designed for firewall testing:
ipsend
ipresend
iptest
Consult the manual pages for further information. Example 6-7 and Example 6-8 present demonstrations of the BSD iptest, ipsend, and ipresend tools.
Example 6-7. BSD ipfilter Ancillary Tools in Action
[root@castor:~#] iptest
Usage: iptest [options] dest
options:
-d device Send out on this device
-g gateway IP gateway to use if non-local dest.
-m mtu fake MTU to use when sending out
-p pointtest
-s src source address for IP packet
-1 Perform test 1 (IP header)
-2 Perform test 2 (IP options)
-3 Perform test 3 (ICMP)
-4 Perform test 4 (UDP)
-5 Perform test 5 (TCP)
-6 Perform test 6 (overlapping fragments)
-7 Perform test 7 (random packets)
[root@castor:~#] iptest -d ed0 -g 192.168.7.254 -1 192.168.14.1
Device: ed0
Source: 192.168.7.7
Dest: 192.168.14.1
Gateway: 192.168.7.254
mtu: 1500
1.1. sending packets with ip_hl < ip_len 7 1.2. sending packets with ip_hl > ip_len
12
1.3. ip_v < 4 3 1.4. ip_v > 4
15
1.5.0 ip_len < packet size (size++, long packets) 63 1.5.1 ip_len < packet size (ip_len-, short packets) 10 1.6.0 ip_len > packet size (increase ip_len)
63
1.6.1 ip_len > packet size (size--, short packets)
10
1.7.0 Zero length fragments (ip_off = 0x2000)
1.7.1 Zero length fragments (ip_off = 0x3000)
1.7.2 Zero length fragments (ip_off = 0xa000)
1.7.3 Zero length fragments (ip_off = 0x0100)
1.8.1 63k packet + 1k fragment at offset 0x1ffe
65792
1.8.2 63k packet + 1k fragment at offset 0x1ffe
skip 12800
skip 37376
skip 61952
65792
1.8.3 33k packet
33536
1.9. ip_off & 0x8000 == 0x8000
1.10.0 ip_ttl = 255
1.10.1 ip_ttl = 128
1.10.2 ip_ttl = 0
Example 6-8. Example Use of the ipsend Utility
[root@castor:~#] ipsend
Usage: ipsend [options] dest [flags]
options:
-d debug mode
-i device Send out on this device
-f fragflags can set IP_MF or IP_DF
-g gateway IP gateway to use if non-local dest.
-I code,type[,gw[,dst[,src]]] Set ICMP protocol
-m mtu fake MTU to use when sending out
-P protocol Set protocol by name
-s src source address for IP packet
-T Set TCP protocol
-t port destination port
-U Set UDP protocol
-v verbose mode
-w Set the TCP window size
Usage: ipsend [-dv] -L
options:
-d debug mode
-L filename Use IP language for sending packets
-v verbose mode
[root@castor:~#] ipsend -i ed0 -P tcp -g 192.168.7.254 192.168.14.1
Device: ed0
Source: 192.168.7.7
Dest: 192.168.14.1
Gateway: 192.168.7.254
mtu: 1500
[root@castor:~#] ipresend
Usage: ipresend [options] <-r filename |-R filename>
-r filename snoop data file to resend
-R filename libpcap data file to resend
options:
-d device Send out on this device
-g gateway IP gateway to use if non-local dest.
-m mtu fake MTU to use when sending out
The Linux Kernel Packet Generator
The Linux packet generator requires compiled-in support as a kernel module (pktgen.o); it is used via a script derived from its documentation (pktgen.txt in the Linux 2.4.x kernel documentation folder). The source code of this script is also provided in Example 6-9.
Example 6-9. Script That Interacts with the Linux Kernel Packet-Generator Module
#! /bin/sh
modprobe pktgen
function pgset() {
local result
echo $1 > /proc/net/pg
result=`cat /proc/net/pg | fgrep "Result: OK:"`
if [ "$result" = "" ]; then
cat /proc/net/pg | fgrep Result:
fi
}
function pg() {
echo inject > /proc/net/pg
cat /proc/net/pg
}
pgset "odev eth0" # set output interface
pgset "dst 192.168.7.7" # set IP destination address
pgset "count 40000" # set numbers of packets to send
#pgset "multiskb 1" use multiple SKBs for packet generation
#pgset "multiskb 0" use single SKB for all transmits
#pgset "pkt_size 9014" sets packet size to 9014
#pgset "frags 5" packet will consist of 5 fragments
#pgset "ipg 5000" sets artificial gap inserted between packets
# to 5000 nanoseconds
#pgset "dstmac 00:00:00:00:00:00" sets MAC destination address
#pgset stop aborts injection
Performance-Testing and Network-Benchmarking Tools
This family of tools provides network performance information and benchmarking by usually taking a client/server approach that allows collecting very accurate end-to-end information and statistics. These tools are powerful and complex; refer to the repository documentation for further details. Some interesting representatives of this family of tools are as follows:
Netperf (Network Performance Benchmarking)
NetPIPE (Network Protocol Independent Performance Evaluator)
ttcp/wsttcp (Test TCP [TTCP]; a benchmarking tool for measuring TCP and UDP performance)
NOTE
A thorough discussion of network performance measurement would dive too much into stack internals and go far beyond the scope of this book.
Among the most useful tools for a network engineer's toolbox are those that combine ping, DNS lookup, and traceroute capabilities. This section introduces three of them (mtr, PingPlotter, and VisualRoute).
mtr is a command-line tool for real-time path surveillance and statistics. PingPlotter and VisualRoute are commercial graphical tools available as trial downloads that add a great deal of statistics and correlation analysis to the ping and traceroute tools and allow probing over an extended period of time. Figures 6-9 through 6-11 provide example screenshots of these tools. VisualRoute is a product of Visualware Inc. (http://www.visualware.com), and PingPlotter is a product of Nessoft, LLC (http://www.nessoft.com).
DNS Auditing Tools
DNS consists of two parts: a resolver (the client part) and Internet name server hierarchies. Consult the manual pages for operation details as well as the man page for resolver(3) or resolv.conf(5). The most widespread package is the Berkeley Internet Name Domain (BIND) toolset; however, there are alternatives and new approaches for securing name server communications and signing/hashing information exchange (DNSsec). Discussion of these tools goes beyond the scope of this book. We will use them in a limited way when discussing DNS round-robin (DNS RR) as a load-balancing approach. The standard query tools are nslookup, dig, and host (see Example 6-4).
Example 6-4. DNS Toolbox—dig, nslookup, and host
[root@callisto:~#] dig www.cisco.com
; <<>> DiG 9.2.2 <<>> www.cisco.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cisco.com. IN A ;; ANSWER SECTION: www.cisco.com. 36356 IN A 198.133.219.25 ;; AUTHORITY SECTION: cisco.com. 38430 IN NS ns1.cisco.com. cisco.com. 38430 IN NS ns2.cisco.com. ;; Query time: 9 msec ;; SERVER: 195.34.133.10#53(195.34.133.10) ;; WHEN: Sat Jan 31 10:31:42 2004 ;; MSG SIZE rcvd: 83 [root@callisto:~#] nslookup www.cisco.com Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 195.34.133.10 Address: 195.34.133.10#53 Non-authoritative answer: Name: www.cisco.com Address: 198.133.219.25 [root@callisto:~#] host www.cisco.com www.cisco.com has address 198.133.219.25 In addition, it is worth mentioning another useful tool, dnstracer; Example 6-5 shows it in use. Example 6-5. dnstracer Example Output [root@callisto:~#] dnstracer -s . www.cisco.com -o Tracing to www.cisco.com via A.ROOT-SERVERS.NET, timeout 15 seconds A.ROOT-SERVERS.NET [.] (198.41.0.4) |\___ M.GTLD-SERVERS.NET [com] (192.55.83.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) Got authoritative answer | \___ NS1.cisco.com [cisco.com] (128.107.241.185) Got authoritative answer |\___ E.GTLD-SERVERS.NET [com] (192.12.94.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ K.GTLD-SERVERS.NET [com] (192.52.178.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ J.GTLD-SERVERS.NET [com] (192.48.79.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ F.GTLD-SERVERS.NET [com] (192.35.51.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ L.GTLD-SERVERS.NET [com] (192.41.162.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ D.GTLD-SERVERS.NET [com] (192.31.80.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ B.GTLD-SERVERS.NET [com] (192.33.14.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ I.GTLD-SERVERS.NET [com] (192.43.172.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ C.GTLD-SERVERS.NET [com] (192.26.92.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ H.GTLD-SERVERS.NET [com] (192.54.112.30) | |\___ NS2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ NS1.cisco.com [cisco.com] (128.107.241.185) (cached) |\___ G.GTLD-SERVERS.NET [com] (192.42.93.30) | |\___ ns2.cisco.com [cisco.com] (192.135.250.69) (cached) | \___ ns1.cisco.com [cisco.com] (128.107.241.185) (cached) \___ A.GTLD-SERVERS.NET [com] (192.5.6.30) |\___ ns2.cisco.com [cisco.com] (192.135.250.69) (cached) \___ ns1.cisco.com [cisco.com] (128.107.241.185) (cached) NS1.cisco.com (128.107.241.185) www.cisco.com -> 198.133.219.25
NS2.cisco.com (192.135.250.69) www.cisco.com -> 198.133.219.25
Traffic and Packet Generators
This section discusses the packet-generation capabilities of the BSD ipfilter firewall package, the Linux kernel module packet generator, and some additional tools for heavy load testing and simulated denial-of-service (DoS) patterns. This arsenal is useful to test traffic shapers, forwarding, filtering performance, network quality of service (QoS), stateful inspection, and Network Address Translation (NAT), just to name a few. Traffic generators generally are concerned with a huge amount of output, whereas packet generators typically are used as a "scalpel" to test firewalls and protocol implementations/compliance.
CAUTION
Exercise extreme care when using these facilities in real-life networks; they are extremely powerful. Check the traffic with a sniffer; you will find what is going on pretty impressive.
What You Need in a Small Toolbox
The following tools have proven useful for packet and traffic creation as well as network testing. They are quite similar in nature, and it is really up to you to decide on a favorite:
Aicmpsend
Sendip
IP Sorcery (ipmagic/magic tools)
Excalibur
Hping2
Traffic (client/server)
Scapy
Example 6-6 presents aicmpsend, sendip, and ipmagic in action. You can deploy them to test security installations and protocol behavior. See the "Recommended Reading" section at the end of this chapter for download locations of these tools.
Example 6-6. Selection of Packet-Generator Tools
[root@callisto:~#] aicmpsend -d 192.168.1.1 –E
ICMP packet: 1 TTL=64
Sending ICMP error from 127.0.0.1 to 192.168.1.1.
Data:
ICMP error: Echo
[root@callisto:~#] sendip -p ipv4 192.168.1.254
[root@callisto:~#] ipmagic -h
Usage: ipmagic [options]
IP: [-is|-id|-ih|-iv|-il|-it|-io|-id|-ip]
-is: source host or address def. 127.0.0.1
-id: source destination or address def. 127.0.0.1
-ih: IP header length def. 5
-iv: IP version def. 4
-il: Time-to-Live def. 64
-it: Type-of-Service def. 0
-io: IP frag offset [(D)on't Fragment | (M)ore Fragments | (F)ragment | (N)one]
-i: IP packet ID for fragmentation def. 0
-ip: IP protocol [TCP | UDP | ICMP | IP] def. TCP
-iO: IP options
TCP: [-ts | -td | -to | -tq | -ta | -tf | -tw | -tu]
-ts: TCP source port, def. rand()
-td: TCP destination port def. 80
-to: TCP data offset of header def. 5
-tq: TCP sequence number def. rand()
-ta: TCP ack sequence number def. 0
-tf: TCP flags [(S)yn | (A)ck | (F)in | (P)ush | (R)st | (U)rg | (N)one] def. S
-tw: TCP Window Size def. rand()
-tu: TCP urg pointer def. 0
UDP: [-us | -ud | -ul]
-us: UDP source port def. rand()
-ud: UDP destination port def. 161
-ul: UDP length
RIP: [-uR |-uRc |-uRv]
-uR: Send default RIP packet to port 520
-uRc: RIP command [RQ | RS | TN | TF | SR | TQ | TS | TA | UQ | US | UA] def. RQ
For a list of RIP commands run program with -h rip
-uRv: RIP version [1 | 2] def. 2
Note: Entry Tables should be used with response packets[RS | TS | US]
-uRa(1 | 2 | etc.): RIP Entry table Address exmp. -uRa1
-uRn(1 | 2 | etc.): RIP Entry table Netmask, exmp. -uRn2
-uRh(1 | 2 | etc.): RIP Entry table Next Hop, exmp. -uRn(num)
-uRm(1 | 2 | etc.): RIP Entry table Metric
-uRr(1 | 2 | etc.): RIP Entry table Route Tag
-uRe: Add default RIP entry table to packet
ICMP: [-ct | -cs]
-ct: ICMP type def. ECHO REQUEST
-cs: ICMP sub code def. 0
-ci: ICMP sequence ID def. 0
For list of ICMP Types and Subcodes run program with -h icmp.
IGMP:[-gt | -gc | -ga | -gn]
-gt: IGMP type [D | L | M | MT | MR | P | R1 | R2 | R3] def. M
-gc: IGMP sub code for types P and D def. 0
-gm: IGMP Max. resp. Time for Queries ie. MR
-ga: IGMP group address def. 0
-gn: IGMP no router alert or no internetwork Type-Of-Service [r | i | | ]
For list of IGMP Types and Subcodes run program with -h igmp.
OSPF:[-ov | -ot | -or | -oe | -oa | -ou]
-ov: OSPF Version
-ot: OSPF Type[(H)ello | (D)b Desc. | (R)equest | (U)pdate | (A)ck]
-or: OSPF Router ID
-oe: OSPF Area ID
-oa: OSPF Auth Type[(N)one | (P)ass | (C)rypto]
-ou : OSPF Authentication Data
-D "": for datapayload
-N
-S
-v: print version
The BSD ipfilter Traffic Generator
The BSD ipfilter stateful firewall package comes equipped with the following tools primarily designed for firewall testing:
ipsend
ipresend
iptest
Consult the manual pages for further information. Example 6-7 and Example 6-8 present demonstrations of the BSD iptest, ipsend, and ipresend tools.
Example 6-7. BSD ipfilter Ancillary Tools in Action
[root@castor:~#] iptest
Usage: iptest [options] dest
options:
-d device Send out on this device
-g gateway IP gateway to use if non-local dest.
-m mtu fake MTU to use when sending out
-p pointtest
-s src source address for IP packet
-1 Perform test 1 (IP header)
-2 Perform test 2 (IP options)
-3 Perform test 3 (ICMP)
-4 Perform test 4 (UDP)
-5 Perform test 5 (TCP)
-6 Perform test 6 (overlapping fragments)
-7 Perform test 7 (random packets)
[root@castor:~#] iptest -d ed0 -g 192.168.7.254 -1 192.168.14.1
Device: ed0
Source: 192.168.7.7
Dest: 192.168.14.1
Gateway: 192.168.7.254
mtu: 1500
1.1. sending packets with ip_hl < ip_len 7 1.2. sending packets with ip_hl > ip_len
12
1.3. ip_v < 4 3 1.4. ip_v > 4
15
1.5.0 ip_len < packet size (size++, long packets) 63 1.5.1 ip_len < packet size (ip_len-, short packets) 10 1.6.0 ip_len > packet size (increase ip_len)
63
1.6.1 ip_len > packet size (size--, short packets)
10
1.7.0 Zero length fragments (ip_off = 0x2000)
1.7.1 Zero length fragments (ip_off = 0x3000)
1.7.2 Zero length fragments (ip_off = 0xa000)
1.7.3 Zero length fragments (ip_off = 0x0100)
1.8.1 63k packet + 1k fragment at offset 0x1ffe
65792
1.8.2 63k packet + 1k fragment at offset 0x1ffe
skip 12800
skip 37376
skip 61952
65792
1.8.3 33k packet
33536
1.9. ip_off & 0x8000 == 0x8000
1.10.0 ip_ttl = 255
1.10.1 ip_ttl = 128
1.10.2 ip_ttl = 0
Example 6-8. Example Use of the ipsend Utility
[root@castor:~#] ipsend
Usage: ipsend [options] dest [flags]
options:
-d debug mode
-i device Send out on this device
-f fragflags can set IP_MF or IP_DF
-g gateway IP gateway to use if non-local dest.
-I code,type[,gw[,dst[,src]]] Set ICMP protocol
-m mtu fake MTU to use when sending out
-P protocol Set protocol by name
-s src source address for IP packet
-T Set TCP protocol
-t port destination port
-U Set UDP protocol
-v verbose mode
-w
Usage: ipsend [-dv] -L
options:
-d debug mode
-L filename Use IP language for sending packets
-v verbose mode
[root@castor:~#] ipsend -i ed0 -P tcp -g 192.168.7.254 192.168.14.1
Device: ed0
Source: 192.168.7.7
Dest: 192.168.14.1
Gateway: 192.168.7.254
mtu: 1500
[root@castor:~#] ipresend
Usage: ipresend [options] <-r filename |-R filename>
-r filename snoop data file to resend
-R filename libpcap data file to resend
options:
-d device Send out on this device
-g gateway IP gateway to use if non-local dest.
-m mtu fake MTU to use when sending out
The Linux Kernel Packet Generator
The Linux packet generator requires compiled-in support as a kernel module (pktgen.o); it is used via a script derived from its documentation (pktgen.txt in the Linux 2.4.x kernel documentation folder). The source code of this script is also provided in Example 6-9.
Example 6-9. Script That Interacts with the Linux Kernel Packet-Generator Module
#! /bin/sh
modprobe pktgen
function pgset() {
local result
echo $1 > /proc/net/pg
result=`cat /proc/net/pg | fgrep "Result: OK:"`
if [ "$result" = "" ]; then
cat /proc/net/pg | fgrep Result:
fi
}
function pg() {
echo inject > /proc/net/pg
cat /proc/net/pg
}
pgset "odev eth0" # set output interface
pgset "dst 192.168.7.7" # set IP destination address
pgset "count 40000" # set numbers of packets to send
#pgset "multiskb 1" use multiple SKBs for packet generation
#pgset "multiskb 0" use single SKB for all transmits
#pgset "pkt_size 9014" sets packet size to 9014
#pgset "frags 5" packet will consist of 5 fragments
#pgset "ipg 5000" sets artificial gap inserted between packets
# to 5000 nanoseconds
#pgset "dstmac 00:00:00:00:00:00" sets MAC destination address
#pgset stop aborts injection
Performance-Testing and Network-Benchmarking Tools
This family of tools provides network performance information and benchmarking by usually taking a client/server approach that allows collecting very accurate end-to-end information and statistics. These tools are powerful and complex; refer to the repository documentation for further details. Some interesting representatives of this family of tools are as follows:
Netperf (Network Performance Benchmarking)
NetPIPE (Network Protocol Independent Performance Evaluator)
ttcp/wsttcp (Test TCP [TTCP]; a benchmarking tool for measuring TCP and UDP performance)
NOTE
A thorough discussion of network performance measurement would dive too much into stack internals and go far beyond the scope of this book.
