Cisco 300-410 Implementing Cisco Enterprise Advanced Routing and Services (ENARSI) Exam Practice Test

The AD of static route is manually configured to 130 which is higher than the AD of OSPF router which is 110.

From the output we can see there are 2 NHRP Peers. The first one with the NBMA Address of

172.18.16.2 and the “Attribute” (Attrb) of Static (S) so we can deduce it is the Hub device.

Therefore the second one must be the remaining Spoke device with the attribute of Dynamic

(D).

--> S - Static, D - Dynamic, I - Incomplete

N - NATed, L - Local, X - No Socket

# Ent --> Number of NHRP entries with same NBMA peer

NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting

UpDn Time --> Up or Down Time for a Tunnel

========================================================================

==

Interface: Tunnel1, IPv4 NHRP Details

Type:Spoke, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb

----- --------------- --------------- ----- -------- -----

1 44.44.44.4 192.168.100.254 UP 00:03:40 S

1 12.12.12.2 192.168.100.2 UP 00:03:20 D

From the exhibit, we learned:

+ VRF customer_a was exported with Route target (RT) of 1:1 so at the remote site it must be

imported with the same RT 1:1.

+ VRF customer_a was imported with Route target (RT) of 1:1 so at the remote site it must be

exported with the same RT 1:1.

