Network Security Interview Questions

Weight is the first attribute evaluated in the Cisco BGP best-path selection process. It is a Cisco-proprietary, router-local value (not advertised to neighbors) that defaults to 0 for learned routes and 32768 for locally originated routes, so it takes precedence over Local Preference, AS_PATH length, and MED.

When an SD-WAN WAN path degrades, the edge follows a strict sequence: detect the SLA breach (latency, loss, or jitter), mark the path as unavailable, recompute the next-best eligible path per forwarding policy, then redirect traffic to the alternate link. Detection must precede the health-status change, which must precede re-computation and the actual traffic redirect.

SD-WAN traffic steering follows a fixed pipeline for each flow: classify the application, match it against forwarding policy, evaluate the real-time SLA metrics of candidate WAN paths, select the best-eligible path, and then forward packets over the chosen overlay tunnel. Each step depends on the prior step's output, so the order is strictly sequential.

During SD-WAN zero-touch provisioning, a new edge device boots and obtains IP/DNS via DHCP, contacts the ZTP server or orchestrator URL, authenticates using its serial number or certificate, downloads its full configuration and forwarding policy, then establishes IPsec overlay tunnels to peer edges and begins forwarding traffic. Each stage depends on the previous one completing successfully.

Design summary: We run a single DHCP server (with a secondary as backup) on the office /24 subnet. When a client first connects, it broadcasts a DHCPDISCOVER to find a server. The server responds with a DHCPOFFER proposing an IP address, lease duration, and gateway/DNS options. The client replies with a DHCPREQUEST, confirming it wants that offered address (and implicitly declining other offers). The server finalizes with a DHCPACK, and the client configures its interface.

Lease duration: I recommend 8 hours. The office has moderate device churn (laptops, guest phones) but not enough to justify very short leases. Eight hours means a disconnected device's address is reclaimable within a workday, while renewal traffic stays negligible — a client renews only once every 4 hours at T1.

Renewal: At 50% of the lease (T1 = 4 hours), the client unicasts a DHCPREQUEST to the server that originally granted the lease. If that server acknowledges, the lease is extended and the timer resets. If the server is unreachable at T1, the client waits until T2 (87.5% ≈ 7 hours) and then broadcasts a DHCPREQUEST to reach any available DHCP server. If no server responds before the lease expires, the client must stop using the address and start a fresh DHCPDISCOVER.

Release: When a device shuts down gracefully or disconnects, it sends a DHCPRELEASE (unicast to the original server). The server immediately marks the address as available in the pool. If a device disappears without releasing, the address is reclaimed automatically when the lease expires.

Design summary: A single central DHCP server (with a failover peer) serves all three building subnets. Each building's router is configured as a DHCP relay agent so it can forward broadcast DHCPDISCOVER messages from local clients to the central server as unicast, and relay responses back.

Relay mechanism: When a client in Building B broadcasts a DHCPDISCOVER, the local router intercepts it (because it is the default gateway and a configured relay agent). The router places its own interface IP — 192.168.20.1 — in the giaddr field of the relayed message and unicasts it to the central DHCP server. The server reads giaddr, determines the requesting subnet is 192.168.20.0/24, and selects an address from Building B's pool. The offer/ack are relayed back through the router to the client. The same applies for Buildings A and C.

Address pool allocation (per building): I would reserve the bottom of each /24 for infrastructure devices and the top for the dynamic pool. For example, in Building A (192.168.10.0/24): reserve 192.168.10.1–192.168.10.50 for the gateway, switches, APs, printers, and servers; allocate 192.168.10.100–192.168.10.200 as the dynamic pool for end-user devices; leave 192.168.10.201–192.168.10.254 as a growth buffer. Apply the same pattern to Buildings B and C.

Lease duration: I recommend 12 hours. With ~150 devices per building and moderate daily turnover (staff arriving and leaving), 12 hours ensures addresses from departed devices are reclaimed within half a day, while renewal traffic is minimal — each client renews once at T1 (6 hours) during a typical work session.

True. A transit relationship means one network carries traffic between two other networks, typically for payment. The transit provider advertises routes learned from one customer to others, providing end-to-end reachability that a direct peering link would not.

False. Settlement-free peering generally limits each network to exchanging traffic only between its own customers. Neither peer is obligated to carry the other's traffic onward to third-party destinations — that broader reachability is what a transit relationship provides, usually for payment.

In a transit relationship, the provider advertises to its customer a full table of routes (the customer gets reachability to the whole internet through the provider), and the customer pays the provider for that service. In a settlement-free (peer) relationship, each party only advertises its own routes and its customers' routes to the other party—neither side carries the other's traffic to third-party destinations. So a peer will not forward traffic received from one peer to another peer; it only exchanges traffic that originates from or is destined for each network's own address space.

Weight is the first attribute evaluated in Cisco's BGP best-path selection process. It is a Cisco-proprietary, locally significant value (never advertised to neighbors), so the route with the highest Weight is always preferred before Local Preference, AS_PATH length, Origin, or MED are even considered.

