Download Cisco.Pass4sure.400-101.v1-0.2017-09-27.1e.230q.vcex

Border Gateway Protocol (BGP) uses a complex method of selecting the best path to the destination. The following list displays the criteria used by BGP for path selection:
Highest weight  
Highest local preference  
Locally originated paths over externally originated paths  
Shortest autonomous system (AS) path  
Lowest origin type  
Lowest multiexit discriminator (MED)  
External BGP (eBGP) paths over internal BGP (iBGP) paths  
Lowest Interior Gateway Protocol (IGP) cost  
Oldest eBGP path  
Lowest BGP router ID (RID) 
When determining the best path, a BGP router first chooses the route with the highest weight. Weight is a Ciscoproprietary BGP path attribute that is significant only to the local router; it is not advertised to neighbor routers. To configure the weight value, you should issue the neighbor {ipaddress | peergroupname} weightweightvalue command, where ipaddress is the IP address of a neighbor router, peergroupname is the name of a BGP peer group, and weightvalue is a locally significant weight value from 0 through 65535. By default, routes generated by the local router are assigned a weight of 32768 and routes learned from another BGP router are assigned a weight of 0. 
When weight values are equal, a BGP router chooses the route with the highest local preference. The local preference value is advertised to iBGP neighbor routers to influence routing decisions made by those routers. To configure the local preference, you should issue the bgp default localpreference number command, where number is a value from 0 through 4294967295. 
When local preferences are equal, a BGP router chooses locally originated paths over externally originated paths. Locally originated paths that have been created by issuing the network or redistribute command are preferred over locally originated paths that have been created by issuing the aggregate-address command. 
If multiple paths to a destination still exist, a BGP router chooses the route with the shortest AS path attribute. The AS path attribute contains a list of the AS numbers (ASNs) that a route passes through.  
If multiple paths have the same AS path length, a BGP router chooses the lowest origin type. An origin type of i, which is used for IGPs, is preferred over an origin type of e, which is used for Exterior Gateway Protocols (EGPs). These origin types are preferred over an origin type of , which is used for incomplete routes where the origin is unknown or the route was redistributed into BGP. 
If origin types are equal, a BGP router chooses the route with the lowest MED. A MED value is basically the external metric of a route that is advertised to eBGP routers in order to specify a preferred path into an AS with multiple entry points. To configure the MED value, you should issue the defaultmetric number command, where number is a value from 1 through 4294967295. Routes redistributed into BGP are assigned this MED value; redistributed connected routes are assigned a MED value of 0 regardless of the defaultmetric setting. 
If MED values are equal, a BGP router chooses eBGP routes over iBGP routes. If there are multiple eBGP paths, or multiple iBGP paths if no eBGP paths are available, a BGP router chooses the route with the lowest IGP metric to the nexthop router. If IGP metrics are equal, a BGP router chooses the oldest eBGP path, which is typically the most stable path.  
Finally, if route ages are equal, a BGP router chooses the path that comes from the router with the lowest RID. The RID can be manually configured by issuing the bgp router-idcommand. If the RID is not manually configured, the RID is the highest loopback IP address on the router. If no loopback address is configured, the RID is the highest IP address from among a router's available interfaces. 
Reference:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

AutoRP messages are sent using multicast addresses 224.0.1.39 and 224.0.1.40. AutoRP dynamically determines the rendezvous point (RP) for a multicast group so that RPs need not be manually configured. The multicast address 224.0.1.39 is used for RPAnnounce messages, which are sent by candidate RPs to advertise their eligibility to become an RP. The RPAnnounce messages are received by the mapping agent, which maps the candidate RPs to multicast groups. If multiple routers are advertised as candidate RPs for a multicast group, the router with the highest IP address is used as the RP for that group. The multicast address 224.0.1.40 is used for RPDiscovery messages, which are sent by mapping agents to advertise the authoritative RP for a multicast group. 
Protocol Independent Multicast version 1 (PIMv1) messages are sent using multicast address 224.0.0.2. The multicast address 224.0.0.2 is the allrouters address. 
The allrouters address is also used by Internet Group Management Protocol (IGMP). 
PIMv2 messages are sent using multicast address 224.0.0.13. The multicast address 224.0.0.13 is the allPIMrouters address. This address is used by PIMv2 to send status messages, such as hello messages, prune messages, and assert messages. The allPIMrouters address is also used to send Bootstrap Router (BSR) messages. Like AutoRP, the BSR feature dynamically assigns RPs to multicast groups. However, BSR can be used only by PIMv2; it cannot be used by PIMv1. Other PIMv2 message types include the Register message, the RegisterStop message, and the Join/Prune message. 
Reference:
https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html#wp1029236

