CCNA Bgp Questions

Local Preference is a well-known discretionary attribute evaluated during inbound processing, so an import policy bound to the eBGP neighbour or group modifies it before best-path selection. Export policy would affect the peer's decision, not the local router's.

eBGP sessions form between routers whose peers sit in different Autonomous Systems, with the AS number in the OPEN message differing. This contrasts with iBGP, where both peers belong to the same AS, satisfying the characteristic being tested.

The Router ID is carried in the BGP OPEN message, allowing peers to identify each other during session establishment. This satisfies the negotiation-phase constraint: each speaker advertises its Router ID before the session reaches Established, so both peers learn the other's identifier as part of capability exchange rather than through later UPDATE messages.

The NOTIFICATION message carries error codes and subcodes, and its receipt causes the peer to tear down the BGP session. Unlike OPEN, UPDATE or KEEPALIVE, it is the message type explicitly used to signal an error condition and terminate the adjacency.

Applying an import policy at the group level affects all neighbors in that group. The policy can match routes and set the next-hop attribute. This is the correct approach because it ensures consistency and reduces configuration redundancy. The next-hop is set before the route is installed in the routing table, influencing BGP path selection.

BGP Keepalive messages sustain established peering sessions by confirming the peer remains reachable, resetting the Hold Timer before it expires. Junos defaults to a 30-second Keepalive interval, with a 90-second Hold Timer, satisfying the stem's requirement for both the message's purpose and its default interval.

By default, iBGP enforces split horizon, meaning a route learned from an iBGP peer is not advertised to another iBGP peer. This prevents routing loops within the AS. To allow propagation, you must configure either a full mesh, route reflectors, or confederations.

The `as-path` match condition evaluates a route's AS_PATH attribute against a regular expression, directly satisfying the requirement to reject routes containing a specific AS number. Junos applies this condition within a policy term, so any path whose AS sequence matches the expression is filtered before advertisement or installation.

The Open message carries the version, my autonomous system number, hold time and BGP identifier, letting both peers agree on session parameters before any routing data flows. It is the first message exchanged after the TCP three-way handshake, directly satisfying the stem's requirement for negotiating session parameters during establishment.

KEEPALIVE messages carry only the 19-byte BGP header with no path attributes, and their sole function is refreshing the hold timer to confirm the peer session remains active. This satisfies the requirement for a message type that maintains session state without transporting routing information.

eBGP peers using loopback addresses are not on the same subnet, so the default TTL of 1 causes the TCP connection to fail. The session remains in Active state because the router cannot establish a TCP session to a non-directly connected peer. Configuring multihop with an appropriate TTL allows the BGP session to be established over multiple hops.

BGP ORIGIN codes are IGP, EGP and Incomplete. Incomplete signals the prefix was not learned natively via a BGP network statement but injected through redistribution from a static route or IGP, so its path origin cannot be fully verified.

The Active state means the router has sent a TCP connection request to the peer but has not received a response, so it keeps retrying. The session is not established; the router is actively attempting to open TCP port 179, which distinguishes it from Idle or Connect states.

The route reflector adds ORIGINATOR_ID, carrying the originating client's router ID, and CLUSTER_LIST, recording the reflection path. A client receiving a route containing its own router ID or cluster ID detects the loop and discards it.

UPDATE messages carry Network Layer Reachability Information (NLRI) for advertised routes and path attributes, as well as withdrawn routes. They are the primary messages for exchanging routing information. This is a correct description of the UPDATE message's purpose.

BGP peers establish sessions over TCP port 179, using it for the initial three-way handshake and all subsequent UPDATE, KEEPALIVE and NOTIFICATION messages. This satisfies the stem's requirement, distinguishing BGP from protocols such as RIP that operate over UDP.

Import policies applied at the BGP neighbour or group level modify attributes of routes received from that peer before they enter the routing table. Configuring 'import' under protocols bgp group neighbour therefore satisfies the requirement to alter Local Preference for all routes from the specific external peer.