The ISP will install the content network's prefixes learned over the settlement-free peering link as the preferred path (e.g., via local-pref), so traffic destined for that content network is sent directly over the peering interconnect instead of through the paid transit link. Because that traffic no longer traverses the transit provider's network, the ISP avoids the per-Mbps or 95th-percentile billing for that volume on its transit port, reducing overall transit costs.

Route A is selected as best. In BGP path selection, Weight is checked first (both are 0 here), then LOCAL_PREF. Since Route A's LOCAL_PREF of 200 exceeds Route B's 100, the decision is made at that step and the shorter AS_PATH on Route B is never evaluated.

A Tier 1 network is a large provider-level network that can reach every other network on the internet without purchasing IP transit from any other provider. Being 'transit-free' means the network does not pay any upstream for reachability; instead it maintains settlement-free peering relationships with all other Tier 1 networks, and together the set of Tier 1 peers forms the default-free zone (DFZ) of the internet routing table.

Each peer advertises only its own (and its customers') prefixes to the other peer — not the full global routing table or routes learned from other peers or upstream transit providers. This enforces the valley-free routing (no-transit) principle: a peer must not carry traffic between two other networks as a transit hop, since it is not compensated for providing transit.

BGP prefers a lower value for MED, Router ID, and AS_PATH length. MED (lower wins), Router ID (lowest wins as a tiebreaker), and AS_PATH length (shorter wins) all favor smaller values. Weight and Local Preference, by contrast, prefer higher values — a higher weight or local preference is more preferred.

In SD-WAN architecture, the IPsec tunnels established between WAN edge routers create a virtual logical network known as the overlay, which is built on top of the physical underlay transports such as MPLS, broadband internet, and cellular links. This separation allows the control plane to manage path selection independently from the underlying physical media.

In peering (typically settlement-free), each party advertises only its own prefixes and those of its own customers to the other — it does not carry the peer's traffic onward to the rest of the Internet. In transit, the provider advertises a full Internet routing table to the customer and carries the customer's traffic to any destination, in exchange for payment. Peering exchanges reachability between two networks' customer cones; transit provides global reachability.

A route leak occurs when a network advertises routes learned from one provider or peer to a different provider or peer — effectively offering to carry traffic it has no business carrying. It violates the valley-free routing principle, which states that traffic may traverse customer→provider, provider→customer, or peer→peer links, but must never go 'down' to a provider and then back 'up' to another provider (forming a valley). Route leaks typically result from misconfigured BGP export (announcement) policies.

A ROA is a cryptographically signed record in the RPKI repository that binds a specific prefix (or sub-prefix range) to the authorized Origin AS and a maximum prefix length. During Route Origin Validation (ROV), a receiving router checks each BGP announcement's origin AS against the RPKI repository and classifies it as Valid (matches a ROA), Invalid (the origin AS is not authorized for that prefix), or NotFound (no ROA exists). Routers configured to reject Invalid announcements drop hijacked routes where an unauthorized AS originates a prefix it doesn't own, preventing the hijack from propagating. NotFound routes are still accepted because not all prefixes have ROAs yet.

In Cisco IOS BGP bestpath selection, the attributes evaluated before AS_PATH length are Weight, Local Preference, and the locally originated preference check. These occupy steps 1–3 of the decision process, while AS_PATH length is step 4. MED (step 6) and origin code (step 5) are both compared after AS_PATH length, not before.

Three statements are correct about Cisco IOS BGP bestpath selection: Weight is Cisco-proprietary and never advertised to peers; MED is compared only between paths from the same neighboring AS by default; and the lowest router ID tiebreaker (step 9) follows the oldest-route tiebreaker (step 8). The eBGP-over-iBGP preference is step 7—after AS_PATH length (step 4)—and Local Preference is not sent to eBGP peers by default.

In Cisco SD-WAN (Viptela-based), the control-plane protocol that runs between WAN Edge routers and vSmart controllers to exchange OMP routes, TLOCs, and IPsec keying material is called OMP. It is architecturally modeled on BGP and uses a similar path-attribute structure, but it is not BGP itself.

In the Cisco SD-WAN architecture, the vSmart is the centralized control-plane component that receives OMP updates from WAN Edge routers, applies centralized data policy, and redistributes routes across the overlay. The vBond (zero-touch provisioning orchestrator) authenticates and onboards new WAN Edge devices, directing each to its assigned control-plane controller. (Provide the component names, not the management UI.)

I would architect this in three layers: (1) the switching fabric providing L2/L3 access controls, (2) the DHCP service tier providing resilient lease assignment, and (3) the IPAM platform serving as the authoritative source of truth for all subnet allocations, reservations, and policy.

Rogue DHCP Prevention (IPv4 and IPv6): On every access switch, I enable DHCP snooping globally and mark only the uplink/trunk ports toward legitimate DHCP servers or relay agents as trusted. All end-user access ports are untrusted by default, so any DHCPOFFER or DHCPACK arriving on them is dropped. I apply per-port rate limiting (e.g., 15 pps) to untrusted ports to suppress DISCOVER floods. For IPv6, I deploy RA Guard on all access ports to drop unsolicited Router Advertisements from endpoints, and DHCPv6 Guard to ensure only the designated DHCPv6 relay or server can respond on trusted ports. Option 82 (relay agent information) is inserted by the snooping switch on the untrusted port's DISCOVER so the DHCP server records the physical ingress port and VLAN of every lease.

Starvation and Exhaustion Defense: DHCP snooping builds a binding table mapping MAC→IP→VLAN→port for every leased address. I enforce a per-port MAC limit (e.g., 5 MACs) so a single port cannot exhaust a pool by rotating source MACs. Dynamic ARP Inspection (DAI) is enabled on all user VLANs and bound to the snooping table, so any ARP reply whose IP/MAC/port tuple is not in the binding table is dropped — this prevents the natural follow-on attack (man-in-the-middle via ARP spoofing) after a starvation attempt. However, snooping MAC limits alone are insufficient against an attacker who randomizes the source MAC of the DHCPDISCOVER faster than the switch's learning window. To close this, I bind 802.1X port authentication to the DHCP process: the switch only forwards DHCPDISCOVER from a MAC that has successfully authenticated via RADIUS, and the NAC system provides the MAC-to-identity mapping. For devices that cannot do 802.1X (legacy IoT), I use MAC Authentication Bypass (MAB) with a whitelist and per-port rate limiting. At the IPAM level, I size each VLAN pool with a 20% reservation buffer, tier lease times (e.g., 8 hours for corporate devices, 1 hour for guest/IoT), and alert when pool utilization exceeds 80%.

HA and Failover Topology: Each site has two DHCP servers configured in DHCP failover (RFC 7384) load-balance mode, with the two servers geographically separated within the region (or one local, one at the regional hub for smaller sites). The failover pair maintains a replicated lease-state database and uses the MCLT (Maximum Client Lead Time) to control how long the surviving partner can extend a lease before the partner-down state is confirmed. In a split-brain scenario (both peers lose connectivity to each other but are still serving clients), the MCLT prevents either peer from re-assigning addresses that the other peer may have leased: each peer can only renew existing leases up to the MCLT boundary, and new address allocation from the peer's portion of the split scope is bounded. Only after the partner-down state is confirmed (via the failover protocol's heartbeat timeout, typically configurable) does the surviving peer take over the full scope. For multi-site redundancy, I also use anycast DHCP — the same DHCP relay address is advertised from multiple sites via the routing protocol, so DISCOVERs are routed to the nearest available server. The IPAM system is the authoritative source of truth for all subnet, reservation, and exclusion definitions, and it pushes configuration to all DHCP servers via API; the DHCP servers push lease events back to IPAM for reconciliation.