RouterA will install all of the routes in the routing table. When multiple routes to overlapping networks exist, a router will prefer the most specific route, which is the route with the longest prefix match. For example, if RouterA receives a packet to 192.168.1.4, it will send the packet to the 192.168.1.0/28 route; if RouterA receives a packet to 192.168.1.20, it will send the packet to the 192.168.1.0/26 route. RouterA will not install only the route with the longest or shortest prefix match. 
RouterA will not install only the route with the highest or lowest administrative distance (AD), because the routes target separate destination networks. When multiple routes to the same destination network exist and each route uses a different routing protocol, a router prefers the routing protocol with the lowest AD. The following list contains the most commonly used ADs:
   
ADs for a routing protocol can be manually configured by issuing the distance command in router configuration mode. For example, to change the AD of Routing Information Protocol (RIP) from 120 to 50, you should issue the following commands:
RouterA(config)#router rip  
RouterA(configrouter)#distance 50 
Reference:
https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8651-21.html

You can issue the eigrp stub command or the ip summary-address eigrp as-number address mask command to limit Enhanced Interior Gateway Routing Protocol (EIGRP) queries. Query packets are sent to find feasible successors to a destination network. When a router does not have a feasible successor, it floods query packets to its neighbors. If a neighbor has a route to the destination network, it replies with the route. However, if a neighbor does not have a route to the destination network, it queries its neighbors, those neighbors query their neighbors, and so on. This process continues until either a router replies with the route or there are no routers left to query. The network cannot converge until all the replies have been received, which can cause a router to become stuck in active (SIA). 
Limiting EIGRP queries prevents queries from consuming bandwidth and processor resources and prevents routers from becoming SIA. You can display which routers have not yet replied to a query by issuing the show ip eigrp topology active command, as shown in the following output:
   
The eigrp stub command limits EIGRP queries by creating a stub router. Stub routers advertise only a specified set of routes and therefore typically need only a default route from the hub router. A hub router detects that a router is a stub router by examining the TypeLengthValue (TLV) field within EIGRP hello packets sent by the router. The hub router will specify in its neighbor table that the router is a stub router and will no longer send query packets to that stub router, thereby limiting how far EIGRP queries spread throughout a network. 
The ip summaryaddress eigrp asnumber address mask command limits EIGRP queries by configuring route summarization. If a neighbor router has a summarized route but does not have the specific route to the destination network in the query, the neighbor router will reply that it does not have a route to the destination network and will not query its neighbors. Thus route summarization creates a query boundary that prevents queries from propagating throughout the network. 
You cannot limit EIGRP queries by issuing the router eigrp asnumber command, which is used to create an EIGRP process for an autonomous system (AS). 
Queries are sent from neighbor to neighbor throughout a network, even from one AS to another. Therefore, creating a separate AS will not limit EIGRP queries. 
You cannot limit EIGRP queries by issuing the ip hellointerval eigrp asnumber seconds command, which is used to adjust the hello timer interval. By default, the hello timer is set to five seconds on high-bandwidth links and 60 seconds on low-bandwidth multipoint links slower than 1.544 Mbps. 
You cannot limit EIGRP queries by issuing the ip holdtime eigrp asnumber seconds command, which is used to adjust the hold timer interval. The hold timer is set to three times the hello timer value by default. Therefore, the hold timer is typically set to 15 seconds on high-bandwidth links and 180 seconds on low-bandwidth multipoint links. If you adjust the hello timer values, you must also adjust the hold timer values because they are not adjusted automatically. 
Reference:
https://www.cisco.com/en/US/technologies/tk648/tk365/technologies_white_paper0900aecd8023df6f.html