The OPEN message initiates the BGP session after TCP establishment, carrying the version, local AS number, hold time, router ID, and optional capability parameters. This negotiation satisfies the stem's requirement by exchanging ASNs and timers before any UPDATE messages flow.

A Notification message signals an unrecoverable error, so the receiving speaker tears down the underlying TCP connection carrying the session. This satisfies the scenario's requirement that the TCP connection associated with the BGP session is closed.

AS_TRANS (AS 23456) is a reserved 2-byte placeholder defined in RFC 6793, allowing a 4-byte-ASN speaker to present a compatible 2-byte value to a legacy peer. The real 4-byte ASN travels in the AS4_PATH attribute, so the constraint of 2-byte-only remote support is satisfied without losing path information.

Well-known mandatory attributes, such as AS_PATH and NEXT_HOP, must be understood by every BGP speaker and carried in each Update advertising a route. This universal recognition and mandatory inclusion is precisely what distinguishes them from optional or discretionary attributes.

BFD provides sub-second failure detection by sending rapid, lightweight hello packets independently of routing protocols, then signalling BGP immediately when a session degrades. This satisfies the stem's sub-second failover constraint, since BGP's own keepalive timers (seconds to minutes) are far too slow to detect link degradation promptly.

AS path prepending increases the length of the AS path attribute. BGP prefers shorter AS paths, so a longer path is less likely to be selected by remote routers. This is a common technique to influence inbound traffic by making a particular path appear less attractive.

`show bgp neighbor 10.1.1.1` queries the BGP neighbour session directly, displaying its state and the received prefix count for that specific peer. This satisfies the stem's requirement to inspect state and verify received prefixes from one neighbour on the MX Series, unlike summary or route-table commands that lack per-neighbour detail.

`show route forwarding-table protocol bgp` queries the FIB itself, filtering to BGP-derived entries, so it directly satisfies the requirement to verify which BGP routes are actually installed for forwarding. The alternative `show route protocol bgp` reads only the routing table (RIB), which may hold BGP routes that never reached the FIB.

BGP treats a malformed path attribute as a fatal error under RFC 4271. The receiving speaker must send a NOTIFICATION with the appropriate error code and subcode, then tear down the peering session rather than silently discard the UPDATE or retain the route.

BGP communities are optional transitive path attributes, so a router that does not recognise them still propagates them to peers. This satisfies the stem's requirement for a true statement about Junos BGP communities, as Junos stores and matches them without stripping the attribute.

The 'next policy' action halts evaluation of the current policy immediately, so no further terms within it are assessed. The route then passes to the next policy in the chain, satisfying the stem's requirement for this terminating behaviour rather than accepting or rejecting the route.

NEXT_HOP carries attribute type code 3 and holds an IP address, exactly matching the observed BGP update. As a well-known mandatory attribute, it specifies the next-hop IP for the advertised prefix, satisfying the stem's requirement to identify the attribute by its type code and IP-address value.

AS_PATH is a well-known mandatory attribute, meaning every BGP update carrying reachable NLRI must include it, and all BGP implementations must recognise and process it. This mandatory classification distinguishes it from optional or discretionary attributes.

MD5 authentication is configured at the BGP group level under protocols bgp, using the authentication-key statement, which applies the TCP MD5 signature to every session in that group. This prevents spoofed TCP segments from establishing or hijacking the peering.

The show bgp neighbor command displays per-peer session details, including the negotiated hold time and keepalive interval exchanged with the eBGP peer. This directly satisfies the requirement to verify the exact timers actually agreed, rather than configured values.

AS4_PATH is an optional transitive attribute, carrying 4-byte AS path information when older 2-byte speakers are involved, satisfying the "optional transitive" classification. Its transitive nature ensures it propagates across autonomous systems that lack native 4-byte AS support, unlike well-known mandatory attributes such as AS_PATH, which every BGP speaker must recognise and include.

BGP Graceful Restart preserves forwarding state during a routing daemon restart by having the helper router retain previously learned routes, avoiding traffic loss. The restarting router's peers keep the TCP session alive, satisfying the requirement to restart BGP without dropping the underlying session or disrupting forwarding.