Secure DNS Integration: Every DHCP lease, release, or renewal triggers a dynamic DNS update. I use TSIG-signed DDNS between the DHCP servers and the DNS infrastructure, with per-zone update ACLs restricting updates to only the DHCP server's TSIG key. For Active Directory-integrated zones, GSS-TSIG (Kerberos-authenticated) updates are used so only domain-joined DHCP servers can update records. Unauthenticated DDNS is explicitly disabled — it would allow any endpoint to inject or overwrite DNS records, enabling cache poisoning via stale A/PTR records and facilitating man-in-the-middle attacks. DNS scavenging/aging is configured with a no-refresh + refresh period matching the DHCP lease time to automatically remove stale records when a device leaves the network without releasing its lease.

Audit and Device Attribution: All DHCP servers forward lease events (DISCOVER, OFFER, REQUEST, ACK, RELEASE, DECLINE, NAK) via syslog (RFC 5424) or IPFIX to a centralized SIEM. Each event includes the client MAC, assigned IP, lease duration, relay agent (Option 82 circuit ID / remote ID), and timestamp. To attribute a lease to a user or device identity, I correlate the DHCP event with 802.1X/RADIUS authentication session logs — the RADIUS accounting record contains the username, the authenticating MAC, the NAS port, and the session start/stop times, which I join to the DHCP binding table on MAC + port + time window. For IoT devices that bypass 802.1X via MAB, the NAC profile and device fingerprint (DHCP fingerprinting — the ordered list of requested DHCP options in parameter request list) provide attribution, and the MAB whitelist ties the MAC to an asset record in the CMDB. All logs are retained for a minimum of 365 days to meet compliance requirements.

In Cisco IOS BGP best-path selection, the 'prefer oldest route' tiebreaker applies exclusively to eBGP-learned routes. When both competing paths are iBGP-learned, this criterion is bypassed entirely, and selection falls through to the next tiebreaker: the route from the neighbor with the lowest Router ID. This design minimizes route-flap instability in eBGP while acknowledging that iBGP session age is a less meaningful stability signal.