Therefore at the remote site we must configure the command “route-target both 1:1” (which is

equivalent to two commands “route-target import 1:1” & “route-target export 1:1”.

Command Default

Accounting port: 1813

Authentication port: 1812

Accounting: enabled

Authentication: enabled

Retransmission count: 1

Idle-time: 0

Server monitoring: disabled

Timeout: 5 seconds

Test username: test

Test password: test

The ―logging console‖ is a default and hidden command.

A label edge router (LER, also known as edge LSR) is a router that operates at the edge of an MPLS network and acts as the entry and exit points for the network. LERs push an MPLS label onto an incoming packet and pop it off an outgoing packet.

https://www.cisco.com/c/en/us/td/docs/routers/xr12000/software/xr1 2k_r3-9/system_management/command/reference/yr39xr12k_chapter4.html#wp1784026936

By default, syslog and debug messages are stamped by UTC, regardless of the time zone that device configured. You should append localtime key word to "service timestamp {log | debug} datetime msec" global command to change that behavior.

https://community.cisco.com/t5/networking-documents/router-log-timestamp-entries-are-different-from-the-system- clock/ta-p/3132258

https://www.cisco.com/E-Learning/bulk/public/tac/cim/cib/ using_cisco_ios_software/cmdrefs/service_timestamps.htm

The ―summary-address‖ is only used to create aggregate addresses for OSPF at an autonomous system boundary. It means this command should only be used on the ASBR when you are trying to summarize externally redistributed routes from another protocol domain or you have a NSSA area. But a requirement to create a summarized route is:

―The ASBR compares the summary route’s range of addresses with all routes redistributed into OSPF on that ASBR to find any subordinate subnets (subnets that sit inside the summary route range). If at least one subordinate subnet exists, the ASBR advertises the summary route.‖

Graphical user interface, application Description automatically generated

By default, Catalyst switches add a simple uptime timestamp to logging messages. This is a cumulative counter that shows the hours, minutes, and seconds since the switch has been booted up

In this topology, Chicago router (Hub) will receive advertisements from Los Angeles (Spoke1) router on its tunnel interface. The problem here is that it also has a connection with New York (Spoke2) on that same tunnel interface. If we don’t disable EIGRP split-horizon, then the Hub will not relay routes from Spoke1 to Spoke2 and the other way around. That is because it received those routes on interface Tunnel1 and therefore it cannot advertise back out that same interface (splithorizon rule). Therefore we must disable split-horizon on the Hub router to make sure the Spokes know about each other.

The IPv6 Router Advertisement Guard feature provides support for allowing the network administrator to block or reject unwanted or rogue router advertisement guard messages that arrive at the network device platform. Router Advertisements are used by devices to announce themselves on the link. The IPv6 Router Advertisement Guard feature analyzes these router advertisements and filters out router advertisements that are sent by unauthorized devices.

Certain switch platforms can already implement some level of rogue RA filtering by the administrator configuring Access Control Lists (ACLs) that block RA ICMP messages that might be inbound on “user” ports.

https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/109597-csr-chained-certificates-wlc-00.html#anc12

1. R1 received DHCP packet and its interface was configured with the DHCP helper address. But we are not sure if R1 forward DHCP packet to R2 or not. 2. If we connect PC directly to R2 then this problem will not appear -> DHCP Server function was configured on R2.

From these facts, the most likely problem is related to Option 82. Maybe R2 ignored DHCP request packets because it was receiving these packets with the giant field set to 0.0.0.0.

By default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping! Reference: https://blog.ine.com/2009/07/22/understanding-dhcp-option-82

If we can run the “debug ip dhcp server packet” on R2, we may see these messages:

*Feb 22 23:54:57.759: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 34 4, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fw dchk FALSE *Feb 22 23:54:57.759: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 34 4, rcvd 2 *Feb 22 23:54:57.759: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 34 4, stop process pak for forus packet

*Feb 22 23:54:57.759: DHCPD: inconsistent relay information. *Feb 22 23:54:57.759: DHCPD: relay information option exists, but giaddr is zero

We are receiving the DHCP packet from R1, source 0.0.0.0, and destination 255.255.255.255 broadcast, but if you notice from the debug output, R2, our DHCP Server, is complaining that the relay information is inconsistent. Option 82, Information Option, is contained in the packet but the GIADDR is zero. The GIADDR stands for Gateway IP Address, which is the IP Address of the relaying agent. The Option 82, Information Option, would then contain the receiving port and hostname of the Relaying Agent by default.

R2 sees the Option 82 information, signalling that the DHCP packet might have been relayed, BUT there is no relaying IP Address. This is the behavior of DHCP Snooping when enabling it on a switch, and since the switchport does not contain an IP Address, since it’s Layer 2, no GIADDR will be added.

Instead, just the Option 82 Information is added and this is the problem we have, but there are options:

1. You could trust all on R2 the DHCP Server, which will cause the server to not be so suspicious: – ip dhcp relay information trust-all – ip dhcp relay information trusted 2. Disable the addition of Option 82 information on SW: – no ip dhcp snooping information option 3. Trust the port that is receiving the DHCP Discover: – ip dhcp snooping trust

Any of these options will fix our predicament.

Desired Min TX Interval: This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets, less any jitterapplied. The value zero is reserved.

Required Min Echo RX Interval: This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting, less anyjitter applied by the sender. If this value is zero, the transmitting system does not support the receipt of BFD Echo packets.

Diagram Description automatically generated

The MPLS LDP Inbound Label Binding Filtering feature can be used to control the amount of

memory used to store Label Distribution Protocol (LDP) label bindings advertised by other

devices. For example, in a simple Multiprotocol Label Switching (MPLS) Virtual Private Network

(VPN) environment, the VPN provider edge (PE) devices might require label switched paths

(LSPs) only to their peer PE devices (that is, they do not need LSPs to core devices). Inbound

label binding filtering enables a PE device to accept labels only from other PE devices.

Explanation

Once again, Cisco changed the IOS configuration commands required for OSPFv3 configuration. The new OSPFv3 configuration uses the “ospfv3” keyword instead of the earlier “ipv6 router ospf” routing process command and “ipv6 ospf” interface commands.

The Open Shortest Path First version 3 (OSPFv3) address families feature enables both IPv4 and IPv6 unicast traffic to be supported. With this feature, users may

have two processes per interface, but only one process per address family (AF).

When the aggregate-address command is used within BGP routing, the aggregated address is advertised, along with the more specific routes. The exception to this

rule is through the use of the summary-only command. The “summary-only” keyword suppresses the more specific routes and announces only the summarized

route.

The set ip default next-hop command verifies the existence of the destination IP address in the routing table, and…+ if the destination IP address exists, the command does not policy route the packet, but forwards the packet based on the routing table.+ if the destination IP address does not exist, the command policy routes the packet by sending it to the specified next hop.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html

We need to use Policy Based Routing (PBR) here on Bangkok router to match the traffic from 192.168.3.0/24 & 192.168.4.0/24 and “set ip next-hop” to HongKong router(172.18.1.2 in this case).

Note: Please notice that we have to apply the PBR on incoming interface e0/3 to receive traffic from 192.168.3.0/24 and 192.168.4.0/24.

To turn off terminal monitor, use “terminal no monitor” in the enable mode

https://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/47121-pbr-cmds-ce.html

From the exhibit we see there are two flow monitors: the first one “FLOW-MONITOR-1” has been configured correctly but the second one “v4_r1” was left empty andinterface E0/0.1 is using it. So the remote server does not receive any NetFlow data.

MPLS Network Protocols

+ IGP: OSPF, EIGRP, IS-IS on core facing and core links+ RSVP and/or LDP on core and/or core facing links ->

+ MP-iBGP on PE devices (for MPLS services), MP-BGP: Multiprotocol Border Gateway Protocol, used for MPLS L3 VPN -> .

From the output of the “show ip eigrp topology …” command, we notice network 192.168.13.0/24 was learned via two routes:+ From 192.168.23.3 (R3) with FD = 1075200 and AD = 281600+ From 192.168.12.1 (R1) with FD = 2611200 and AD = 281600

From the output of the “show ip route …” command, we learned that the best (and chosen) path is via 192.168.23.3 (R3).

To use both paths (called unequal cost load balancing) with EIGRP, the second path via R1 must satisfy the feasibility condition. The feasibility condition states that, theAdvertised Distance (AD) of a route must be lower than the feasible distance of the current successor route.

In this case, the second path satisfies the feasible condition as its AD (281600) is smaller than the FD (1075200) of the best path. Therefore we can configure loadbalancing with “variance” command.

In other words, EIGRP will install all paths with metric < variance * best_metric into the local routing table, provided that it meets the feasibility condition to preventrouting loop. Therefore we can calculate the variance > metric / best_metric = 2611200 / 1075200 =2.4.

So with a variance greater than 2 (and must be an integer), we can load balance traffic to network 192.168.13.0/24.

https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200785-ISP-Failover-withdefault-

routes-using-I.html

For OSPF, we can only summary at the ABR with the command “area range” or at the ASBR with the command “summary-address” -> Therefore answer A and answer B are not correct.

In this question, the most likely problem is that when doing summarization, the network mask is configured wrong and summarization doesn’t work because of the misconfiguration. When configuring the area range command, make sure that the summarization mask is in the form of a prefix mask rather than a wildcard mask (that is, 255.255.255.0 instead of 0.0.0.255).

Good reference: https://www.configrouter.com/troubleshooting-route-summarization-ospf-14082/

Solution:

• Use cu-red under interfaces facing SW1 & SW3:

On R1:

interface Ethernet0/0

ip vrf forwarding cu-red

ip address 192.168.1.254 255.255.255.0

Check reachability to SW1:

R1#ping vrf cu-red 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

On R2:

interface Ethernet0/0

ip vrf forwarding cu-red

ip address 192.168.2.254 255.255.255.0

Check reachability to SW3:

R2#ping vrf cu-red 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

• Use vrf cu-green for SW2 & SW4:

On R1:

interface Ethernet0/1

ip vrf forwarding cu-green

ip address 192.168.20.254 255.255.255.0

Test reachability to SW2:

R1#ping vrf cu-green 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.22.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

On R2:

interface Ethernet0/1

ip vrf forwarding cu-green

ip address 192.168.22.254 255.255.255.0

Test reachability to SW4:

R2#ping vrf cu-green 192.168.22.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

• On R1:

interface Ethernet0/2.100

mpls ip

!

interface Ethernet0/2.200

mpls ip

!

Configure BGP:

router bgp 65000

neighbor 10.10.10.2 remote-as 65000

neighbor 10.10.20.2 remote-as 65000

!

address-family vpnv4

neighbor 10.10.10.2 activate

neighbor 10.10.20.2 activate

exit-address-family

!

address-family ipv4 vrf cu-green

redistribute connected

exit-address-family

!

address-family ipv4 vrf cu-red

redistribute connected

exit-address-family

!

R1(config)#ip vrf cu-red

R1(config-vrf)#route-target both 65000:100

!

R1(config)#ip vrf cu-green

R1(config-vrf)#route-target both 65000:200

• On R2:

interface Ethernet0/2.100

mpls ip

!

interface Ethernet0/2.200

mpls ip

!

router bgp 65000

neighbor 10.10.10.1 remote-as 65000

neighbor 10.10.20.1 remote-as 65000

!

address-family vpnv4

neighbor 10.10.10.1 activate

neighbor 10.10.20.1 activate

exit-address-family

!

address-family ipv4 vrf cu-green

redistribute connected

exit-address-family

!

address-family ipv4 vrf cu-red

redistribute connected

exit-address-family

R2(config)#ip vrf cu-red

R2(config-vrf)#route-target both 65000:100

!

R2(config)#ip vrf cu-green

R2(config-vrf)#route-target both 65000:200

• Verification:

From SW1 to SW3:

SW1#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

But can’t Reach SW2 or SW4 in VRF cu-green:

SW1#ping 192.168.22.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.22.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

SW1#ping 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

Same Test for SW2:

From SW2 to SW4:

SW2#ping 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

But can’t Reach SW3 or SW1 in VRF cu-red:

SW2#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

SW2#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

Both R1 & R2 has separate tables for VRFs cu-red and cu-green.