Computer networks viva questions are rarely testing definitions alone. A good answer explains what happens, why it happens, what evidence you would collect, and which trade-off or limitation matters.
Because computer science viva formats differ between universities and courses, check your department’s official guidance for the assessed format, timing and marking criteria. The method below is designed for oral assessment generally: answer clearly under interruption, reason from first principles, and connect protocol behaviour to observable symptoms.
What a computer networks viva answer needs to do
A strong oral answer usually has four parts:
- Define the mechanism. State what the protocol, algorithm or device does.
- Walk through the sequence. Explain the important messages or decisions in order.
- Apply it to a case. Use a small example, packet flow, address range or failure.
- State a limitation or trade-off. Explain when the mechanism is unsuitable or what it costs.
For example, if asked why TCP is reliable, do not stop at “it uses acknowledgements”. Explain sequence numbers, cumulative acknowledgements, retransmission timers, the sliding window and congestion control. Then distinguish reliability from encryption: TCP can deliver bytes reliably, but it does not by itself provide confidentiality or authentication.
Keep a consistent answer shape. Start with the direct answer, then give the sequence, then the qualification. This prevents a technically correct response from becoming an unstructured list of terms.
A practical marking lens
For practice, assess each answer against four areas:
- technical accuracy;
- ordered reasoning;
- use of a relevant example;
- awareness of trade-offs and failure modes.
These are useful preparation criteria, not claims about how a particular university will mark its viva. If you are unsure of a detail, say what you know, identify the uncertainty, and explain how you would verify it. Do not fill silence with an invented protocol rule.
An examiner-style persona for a computer networks board can keep these expectations visible while you practise:
Build stations from the topics you actually studied
Do not prepare a single page of definitions. Build stations that require a decision or explanation. A useful set covers transport, addressing, name resolution, routing and network design.
The opening question should be broad enough to expose your reasoning, followed by likely probes. For example:
- “Explain how a TCP connection is established.”
- What do the sequence and acknowledgement numbers represent?
- What does the third packet confirm?
- What happens if the SYN is lost?
- “Divide 192.168.10.0/24 into four equal subnets.”
- What prefix results?
- Which addresses are network and broadcast addresses?
- What changes if the links need different numbers of hosts?
- “A user can reach an IP address but not a hostname. Diagnose it.”
- Which DNS messages would you expect?
- Which caches could be involved?
- How would you distinguish DNS failure from a routing failure?
The stations below show how to turn those prompts into spoken practice. The attempts and scores are deliberately mixed: the point is to identify what to repair, not to display a perfect record.
Before recording an answer, take a short pause and outline the order in your head. Say “I will explain the normal sequence first, then the failure case” if that helps the examiner follow you. Avoid beginning with every related protocol. Relevance is part of oral performance.
Station 1: TCP connection and reliable delivery
This station tests whether you can separate connection establishment from reliable byte-stream delivery. It also tests whether you can describe a packet exchange rather than recite “SYN, SYN-ACK, ACK”.
Examiner
Explain the TCP three-way handshake and how TCP provides reliable delivery after the connection is established.
You correctly described SYN, SYN-ACK and the final ACK, and you linked acknowledgements to sequence numbers.
ImproveState that the handshake synchronises each endpoint's initial sequence number and confirms bidirectional reachability.
The normal exchange was in order, but reliability mechanisms were introduced before the handshake had been closed.
ImproveUse a clear sequence: handshake, byte numbering, acknowledgements, retransmission and congestion control.
You used a lost-segment example, but did not show what the receiver acknowledges when a segment arrives out of order.
ImproveExplain that duplicate cumulative ACKs can signal a missing earlier segment, contributing to fast retransmit.
You mentioned retransmission delay but did not distinguish congestion control from reliability.
ImproveAdd that retransmission repairs loss, while congestion control limits sending to avoid worsening congestion; neither encrypts the payload.
A strong answerThe client sends a SYN containing its initial sequence number, and the server replies with a SYN-ACK containing its own initial sequence number and an acknowledgement of the client’s SYN. The client sends an ACK, so both sides have confirmed the initial sequence numbers and the connection is established. TCP then numbers bytes, acknowledges received data and retransmits data when an acknowledgement does not arrive within the retransmission timeout; duplicate cumulative ACKs can also support fast retransmit. Its congestion-control algorithms adjust the sending rate, but TCP itself does not provide encryption or peer authentication; TLS is used above it for those properties.
The common weak answer is not wholly wrong; it is incomplete. “TCP sends packets again if they are lost” omits how the sender knows which data arrived, how the receiver represents progress, and why sending faster can make congestion worse.
Practise the answer with one deliberate variation: the SYN-ACK is lost. The client retransmits its SYN after a timeout, and the server may retransmit its SYN-ACK or create no lasting connection state, depending on where the exchange stopped. The important point is that the handshake is not complete until the final acknowledgement has been received by the server.
Station 2: subnetting and address reasoning
Subnetting questions reward precise arithmetic and clear labelling. State the borrowed bits, the resulting prefix, the block size and the usable host range. Do not jump straight to a list of addresses without explaining how you obtained it.
Examiner
Divide 192.168.10.0/24 into four equal subnets. Give the prefix, network address, usable host range and broadcast address for each subnet.
You correctly borrowed two host bits, producing /26 subnets with 64 addresses each and 62 usable host addresses.
ImproveExplicitly state that the all-zero and all-one host values are reserved as network and broadcast addresses in each ordinary subnet.
You derived /26 before listing the four blocks in increments of 64.
ImproveKeep the same sequence in future answers: prefix, block size, then ranges.
You listed the ranges but did not show where a default gateway could sit.
ImproveGive one example, such as 192.168.10.1 as a possible gateway in the first subnet, while noting that the assignment is a design choice.
You noted that equal subnets can waste addresses when departments have different sizes.
ImproveMention VLSM as the alternative when unequal subnet sizes are needed, provided the allocated ranges do not overlap.
A strong answerFour equal subnets require two more subnet bits, so the /24 becomes /26. A /26 has 64 addresses per block and 62 usable host addresses when the network and broadcast addresses are excluded. The four ranges are 192.168.10.0/26, with usable hosts .1 to .62 and broadcast .63; 192.168.10.64/26, with usable hosts .65 to .126 and broadcast .127; 192.168.10.128/26, with usable hosts .129 to .190 and broadcast .191; and 192.168.10.192/26, with usable hosts .193 to .254 and broadcast .255. Equal-size subnetting is simple, while VLSM can use addresses more efficiently for unequal requirements.
A useful follow-up is to ask what changes if one department needs 100 hosts and two others need 40 hosts each. Four /26 networks cannot provide 100 usable addresses in one block. You would need a larger allocation or a variable-length design such as a /25 for at least 126 usable hosts, plus appropriately sized non-overlapping ranges for the other networks. In a real design, also account for growth, infrastructure addresses and the organisation’s addressing policy.
Say the slash notation aloud: “twenty-four” or “twenty-six”, not just “slash”. Examiners can then hear whether you are treating the prefix as a number of network bits rather than as a vague label.
Station 3: diagnosing DNS failure
Troubleshooting stations test whether you can use evidence to narrow the fault. Do not restart services immediately or name ten possible causes without prioritising them. Establish what works, then test the next dependency.
Examiner
A client can reach 203.0.113.20 but cannot reach the service by hostname. Talk through your diagnosis, including the DNS queries and caches you would check.
You correctly separated IP connectivity from name resolution and identified the configured recursive resolver as an early check.
ImproveDistinguish a recursive query from iterative referral behaviour and mention that the answer may come from a cache rather than the authoritative server.
You tested the hostname locally, then compared another client, but the decision points were not always explicit.
ImproveState what each result would imply: local cache or configuration, resolver issue, authoritative issue, or record problem.
You named nslookup but did not specify records or expected observations.
ImproveQuery the A and AAAA records, inspect the response status and TTL, and compare the configured resolver with a known permitted resolver.
You mentioned stale records but not split-horizon DNS or an AAAA record leading clients down a failing IPv6 path.
ImproveInclude split-horizon answers and compare A and AAAA results before changing records.
A strong answerFirst I would confirm that the failure is name resolution rather than application or transport failure by testing the IP address and then querying the hostname with a diagnostic tool. I would inspect the client’s resolver configuration, query the A and AAAA records, and check the response status, returned address and TTL. If the local resolver fails but another client works, I would check the client cache and configuration; if many clients fail, I would test the recursive resolver and then the authoritative DNS path. I would also consider stale or incorrect records, split-horizon DNS and an AAAA record that sends clients towards an unavailable IPv6 service. I would use packet capture or resolver logs only after forming a hypothesis, and would avoid changing records until the evidence identifies the fault.
The key distinction is between “the hostname does not resolve” and “the application does not work”. A DNS lookup might return an address successfully while the service is down, blocked by a firewall, listening on a different port or serving the wrong virtual host. Conversely, a successful ping does not prove that the application path is healthy.
Use conditional language precisely: “If every client receives SERVFAIL, I would investigate the resolver or its upstream path; if only one client fails, I would investigate its configuration and cache first.” This sounds more competent than claiming that one command always identifies the cause.
Practise the words that lose marks
Recording yourself is useful only if you review the exact sentence where the reasoning becomes vague. A strong transcript review marks missing detail, not every hesitation. Look for unsupported words such as “the network knows”, “the server checks it” or “DNS sends it to the right place”. Replace them with the component, message and decision involved.
I would check whether the hostname resolves and then see if the server is available. DNS sends the request to the right server. If that does not work, I would check the network. I would compare the result from the client’s configured recursive resolver with the authoritative answer and inspect the A and AAAA records.
DNS sends the request to the right server.
This hides the distinction between a stub resolver, a recursive resolver and an authoritative server, and it does not say whether the query is answered from cache or by referral and recursion.
Say: The client’s stub resolver sends a recursive query to its configured recursive resolver; that resolver may answer from cache or obtain the answer through the DNS hierarchy from an authoritative server.Build a personal list of replacements:
- “It finds the route” becomes “the router performs a longest-prefix match in its forwarding table”.
- “TCP checks the packet” becomes “the receiver checks the sequence space and acknowledges the highest contiguous byte range received”.
- “The subnet has 64 hosts” becomes “the /26 has 64 addresses, of which 62 are normally usable for hosts after excluding network and broadcast addresses”.
The aim is not to sound complicated. It is to make each claim testable.
A short debrief after every station
After each answer, record three items:
- One fact you stated correctly. This prevents you from rewriting the whole answer unnecessarily.
- One missing mark. Choose a specific omission, such as AAAA records, duplicate ACKs or the broadcast address.
- One sentence to insert next time. Practise that sentence aloud immediately.
You can also listen back at normal speed and ask whether the first sentence answered the question. If it did not, rewrite the opening. For example: “TCP establishes shared sequence-number state with a three-way handshake; reliability after that comes from numbered bytes, acknowledgements and retransmission.”
An examiner-style spoken debrief should be short and actionable:
You separated DNS resolution from application availability correctly; next time, name the A and AAAA queries before you move to packet capture.
How to practise this week
Use three sessions rather than one long revision block:
- Session one, 25 minutes: answer the TCP station twice. On the second attempt, include the lost-SYN case and distinguish reliability, congestion control and encryption.
- Session two, 25 minutes: solve the /24 subnetting station without notes, then alter the host requirement and explain why equal subnets may no longer fit.
- Session three, 30 minutes: diagnose the DNS station using conditional statements. Review the transcript and repair only the two most costly omissions.
On the next cycle, shuffle the order. If you always answer TCP first, you may be relying on warm-up rather than transferable reasoning. Add follow-up questions that change one fact at a time: IPv6 instead of IPv4, UDP instead of TCP, a cached DNS answer instead of an authoritative response, or unequal subnet sizes instead of equal ones.
How MySummaries helps
MySummaries can turn your computer networks notes into a board, create oral stations from sections such as TCP, subnetting and DNS, record your spoken answers, and return criteria-based feedback on technical accuracy, structure, examples and failure modes. You can review the transcript, save missed points for later practice, and listen to an examiner-voice lecture built from your own material at portal.mysummaries.app.