RouterC will advertise only networks A, C, E, and F to RouterD. RouterC and RouterD are internal Border Gateway Protocol (iBGP) peers, which are Border Gateway Protocol (BGP) routers that exist within the same autonomous system (AS). The BGP split horizon rule states that routes learned through iBGP are not advertised to iBGP peers. Therefore, only routes learned through external BGP (eBGP), routes learned through redistribution, and routes originated by a network statement are advertised to iBGP peers. In this scenario, the routes to networks E and F are learned through eBGP, the route to network A is learned through redistribution, and the route to network C originated on RouterC. 
RouterC will not advertise network B to RouterD, because RouterC learned of network B through an iBGP peer, RouterB. Because iBGP routes are not advertised to iBGP peers, one of the following actions must be taken to enable routers running iBGP to communicate:
Configure a full mesh. 
Configure a confederation. 
Configure a route reflector. 
A full-mesh configuration enables each router to learn each iBGP route independently without passing through a neighbor. However, a full-mesh configuration requires the most administrative effort to configure. A confederation enables an AS to be divided into discrete units, each of which acts like a separate AS. Within each confederation, the routers must be fully meshed unless a route reflector is established. A route reflector can be used to pass iBGP routes between iBGP routers, which would eliminate the need for a full-mesh configuration. However, it is important to note that route reflectors advertise best paths only to route reflector clients. Additionally, if multiple paths exist, a route reflector will always advertise the exit point that is closest to the route reflector. 
RouterC will not advertise network D to RouterD. When RouterD advertises network D to RouterC, RouterD adds the AS number to the AS_PATH. Routes with an AS_PATH that contains the AS number of a BGP peer are not advertised back to that peer. The AS_PATH attribute contains all of the AS numbers that a packet must traverse to reach a destination network. If a BGP router receives an advertised route that contains its own AS number, the route is ignored, thereby preventing routing loops. 
Reference:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#ibgp
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#aspathattribute

The root port on a switch is the port that receives the best Spanning Tree Protocol (STP) bridge protocol data unit (BPDU), which indicates the best path to the root bridge based on the best root port cost. A root port is always in the forwarding state. Because there is only one best path to the root bridge, a switch cannot have more than one root port. 
The root bridge sends BPDUs every two seconds by default. When a switch receives a BPDU, the receiving switch modifies the forwarding switch's bridge ID, port priority, port number, and cost to reach the root bridge before forwarding the BPDU to neighboring switches. The interface that receives the hello packet with the lowest path cost will become the root port. When a switch receives multiple BPDUs with the same path cost, it will choose the interface connected to the forwarding switch with the lowest bridge ID. When multiple equal-cost paths to a forwarding switch exist, the receiving switch will choose the lowest port priority of the forwarding switch. If all port priorities are equal, the receiving switch will choose the lowest port number of the forwarding switch. 
Reference:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960xr/software/15-0_2_EX1/layer2/configuration_guide/b_lay2_152ex1_2960-xr_cg/b_lay2_152ex1_2960-xr_cg_chapter_010.html#ID92

Tail drop is the default congestion avoidance mechanism on Cisco routers. Interface congestion occurs when a router receives packets faster than it can send them. When congestion exists, the excess packets are stored in a queue until the interface can transmit them. When the queue becomes full, the router drops all packets on the congested interface until there is room in the queue. This method of discarding packets is referred to as the tail drop mechanism. As the router drops packets, each sending device detects the packet loss and reduces its transmission rate, thereby reducing the congestion on the interface. This behavior is a feature of Transmission Control Protocol (TCP), which was designed to adjust transmit rates based on network conditions. However, because the tail drop mechanism does not differentiate between highpriority and lowpriority packets, all packets are dropped without regard to priority. Additionally, because the tail drop mechanism does not differentiate between packet flows, all TCP sessions are affected. 
Global synchronization is a phenomenon associated with the tail drop mechanism. Because the tail drop mechanism discards packets for all TCP sessions, all sending devices reduce their transmission rates in unison. This behavior typically results in a lull in network traffic, causing the receiving router's interface to be underutilized. Then, as each TCP session attempts to maximize its transmission window, the interface rapidly becomes congested again, causing the router to tail drop packets. This cycle is referred to as global synchronization. 
Queuing is a method of congestion management, not congestion avoidance. Every physical interface on a router has a hardware queue and a software queue. The hardware queue is always a first-in-first-out (FIFO) queue and has limited configuration options. The software queue can be configured for one of various queuing methods, such as weighted fair queuing (WFQ) or low latency queuing (LLQ). 
TCP starvation is a phenomenon that occurs when TCP traffic is dominated by nonTCP traffic on an interface. Because nonTCP traffic, such as User Datagram Protocol (UDP) traffic, is not aware of packet loss due to congestion control mechanisms, devices sending nonTCP traffic might not reduce their transmission rates. 
This behavior causes the nonTCP traffic to dominate the queue and prevent TCP traffic from resuming a normal flow. To mitigate TCP starvation, you should avoid mixing TCP and UDP traffic in the same traffic class. 
Reference:
https://search.cisco.com/search?query=Cisco%20IOS%20Quality%20of%20Service%20Configuration%20Guide&locale=enUS&tab=Cisco

