Summary


Comprehensive Example

This section presents a comprehensive example, tying together many of the concepts covered in the rest of this appendix. Figure B-17 illustrates the network used in this example.

Figure B-17. PC1 in New York Is Sending FTP Data to FS1 in London


In this network, PC1, located in New York, has an FTP connection with the file server FS1 in London. PC1 is transferring a file, using FTP, to FS1. The path between PC1 and FS1 goes through switch S1; Routers R1, R2, and R3; and switch S2, as illustrated by the thick line in the figure. (The routers have communicated, using a routing protocol, to determine the best path between network 10.0.0.0 and network 172.16.0.0.) PC1 has an IP address of 10.1.1.1, and FS1 has an IP address of 172.16.3.5. When PC1 first needed to send data to a device on another network, it sent an ARP request; its default gateway R1 replied with its own MAC address, which PC1 keeps in its memory.

FTP data is now being sent from PC1 to FS1. Figure B-18 shows how this data flows within the devices in the network, and what the data looks like at each point within the network.

Figure B-18. Data Is Encapsulated and Decapsulated as It Flows Through the Network


Starting at the left of Figure B-18, PC1 prepares the data for transport across the network, and the resulting frame is shown as point A in the figure. PC1 encapsulates the FTP data in a TCP segment; the destination port field of the segment is set to 20, indicating that it contains FTP data. This TCP segment is then encapsulated in an IP datagram. The protocol number of the datagram is set to 6, indicating that it contains a TCP segment. The source IP address is set to PC1's address, 10.1.1.1, while the destination IP address is set to FS1's address, 172.16.3.5. The IP datagram is encapsulated in an Ethernet frame, with the source MAC address set to PC1's MAC address and the destination MAC address set to R1's MAC address. PC1 then puts the frame on the Ethernet network, and the bits arrive at S1.

S1 receives the frame and looks at the destination MAC addressit is R1's MAC address. S1 looks in its MAC address table and sees that this MAC address is on its Fast Ethernet port. Therefore, S1 encapsulates the IP datagram in a Fast Ethernet frame, as shown at point B in the figure. Notice that the source and destination MAC addresses have not changed in this new frame type, and that the datagram, segment, and data all remain untouched by the switch. S1 then puts the frame on the Fast Ethernet network, and the bits arrive at R1.

R1 receives the frame, and because it is destined for R1's MAC address, R1 decapsulates the frame to Layer 3. R1 looks at the destination IP address 172.16.3.5 and compares it to its routing table. This network is accessible through R2, over a Frame Relay network, so R1 encapsulates the IP datagram in a Frame Relay frame, as shown at point C in the figure. Notice that the datagram, segment, and data all remain untouched by the router, but the frame type has changed. R1 then puts the frame on the Frame Relay network, and the bits arrive at R2.

R2 receives the frame and decapsulates it to Layer 3. R2 looks at the destination IP address 172.16.3.5 and compares it to its routing table. This network is accessible through R3, over an HDLC network, so R2 encapsulates the IP datagram in an HDLC frame, as shown at point D in the figure. Notice that the datagram, segment, and data all remain untouched by the router, but the frame type has changed again. R2 then puts the frame on the HDLC network, and the bits arrive at R3.

R3 receives the frame and decapsulates it to Layer 3. R3 looks at the destination IP address 172.16.3.5 and compares it to its routing table. This network is accessible through its Gigabit Ethernet interfaceit is directly connected to that network. When R3 first needed to send data to FS1, it sent an ARP request; FS1 replied with its own MAC address, which R3 keeps in its memory. So R3 encapsulates the IP datagram in a Gigabit Ethernet frame, as shown at point E in the figure, with the source MAC address set to its own address and the destination MAC address set to FS1's address. Notice that the datagram, segment, and data all remain untouched by the router, but the frame type has changed. The bits arrive at S2.

S2 receives the frame and looks at the destination MAC addressIt is FS1's MAC address. S2 looks in its MAC address table and sees that this MAC address is on another one of its Gigabit Ethernet ports. Therefore, the IP datagram can stay in a Gigabit Ethernet frame, as shown at point F in the figure. Notice that the source and destination MAC addresses have not changed in this frame, and that the datagram, segment, and data all remain untouched by the switch. S2 then puts the frame on the other Gigabit Ethernet network, and the bits arrive at FS1. FS1 receives the frame, and because it is destined for FS1's MAC address, FS1 decapsulates the frame to Layer 3. FS1 looks at the destination IP address and determines that it is its own address. Therefore, FS1 decapsulates the segment and the FTP data and then sends it to its FTP application. The FTP data is now at its destination.

Key Point

At each communication layer, the same protocol must be used at each side of a connection.

For example, PC1 is sending data to FS1 using FTP, so both PC1 and FS1 must support FTP at the application layer. If they don't, the session will fail and data will not be sent.

Note, however, that the FTP data can go through many different types of mediaLayers 1 and 2on its way to FS1. The devices (switches, routers, PC, and file server) all decapsulate up to at least Layer 2; thus, both sides of each connection between these devices must support the same Layers 1 and 2. For example, if PC1 only supported Ethernet and S1 only supported Fast Ethernet, they would not be able to communicate. Because S1 has an Ethernet port, it can connect to PC1 and then convert the data to send out on its Fast Ethernet port.





Campus Network Design Fundamentals
Campus Network Design Fundamentals
ISBN: 1587052229
EAN: 2147483647
Year: 2005
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net