Figure 1.6: Packet flow through the TCP/IP layers.
Figure 1.7: (a) IP version 4, (b) IP version 6 message formats.
Figure 1.8: UDP header format.
Figure 1.9: TCP message format.
Figure 1.10: Network devices in context.
Figure 1.11: Simplified network design illustrating the typical locations for key hardware devices.
Figure 1.12: Architecture of a multiprotocol bridge router.
Figure 1.13: Integrated bridge router and discrete bridge routers in parallel.
Figure 1.14: Integrated bridge router and discrete bridge and routers in parallel.
Figure 1.15: Sample media and bandwidth choices available today.
Chapter 2: Addressing, Naming, and Configuration
Figure 2.1: Conceptual model showing the key protocols and context for addressing, naming, and configuration operations in an IP internetwork environment.
Figure 2.2: IP header formats showing the space allocated for source and destination IP addresses. (a) The IPv4 header length is a minimum of 20 bytes, supporting 32-bit addresses. (b) The IPv6 header length is a minimum of 40 bytes, supporting 128-bit addresses.
Figure 2.3: General IPv4 address format.
Figure 2.4: Classes A through E: IP version 4 address formats.
Figure 2.5: Multicast addresses mapping between an IPv4 address and Ethernet. In this example the class D multicast 224.3.5.1 is mapped onto the MAC address 0x01005e030501.
Figure 2.6: IPv6 message format. Only the version field (Ver) remains intact from the IPv4 format.
Figure 2.7: Examples of Proxy ARP applications.
Figure 2.8: BOOTP message format.
Figure 2.9: DHCP message format.
Figure 2.10: Interaction between DHCP client and server.
Figure 2.11: Domain hierarchy.
Figure 2.12: Zone relationship with a domain. The zone extends down to all subdomains that are not self-administered.
Figure 2.13: DNS operation in a fictitious university campus.
Figure 2.14: LDAP directory information tree hierarchy.
Figure 2.15: NAT concepts.
Figure 2.16: A single class B network with 7 functional work groups.
Figure 3.2: Scalability of link-state protocols versus distance-vector protocols as the number of routes increase.
Figure 3.3: Based on various path selection criteria and the routing algorithm chosen, any number of bad choices could be made in selecting the optimum path.
Figure 3.4: Conceptual flowchart illustrating the IP forwarding algorithm.
Figure 3.5: Default gateway configuration under Windows 98.
Figure 3.6: Simple flowchart for possible IGP selection.
Figure 3.7: RIPv1 header format.
Figure 3.8: RIPv1 routing entry format.
Figure 3.9: RIPv1 routing update message.
Figure 3.10: RIPv2 routing entry format.
Figure 3.11: RIPv2 authentication format.
Figure 3.12: OSPF header format.
Figure 3.13: OSPF hello packet.
Figure 3.14: Hierarchical OSPF internetwork showing the four basic router classifications.
Figure 3.15: Trace of OSPF neighbors forming an adjacency.
Figure 3.16: (a) OSPF full-mesh peering required without designated router (DR) support (adjacencies scale exponentially and so clearly cannot scale). (b) Peering required when router 1 acts as a DR. Note that normally a Backup Designated Router (BDR) would also be used for resilience, so we scale adjacencies linearly as (n ×2) — 2.
Figure 3.17: Linear versus logarithmic growth.
Figure 3.18: BGP packet format.
Figure 3.19: Two BGP routers peering.
Figure 3.20: Conceptual BGP design.
Figure 3.21: BGP aggregation.
Figure 3.22: BGP default routes.
Figure 3.23: BGP homing topology options. (a) Single homing. (b) Multihoming, single provider. (c) Multihoming, multiple providers. (d) Multiple customers sharing a private iBGP link to a single multihomed provider. (e) Multiple customers sharing a private iBGP link to multiple multihomed providers.
Figure 3.24: Examples of redistribution interfaces. (1) The AS border interface between exterior routing protocols such as BGP-4 or static routing. (2) The AS border interface between exterior routing protocols and interior routing protocols such as OSPF, EIGRP, and RIP. (3) The interior interface between two different routing domains (e.g., Domain-1 could run OSPF, Domain-3 could run EIGRP). (4) Same as (3), except that redistribution here is not mutual (e.g., Domain-3 runs RIP, and receives only a default route back from OSPF in Domain-1.).
Chapter 4: Multicast Network Design
Figure 4.1: Multicast leaking in a flattened LAN environment.
Figure 4.2: Example internetwork topology required to support multicasting.
Figure 4.3: Multicast Spanning Tree, rooted at S, for the example network shown in Figure 4.2.
Figure 4.4: IGMP message format.
Figure 4.5: Multicast routing operations with IGMP.
Figure 4.6: DVMRP message format.
Figure 4.7: Multicast network running DVMRP between routers and IGMP on the router interfaces.
Figure 4.8: OSPF hello message example.
Figure 4.9: PIM dense-mode operation, (a) Shows multicast flooding for multicast group G1 and reverse pruning (either because G1 multicast is not required or duplicate sources are detected). (b) The resulting pruned multicast tree for group G1.
Figure 4.10: PIM sparse-mode operation. (a) Shows multicast delivery to the rendezvous point (router R6) for multicast group G1. (b) The resulting optimized multicast tree for group G1.
Figure 4.11: Example CBT topology.
Figure 4.12: Major MBone routers and links as of May 11, 1994. (Attributed to S. Casner)
Figure 4.13: MBone tunnel. Shaded nodes are multicast-enabled routers forming an overlay network (shown in bold).
Figure 4.14: Modified MBone tunnel topology. By changing the tunnel metrics between R2 and R4 we can force a different path.
Figure 4.15: IP multicast and real-time application support protocols in context. For a description of the Streaming Protocol (ST2) and associated higher-level protocols refer to [30].
Chapter 5: Designing Secure Networks
Figure 5.1: Growth in complexity of the Microsoft Windows operating systems between 1992 and 2000, showing the estimated number of lines of code used in each OS [2].
Figure 5.2: Common protocol features used for IP-based hacking.
Figure 5.3: Simplified and incomplete attack tree for getting a copy of a sensitive client database from a corporate server (progress is from top to bottom).
Figure 5.4: Security solutions in context.
Figure 5.5: The process of agreeing on a shared secret key, using the Diffie-Helman technique, by exchanging only the public key of the peer.
Figure 5.6: PKI architectural model. Each CA is responsible for a security domain. CAs may perform cross-certification with other CAs.
Figure 5.7: NAT configuration.
Figure 5.8: Traditional firewall concepts.
Figure 5.9: General model for a proxy server handling e-mail, Web, terminal, and file transfer traffic.
Figure 5.10: Conceptual architecture of a stateful firewall.
Figure 5.11: VPN and normal session characteristics.
Figure 5.12: Simple VPN deployment over the Internet.
Figure 5.13: Dial-up VPN operation.
Figure 5.14: IKE and IPSec Security Associations (SAs) for two VPNs.
Figure 5.15: SAs are defined in either transport mode or tunnel mode.
Figure 5.16: The shaded area represents the scope of authentication for IPSec transport and tunnel mode using either the AH or the ESP protocol.
Figure 5.17: AH header format.
Figure 5.18: ESP header and trailer.
Figure 5.19: Phase 1 and Phase 2 IKE and IPSec SA negotiations.
Figure 5.20: Simple end-to-end security using a host IPSec stack only. Note that IPorg is the original IP header; IPtun is the new IP header created in IPSec tunnel mode.
Figure 5.21: Basic VPN security using gateway IPSec stacks between two intranets. Note that IPorg is the original IP header; IPtun is the new IP header created in IPSec tunnel mode.
Figure 5.22: Remote access.
Figure 5.23: End-to-end security. Both gateways and hosts support IPSec.
Figure 5.24: Alternative locations for VPN termination in cooperation with a firewall and router.
Figure 5.25: VPN termination between two trusted sites. The firewall and router must be configured to accept any VPN tunneling or key-management protocols.
Chapter 6: Designing Reliable Networks
Figure 6.1: Cost of unavailability in a fictitious call center.
Figure 6.2: Failure analysis of a simple nonresilient design.
Figure 6.3: Point-to-point network in series.
Figure 6.4: Point-to-point network in parallel.
Figure 6.5: Topological fault tolerance. (a) Bus or multidrop, (b) Tree, (c) Partial mesh, (d) Full mesh, (e) Star.
Figure 6.6: (a) Traditional leased-line star topology. (b) Leased-line star topology, supplemented by dial-up links. (c) Twin star topology with leased lines.
Figure 6.7: (a) Partial mesh leased line network. (b) Fully meshed leased line network.
Figure 6.8: Logical routing topology where both multilink and multipath load sharing are employed.
Figure 6.9: Resilient connections into a switched cloud via dual connections to different PoPs.
Figure 6.10: Topological resilience in LAN backbones. (a) Self-healing fiber ring backbone (e.g., FDDI, Token Ring), (b) Meshed-switched backbone (e.g., FDDI, Fast Ethernet, Gigabit Ethernet, ATM).
Figure 6.11: Basic redundant link configurations. (a) A simple star configuration requiring four physical cables to provide link resilience but having a single point of failure at hub H1. (b) An improved configuration with only three cables and no single point of failure.
Figure 6.12: User workstation wired back to two communications rooms using a dual port transceiver connected to different floor outlets.
Figure 6.13: General architecture for servers in (a) fault-tolerant mode and (b) clustered high-availability (HA) mode.
Figure 6.14: VRRP packet format.
Figure 6.15: VRRP configuration with resilience for highspeed server farm.
Figure 6.16: VRRP configuration with LAN and WAN interfaces.
Figure 6.17: Fault-tolerant backbone design.
Figure 6.18: Total resilience in a building environment.
Figure 6.19: First floor conceptual wiring plan at New York XChange-A, Floor 1.
Chapter 7: Network Optimization
Figure 7.1: Policy implementation using SAP packet filtering.
Figure 7.2: Token bucket scheme.
Figure 7.3: A classification of queuing disciplines.
Figure 7.4: Enhanced FIFO queuing.
Figure 7.5: Priority queuing.
Figure 7.6: Custom queuing.
Figure 7.7: The effects of an applied CBQ class to a Web-browsing application. In (a) the traffic is unconstrained and has regular bursts above 50 Mbps, affecting other services. In (b) the traffic class applied limits the maximum available bandwidth to 40 Mbps.
Figure 7.8: (a) Local proxy configuration. (b) Remote proxy configuration.
Figure 7.9: VRRP configuration with load sharing and resilience for a server farm.
Figure 7.10: Deterministic flow hashing using two monster switches.
Figure 7.11: Deterministic flow hashing.
Figure 7.12: Distributing flows using hashing techniques. Here, four flows (A, B, C, and D) are fed into the cluster. (a) An autocratic model, where a master (MI) is elected and performs flow distribution at the ingress port. (b) A democratic model, where each node is aware of the flow states being handled by other members of the cluster.
Figure 7.13: Web browsing and FTP file requests without caching. (1) The Web browser issues an HTTP request for a Uniform Resource Locator (URL), which refers to a specific Web page on a particular server (also known as an HTTP server or origin server) attached to the Internet. (2) The request is forwarded to the server through standard IP routing. (3) The HTTP Content Server returns content to the Web browser one file at a time (which typically comprises a sequence of large packets).
Figure 7.14: Web and FTP transactions with caching.
Figure 7.15: Cache deployment options. Note that cache locations are highlighted with a C. (1) Cache server acting as a default gateway. (2) Layer 4 switches can route requests for cacheable data (HTTP, NNTP, etc.) to the cache server while forwarding all other requests to the Internet. (3) Web Cache Control Protocol (WCCP) implemented in a Cisco IOS-based router. Port 80 (HTTP) requests are routed to the cache servers, while other requests are routed to the Internet. (4) In front of a Web farm to reduce load on content servers. (5) At an ISP Point of Presence (PoP) to serve requests locally. (6) At an aggregation point at the edge of the Internet to reduce bandwidth requirements.
Figure 8.14: Pieces of the QoS jigsaw puzzle in context.
Figure 8.15: The transit (backbone) network is running DiffServ for scalability and ease of deployment. RSVP is run on the stub (access) networks between the edge routers and the backbone routers.
Chapter 9: Network Management
Figure 9.1: A typical Graphical User Interface (GUI) showing a network map.
Figure 9.2: Basic SNMP architecture.
Figure 9.3: MIB tree hierarchy.
Figure 9.4: Example GetRequest for 1.3.6.1.2.1.1.1.1.1.1.1.1.0.
Figure 9.5: Basic SNMP protocol stack and object interaction.
Figure 9.6: OSI management structure.
Figure 9.7: Nokia's Voyager HTTP interface for firewall configuration management.
Figure 9.8: HP++ SNMP browser tool. An example showing the Get primitive being configured for MIB-II.
Figure 9.9: Simple one-tier centralized management, with three remote subnets connected via 64-Kbps links.
Figure 9.10: Manager-of-Manager (MoM) concepts offering a hierarchical and distributed management design.
Figure 9.11: Traceroute recording example.
Figure 9.12: A PC-based network analyzer, showing detailed protocol decoding of a TCP/IP frame over an Ethernet interface.