The origin, AS-path, and next hop Border Gateway Protocol (BGP) attributes are best described as well-known, mandatory BGP path attributes. Internet Engineering Task Force (IETF)standard BGP path attributes can be broken down into the following categories:
   
Support for optional BGP path attributes is not required of any BGP implementation. However, optional attributes must still be handled by BGP in either a transitive or nontransitive fashion. Optional, transitive path attributes are passed to BGP peers regardless of whether support for the attribute is available. Aggregator and community are both optional, transitive BGP attributes. Optional, nontransitive BGP attributes are silently discarded if support for the attribute is not available. 
Cluster list, originator ID, and multi-exit discriminator (MED) are optional, nontransitive BGP attributes. 
Well-known BGP attributes are required path attributes that must be supported by every BGP implementation. Well-known, mandatory attributes must be sent in every BGP update message. Well-known, discretionary attributes, on the other hand, are only included in BGP update messages under specific sets of circumstances. Atomic aggregate and local preference are both well-known, discretionary BGP attributes. 
Reference:
https://tools.ietf.org/html/rfc4271#section-5

Of the choices available, Remote Authentication DialIn User Service (RADIUS) is an Internet Engineering Task Force (IETF) standard protocol and combines authentication and authorization into a single function. RADIUS is an Authentication, Authorization, and Accounting (AAA) protocol that can be used for controlling access to a router or switch. Although RADIUS does not encrypt the entire contents of a packet, it does provide some security by encrypting the password in an AccessRequest packet. By contrast, Terminal Access Controller Access Control System Plus (TACACS+) encrypts the entire packet. 
RADIUS is limited by the fact that authorization and authentication are combined into a single function. By contrast, TACACS+ separates authorization, authentication, and accounting functions, which provides TACACS+ with more flexible security options for controlling access to configuration commands. 
RADIUS uses User Datagram Protocol (UDP), not Transmission Control Protocol (TCP), for packet delivery. By contrast, TACACS+ uses TCP on port 49 for data delivery. 
Reference:
https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html#comparing

Only Router2 will be able to connect successfully to RouterMain. The syntax of the username command is username hostname password password. By default, the hostname parameter is the host name configured in the hostname command of the peer router. However, you can use the ppp chap hostname command to specify a separate host name that is used only for Challenge Handshake Authentication Protocol (CHAP) authentication. Since the ppp chap hostname command has not been issued on the routers in this scenario, the host name that should be specified in the username command is the normal host name for each router. 
Router1 will not be able to connect successfully to RouterMain, because the host name and password are specified incorrectly in the username command on Router1. The host name and password specified in the username command are case-sensitive. Therefore, the host name "routermain" does not match the host name "RouterMain", and the password "boson" does not match the password "Boson". To enable Router1 to connect, you should issue the username RouterMain password Boson command. 
Router3 will not be able to connect successfully to RouterMain. Although the host name is specified correctly in the username command on Router3, the password is specified incorrectly? the password "boson" does not match the password "Boson". To enable Router3 to connect, you should issue the username RouterMain password Boson command. 
Reference:
https://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25647-understanding-ppp-chap.html