First, the essential ideas
- Application
- A program or service that does a useful job, such as showing a web page or looking up a website name.
- Protocol
- Agreed rules for exchanging information, including how messages are formed and interpreted.
- Transport protocol
- Rules used by endpoint software to exchange application data; TCP and UDP provide different services.
- Port number
- A numbered field used with an address and transport protocol to identify a communication endpoint; it is not a cable socket.
- IP packet and frame
- An IP packet carries network addresses. On an Ethernet link, a frame wraps that packet with local link information.
- Byte stream
- An ordered sequence of bytes, the small units that represent data; TCP does not preserve the application's separate message boundaries.
- Datagram
- One independently handled message; UDP preserves datagram boundaries but does not itself recover missing messages.
- Acknowledgment
- A transport message indicating received data; a TCP acknowledgment does not prove a person read the data or that an application saved it.
- Console and VPCS
- A console is a text window for commands. VPCS, the Virtual PC Simulator, is a small simulated endpoint, not a full Windows or Linux computer.
- Packet capture
- A record of traffic observed at one selected link or interface; it is evidence from that observation point, not a view of every network.
- ICMP and ping
- ICMP carries IP control messages. Ordinary ping requests an echo reply using ICMP; it is neither a TCP test nor a UDP test.
- Local subnet
- The IP address group a host treats as directly reachable on its local network, as determined by its address and mask.
Read these definitions before the comparison. This lesson separates three questions: can the other endpoint be reached, which transport is present, and did an actual application complete its job? Each question needs different evidence. Our practical exercise answers the first two only; the application examples are conceptual comparisons.
See the idea
One local path, two transport probes
Identify what PC1 sends to PC2; a captured probe is not proof that an application completed its work.
Establish the local path
Configure PC1 and PC2 on the same subnet and check ICMP replies through Switch1. Both cable endpoints are shown; no router forwards this local exchange.
What this model leaves out: This isolated wired path omits routers, firewalls and application servers. VPCS probes reveal transport fields; they do not demonstrate full sessions, application delivery or performance.
Full visual explanation and references
PC1 sends probes through Switch1 to PC2. The diagram ends at PC2 and compares outgoing UDP and TCP probes, not completed application sessions.
This isolated wired path omits routers, firewalls and application servers. VPCS probes reveal transport fields; they do not demonstrate full sessions, application delivery or performance.
- Establish the local path
Configure PC1 and PC2 on the same subnet and check ICMP replies through Switch1. Both cable endpoints are shown; no router forwards this local exchange.
docs.gns3.comdocs.gns3.com - Observe the UDP probe
PC1 sends a synthetic UDP probe through Switch1 toward PC2. Inspect the UDP header at the PC1 link; no application server or delivery guarantee is demonstrated.
www.rfc-editor.orgwww.wireshark.org - Observe the TCP probe
PC1 sends a synthetic TCP SYN through Switch1 toward PC2. Inspect its flags and port; a SYN alone does not show a completed handshake or a successful web request.
www.rfc-editor.orgwww.wireshark.org
One idea at a time
Start with something familiar.
You do not need to know router commands. Imagine two programs exchanging data, then ask what help they need from the transport. Use the definitions first. When a lab instruction says Console, right-click the named GNS3 device and choose Console; its prompt shows where commands belong.
Why learn this?
A website can fail even when ping works. A transport can be visible even when no application is listening. Learning to separate those observations prevents unnecessary router changes and makes troubleshooting reports more useful.
An everyday comparison
For a memory aid, compare a numbered set of notes checked for missing pages with separate announcements sent without that check. This is an organizational metaphor, not a literal description of devices or a promise that every message arrives.
What happens in a network
TCP provides ordered bytes and mechanisms to recover loss. UDP provides independent messages; an application can implement additional checking when needed. The application decides what successful work means.
Where the comparison stopsReal protocols use headers, state and timers, not paper or people. The analogy cannot predict speed, establish security or demonstrate how an actual application handles missing data.
Follow one worked example
- Name the task before choosing a protocol.
Write whether the application needs a complete ordered result, timely individual updates, or its own reliability rules. Do not start by assuming that every video or web service uses the same transport.
Why: The required behavior is a better starting point than a memorized slogan about TCP being slow or UDP being fast.
- Name the evidence you can actually collect.
A capture can show addresses, the transport and ports at the selected link. In our lab, PC1 sends to PC2 through Switch1; no router forwards this same-subnet exchange.
Why: Knowing the path prevents you from inspecting an unrelated router and mistaking its local sockets for all transit sessions.
- Compare the test with the real application.
A synthetic TCP probe is not a browser fetching a page. A UDP probe is not a phone call. Keep the real-application explanation separate from what the simulator actually ran.
Why: This keeps your conclusion proportional to the evidence and avoids treating a missing reply as proof of a particular fault.
Your first small task
On paper, make three columns: ICMP reachability, TCP or UDP traffic, and successful application work. Place 'a ping reply', 'a captured UDP datagram' and 'a completed web request' into the appropriate columns.
Show a hint
Ask what produced each observation and whether an application actually completed its requested job.
Check the expected result
The three observations answer different questions; none should be silently substituted for another.
Pause and explain it in your own words
Does a reply to ordinary ping prove that a TCP web service is running?
Show a hint
Compare the ICMP definition with the transport and application definitions.
Show the explanation
No. An ICMP echo reply supports reachability for that test at that time. A web service needs its own transport exchange and successful application response; it may be unavailable even while ping works.
Short answer
What should you understand today?
TCP offers an ordered byte stream with loss recovery; UDP sends separate datagrams without built-in delivery or ordering guarantees. Choose by application needs, then inspect actual traffic. A port number or successful ping alone cannot identify or prove a working application.
Before you begin
Learning targets
- Review the earlier lessons on endpoints, Ethernet frames and IP packets; the key terms are reintroduced here.
- Install GNS3 with its included VPCS and Ethernet switch nodes, plus a working Wireshark capture integration.
- Use a new isolated project with no Cloud, NAT, physical adapter or connection to shared networks.
- No Cisco image, Linux container, web server or previous router configuration is needed for this lab.
- Compare TCP's byte-stream service with UDP's datagram service without assuming one is always faster.
- Explain why application names and port numbers do not uniquely determine the transport in use.
- Generate bounded synthetic probes and inspect their transport fields on an isolated virtual link.
- Separate successful network reachability from a listening service, complete session and successful application transaction.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Application
A program or service that does a useful job, such as showing a web page or looking up a website name.
Protocol
Agreed rules for exchanging information, including how messages are formed and interpreted.
Transport protocol
Rules used by endpoint software to exchange application data; TCP and UDP provide different services.
Port number
A numbered field used with an address and transport protocol to identify a communication endpoint; it is not a cable socket.
IP packet and frame
An IP packet carries network addresses. On an Ethernet link, a frame wraps that packet with local link information.
Byte stream
An ordered sequence of bytes, the small units that represent data; TCP does not preserve the application's separate message boundaries.
Datagram
One independently handled message; UDP preserves datagram boundaries but does not itself recover missing messages.
Acknowledgment
A transport message indicating received data; a TCP acknowledgment does not prove a person read the data or that an application saved it.
Console and VPCS
A console is a text window for commands. VPCS, the Virtual PC Simulator, is a small simulated endpoint, not a full Windows or Linux computer.
Packet capture
A record of traffic observed at one selected link or interface; it is evidence from that observation point, not a view of every network.
ICMP and ping
ICMP carries IP control messages. Ordinary ping requests an echo reply using ICMP; it is neither a TCP test nor a UDP test.
Local subnet
The IP address group a host treats as directly reachable on its local network, as determined by its address and mask.
Five-tuple
A directional traffic identifier consisting of source IP, destination IP, transport protocol, source port and destination port.
SYN and ACK
TCP flags used in establishing and acknowledging communication; SYN synchronizes sequence numbers and ACK indicates acknowledgment.
DNS
The Domain Name System, which retrieves records associated with names and supports traditional exchanges over UDP and TCP.
QUIC
A transport protocol carried over UDP that provides mechanisms such as reliable streams; HTTP/3 uses it for web communication.
Start with the application and the evidence
A program asks the network to help it do a job. An operator should describe that job before choosing a test. Suppose a student can ping a classroom server but cannot open its page. Record the requested page, time, client and server, then investigate the actual service. Do not report that the entire application is healthy merely because one lower-level test worked. Conversely, do not report that the entire network is down after one missing response. Our working method is to name the test, state the observation, and state the remaining uncertainty. The hands-on exercise below is deliberately narrow: it identifies transport headers in synthetic probes between two virtual endpoints. It does not install a website, simulate a live call or compare real application performance.
- An address identifies an endpoint in the IP plan, not an application outcome.
- Record what the test observed and what remains untested.
- Use the smallest isolated experiment that answers the current question.
TCP: ordered bytes, recovery and a real limit
TCP gives applications an ordered byte stream. Sequence numbers and acknowledgments support tracking received bytes; retransmission can recover lost data. A normal new connection begins with a SYN, SYN-ACK and ACK exchange. SYN means synchronize sequence numbers; ACK means acknowledge. These are transport control flags, not application content. This service has limits: a broken path can still make the connection fail, and a transport acknowledgment does not prove the receiving application saved a file. A conceptual file-transfer example therefore needs both the transport exchange and an application-level completion check. The probe exercise later sends a SYN but deliberately does not claim to demonstrate a complete connection or file transfer.
- TCP preserves byte order, not the application's original message boundaries.
- A SYN probe is not evidence of a completed three-way handshake.
- Reliability mechanisms cannot guarantee success through a permanently broken path.
UDP: separate messages and application responsibility
UDP carries independent datagrams with source and destination port fields. UDP itself does not add acknowledgments, loss recovery or ordered delivery. This does not mean every UDP-based application is careless: software can add its own reliability, timing or security mechanisms. It also does not establish that UDP is always faster. A comparison needs a defined workload, complete protocol stack and measurements. We do not measure those properties here. For an individual update whose usefulness expires quickly, the application designer may handle lateness differently from a file-transfer program. The exact behavior belongs to that application, not to a blanket promise made by UDP.
- A datagram retains its message boundary.
- No UDP reply is not proof that the outbound message never arrived.
- Application behavior must be documented or observed, not guessed from the transport.
Real services can use more than one transport
DNS, the Domain Name System, helps resolve names into records such as IP addresses. Traditional DNS supports UDP and TCP; TCP is not reserved exclusively for one special administrative task. HTTP/3, a version of the protocol used for web communication, runs over QUIC, which uses UDP. QUIC supplies mechanisms beyond raw UDP, including reliable streams. These examples show why 'DNS equals UDP' and 'the web equals TCP' are incomplete rules. In a troubleshooting report, identify the actual protocol version and configuration. If that information is unavailable, label the application identity as unconfirmed. These are paper comparisons in this lesson: the two VPCS nodes are not DNS, QUIC or web servers.
- DNS implementations need TCP support as well as UDP behavior.
- HTTP/3 is a counterexample to the claim that every web exchange uses TCP.
- The isolated VPCS exercise does not simulate these full application protocols.
Read transport and port evidence without overclaiming
A network port number is a field, not a physical connector. Port registrations provide useful conventions, but a service can run on a different number and arbitrary traffic can use a familiar one. For one direction of a conversation, record the source IP, destination IP, transport, source port and destination port. Together these form a useful five-part identifier, often called a five-tuple. Check packet contents and application context before assigning a service name. In this lab, port 80 is a selected TCP probe destination and port 5000 is a selected UDP probe destination; neither selection starts a server. In Wireshark, select a packet and expand the transport details to record the actual values rather than guessing a source port.
- Read transport and both endpoint addresses before interpreting ports.
- Distinguish an observed value from a chosen test parameter.
- Do not infer application identity from a registered number alone.
A small lab with an explicit stopping point
Build only PC1, Switch1 and PC2. The PCs use addresses in the same local subnet and therefore exchange local traffic through the switch; there is no routing step. VPCS is intentionally limited and its network stack is not a complete substitute for a real operating system. Use its local help to check which probe options your installed version supports. If the required options are absent, stop the transport-probe part and use the clearly labeled paper comparison, rather than inventing console results. Keep a baseline note with the address plan, cable endpoints, installed VPCS version and what was actually observed. Stop if the ordinary ICMP baseline is not working. That prevents an unrelated setup problem from contaminating the transport comparison.
- Only the three named nodes and two named cables are active.
- A switch does not require an IOS console for this built-in GNS3 setup.
- Expected results are instructions for your experiment, not claims that QCS executed your local lab.
Real-world walkthrough
A classroom page fails although ping replies
A hypothetical training room reports that a classroom page will not open. One learner has a ping reply and concludes that the application must be fine. Another sees a missing response to a probe and wants to replace the router. Both conclusions go beyond the evidence. Before making changes, the operator separates local reachability, the actual service transport and the requested application result. This is a conceptual scenario, not an additional server installed in the lab.
- Record the affected client, requested service and time. Ask which protocol version and service address are intended rather than assuming a port from the application name.
- Record ping as an ICMP observation only. In real networks, missed replies can reflect filtering, rate limits, host behavior or link problems; they do not isolate one fault.
- Capture only authorized test traffic at a known observation point. Check direction, addresses, transport and ports; avoid collecting unrelated users' data.
- Check whether the actual service is listening and whether its application request succeeds using its own approved diagnostic method. A synthetic probe cannot substitute for that transaction.
- Compare observations with the known working baseline. Change one authorized setting only after the evidence supports it, then repeat the same application check and record the outcome.
Guided GNS3 lab
Inspect ICMP, TCP and UDP probes on one isolated link
Build a local two-endpoint path, establish an ICMP baseline and identify synthetic TCP and UDP probes in a capture without claiming a full application session or performance result.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| PC1 | Ethernet0 | 192.168.7.10/24 | Source for probes; distinct from PC2. |
| PC2 | Ethernet0 | 192.168.7.20/24 | Destination on the same local subnet. |
| Switch1 | Ethernet0 and Ethernet1 | No IP address required | Joins the two local Ethernet links. |
Set up the lab
- Create a new GNS3 project named Day7-Transport. Use a working local or GNS3 VM server configured for your installation.
- Drag two VPCS nodes from End devices and one built-in Ethernet switch from Switches. Rename them PC1, PC2 and Switch1.
- Connect exactly the interfaces in the topology and start both PCs. Keep the switch's connected ports on default access VLAN 1.
- Do not add Cloud, NAT, Internet or physical adapters. All probes must remain inside this disconnected lab.
- Open a text editor for notes: Notepad on Windows, TextEdit in plain-text mode on macOS, or a plain-text editor on Linux. Create Day7-baseline.txt.
- Confirm Wireshark is installed and configured in GNS3 before starting. If capture integration fails, fix that prerequisite before claiming any packet observations.
Configure PC1
Right-click PC1 and choose Console before typing. Confirm a PC1> or VPCS> prompt, then enter each command separately; do not type the prompt itself. Record the returned address and mask in Day7-baseline.txt.
ip 192.168.7.10/24
show ipWhat each command means
ip 192.168.7.10/24- Assign PC1 the address 192.168.7.10 and the supplied /24 local prefix. No gateway is needed for this same-subnet exercise.
show ip- Display PC1's actual address settings so you can compare them with the plan; this command does not send a connectivity test.
- What you should see
- PC1 displays 192.168.7.10 with mask 255.255.255.0. Stop and correct any different address before proceeding.
- Why this step matters
- Recording the real configuration prevents an address typo from being misdiagnosed as a TCP or UDP property.
Configure PC2
Right-click PC2 and choose Console before typing. Check that this is PC2, not the already configured PC1 console. Enter the commands separately and add the actual result to your notes.
ip 192.168.7.20/24
show ipWhat each command means
ip 192.168.7.20/24- Assign PC2 its own address, 192.168.7.20, with the same /24 prefix as PC1; do not reuse PC1's address.
show ip- Display PC2's actual settings and confirm that it is the intended remote destination.
- What you should see
- PC2 displays 192.168.7.20 with mask 255.255.255.0, distinct from PC1's address.
- Why this step matters
- Two unique local addresses are required; pinging yourself would not test the other cable or endpoint.
Check installed probe help
Right-click PC1 and choose Console before typing. Read the local ping help and record the VPCS version from the console banner. Confirm that -2 selects UDP, -3 selects TCP, -p sets the destination port, -f sets TCP flags and -c limits the count. If any option differs or is absent, stop those probe steps and use the paper comparison instead.
ping ?What each command means
ping ?- Show this VPCS installation's ping options; this is local help, not a packet sent to the other endpoint.
- What you should see
- The installed help identifies the required probe options. Unsupported options are a version or prerequisite issue, not a failed transport test.
- Why this step matters
- Checking the local implementation avoids treating a simulator as a complete application host or relying on unsupported commands.
Establish the local baseline
Right-click PC1 and choose Console before typing. Send three ordinary ping requests to PC2's address, not PC1's own address. If an initial request times out, repeat the same bounded test; persistent loss must be resolved before capture comparison.
ping 192.168.7.20 -c 3What each command means
ping 192.168.7.20 -c 3- Send three ICMP echo requests from PC1 to PC2 at 192.168.7.20; -c 3 bounds the count and does not select TCP or UDP.
- What you should see
- The repeated baseline receives echo replies from PC2. Record actual output rather than copying an expected transcript.
- Why this step matters
- A working ICMP baseline supports basic local reachability, but does not prove that a TCP or UDP application is listening.
Start the link capture
In the GNS3 workspace, right-click the PC1-to-Switch1 cable and select Start capture, then accept the offered Ethernet link capture and open it in Wireshark. Use the display-filter bar above the packet list to enter tcp || udp || icmp and apply it. This is a Wireshark filter, not a VPCS command.
- What you should see
- Wireshark is recording the selected virtual link. The filter may initially display no packets because no new relevant traffic has been sent yet.
- Why this step matters
- An empty filtered view before a probe is not evidence of a fault. The capture point and filter determine what you can observe.
Send a bounded UDP probe
Right-click PC1 and choose Console before typing. Send three UDP probes to PC2 on destination port 5000. Return to Wireshark and select an outgoing UDP packet, then expand its IP and UDP details. Record both addresses and the observed ports.
ping 192.168.7.20 -2 -p 5000 -c 3What each command means
ping 192.168.7.20 -2 -p 5000 -c 3- VPCS -2 selects a synthetic UDP probe, -p 5000 chooses the destination port, and -c 3 limits the count. It does not start a service on PC2.
- What you should see
- The capture should contain outbound UDP probes to 192.168.7.20 and destination port 5000. PC2 may return an ICMP error or no useful response; no application listener was installed.
- Why this step matters
- The outbound header establishes which transport was sent. A timeout or error does not establish application health or UDP delivery guarantees.
Send a bounded TCP probe
Right-click PC1 and choose Console before typing. Send three SYN probes to PC2 on destination port 80. Return to Wireshark, select an outgoing TCP packet and expand TCP Flags. Record the SYN flag and the destination port, keeping any response as a separate observation.
ping 192.168.7.20 -3 -f S -p 80 -c 3What each command means
ping 192.168.7.20 -3 -f S -p 80 -c 3- VPCS -3 selects TCP, -f S selects SYN, -p 80 chooses the destination port, and -c 3 limits the probe count. This is not a browser request or complete TCP session.
- What you should see
- The capture should contain outbound TCP SYN probes to 192.168.7.20 port 80. A reset, error or timeout is possible because no TCP service was installed; do not claim a completed handshake.
- Why this step matters
- A chosen port and visible SYN are limited evidence. They do not prove that HTTP, a three-way handshake or reliable application delivery occurred.
Compare one packet of each kind
In Wireshark, keep the same display filter and compare one UDP packet with one TCP SYN. In Day7-baseline.txt, write the addresses, transport, ports and visible flags. If ICMP errors are shown, select them separately; do not label an ICMP error as a UDP acknowledgment.
- What you should see
- Your table contains only observed values. TCP has its SYN flag in this test; UDP has no TCP flag field. Any ICMP response is labeled as a different protocol.
- Why this step matters
- Separating packets by protocol prevents a generic reply or error message from being mistaken for application success.
Check the reverse baseline
Right-click PC2 and choose Console before typing. Use PC1's address as the remote destination and record the result. This is a separate ICMP check, not a measurement of TCP or UDP throughput.
ping 192.168.7.10 -c 3What each command means
ping 192.168.7.10 -c 3- Send three ICMP echo requests from PC2 to PC1 at 192.168.7.10; do not use PC2's own .20 address.
- What you should see
- PC1 returns echo replies when the baseline path and settings are intact. Investigate persistent loss rather than declaring one transport broken.
- Why this step matters
- A reverse check confirms the intended remote endpoint and makes accidental self-tests easier to detect.
Save observations and stop
In Wireshark, stop recording and save the capture as Day7-probes.pcapng. In GNS3, stop the cable capture as well. Add an explicit note that no application server, complete TCP transfer or performance benchmark was run, then stop the isolated project.
- What you should see
- You have the address plan, observed probe table and a local capture, clearly separated from the hypothetical application examples.
- Why this step matters
- A reproducible evidence record is more useful than invented successful output and prevents the exercise being overinterpreted later.
Verify
- Confirm PC1 and PC2 have distinct addresses and both tests target the other endpoint, not themselves.
- Record ordinary ICMP replies separately from transport probes and application outcomes.
- Inspect an actual outgoing UDP header and TCP SYN header at the named capture point; do not invent values if capture failed.
- Confirm no router, firewall, application server or external network was added to the exercise.
- State explicitly that a visible transport probe does not demonstrate a completed session, delivery guarantee or real application performance.
Troubleshoot
- If a VPCS console will not open, start the named PC and check GNS3's console application setting. Switch1 is a built-in Ethernet switch and has no IOS console.
- If the ICMP baseline repeatedly fails, inspect both addresses, masks, cable endpoints and switch VLAN settings. Do not diagnose TCP or UDP before the baseline is established.
- If the installed ping help lacks a required flag, stop that probe exercise. Use the paper comparison and document the limitation instead of claiming the missing command ran.
- If Wireshark appears empty, confirm the selected cable, recording state and display filter, then generate a new bounded probe. A filter changes the displayed view, not whether a service is available.
- Do not treat a SYN reset, an ICMP port error or a timeout as a surprise success or definitive failure of an application: none was installed. In real networks, filtering, host state and rate limits can also affect replies.
- Keep troubleshooting inside the isolated project. Never bridge it to a real network to make the example work or capture unrelated people's traffic.
This lab uses built-in VPCS and Ethernet switch nodes; no Cisco image is needed. GNS3 does not provide Cisco images. Use Cisco images only when the applicable license permits that use; do not share or redistribute image files. Cisco Modeling Labs is the official Cisco alternative.
- Stop the Wireshark recording and the GNS3 link capture, then stop all nodes in the isolated project.
- Keep the address plan and observations with the capture; do not publish unrelated captured data.
- Keep all external connections absent. If reusing the project, verify the same baseline before the next exercise and re-enter VPCS addresses if they were not saved.
Practice set
Answer before you reveal
01Why does the PC1-to-PC2 path not need a router in this lab?
The local exchange uses the two shown Ethernet links. Introducing an unseen router into the explanation would contradict the actual topology and send the learner to the wrong place for evidence.
02What useful fact does the outgoing TCP SYN prove, and what does it not prove?
The lab does not install a listener on PC2. Read the outgoing fields and any response separately, and retain uncertainty about the application instead of claiming a successful transaction.
03Why is 'UDP is always faster' an unsafe general conclusion?
This exercise does not run an application benchmark. A fair comparison needs a workload, metrics and the full protocol behavior, including any mechanisms the application adds above UDP.
04Can an application using UDP add reliability above it?
HTTP/3 over QUIC is a useful counterexample to simple slogans. Do not use the presence of a UDP header to conclude that every higher-level exchange lacks reliable delivery mechanisms.
05What should you do if a required VPCS probe option is missing?
Unsupported commands do not establish a network failure. Do not make up expected output or change the topology to a real network just to force a demonstration.
06What is missing from the claim 'destination port 80 proves this is HTTP'?
A number is a useful convention but not an identity guarantee. This lab deliberately sends a synthetic probe to port 80 without running a web server, making that distinction visible.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Choose and test transport behavior in the context of the actual application.
- TCP provides ordered bytes and recovery mechanisms, not an unconditional promise of application success.
- UDP datagrams do not include built-in ordered delivery, but higher protocols can add their own mechanisms.
- Record addresses, protocol and ports rather than naming an application from its port alone.
- A synthetic probe, ICMP reply and successful application transaction are different observations.
- Keep the lab isolated and clearly label conceptual examples and unmeasured properties.