Judul : Kitab Nikah
Penulis : Ahmad Sarwat, Lc
Penerbit : Kampus Syariah
Jumlah Halaman 195
Buku fiqih nikah ini hanyalah sebuah catatan kecil dari ilmu fiqih yg sedemikian luas. Para ulama pendahulu kita telah menuliskan ilmu ini dalam ribuan jilid kitab yg menjadi pusaka dan pustaka khazanah peradaban Islam.
Sayangnya kebanyakan umat islam malah tidak dapat menikmati 'warisan' itu, salah satunya karena kendala bahasa. Padalah tak satunya karena kendala bahasa. maka penulisan kitab ini merupakan salah satu upaya mendekatkan umat ini dengan salah satu warisan agamanya.
semoga bermanfaat.
download
Showing posts with label Ebook. Show all posts
Showing posts with label Ebook. Show all posts
Download 29 ebook Visual Basic Programming Gratis
Download 29 ebook [VB] Visual Basic programming gratis
29 Visual Basic programming books
29 books | 2001 - 2006 | RAR | 273 Mb
29 Visual Basic programming books
29 books | 2001 - 2006 | RAR | 273 Mb
An Introduction To Programming Using Visual Basic 2005, 6th Edition - 752 pages | CHM | March 13, 2006 http://www.amazon.com/Introduction-Programming-Using-Visual-Basic/dp/0130306541
Beginner's Guide To DarkBASIC Game Programming - 752 pages | CHM | January 22, 2003
http://www.amazon.com/Beginners-Guide-DarkBASIC-Programming-Development/dp/1592000096
Beginning REALbasic - From Novice To Professional - 400 pages | PDF | May 11, 2006
http://www.amazon.com/Beginning-REALbasic-Novice-Professional-Experts/dp/159059634X
Beginning Visual Basic 2005 - 840 pages | PDF | November 7, 2005
http://www.amazon.com/Beginning-Visual-Basic-Thearon-Willis/dp/0764574019
Beginning Visual Basic 2005 Express Edition - From Novice To Professional - 544 pages | PDF | September 25, 2006
http://www.amazon.com/Beginning-Visual-Basic-2005-Express/dp/1590596226
Expert VB 2005 Business Objects, 2nd Edition - 696 pages | PDF | May 8, 2006
http://www.amazon.com/Expert-2005-Business-Objects-Second/dp/1590596315
Mastering Visual Basic .NET - 1100 pages | PDF | December 5, 2001
http://www.amazon.com/Mastering-Visual-Basic-Evangelos-Petroutsos/dp/0782128777
Microsoft Visual Basic 2005 Express Edition Programming For The Absolute Beginner - 440 pages | CHM | December 22, 2005
http://www.amazon.com/Microsoft-Express-Programming-Absolute-Beginner/dp/1592008143
Microsoft Visual Basic 2005 Step By Step - 560 pages | CHM | October 5, 2005
http://www.amazon.com/Microsoft-Visual-Basic-2005-Step/dp/0735621314
Peer-To-Peer With VB .NET - 440 pages | CHM | July 24, 2003
http://www.amazon.com/Peer-Peer-NET-Matthew-MacDonald/dp/1590591054
Pro ASP.NET 2.0 In VB 2005, Special Edition - 1360 pages | PDF | September 22, 2006
http://www.amazon.com/Pro-ASP-NET-2-0-2005-Special/dp/1590597761
Pro VB 2005 And The .NET 2.0 Platform, 2nd Edition - 1088 pages | PDF | April 17, 2006
http://www.amazon.com/Pro-2005-NET-Platform-Second/dp/1590595785
Professional VB 2005 - 1104 pages | PDF | November 10, 2005
http://www.amazon.com/Professional-VB-2005-Programmer/dp/0764575368
Programming Microsoft Visual Basic 2005 - The Language (Pro Developer) - 990 pages | CHM | January 25, 2006
http://www.amazon.com/Programming-Microsoft-Visual-Basic-2005/dp/0735621837
Programming Visual Basic .NET - 800 pages | PDF | Januar 2002
http://www.amazon.ca/Programming-Visual-Basic-Net-Jesse-Liberty/dp/0596004389
Security For Microsoft Visual Basic .NET - 416 pages | CHM | May 28, 2003
http://www.amazon.com/Security-Microsoft-Visual-Basic-NET/dp/0735619190
The Book Of Visual Basic 2005 - .NET Insight For Classic VB Developers - 512 pages | PDF | April 30, 2006
http://www.amazon.com/Book-Visual-Basic-2005-Developers/dp/1593270747
VBScript In A Nutshell, 2nd Edition - 552 pages | CHM | April 1, 2003
http://www.amazon.com/VBScript-Nutshell-2nd-Paul-Lomax/dp/0596004885
Visual Basic .NET Power Tools - 800 pages | CHM | September 24, 2003
http://www.amazon.com/Visual-Basic-NET-Power-Tools/dp/0782142427
Visual Basic 2005 Cookbook - 740 pages | CHM | September 21, 2006
http://www.amazon.com/Visual-Basic-2005-Cookbook-Programmers/dp/0596101775
Visual Basic 2005 Database Programming - 624 pages | PDF | December 19, 2005
http://www.amazon.com/Expert-Visual-Basic-Database-Programming/dp/076457678X
Visual Basic 2005 Express Edition Starter Kit - 384 pages | PDF | January 18, 2006
http://www.amazon.com/Wroxs-Visual-Express-Starter-Programmer/dp/0764595733
Visual Basic 2005 For Dummies - 384 pages | PDF | October 17, 2005
http://www.amazon.com/Visual-Basic-2005-Dummies-Sempf/dp/076457728X
Visual Basic 2005 In A Nutshell, 3rd Edition - 766 pages | CHM | January 2006
http://www.oreilly.com/catalog/vb2005ian3/
Visual Basic 2005 Jumpstart - 214 pages | CHM | June 1, 2005
http://www.amazon.com/Visual-Basic-2005-Jumpstart-Wei-Meng/dp/059610071X
Visual Basic 2005 Programmer's Reference - 1056 pages | PDF | October 21, 2005
http://www.amazon.com/Visual-Basic-Programmers-Reference-Programmer/dp/0764571982
Visual Basic Shell Programming - 388 pages | CHM | July 1, 2000
http://www.amazon.com/o/ASIN/1565926706/102-4711228-7755368?SubscriptionId=18F0HAA4KWCRBW7SEZG2
Visual Studio Tools For Office - Using Visual Basic 2005 With Excel, Word, Outlook, And InfoPath - 1120 pages | CHM | May 6, 2006
http://www.amazon.com/Visual-Studio-Tools-Office-Development/dp/0321411757
Windows Forms Programming In Visual Basic .NET - 736 pages | CHM | November 1, 2003
http://www.amazon.com/Windows-Programming-Visual-Microsoft-Development/dp/0321125193
Number Theory An Introduction to Mathematics
Number Theory is more than a comprehensive treatment of the subject. It is an introduction to topics in higher level mathematics, and unique in its scope; topics from analysis, modern algebra, and discrete mathematics are all included.
The book is divided into two parts. Part A covers key concepts of number theory and could serve as a first course on the subject. Part B delves into more advanced topics and an exploration of related mathematics. Part B contains, for example, complete proofs of the Hasse-Minkowski theorem and the prime number theorem, as well as self-contained accounts of the character theory of finite groups and the theory of elliptic functions.
The prerequisites for this self-contained text are elements from linear algebra. Valuable references for the reader are collected at the end of each chapter. It is suitable as an introduction to higher level mathematics for undergraduates, or for self-study.
Practical Designs and Construction
Ebooks TCP/IP Sockets in Java
I think the book does a good job of hitting this market. It is not suited to be a main textbook for a class, and it does not try to do that, But it does do a nice job of succinctly hitting the major points, providing nice examples,
As well as a reference for the major important topics.
So I see this as a nice book for developers who want to quickly (and cheaply) master networking Java, as well as a supplemental book for courses in continuing education courses or colleges.
Color Correction for Video Ebook
Use color to improve your storytelling, deliver critical emotional cues, and add impact to you videos.
This book shows you how to analyze color correction problems and solve them- whatever NLE or plugin you use.
Experienced editors and colorists in their own right, the authors also include the wisdom of top colorists, directors of photography, and color scientists to deliver this insightful and authoritative presentation of the theory and practice of color correction.
Sensors Handbook Second Editon
Fully revised with the latest breakthroughs in integrated sensors and control systems, Sensors Handbook, Second Edition provides all of the information needed to select the optimum sensor for any type of application, including engineering, semiconductor manufacturing, medical, military, agricultural, geographical, and environmental implementations.
This definitive volume discusses a wide array of sensors, including MEMS, nano, microfabricated, CMOS, smart, NIR, SpectRx(tm), remote-sensing, fiber-optic, light, ceramic, and silicon sensors. Several in-depth application examples from a variety of industries are included.
The comprehensive details in this authoritative resource enable you to accurately verify the specifications for any required component. This is the most through, up-to-date reference on sensing technologies available.
How to Start and Operate a Digital Portrait Photography Studio
How to Start and Operate a Digital Portrait Photography Studio
Twenty successful studio owners offer their expertise to aspiring professional photographers in this guide to operating a digital portrait studio. Every element of a thriving studio is covered, from choosing a location and determining a budget to selecting computer equipment and streamlining the digital work flow. Details on selecting backgrounds, sets, and props that set a studio apart and advice on lighting patterns, posing, and clothing selection help photographers ensure that they produce client-pleasing images and return customers.
Twenty successful studio owners offer their expertise to aspiring professional photographers in this guide to operating a digital portrait studio. Every element of a thriving studio is covered, from choosing a location and determining a budget to selecting computer equipment and streamlining the digital work flow. Details on selecting backgrounds, sets, and props that set a studio apart and advice on lighting patterns, posing, and clothing selection help photographers ensure that they produce client-pleasing images and return customers.
Free Ebook Data Analisys Community
Ecologists need to analyze their field data to interpret relationships within plant and animal communities and with their environments. The purpose of this book is to show ecologists and environmental scientists what numerical and statistical methods are most useful, how to use them and interpret the results from them, and what pitfalls to avoid. Subjects treated include data requirements, regression analysis, calibration (or inverse regression)
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
