To Pass CCIE Enterprise Infrastructure v1.1 Deploy discussion - Real Attempt

[mrhacker]

HI Guys,

 

if we agree so we can start the discussion of CCIE EI. If all agree so i can share the list of Questions of Section wise.

 

[idataproxy]

thanks

[Merlz]

On 7/18/2021 at 10:36 PM, mrhacker said:

HI Guys,

 

if we agree so we can start the discussion of CCIE EI. If all agree so i can share the list of Questions of Section wise.

 

Hi Mr Hacker, what would you like us to do that will make you share the questions?

[ccieeii]

On 7/19/2021 at 2:06 AM, mrhacker said:

HI Guys,

 

if we agree so we can start the discussion of CCIE EI. If all agree so i can share the list of Questions of Section wise.

 

Offcourse please start sharing 

[mrhacker]

Thanks to all Dear's,

Below are the list of question and review and validate the solutions.

 

1.2                                                                                                       : Layer 2 Technologies in HQ

Complete and correct the EtherChannel configuration between switches sw101, sw102, sw110 according to these requirements:

 ·         At the end of the task, all EtherChannel’s between switches sw101, sw102, sw110 must be up and operational including all their physical member links.

·         Do not create new Port- channel interface; reuse those that already exist on the switches.

·         When resolving existing issues, do not change the preconfigured negotiation protocol (if any)

·         On EtherChannel’s that use a negotiation protocol, tune its mode of operation for the shortest link building time possible.

 

Configure spanning tree protocol on switches sw101, sw102, sw110 according to these requirements:

 

·         The STP root for VLAN 2000 must be sw101.

·         The STP root for VLAN 2001 must be sw102.

·         STP roots must be elected based on bridge priorities.

·         On the three switches, have STP perform cost calculations in 32-bit arithmetic.

·         On the three switches, use the Rapid STP version and ensure that it can achieve rapid convergence on all interconnections between the switches.

·         On Sw110, prevent all current and future access mode interfaces from being affected by the proposal/ Agreement process.

 

 

1.2                                                                                  : First Hop Redundancy Protocol in HQ

 

For IPv4, implement an FHRP mechanism on sw101 and sw102 fo rVLANs 2000 and 2001 according to these requirements:

 

·         Use Group number 100 for VLAN 2000 and group number 101 for VLAN 2001.

·         Use the first available IPV4 address in the subnet for the address of the virtual router.

·         For VLAN 2000, sw101 must be preferred gateway; for VLAN 2001, sw102 must be the preferred gateway. Do not rely on the IPv4 addresses of the switches as role tiebreakers. The role must determine by an explicit configuration solely on the intended preferred gateway.

·         Each preferred gateway must monitor the reachability of both routers r11 and r12 using the loopback IPv4 addresses of the routers by an ICMP Echo. The reachability is to be verified every 5 seconds with a timeout of 400 msec. A router must be declared unreachable as soon as it does not respond to three probes in a row. If both r11 an dr12 are declared unreachable from a preferred gateway, the other switch must be allowed to assume the gateway role.

·         Use the FHRP protocol that allows the virtual IPv4 address to match the IPv4 address of a member router.

 

 

1.3                                                                                                    : OSPFv2 between HQ and DC

 

Complete and correct the OSPF configuration on the switches sw101, sw102,sw201 and sw202 according to these requirements:

 

·         Enable OSPFv2 on the redundant interconnections between the DC and HQ sites. Make sure that establishes adjacencies on these interconnections and exchanges routing information between the DC and HQ sites.

·         Protect the authenticity and integrity of the OSPFv2 sessions on the redundant interconnections between DC and HQ with the SHA-384 mechanism. Use key ID 1 and a shared secret of “cci3” (without quotes).

·         Improve the detection of unreachable OSPFv2 neighbors on the redundant interconnections between DC and HQ so that OSPF can detect the loss of a neighbor within 200 msec, with the probes being sent every 100 msec. it is not allowed to modify ODPF timers to accomplish this requirement.

 

 

1.4                                                                                                            : DHCP IPv4 service for HQ

 

Enable hosts in HQ VLAN 2000 and VLAN 2001 to obtain their IP configuration via DHCP according to these requirements:

 

·         On sw211, create IPv4 DHCP pools named hq_v2000 and hq_v2001 for HQ VLANs 2000 and 2001, respectively. In each subnet, assign addresses from .101 upto .254 inclusively, and the appropriate gateway to clients.

·         Enable DHCP snooping on sw110 in VLANs 2000 and 2001 to protect against DHCP-related attacks.

·         Place host11 into VLAN 2000.

·         Place host12 into VLAN 2001.

·         Perform the necessary configuration on switches sw101, sw102, sw110 to enable hosts in VLANs2000 and 2001 to obtain IPv4 configuration through DHCP. The DHCP server running at sw211 in the DC must be referred to by its loopback IPv4 address 10.2.255.211. Do not disable the Option 82 insertion, and do not enable DHCP snooping on other switches.

·         Verify that host11 and host12 have IP connectivity to the Cisco DNA Center, VManage and UCE running in the DC using their internal (In Band Connectivity) addresses.

 

1.5                                                                                                                                             : IPv6 in HQ

 

Implement IPv6 on sw101 and sw102 for switch virtual interfaces (SVIs) Vlan 2000 and Vlan 2001 according to these requirements:

·         sw101

Interface Vlan2000:2001:db:8:1:100::1/64 Interface Vlan2001:2001:db8:1:101::1/64

 

·         sw102

Interface Vlan2000:2001:db8:1:100::2/64 Interface Vlan2001:2001:db8:1:101::2/64

 

·         The configuration must enable hosts in these VLANs to obtain their IPv6 configuration via SLAAC and keep a stable connectivity with other IPv6 networks.

·         Use native IPv6 means to provide gateway redundancy, with sw101 being the preferred gateway in VLAN 2000 and sw102 being the preferred gateway in VLAN 2001. The role must be determined by an explicit configuration solely on the intended preferred gateway.

·         Hosts must be able to detect the failure of the preferred gateway in as little as 3 seconds.

 

1.6                                                                                                                              : IPv6 EIGRP in HQ

 

In HQ, enable EIGRP for IPv6 on r11, r12, sw101 and sw102 according to these requirements:

·         Use process name “ccie” (without the quotes) and AS number 65001.

·         Do not configure any additional IPv6 addresses.

·         IPv6 EIGRP may form adjacencies only over the physical Layer3 interfaces between r11, r12, sw101 and sw102.

·         Prevent IPv6 EIGRP from automatically running on, or advertising attached prefixes from, new IPv6-enabled interfaces in the future unless allowed explicitly.

·         Ensure that the attached IPv6 prefixes on SVIs Vlan2000 and Vlan2001 onsw101 and sw102 are advertised in IPv6 EIGRP and learned on r11 and r12.

·         No route filtering is allowed to accomplish this entire task.

 

1.7                                                                                                                                      : OSPFv2 in DC

 

Configure devices in the DC according to these requirements:

 

·         Switches sw201 and sw202 must establish a stable OSPF adjacency in the FULL state with vedge21 and vedge22 on interface Vlan3999. Any configuration changes and corrections necessary to meet this requirement may be performed only on the switches, and any mismatched parameters causing the issue must be changed to exactly match the configuration of the vEdges.

·         All OSPF speakers in the DC running Cisco IOS and IOS-XE software must be configured to keep the number of advertised internal routes to an absolute minimum while not impacting the reachability of the services. This included the reachability of ISE,DNA center,vManage,vBond and vSmart on their internal (in Band Connectivty) addresses, as well as any existing and future devices in VLAN 4000 and sw201 and sw202. The configuration of this requirement must be completed exclusively within the “router ospf” and “interface vlan” contexts without causing any impact to existing OSPF adjacencies.

·         Router r24 must advertise two prefixes, 10.6.0.0/15 and 10.200.0.0/24, as Type-5 LSAs in OSPFv2 to provide HQ and DC with the reachability to the DMVPN tunnel and branches #3 and #4. The configuration of this requirement must be completed exclusively within the “router ospf” context.

·         Any route from the 10.2.0.0/16 range that keeps being advertised in OSPF must continue being advertised as an intra-area route.

·         It is not allowed to modify existing areas to accomplish this entire task.

 

1.8                                                                     : BGP between HQ/DC and service providers

Configure the BGP peering’s between HQ/DC and Global SP#1 and Global SP#2 according to these requirements:

·         Bring up the BGP peering between HQ r11 and SP#1 r3

·         Bring up the BGP peering between DC r21 and SP#1 r3

·         Bring up the BGP Peering between DC r22 and SP#2

·         Ensure that the routes learned over eBGP sessions and further advertised in iBGP will be considered reachable even if the networks on inter-AS links are not advertised in OSPF. The configuration of this requirement must be completed exclusively within the “router bgp” context.

·         On r11, r21 and r22 perform mutual redistribution between OSPFv2 and BGP. However, prevent routes that were injected into OSPF from BGP to be reinjected back into BGP. This requirement must be solved on r11, r21 and r22 using only a single route-map on each of the routers and without any reference to ACLs, prefix lists, or route types.

·         Prevent HQ and DC from ever communicating through SP#1 r3. All Communication between HQ and DC must occur only over the direct SW101/SW201 and SW102/SW202 interconnections. Any other communication must remain unaffected. This requirement must be solved on r21 and r22 by route filtering based on a well-known mandatory attribute without the use of route maps.

·         No command may be removed from the configuration on r11 to accomplish this entire task.

·         It is allowed to modify existing configuration commands on r21 and r22 to accomplish this entire task.

 

1.9                                                                                           : Bringing up VPNv4/VPNv6 in SP#1

 

Configure routers r3, r4, r5 and r6 in SP#1 according to these requirements:

 

·         Configure r3 through r6 for mutual VPNv4 and VPNv6 route exchange without the use of a route reflector. Use Lo0 IPv4 addresses for peering’s.

·         Configure r3 through r6 to assign (allocate/bind) as few unique MPLS labels to all existing and future VPNv4 and VPNv6 routes as possible.

·         On Routers r3 through r6, prevent any existing and future customer from discovering details about the inner topology of SP#1. It is not allowed to use ACLs to accomplish this requirement.

1.10  : Fixing Broken DMVPN between Dc and Branches #3 and #4

Correct the configuration issues resulting in broken DMVPN tunnel connectivity between DC, Branch3 and Branch4 according to these requirements:

·         The DMVPN must operate in IPsec-protected phase 3 mode.

·         Using the FVRF approach, safeguard the DMVPN operation against any potential recursive routing issues involving the tunnel.

·         Do not create any new VRFs.

·         Do not change the tunnel source commands on Tunnel interfaces.

·         On Spokes, do not add new BGP neighbors; reuse those that are currently up while changing their VRF membership as needed.

·         It is not allowed to modify configuration on DC r24 to complete this entire task.

 

1.11                                               : Tuning EIGRP on DMVPN and DMVPN-enabled Sites

Optimize the DMVPN operation according to these requirements:

·         Ensure that Branches#3 and #4 receive only a default route over EIGRP in DMVPN.

·         The default route origination must be done on DC r24 without the use of any static routes, redistribution, or route filtering.

·         It is not allowed to modify the configuration of r61 and r62 in Branch#3 to accomplish this task;

·         It is allowed to add commands to the configuration of r70 in branch #4 to accomplish this task;

None of the existing configuration on r70 may be removed to accomplish this task.

           

            Configure Sw601 and Sw602 at Branch#3 according to these requirements:

·         Routers r61 and r62 must not send EIGRP queries to SW601 and SW602.

·         Switches SW601 and SW602 must allow advertising any current or future directly connected network to r61 and r62 after the network is added to EIGRP.

·         Switches Sw601 and Sw602 must continue to propagate the default route received from r61 and r62 to each other. To Select the default route, use a prefix list with a “Permit” – type entry only.

·         Switches SW601 and SW602 must not propagate the default route back to r61 and r62.

·         If the prefix list that allows the propagation of selected EIGRP-learned networks between sw601 and sw602 is modified in the future, the same set of networks must be disallowed from being advertised back to r61 and r62 automatically, without any additional commands.

·          

 

1.12                                                                                     : IPv4 Networks on Legacy Branches

 

On sw211 in DC, complete the DHCP server configuration according to these requirements:

 

·         Create IPv4 DHCP pools named br3_v2000 and br3_v2001 for Branch #3 VLANs 2000 (10.6.100.0/24) and 2001 (10.6.101.0/24), respectively.

·         Create IPv4 DHCP pool named br4_v1 for the subnet 10.7.1.0/24 on branch #4.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

On Branch #3; Complete and correct the configuration on switches sw601, sw602 and sw610 to allow HSRP and DHCP relay operation in VLANs 2000 and 2001 according to these requirements:

 

·         HSRP must implicitly use the vMAC address range of 0000. 0c9f.f000 through 0000. 0c9f.ffff

·         The group member must be 100 for VLAN 2000 and 101 for VLAN 2001

·         Sw601 must be the Active gateway for VLAN 2000 with a priority of 110; the Active role ownership must be deterministic

·         Sw602 must be the Active gateway for VLAN 2001 with a priority of 110; the Active role ownership must be deterministic

·         Each active switch must track its uplink interfaces gi0/1 and gi0/2/ if either of these interfaces goes down; the active switch must allow the other switch to become Active. However, it is not allowed for the tracking to modify the HSRP priority to accomplish this requirement.

·         Both sw601 and sw602 must be configured as DHCP relay agents in both VLANs 2000 and 2001, pointing toward the DHCP server 10.2.255.211 at sw211. However, at any time, only the Active router in the particular VLAN should relay the DHCP messages.

·         Place host61 and host62 into VLANs 2000 and 2001, respectively, and make sure they are assigned their correct IPv4 configuration.

It is not permitted to use any kind of scripting to complete this task.

 

On Branch #4, complete the configuration of the router r70 according to these requirements;

 

·         Assign IP address 10.7.1.1/24 to gi0/2

·         Enable DHCP relay on this interface and point it to the DHCP server 10.2.255.211 at sw211

·         It is allowed to add one additional missing command to the r70 configuration to allow DHCP clients connected to gi0/2 obtain their IPv4 configuration.

·         Make sure that host71 and host72 are assigned their correct IPv4 configuration.

 

1.13                                                                                                                       : Multicast in FABD2

FABD2 is preparing to enable PIM Sparse mode multicast routing in its network. As a part of validating the runbooks, FABD2 requires a sanity check to prevent inappropriate use of multicast-related configuration commands on different router types:

·         First Hop Routers – Routers where multicast sources are connected

·         Last Hop Routers- routers where multicast receivers (subscribers) are connected

·         Intermediary Hop Routers- routers on the path between First Hop and Last Hop routers In the Table below, for each configuration command, select all router type where the use of the command is appropriate. (Select all that apply)

 

Router Type
Command	First Hop Router	Intermediary Hop Router	Last Hop Router
Ip pim register-source	ÿ	ÿ	ÿ
Ip igmp version	ÿ	ÿ	ÿ
ip pim spt-threshold	ÿ	ÿ	ÿ
ip pim rp-address	ÿ	ÿ	ÿ
IP pim sparse-mode	ÿ	ÿ	ÿ

 

 1.14                                                                                     : Extending Connectivity to laaS Site

 Extend the IPv6 connectivity from HQ through the SP into the giosk VRF on the laaS site according to these requirements:

 Set up global IPv6 addressing on the link between r11 and r3

·         On r11, assign 2001:2710:311::2/64 to g0/0

·         On r3, assign 2001:2710:311::1/64 to g1

·         Enable the existing IPv4 BGP session between r11 and r3 to also advertise IPv6 prefixes. Do not configure a standalone IPv6 BGP session between these two routers.

·         Perform bidirectional route redistribution between the IPv6 EIGRP and BGP processes on r11.

·         Ensure that all current and future IPv6 prefixes advertised between r11 and r3 will be installed into the RIB of these routers with the next hop address set to the proper global unicast address on their interconnection. Any policy that accomplishes this requirement must be applied in the inbound direction.

·         The giosk VRF on r4 that extends the IPv6 connectivity from r4 to r30 on the laaS site is a separate VRF independent of fabd2 VRF. Any route leaking from fabd2 VRF into giosk VRF must be done on per-site basis and only for those FABD2 sites that need connectivity in the laaS site.

·         By configuring r3 and r4 only, ensure that the HQ FABD2 site will have mutual visibility with the laaS site while preventing

-          Any other FABD2 site from possibly learning about the routes on the laaS site

-          The laaS site from possibly learning about the routes on any other FABD2 site

 Use the minimum amount of commands necessary to accomplish this requirement. Do not remove any existing configuration. If necessary, you are allowed to use an additional route target with the value of 10000:3681.

·         Verify that host11 and host12 can ping 2001:db8:14::1 located at the laaS site. It is permitted to modify one existing configuration command on one of the SP routers to meet this requirement.

 

1.15                                                                                    : Enabling Internet Access for FABD2

 

Enable highly available internet access for the FABD2 company network according to these requirements:

·         On routers r12, r23 and r24, bring up IPv4 BGP peerings with the ISP, make sure that a default route is received over these peerings.

·         On router r12 and r23, inject default route into OSPF if it present in the routing table from a different routing source than the OSPFv2 process 1. On each router, this requirement must be completed using the minimum possible number of commands.

·         On route r24, inject default route into OSPF if any only if it is learned from ISP over BGP, To accomplish this requirement, it is allowed to use a route-map that referenced both a prefix-list and tag. This requirement must be completed using the minimum possible number of commands.

·         Router r12 may be used as an internet exit for the FABD2 company network only if neither r23 nor r24 are advertising the default route in OSPF. This requirement must be accomplished exclusively in “router ospf” mode on router r12 without changing the default parameters on routers r23 and r24.

·         On routers r12, r23 and r24, configure PAT and translate the entire FABD2 internal network 10.0.0.0/8 to the router address on the link toward the ISP. Create a standard ACL named NAT for this purpose. Do not use NAT pools.

Ensure that the internet connectivity of the FABD2 company network makes use of the highly availability provided by r12, r23 and r24.

 

2.1 : Correcting the IP addresses of Managed switches in DNA center

After Cisco DNA center first achieves IP connectivity with the managed switches in Branches #1 and #2, it will place them into maintenance mode due to their serial number being different from the one DNA center remember, In addition, their management IP addresses in DNA Center will be automatically changed by appending them with the “.dummy.com” string. As a result, after an initial contact, DNA Center will lose connectivity with the switches unless their management IP addresses are corrected in the DNA center settings.

Correct the IP addresses of managed switches in the DNA center according to the following requirements:

·         Use any host, such as host11, to access the DNA Center GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Execute the provision-Devices- Inventory- Global- Actions-Inventory- Resync Device action in DNA Center on all switches before proceeding further.

·         DNA Center API reference and sandbox is available at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         The /network/device/update-maintenance-device-ip-address API call description and sandbox are available in the Inventory section of the API reference.

·         Use the /network-device/update-maintenance-device-ip address API call to correct the IP addresses of the switches in Branches #1 and #2 by removing the appended text.

Note: These IP addresses cannot be changed from DNA Center GUI directly because they will become automatically invalidated again. This is a built-in DNA Center behavior.

 

2.2                                                                   : Completing VN Configuration in DNA center

Using the DNA Center GUI, perform configuration tasks according to these requirements:

·         Add new virtual Network named IoT for the internet-of-things network on the Branches #1 and #2

·         Create new address pools for the IoT VN named Branch1- For IoT and Branch2-ForIoT on the global level, and branch1-IoT and Branch2-IoT on the Branch level.

·         For Branch #1 loT VN, allocate the subnet 10.4.198.0/24 and the gateway IP address 10.4.198.1.

·         For Branch #2 loT VN, allocate the subnet 10.5.198.0/24, and the gateway IP address 10.5.198.1.

·         Associate the Branch1-loT and Branch2-loT pools with the loT VN on the respective branches.

·         Complete the configuration of the address pools for the Guest VN in the DNA Center so that Branch #1 and Branch #2 can accommodate guest connections. If a new address pool needs to be created and an address range allocated to it, follow the established addressing plan.

·         Correct the addressing information currently defined for the Branch2- For Employees and Branch2- Employees address pool.

·         For all address pools, use the DHCP server 10.2.255.211 to allocate addresses to clients.

On sw211, complete the DHCP server configuration according to these requirements:

·         Create four new DHCP pools for the loT and Employees VNs on respective branches

o   Pool named br1_iot for Branch #1 loT VN

o   Pool named br1_emp for Branch #1 Employees VN

o   Pool named br2_iot for Branch #2 loT VN

o   Pool named br2_emp for Branch #2 Employees VN

·         In each subset, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

2.3                                                                                     : Mapping SDA VNs to SD-WAN VPNs

Using vManage GUI, perform configuration tasks according to these requirements:

·         Use any host, such as host11, to access the vManage GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Create three new SD-WAN VPNs to carry the SDA VN traffic

o   VPN ID 198 for IoT VN

o   VPN ID 199 for Guest VN

o   VPN ID 200 for Employees VN

·         On Branch #1 and Branch #2 vEdges, for each of these VPNs:

o   Create a new sub-interface on the interface toward the SDA border switch. Align the VLAN ID and IP address on the sub interface with the configuration generated by DNA Center on the border switches for the appropriate VN.

o   Peer the vEdge and the SDA border switch using iBGP. Ensure full reachability between all locations of the same VPN.

 

2.4                                                                           : Configuring SD-WAN VPN Route Leaking

To Allow the traditional parts of the FABD2 network to communication with the employees and IOT VPNs/VNs, configure route leaking in SD-WAN according to these requirements:

·         Prefixes in the IoT VPN 198 must be imported into the existing SDA Underlay VPN 999 and tagged with tag value of 198.

·         Prefixes in the Employees VPN 200 must be imported into the existing SDA Underlay VPN 999 and tagged with the tag value of 200

·         Prefixes in the SDA underlay VPN 999 advertised from the DC that are within the 10.4.0.0/15 range must be rejected. Other prefixes in the SDA underlay VPN 999 advertise from DC must be accepted and also imported into IoT VPN 198 and Employees VPN 200.

·         Redistribution from OMP into OSPF on Branches#1 and #2 in VPN 999 must exclude vRoutes tagged with values 198 or 200.

·         Place host41 into Employees VN. Place host51 into IoT VN. Make sure both hosts receive their IP setting from DHCP.

·         Ensure that the IoT and Employees VPNs on Branches #1 and #2 have reachability to Branches #3 and #4. It is allowed to modify the VPN 999 OMP settings to accomplish this requirement.

 

2.5                                                                                                                   : Handling Guest Traffic

The guest VN/VPN on Branches #1 and #2 must remain isolated from the rest of the company network. It ‘s only allowed to reach internet through r23 and r24 in the DC. Enable internet connectivity for the Guest VPN according to these requirements:

·         On Vedge21 and Vedge22, place the ge0/2 interfaces into the Guest VPN 199.

·         On r23 and r24, create a new VRF named Guest using the RD of 65002:199, and place the gi4 interfaces into the VRF.

·         Assign addresses to these Interfaces:

·         R23 Gi4: 10.2.123.1/24

·         R24 Gi4: 10.2.224.1/24

·         Vedge 21 gi0/2: 10.2.123.2/24

·         Vedge 22 Gi0/2: 10.2.224.2/24

·         Peer r23 and vedge21 in the Guest VRF/VPN using iBGP.

·         Peer r24 and vedge22 in the Guest VRF/VPN using iBGP.

·         Ensure that r23 and r24 learn the routes in the Guest VRF/VPN over iBGP.

·         On r23 and r24, configure a static default route in the Guest VRF and point it to the ISP’s IP address 200.99.23.1 or 200.99.24.1 as appropriate. Advertise this default route in iBGP to vedge21 and vedge22.

·         On r23 and r24, configure PAT to allow the Guest VPN to access internet by translating it to the router address on the link toward the ISP. Reuse the NAT ACL already created on the router. Do not use NAT pools. 

Configure r23 as DHCP server for Guest VPN according to these requirements:

·         Create loopback1 interface on r23 associated with the Guest VRF and having the IP address 10.2.255.211/32

·         Advertise this prefix in BGP toward vedge21.

·         Create DHCP Pool named br1_guest for branch#1 Guest subnet.

·         Create DHCP Pool named br2_guest for branch#2 Guest subnet.

·         Explicitly associate both DHCP pools with the VRF guest.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

·         Associate host42 and host52 with guest VN in DNAC, and make sure that both hosts receive the appropriate address.

·         Make sure that host42 and host 52 can ping 8.8.8.8 in the ISP cloud.

 

2.6                                                                                   : Support for silent Hosts in Branch #2

The item consists of multiple questions. You may need to scroll down to be able to see all questions. In future, Branch#2 will be equipped with IP-based IoT endpoints operating in speak-when-spoken-to mode also called silent hosts. Which of the following SDA features enables a working connectivity with these IoT endpoints?

·         Native Multicast

·         Endpoint Mobility

·         Layer 2 flooding

·         Layer 2 Extension

In the statement below, select one of the options from the drop-down list to complete the sentence and form a correct statement.

For SDA to support silent hosts,   ---------------------Selection Option----- in the underlay as a prerequisite.

Options:-

·         IP Multicast routing with PIM-SM must be enabled

·         No additional capability aside from unicast IP Connectivity is required.

·         IS-IS must be used as a routing protocol

·         DHCP Snooping must be enabled.

 

3.1: Enabling CLI access to r30

          There is no direct console access provided to the router r30. Moreover, r30 does not accept any remote connections because its VTY lines are configured with transport input non. Using RESTCONF, enable remote access to r30 for all remote access protocols, according to these requirements:

·         You can use host31 to access router r30 using ip address 10.3.11.1

·         You can use any method of accessing the RESTCONF API on r30 from host31, including curl, python, or postman.

·         You must change the input transport protocol on all configurable VTY lines.

·         The input transport protocol value setting must be changed from none to all.

Important Parameters:

·         Username / Password for HTTP authentication

§  admin / admin

§  URL

§ 

This is the hidden content, please

• Sign In
• or
• Sign Up

·         HTTP Method

§  GET

o   HTTP method to modify the configuration

§  PATCH

o   HTTP Headers

§  Content-Type:application/yang-data+json

§  Accept:application/yang-data+json

o   Recommended curl switches

§  -I,-k,-X,-H,-u,-d

 

3.2 Using Guest Shell and Python on r30

On r30, enable guestshell and create a python script name ribdump.py in the guestshell according to these requirements:

·         If an additional IP network is necessary to start guestshell, you are allowed to use addresses from the range 192.168.255.0/24. This range must not be advertised in any routing protocol.

·         The python script must be saved under the name ribdump.py in the home directory of the guestshell user.

·         The purpose of the script is to display the complete contents of all routing tables in non-default VRFs created on the router.

·         The script must execute the show ip route Vrf… or show ipv6 route vrf… command for every non default VRF created on the router, depending on what address families are enabled in that VRF.

·         The script must determine the list of created VRFs and enabled address families dynamically every time it is run using, for example, show vrf brief | include ipv4

·         The script must not attempt to display the VRF routing table for an address family that is not enabled in the VRF.

·         It must be possible to run the script using the guestshell run python ribdump.py command from privileged EXEC mode.

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

Please update the solution like CCIE V5.  I hope everyone will support and update their knowledge to make perfect solution.

 

[kumbi]

thank you

[Natasha]

Section 1.1

SW110
  
sw110(config)#spanning-tree mode rapid  
sw110(config)#spanning-tree pathcost method long 
sw110(config)#spanning-tree portfast edge default  

sw110(config)#interface range gi1/2-3  
sw110(config-if-range)#channel-group 2 mode active  

SW101  

sw101(config)#spanning-tree mode rapid 
sw101(config)#spanning-tree pathcost method long 
sw101(config)#spanning-tree vlan 2000 priority 0 
sw101(config)#spanning-tree vlan 1-4094 hello-time 1 

sw101(config)#interface range gi1/2-3  
sw101(config-if-range)#channel-group 1 mode on 

SW102

sw102(config)#spanning-tree mode rapid
sw102(config)#spanning-tree pathcost method long 
sw102(config)#spanning-tree vlan 2001 priority 0 
sw102(config)#spanning-tree vlan 1-4094 hello-time 1  

sw102(config)#interface range gi1/2-3  
sw102(config-if-range)#channel-group 2 mode active

Verification:  

sw110# sh etherchannel summary 
sh spanning-tree vlan 2000   
  
SWll0#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Pol (SU) LACP Gil/O(P) Gil/l(P) 
2 Po2 (SU) LACP Gil/2(P) Gil/3(P)

SWl02#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Po2 (SU) LACP Gil/2(P) Gil/3(P) 
2 Po3 (SU) LACP Gi2/0(P) Gi2/1(P)

SWl01#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Pol (SU) LACP Gil/2(P) Gil/3(P) 
2 Po2 (SU) LACP Gil/2(P) Gil/3(P)

 

[Merlz]

On 7/23/2021 at 10:34 PM, mrhacker said:

Thanks to all Dear's,

Below are the list of question and review and validate the solutions.

 

1.2                                                                                                       : Layer 2 Technologies in HQ

Complete and correct the EtherChannel configuration between switches sw101, sw102, sw110 according to these requirements:

 ·         At the end of the task, all EtherChannel’s between switches sw101, sw102, sw110 must be up and operational including all their physical member links.

·         Do not create new Port- channel interface; reuse those that already exist on the switches.

·         When resolving existing issues, do not change the preconfigured negotiation protocol (if any)

·         On EtherChannel’s that use a negotiation protocol, tune its mode of operation for the shortest link building time possible.

 

Configure spanning tree protocol on switches sw101, sw102, sw110 according to these requirements:

 

·         The STP root for VLAN 2000 must be sw101.

·         The STP root for VLAN 2001 must be sw102.

·         STP roots must be elected based on bridge priorities.

·         On the three switches, have STP perform cost calculations in 32-bit arithmetic.

·         On the three switches, use the Rapid STP version and ensure that it can achieve rapid convergence on all interconnections between the switches.

·         On Sw110, prevent all current and future access mode interfaces from being affected by the proposal/ Agreement process.

 

 

1.2                                                                                  : First Hop Redundancy Protocol in HQ

 

For IPv4, implement an FHRP mechanism on sw101 and sw102 fo rVLANs 2000 and 2001 according to these requirements:

 

·         Use Group number 100 for VLAN 2000 and group number 101 for VLAN 2001.

·         Use the first available IPV4 address in the subnet for the address of the virtual router.

·         For VLAN 2000, sw101 must be preferred gateway; for VLAN 2001, sw102 must be the preferred gateway. Do not rely on the IPv4 addresses of the switches as role tiebreakers. The role must determine by an explicit configuration solely on the intended preferred gateway.

·         Each preferred gateway must monitor the reachability of both routers r11 and r12 using the loopback IPv4 addresses of the routers by an ICMP Echo. The reachability is to be verified every 5 seconds with a timeout of 400 msec. A router must be declared unreachable as soon as it does not respond to three probes in a row. If both r11 an dr12 are declared unreachable from a preferred gateway, the other switch must be allowed to assume the gateway role.

·         Use the FHRP protocol that allows the virtual IPv4 address to match the IPv4 address of a member router.

 

 

1.3                                                                                                    : OSPFv2 between HQ and DC

 

Complete and correct the OSPF configuration on the switches sw101, sw102,sw201 and sw202 according to these requirements:

 

·         Enable OSPFv2 on the redundant interconnections between the DC and HQ sites. Make sure that establishes adjacencies on these interconnections and exchanges routing information between the DC and HQ sites.

·         Protect the authenticity and integrity of the OSPFv2 sessions on the redundant interconnections between DC and HQ with the SHA-384 mechanism. Use key ID 1 and a shared secret of “cci3” (without quotes).

·         Improve the detection of unreachable OSPFv2 neighbors on the redundant interconnections between DC and HQ so that OSPF can detect the loss of a neighbor within 200 msec, with the probes being sent every 100 msec. it is not allowed to modify ODPF timers to accomplish this requirement.

 

 

1.4                                                                                                            : DHCP IPv4 service for HQ

 

Enable hosts in HQ VLAN 2000 and VLAN 2001 to obtain their IP configuration via DHCP according to these requirements:

 

·         On sw211, create IPv4 DHCP pools named hq_v2000 and hq_v2001 for HQ VLANs 2000 and 2001, respectively. In each subnet, assign addresses from .101 upto .254 inclusively, and the appropriate gateway to clients.

·         Enable DHCP snooping on sw110 in VLANs 2000 and 2001 to protect against DHCP-related attacks.

·         Place host11 into VLAN 2000.

·         Place host12 into VLAN 2001.

·         Perform the necessary configuration on switches sw101, sw102, sw110 to enable hosts in VLANs2000 and 2001 to obtain IPv4 configuration through DHCP. The DHCP server running at sw211 in the DC must be referred to by its loopback IPv4 address 10.2.255.211. Do not disable the Option 82 insertion, and do not enable DHCP snooping on other switches.

·         Verify that host11 and host12 have IP connectivity to the Cisco DNA Center, VManage and UCE running in the DC using their internal (In Band Connectivity) addresses.

 

1.5                                                                                                                                             : IPv6 in HQ

 

Implement IPv6 on sw101 and sw102 for switch virtual interfaces (SVIs) Vlan 2000 and Vlan 2001 according to these requirements:

·         sw101

Interface Vlan2000:2001:db:8:1:100::1/64 Interface Vlan2001:2001:db8:1:101::1/64

 

·         sw102

Interface Vlan2000:2001:db8:1:100::2/64 Interface Vlan2001:2001:db8:1:101::2/64

 

·         The configuration must enable hosts in these VLANs to obtain their IPv6 configuration via SLAAC and keep a stable connectivity with other IPv6 networks.

·         Use native IPv6 means to provide gateway redundancy, with sw101 being the preferred gateway in VLAN 2000 and sw102 being the preferred gateway in VLAN 2001. The role must be determined by an explicit configuration solely on the intended preferred gateway.

·         Hosts must be able to detect the failure of the preferred gateway in as little as 3 seconds.

 

1.6                                                                                                                              : IPv6 EIGRP in HQ

 

In HQ, enable EIGRP for IPv6 on r11, r12, sw101 and sw102 according to these requirements:

·         Use process name “ccie” (without the quotes) and AS number 65001.

·         Do not configure any additional IPv6 addresses.

·         IPv6 EIGRP may form adjacencies only over the physical Layer3 interfaces between r11, r12, sw101 and sw102.

·         Prevent IPv6 EIGRP from automatically running on, or advertising attached prefixes from, new IPv6-enabled interfaces in the future unless allowed explicitly.

·         Ensure that the attached IPv6 prefixes on SVIs Vlan2000 and Vlan2001 onsw101 and sw102 are advertised in IPv6 EIGRP and learned on r11 and r12.

·         No route filtering is allowed to accomplish this entire task.

 

1.7                                                                                                                                      : OSPFv2 in DC

 

Configure devices in the DC according to these requirements:

 

·         Switches sw201 and sw202 must establish a stable OSPF adjacency in the FULL state with vedge21 and vedge22 on interface Vlan3999. Any configuration changes and corrections necessary to meet this requirement may be performed only on the switches, and any mismatched parameters causing the issue must be changed to exactly match the configuration of the vEdges.

·         All OSPF speakers in the DC running Cisco IOS and IOS-XE software must be configured to keep the number of advertised internal routes to an absolute minimum while not impacting the reachability of the services. This included the reachability of ISE,DNA center,vManage,vBond and vSmart on their internal (in Band Connectivty) addresses, as well as any existing and future devices in VLAN 4000 and sw201 and sw202. The configuration of this requirement must be completed exclusively within the “router ospf” and “interface vlan” contexts without causing any impact to existing OSPF adjacencies.

·         Router r24 must advertise two prefixes, 10.6.0.0/15 and 10.200.0.0/24, as Type-5 LSAs in OSPFv2 to provide HQ and DC with the reachability to the DMVPN tunnel and branches #3 and #4. The configuration of this requirement must be completed exclusively within the “router ospf” context.

·         Any route from the 10.2.0.0/16 range that keeps being advertised in OSPF must continue being advertised as an intra-area route.

·         It is not allowed to modify existing areas to accomplish this entire task.

 

1.8                                                                     : BGP between HQ/DC and service providers

Configure the BGP peering’s between HQ/DC and Global SP#1 and Global SP#2 according to these requirements:

·         Bring up the BGP peering between HQ r11 and SP#1 r3

·         Bring up the BGP peering between DC r21 and SP#1 r3

·         Bring up the BGP Peering between DC r22 and SP#2

·         Ensure that the routes learned over eBGP sessions and further advertised in iBGP will be considered reachable even if the networks on inter-AS links are not advertised in OSPF. The configuration of this requirement must be completed exclusively within the “router bgp” context.

·         On r11, r21 and r22 perform mutual redistribution between OSPFv2 and BGP. However, prevent routes that were injected into OSPF from BGP to be reinjected back into BGP. This requirement must be solved on r11, r21 and r22 using only a single route-map on each of the routers and without any reference to ACLs, prefix lists, or route types.

·         Prevent HQ and DC from ever communicating through SP#1 r3. All Communication between HQ and DC must occur only over the direct SW101/SW201 and SW102/SW202 interconnections. Any other communication must remain unaffected. This requirement must be solved on r21 and r22 by route filtering based on a well-known mandatory attribute without the use of route maps.

·         No command may be removed from the configuration on r11 to accomplish this entire task.

·         It is allowed to modify existing configuration commands on r21 and r22 to accomplish this entire task.

 

1.9                                                                                           : Bringing up VPNv4/VPNv6 in SP#1

 

Configure routers r3, r4, r5 and r6 in SP#1 according to these requirements:

 

·         Configure r3 through r6 for mutual VPNv4 and VPNv6 route exchange without the use of a route reflector. Use Lo0 IPv4 addresses for peering’s.

·         Configure r3 through r6 to assign (allocate/bind) as few unique MPLS labels to all existing and future VPNv4 and VPNv6 routes as possible.

·         On Routers r3 through r6, prevent any existing and future customer from discovering details about the inner topology of SP#1. It is not allowed to use ACLs to accomplish this requirement.

1.10  : Fixing Broken DMVPN between Dc and Branches #3 and #4

Correct the configuration issues resulting in broken DMVPN tunnel connectivity between DC, Branch3 and Branch4 according to these requirements:

·         The DMVPN must operate in IPsec-protected phase 3 mode.

·         Using the FVRF approach, safeguard the DMVPN operation against any potential recursive routing issues involving the tunnel.

·         Do not create any new VRFs.

·         Do not change the tunnel source commands on Tunnel interfaces.

·         On Spokes, do not add new BGP neighbors; reuse those that are currently up while changing their VRF membership as needed.

·         It is not allowed to modify configuration on DC r24 to complete this entire task.

 

1.11                                               : Tuning EIGRP on DMVPN and DMVPN-enabled Sites

Optimize the DMVPN operation according to these requirements:

·         Ensure that Branches#3 and #4 receive only a default route over EIGRP in DMVPN.

·         The default route origination must be done on DC r24 without the use of any static routes, redistribution, or route filtering.

·         It is not allowed to modify the configuration of r61 and r62 in Branch#3 to accomplish this task;

·         It is allowed to add commands to the configuration of r70 in branch #4 to accomplish this task;

None of the existing configuration on r70 may be removed to accomplish this task.

           

            Configure Sw601 and Sw602 at Branch#3 according to these requirements:

·         Routers r61 and r62 must not send EIGRP queries to SW601 and SW602.

·         Switches SW601 and SW602 must allow advertising any current or future directly connected network to r61 and r62 after the network is added to EIGRP.

·         Switches Sw601 and Sw602 must continue to propagate the default route received from r61 and r62 to each other. To Select the default route, use a prefix list with a “Permit” – type entry only.

·         Switches SW601 and SW602 must not propagate the default route back to r61 and r62.

·         If the prefix list that allows the propagation of selected EIGRP-learned networks between sw601 and sw602 is modified in the future, the same set of networks must be disallowed from being advertised back to r61 and r62 automatically, without any additional commands.

·          

 

1.12                                                                                     : IPv4 Networks on Legacy Branches

 

On sw211 in DC, complete the DHCP server configuration according to these requirements:

 

·         Create IPv4 DHCP pools named br3_v2000 and br3_v2001 for Branch #3 VLANs 2000 (10.6.100.0/24) and 2001 (10.6.101.0/24), respectively.

·         Create IPv4 DHCP pool named br4_v1 for the subnet 10.7.1.0/24 on branch #4.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

On Branch #3; Complete and correct the configuration on switches sw601, sw602 and sw610 to allow HSRP and DHCP relay operation in VLANs 2000 and 2001 according to these requirements:

 

·         HSRP must implicitly use the vMAC address range of 0000. 0c9f.f000 through 0000. 0c9f.ffff

·         The group member must be 100 for VLAN 2000 and 101 for VLAN 2001

·         Sw601 must be the Active gateway for VLAN 2000 with a priority of 110; the Active role ownership must be deterministic

·         Sw602 must be the Active gateway for VLAN 2001 with a priority of 110; the Active role ownership must be deterministic

·         Each active switch must track its uplink interfaces gi0/1 and gi0/2/ if either of these interfaces goes down; the active switch must allow the other switch to become Active. However, it is not allowed for the tracking to modify the HSRP priority to accomplish this requirement.

·         Both sw601 and sw602 must be configured as DHCP relay agents in both VLANs 2000 and 2001, pointing toward the DHCP server 10.2.255.211 at sw211. However, at any time, only the Active router in the particular VLAN should relay the DHCP messages.

·         Place host61 and host62 into VLANs 2000 and 2001, respectively, and make sure they are assigned their correct IPv4 configuration.

It is not permitted to use any kind of scripting to complete this task.

 

On Branch #4, complete the configuration of the router r70 according to these requirements;

 

·         Assign IP address 10.7.1.1/24 to gi0/2

·         Enable DHCP relay on this interface and point it to the DHCP server 10.2.255.211 at sw211

·         It is allowed to add one additional missing command to the r70 configuration to allow DHCP clients connected to gi0/2 obtain their IPv4 configuration.

·         Make sure that host71 and host72 are assigned their correct IPv4 configuration.

 

1.13                                                                                                                       : Multicast in FABD2

FABD2 is preparing to enable PIM Sparse mode multicast routing in its network. As a part of validating the runbooks, FABD2 requires a sanity check to prevent inappropriate use of multicast-related configuration commands on different router types:

·         First Hop Routers – Routers where multicast sources are connected

·         Last Hop Routers- routers where multicast receivers (subscribers) are connected

·         Intermediary Hop Routers- routers on the path between First Hop and Last Hop routers In the Table below, for each configuration command, select all router type where the use of the command is appropriate. (Select all that apply)

 

Router Type
Command	First Hop Router	Intermediary Hop Router	Last Hop Router
Ip pim register-source	ÿ	ÿ	ÿ
Ip igmp version	ÿ	ÿ	ÿ
ip pim spt-threshold	ÿ	ÿ	ÿ
ip pim rp-address	ÿ	ÿ	ÿ
IP pim sparse-mode	ÿ	ÿ	ÿ

 

 1.14                                                                                     : Extending Connectivity to laaS Site

 Extend the IPv6 connectivity from HQ through the SP into the giosk VRF on the laaS site according to these requirements:

 Set up global IPv6 addressing on the link between r11 and r3

·         On r11, assign 2001:2710:311::2/64 to g0/0

·         On r3, assign 2001:2710:311::1/64 to g1

·         Enable the existing IPv4 BGP session between r11 and r3 to also advertise IPv6 prefixes. Do not configure a standalone IPv6 BGP session between these two routers.

·         Perform bidirectional route redistribution between the IPv6 EIGRP and BGP processes on r11.

·         Ensure that all current and future IPv6 prefixes advertised between r11 and r3 will be installed into the RIB of these routers with the next hop address set to the proper global unicast address on their interconnection. Any policy that accomplishes this requirement must be applied in the inbound direction.

·         The giosk VRF on r4 that extends the IPv6 connectivity from r4 to r30 on the laaS site is a separate VRF independent of fabd2 VRF. Any route leaking from fabd2 VRF into giosk VRF must be done on per-site basis and only for those FABD2 sites that need connectivity in the laaS site.

·         By configuring r3 and r4 only, ensure that the HQ FABD2 site will have mutual visibility with the laaS site while preventing

-          Any other FABD2 site from possibly learning about the routes on the laaS site

-          The laaS site from possibly learning about the routes on any other FABD2 site

 Use the minimum amount of commands necessary to accomplish this requirement. Do not remove any existing configuration. If necessary, you are allowed to use an additional route target with the value of 10000:3681.

·         Verify that host11 and host12 can ping 2001:db8:14::1 located at the laaS site. It is permitted to modify one existing configuration command on one of the SP routers to meet this requirement.

 

1.15                                                                                    : Enabling Internet Access for FABD2

 

Enable highly available internet access for the FABD2 company network according to these requirements:

·         On routers r12, r23 and r24, bring up IPv4 BGP peerings with the ISP, make sure that a default route is received over these peerings.

·         On router r12 and r23, inject default route into OSPF if it present in the routing table from a different routing source than the OSPFv2 process 1. On each router, this requirement must be completed using the minimum possible number of commands.

·         On route r24, inject default route into OSPF if any only if it is learned from ISP over BGP, To accomplish this requirement, it is allowed to use a route-map that referenced both a prefix-list and tag. This requirement must be completed using the minimum possible number of commands.

·         Router r12 may be used as an internet exit for the FABD2 company network only if neither r23 nor r24 are advertising the default route in OSPF. This requirement must be accomplished exclusively in “router ospf” mode on router r12 without changing the default parameters on routers r23 and r24.

·         On routers r12, r23 and r24, configure PAT and translate the entire FABD2 internal network 10.0.0.0/8 to the router address on the link toward the ISP. Create a standard ACL named NAT for this purpose. Do not use NAT pools.

Ensure that the internet connectivity of the FABD2 company network makes use of the highly availability provided by r12, r23 and r24.

 

2.1 : Correcting the IP addresses of Managed switches in DNA center

After Cisco DNA center first achieves IP connectivity with the managed switches in Branches #1 and #2, it will place them into maintenance mode due to their serial number being different from the one DNA center remember, In addition, their management IP addresses in DNA Center will be automatically changed by appending them with the “.dummy.com” string. As a result, after an initial contact, DNA Center will lose connectivity with the switches unless their management IP addresses are corrected in the DNA center settings.

Correct the IP addresses of managed switches in the DNA center according to the following requirements:

·         Use any host, such as host11, to access the DNA Center GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Execute the provision-Devices- Inventory- Global- Actions-Inventory- Resync Device action in DNA Center on all switches before proceeding further.

·         DNA Center API reference and sandbox is available at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         The /network/device/update-maintenance-device-ip-address API call description and sandbox are available in the Inventory section of the API reference.

·         Use the /network-device/update-maintenance-device-ip address API call to correct the IP addresses of the switches in Branches #1 and #2 by removing the appended text.

Note: These IP addresses cannot be changed from DNA Center GUI directly because they will become automatically invalidated again. This is a built-in DNA Center behavior.

 

2.2                                                                   : Completing VN Configuration in DNA center

Using the DNA Center GUI, perform configuration tasks according to these requirements:

·         Add new virtual Network named IoT for the internet-of-things network on the Branches #1 and #2

·         Create new address pools for the IoT VN named Branch1- For IoT and Branch2-ForIoT on the global level, and branch1-IoT and Branch2-IoT on the Branch level.

·         For Branch #1 loT VN, allocate the subnet 10.4.198.0/24 and the gateway IP address 10.4.198.1.

·         For Branch #2 loT VN, allocate the subnet 10.5.198.0/24, and the gateway IP address 10.5.198.1.

·         Associate the Branch1-loT and Branch2-loT pools with the loT VN on the respective branches.

·         Complete the configuration of the address pools for the Guest VN in the DNA Center so that Branch #1 and Branch #2 can accommodate guest connections. If a new address pool needs to be created and an address range allocated to it, follow the established addressing plan.

·         Correct the addressing information currently defined for the Branch2- For Employees and Branch2- Employees address pool.

·         For all address pools, use the DHCP server 10.2.255.211 to allocate addresses to clients.

On sw211, complete the DHCP server configuration according to these requirements:

·         Create four new DHCP pools for the loT and Employees VNs on respective branches

o   Pool named br1_iot for Branch #1 loT VN

o   Pool named br1_emp for Branch #1 Employees VN

o   Pool named br2_iot for Branch #2 loT VN

o   Pool named br2_emp for Branch #2 Employees VN

·         In each subset, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

2.3                                                                                     : Mapping SDA VNs to SD-WAN VPNs

Using vManage GUI, perform configuration tasks according to these requirements:

·         Use any host, such as host11, to access the vManage GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Create three new SD-WAN VPNs to carry the SDA VN traffic

o   VPN ID 198 for IoT VN

o   VPN ID 199 for Guest VN

o   VPN ID 200 for Employees VN

·         On Branch #1 and Branch #2 vEdges, for each of these VPNs:

o   Create a new sub-interface on the interface toward the SDA border switch. Align the VLAN ID and IP address on the sub interface with the configuration generated by DNA Center on the border switches for the appropriate VN.

o   Peer the vEdge and the SDA border switch using iBGP. Ensure full reachability between all locations of the same VPN.

 

2.4                                                                           : Configuring SD-WAN VPN Route Leaking

To Allow the traditional parts of the FABD2 network to communication with the employees and IOT VPNs/VNs, configure route leaking in SD-WAN according to these requirements:

·         Prefixes in the IoT VPN 198 must be imported into the existing SDA Underlay VPN 999 and tagged with tag value of 198.

·         Prefixes in the Employees VPN 200 must be imported into the existing SDA Underlay VPN 999 and tagged with the tag value of 200

·         Prefixes in the SDA underlay VPN 999 advertised from the DC that are within the 10.4.0.0/15 range must be rejected. Other prefixes in the SDA underlay VPN 999 advertise from DC must be accepted and also imported into IoT VPN 198 and Employees VPN 200.

·         Redistribution from OMP into OSPF on Branches#1 and #2 in VPN 999 must exclude vRoutes tagged with values 198 or 200.

·         Place host41 into Employees VN. Place host51 into IoT VN. Make sure both hosts receive their IP setting from DHCP.

·         Ensure that the IoT and Employees VPNs on Branches #1 and #2 have reachability to Branches #3 and #4. It is allowed to modify the VPN 999 OMP settings to accomplish this requirement.

 

2.5                                                                                                                   : Handling Guest Traffic

The guest VN/VPN on Branches #1 and #2 must remain isolated from the rest of the company network. It ‘s only allowed to reach internet through r23 and r24 in the DC. Enable internet connectivity for the Guest VPN according to these requirements:

·         On Vedge21 and Vedge22, place the ge0/2 interfaces into the Guest VPN 199.

·         On r23 and r24, create a new VRF named Guest using the RD of 65002:199, and place the gi4 interfaces into the VRF.

·         Assign addresses to these Interfaces:

·         R23 Gi4: 10.2.123.1/24

·         R24 Gi4: 10.2.224.1/24

·         Vedge 21 gi0/2: 10.2.123.2/24

·         Vedge 22 Gi0/2: 10.2.224.2/24

·         Peer r23 and vedge21 in the Guest VRF/VPN using iBGP.

·         Peer r24 and vedge22 in the Guest VRF/VPN using iBGP.

·         Ensure that r23 and r24 learn the routes in the Guest VRF/VPN over iBGP.

·         On r23 and r24, configure a static default route in the Guest VRF and point it to the ISP’s IP address 200.99.23.1 or 200.99.24.1 as appropriate. Advertise this default route in iBGP to vedge21 and vedge22.

·         On r23 and r24, configure PAT to allow the Guest VPN to access internet by translating it to the router address on the link toward the ISP. Reuse the NAT ACL already created on the router. Do not use NAT pools. 

Configure r23 as DHCP server for Guest VPN according to these requirements:

·         Create loopback1 interface on r23 associated with the Guest VRF and having the IP address 10.2.255.211/32

·         Advertise this prefix in BGP toward vedge21.

·         Create DHCP Pool named br1_guest for branch#1 Guest subnet.

·         Create DHCP Pool named br2_guest for branch#2 Guest subnet.

·         Explicitly associate both DHCP pools with the VRF guest.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

·         Associate host42 and host52 with guest VN in DNAC, and make sure that both hosts receive the appropriate address.

·         Make sure that host42 and host 52 can ping 8.8.8.8 in the ISP cloud.

 

 

2.6                                                                                   : Support for silent Hosts in Branch #2

The item consists of multiple questions. You may need to scroll down to be able to see all questions. In future, Branch#2 will be equipped with IP-based IoT endpoints operating in speak-when-spoken-to mode also called silent hosts. Which of the following SDA features enables a working connectivity with these IoT endpoints?

·         Native Multicast

·         Endpoint Mobility

·         Layer 2 flooding

·         Layer 2 Extension

In the statement below, select one of the options from the drop-down list to complete the sentence and form a correct statement.

For SDA to support silent hosts,   ---------------------Selection Option----- in the underlay as a prerequisite.

Options:-

·         IP Multicast routing with PIM-SM must be enabled

·         No additional capability aside from unicast IP Connectivity is required.

·         IS-IS must be used as a routing protocol

·         DHCP Snooping must be enabled.

 

3.1: Enabling CLI access to r30

          There is no direct console access provided to the router r30. Moreover, r30 does not accept any remote connections because its VTY lines are configured with transport input non. Using RESTCONF, enable remote access to r30 for all remote access protocols, according to these requirements:

·         You can use host31 to access router r30 using ip address 10.3.11.1

·         You can use any method of accessing the RESTCONF API on r30 from host31, including curl, python, or postman.

·         You must change the input transport protocol on all configurable VTY lines.

·         The input transport protocol value setting must be changed from none to all.

Important Parameters:

·         Username / Password for HTTP authentication

§  admin / admin

§  URL

§ 

This is the hidden content, please

• Sign In
• or
• Sign Up

·         HTTP Method

§  GET

o   HTTP method to modify the configuration

§  PATCH

o   HTTP Headers

§  Content-Type:application/yang-data+json

§  Accept:application/yang-data+json

o   Recommended curl switches

§  -I,-k,-X,-H,-u,-d

 

3.2 Using Guest Shell and Python on r30

On r30, enable guestshell and create a python script name ribdump.py in the guestshell according to these requirements:

·         If an additional IP network is necessary to start guestshell, you are allowed to use addresses from the range 192.168.255.0/24. This range must not be advertised in any routing protocol.

·         The python script must be saved under the name ribdump.py in the home directory of the guestshell user.

·         The purpose of the script is to display the complete contents of all routing tables in non-default VRFs created on the router.

·         The script must execute the show ip route Vrf… or show ipv6 route vrf… command for every non default VRF created on the router, depending on what address families are enabled in that VRF.

·         The script must determine the list of created VRFs and enabled address families dynamically every time it is run using, for example, show vrf brief | include ipv4

·         The script must not attempt to display the VRF routing table for an address family that is not enabled in the VRF.

·         It must be possible to run the script using the guestshell run python ribdump.py command from privileged EXEC mode.

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

Please update the solution like CCIE V5.  I hope everyone will support and update their knowledge to make perfect solution.

 

 

On 7/23/2021 at 10:34 PM, mrhacker said:

Thanks to all Dear's,

Below are the list of question and review and validate the solutions.

 

1.2                                                                                                       : Layer 2 Technologies in HQ

Complete and correct the EtherChannel configuration between switches sw101, sw102, sw110 according to these requirements:

 ·         At the end of the task, all EtherChannel’s between switches sw101, sw102, sw110 must be up and operational including all their physical member links.

·         Do not create new Port- channel interface; reuse those that already exist on the switches.

·         When resolving existing issues, do not change the preconfigured negotiation protocol (if any)

·         On EtherChannel’s that use a negotiation protocol, tune its mode of operation for the shortest link building time possible.

 

Configure spanning tree protocol on switches sw101, sw102, sw110 according to these requirements:

 

·         The STP root for VLAN 2000 must be sw101.

·         The STP root for VLAN 2001 must be sw102.

·         STP roots must be elected based on bridge priorities.

·         On the three switches, have STP perform cost calculations in 32-bit arithmetic.

·         On the three switches, use the Rapid STP version and ensure that it can achieve rapid convergence on all interconnections between the switches.

·         On Sw110, prevent all current and future access mode interfaces from being affected by the proposal/ Agreement process.

 

 

1.2                                                                                  : First Hop Redundancy Protocol in HQ

 

For IPv4, implement an FHRP mechanism on sw101 and sw102 fo rVLANs 2000 and 2001 according to these requirements:

 

·         Use Group number 100 for VLAN 2000 and group number 101 for VLAN 2001.

·         Use the first available IPV4 address in the subnet for the address of the virtual router.

·         For VLAN 2000, sw101 must be preferred gateway; for VLAN 2001, sw102 must be the preferred gateway. Do not rely on the IPv4 addresses of the switches as role tiebreakers. The role must determine by an explicit configuration solely on the intended preferred gateway.

·         Each preferred gateway must monitor the reachability of both routers r11 and r12 using the loopback IPv4 addresses of the routers by an ICMP Echo. The reachability is to be verified every 5 seconds with a timeout of 400 msec. A router must be declared unreachable as soon as it does not respond to three probes in a row. If both r11 an dr12 are declared unreachable from a preferred gateway, the other switch must be allowed to assume the gateway role.

·         Use the FHRP protocol that allows the virtual IPv4 address to match the IPv4 address of a member router.

 

 

1.3                                                                                                    : OSPFv2 between HQ and DC

 

Complete and correct the OSPF configuration on the switches sw101, sw102,sw201 and sw202 according to these requirements:

 

·         Enable OSPFv2 on the redundant interconnections between the DC and HQ sites. Make sure that establishes adjacencies on these interconnections and exchanges routing information between the DC and HQ sites.

·         Protect the authenticity and integrity of the OSPFv2 sessions on the redundant interconnections between DC and HQ with the SHA-384 mechanism. Use key ID 1 and a shared secret of “cci3” (without quotes).

·         Improve the detection of unreachable OSPFv2 neighbors on the redundant interconnections between DC and HQ so that OSPF can detect the loss of a neighbor within 200 msec, with the probes being sent every 100 msec. it is not allowed to modify ODPF timers to accomplish this requirement.

 

 

1.4                                                                                                            : DHCP IPv4 service for HQ

 

Enable hosts in HQ VLAN 2000 and VLAN 2001 to obtain their IP configuration via DHCP according to these requirements:

 

·         On sw211, create IPv4 DHCP pools named hq_v2000 and hq_v2001 for HQ VLANs 2000 and 2001, respectively. In each subnet, assign addresses from .101 upto .254 inclusively, and the appropriate gateway to clients.

·         Enable DHCP snooping on sw110 in VLANs 2000 and 2001 to protect against DHCP-related attacks.

·         Place host11 into VLAN 2000.

·         Place host12 into VLAN 2001.

·         Perform the necessary configuration on switches sw101, sw102, sw110 to enable hosts in VLANs2000 and 2001 to obtain IPv4 configuration through DHCP. The DHCP server running at sw211 in the DC must be referred to by its loopback IPv4 address 10.2.255.211. Do not disable the Option 82 insertion, and do not enable DHCP snooping on other switches.

·         Verify that host11 and host12 have IP connectivity to the Cisco DNA Center, VManage and UCE running in the DC using their internal (In Band Connectivity) addresses.

 

1.5                                                                                                                                             : IPv6 in HQ

 

Implement IPv6 on sw101 and sw102 for switch virtual interfaces (SVIs) Vlan 2000 and Vlan 2001 according to these requirements:

·         sw101

Interface Vlan2000:2001:db:8:1:100::1/64 Interface Vlan2001:2001:db8:1:101::1/64

 

·         sw102

Interface Vlan2000:2001:db8:1:100::2/64 Interface Vlan2001:2001:db8:1:101::2/64

 

·         The configuration must enable hosts in these VLANs to obtain their IPv6 configuration via SLAAC and keep a stable connectivity with other IPv6 networks.

·         Use native IPv6 means to provide gateway redundancy, with sw101 being the preferred gateway in VLAN 2000 and sw102 being the preferred gateway in VLAN 2001. The role must be determined by an explicit configuration solely on the intended preferred gateway.

·         Hosts must be able to detect the failure of the preferred gateway in as little as 3 seconds.

 

1.6                                                                                                                              : IPv6 EIGRP in HQ

 

In HQ, enable EIGRP for IPv6 on r11, r12, sw101 and sw102 according to these requirements:

·         Use process name “ccie” (without the quotes) and AS number 65001.

·         Do not configure any additional IPv6 addresses.

·         IPv6 EIGRP may form adjacencies only over the physical Layer3 interfaces between r11, r12, sw101 and sw102.

·         Prevent IPv6 EIGRP from automatically running on, or advertising attached prefixes from, new IPv6-enabled interfaces in the future unless allowed explicitly.

·         Ensure that the attached IPv6 prefixes on SVIs Vlan2000 and Vlan2001 onsw101 and sw102 are advertised in IPv6 EIGRP and learned on r11 and r12.

·         No route filtering is allowed to accomplish this entire task.

 

1.7                                                                                                                                      : OSPFv2 in DC

 

Configure devices in the DC according to these requirements:

 

·         Switches sw201 and sw202 must establish a stable OSPF adjacency in the FULL state with vedge21 and vedge22 on interface Vlan3999. Any configuration changes and corrections necessary to meet this requirement may be performed only on the switches, and any mismatched parameters causing the issue must be changed to exactly match the configuration of the vEdges.

·         All OSPF speakers in the DC running Cisco IOS and IOS-XE software must be configured to keep the number of advertised internal routes to an absolute minimum while not impacting the reachability of the services. This included the reachability of ISE,DNA center,vManage,vBond and vSmart on their internal (in Band Connectivty) addresses, as well as any existing and future devices in VLAN 4000 and sw201 and sw202. The configuration of this requirement must be completed exclusively within the “router ospf” and “interface vlan” contexts without causing any impact to existing OSPF adjacencies.

·         Router r24 must advertise two prefixes, 10.6.0.0/15 and 10.200.0.0/24, as Type-5 LSAs in OSPFv2 to provide HQ and DC with the reachability to the DMVPN tunnel and branches #3 and #4. The configuration of this requirement must be completed exclusively within the “router ospf” context.

·         Any route from the 10.2.0.0/16 range that keeps being advertised in OSPF must continue being advertised as an intra-area route.

·         It is not allowed to modify existing areas to accomplish this entire task.

 

1.8                                                                     : BGP between HQ/DC and service providers

Configure the BGP peering’s between HQ/DC and Global SP#1 and Global SP#2 according to these requirements:

·         Bring up the BGP peering between HQ r11 and SP#1 r3

·         Bring up the BGP peering between DC r21 and SP#1 r3

·         Bring up the BGP Peering between DC r22 and SP#2

·         Ensure that the routes learned over eBGP sessions and further advertised in iBGP will be considered reachable even if the networks on inter-AS links are not advertised in OSPF. The configuration of this requirement must be completed exclusively within the “router bgp” context.

·         On r11, r21 and r22 perform mutual redistribution between OSPFv2 and BGP. However, prevent routes that were injected into OSPF from BGP to be reinjected back into BGP. This requirement must be solved on r11, r21 and r22 using only a single route-map on each of the routers and without any reference to ACLs, prefix lists, or route types.

·         Prevent HQ and DC from ever communicating through SP#1 r3. All Communication between HQ and DC must occur only over the direct SW101/SW201 and SW102/SW202 interconnections. Any other communication must remain unaffected. This requirement must be solved on r21 and r22 by route filtering based on a well-known mandatory attribute without the use of route maps.

·         No command may be removed from the configuration on r11 to accomplish this entire task.

·         It is allowed to modify existing configuration commands on r21 and r22 to accomplish this entire task.

 

1.9                                                                                           : Bringing up VPNv4/VPNv6 in SP#1

 

Configure routers r3, r4, r5 and r6 in SP#1 according to these requirements:

 

·         Configure r3 through r6 for mutual VPNv4 and VPNv6 route exchange without the use of a route reflector. Use Lo0 IPv4 addresses for peering’s.

·         Configure r3 through r6 to assign (allocate/bind) as few unique MPLS labels to all existing and future VPNv4 and VPNv6 routes as possible.

·         On Routers r3 through r6, prevent any existing and future customer from discovering details about the inner topology of SP#1. It is not allowed to use ACLs to accomplish this requirement.

1.10  : Fixing Broken DMVPN between Dc and Branches #3 and #4

Correct the configuration issues resulting in broken DMVPN tunnel connectivity between DC, Branch3 and Branch4 according to these requirements:

·         The DMVPN must operate in IPsec-protected phase 3 mode.

·         Using the FVRF approach, safeguard the DMVPN operation against any potential recursive routing issues involving the tunnel.

·         Do not create any new VRFs.

·         Do not change the tunnel source commands on Tunnel interfaces.

·         On Spokes, do not add new BGP neighbors; reuse those that are currently up while changing their VRF membership as needed.

·         It is not allowed to modify configuration on DC r24 to complete this entire task.

 

1.11                                               : Tuning EIGRP on DMVPN and DMVPN-enabled Sites

Optimize the DMVPN operation according to these requirements:

·         Ensure that Branches#3 and #4 receive only a default route over EIGRP in DMVPN.

·         The default route origination must be done on DC r24 without the use of any static routes, redistribution, or route filtering.

·         It is not allowed to modify the configuration of r61 and r62 in Branch#3 to accomplish this task;

·         It is allowed to add commands to the configuration of r70 in branch #4 to accomplish this task;

None of the existing configuration on r70 may be removed to accomplish this task.

           

            Configure Sw601 and Sw602 at Branch#3 according to these requirements:

·         Routers r61 and r62 must not send EIGRP queries to SW601 and SW602.

·         Switches SW601 and SW602 must allow advertising any current or future directly connected network to r61 and r62 after the network is added to EIGRP.

·         Switches Sw601 and Sw602 must continue to propagate the default route received from r61 and r62 to each other. To Select the default route, use a prefix list with a “Permit” – type entry only.

·         Switches SW601 and SW602 must not propagate the default route back to r61 and r62.

·         If the prefix list that allows the propagation of selected EIGRP-learned networks between sw601 and sw602 is modified in the future, the same set of networks must be disallowed from being advertised back to r61 and r62 automatically, without any additional commands.

·          

 

1.12                                                                                     : IPv4 Networks on Legacy Branches

 

On sw211 in DC, complete the DHCP server configuration according to these requirements:

 

·         Create IPv4 DHCP pools named br3_v2000 and br3_v2001 for Branch #3 VLANs 2000 (10.6.100.0/24) and 2001 (10.6.101.0/24), respectively.

·         Create IPv4 DHCP pool named br4_v1 for the subnet 10.7.1.0/24 on branch #4.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

On Branch #3; Complete and correct the configuration on switches sw601, sw602 and sw610 to allow HSRP and DHCP relay operation in VLANs 2000 and 2001 according to these requirements:

 

·         HSRP must implicitly use the vMAC address range of 0000. 0c9f.f000 through 0000. 0c9f.ffff

·         The group member must be 100 for VLAN 2000 and 101 for VLAN 2001

·         Sw601 must be the Active gateway for VLAN 2000 with a priority of 110; the Active role ownership must be deterministic

·         Sw602 must be the Active gateway for VLAN 2001 with a priority of 110; the Active role ownership must be deterministic

·         Each active switch must track its uplink interfaces gi0/1 and gi0/2/ if either of these interfaces goes down; the active switch must allow the other switch to become Active. However, it is not allowed for the tracking to modify the HSRP priority to accomplish this requirement.

·         Both sw601 and sw602 must be configured as DHCP relay agents in both VLANs 2000 and 2001, pointing toward the DHCP server 10.2.255.211 at sw211. However, at any time, only the Active router in the particular VLAN should relay the DHCP messages.

·         Place host61 and host62 into VLANs 2000 and 2001, respectively, and make sure they are assigned their correct IPv4 configuration.

It is not permitted to use any kind of scripting to complete this task.

 

On Branch #4, complete the configuration of the router r70 according to these requirements;

 

·         Assign IP address 10.7.1.1/24 to gi0/2

·         Enable DHCP relay on this interface and point it to the DHCP server 10.2.255.211 at sw211

·         It is allowed to add one additional missing command to the r70 configuration to allow DHCP clients connected to gi0/2 obtain their IPv4 configuration.

·         Make sure that host71 and host72 are assigned their correct IPv4 configuration.

 

1.13                                                                                                                       : Multicast in FABD2

FABD2 is preparing to enable PIM Sparse mode multicast routing in its network. As a part of validating the runbooks, FABD2 requires a sanity check to prevent inappropriate use of multicast-related configuration commands on different router types:

·         First Hop Routers – Routers where multicast sources are connected

·         Last Hop Routers- routers where multicast receivers (subscribers) are connected

·         Intermediary Hop Routers- routers on the path between First Hop and Last Hop routers In the Table below, for each configuration command, select all router type where the use of the command is appropriate. (Select all that apply)

 

Router Type
Command	First Hop Router	Intermediary Hop Router	Last Hop Router
Ip pim register-source	ÿ	ÿ	ÿ
Ip igmp version	ÿ	ÿ	ÿ
ip pim spt-threshold	ÿ	ÿ	ÿ
ip pim rp-address	ÿ	ÿ	ÿ
IP pim sparse-mode	ÿ	ÿ	ÿ

 

 1.14                                                                                     : Extending Connectivity to laaS Site

 Extend the IPv6 connectivity from HQ through the SP into the giosk VRF on the laaS site according to these requirements:

 Set up global IPv6 addressing on the link between r11 and r3

·         On r11, assign 2001:2710:311::2/64 to g0/0

·         On r3, assign 2001:2710:311::1/64 to g1

·         Enable the existing IPv4 BGP session between r11 and r3 to also advertise IPv6 prefixes. Do not configure a standalone IPv6 BGP session between these two routers.

·         Perform bidirectional route redistribution between the IPv6 EIGRP and BGP processes on r11.

·         Ensure that all current and future IPv6 prefixes advertised between r11 and r3 will be installed into the RIB of these routers with the next hop address set to the proper global unicast address on their interconnection. Any policy that accomplishes this requirement must be applied in the inbound direction.

·         The giosk VRF on r4 that extends the IPv6 connectivity from r4 to r30 on the laaS site is a separate VRF independent of fabd2 VRF. Any route leaking from fabd2 VRF into giosk VRF must be done on per-site basis and only for those FABD2 sites that need connectivity in the laaS site.

·         By configuring r3 and r4 only, ensure that the HQ FABD2 site will have mutual visibility with the laaS site while preventing

-          Any other FABD2 site from possibly learning about the routes on the laaS site

-          The laaS site from possibly learning about the routes on any other FABD2 site

 Use the minimum amount of commands necessary to accomplish this requirement. Do not remove any existing configuration. If necessary, you are allowed to use an additional route target with the value of 10000:3681.

·         Verify that host11 and host12 can ping 2001:db8:14::1 located at the laaS site. It is permitted to modify one existing configuration command on one of the SP routers to meet this requirement.

 

1.15                                                                                    : Enabling Internet Access for FABD2

 

Enable highly available internet access for the FABD2 company network according to these requirements:

·         On routers r12, r23 and r24, bring up IPv4 BGP peerings with the ISP, make sure that a default route is received over these peerings.

·         On router r12 and r23, inject default route into OSPF if it present in the routing table from a different routing source than the OSPFv2 process 1. On each router, this requirement must be completed using the minimum possible number of commands.

·         On route r24, inject default route into OSPF if any only if it is learned from ISP over BGP, To accomplish this requirement, it is allowed to use a route-map that referenced both a prefix-list and tag. This requirement must be completed using the minimum possible number of commands.

·         Router r12 may be used as an internet exit for the FABD2 company network only if neither r23 nor r24 are advertising the default route in OSPF. This requirement must be accomplished exclusively in “router ospf” mode on router r12 without changing the default parameters on routers r23 and r24.

·         On routers r12, r23 and r24, configure PAT and translate the entire FABD2 internal network 10.0.0.0/8 to the router address on the link toward the ISP. Create a standard ACL named NAT for this purpose. Do not use NAT pools.

Ensure that the internet connectivity of the FABD2 company network makes use of the highly availability provided by r12, r23 and r24.

 

2.1 : Correcting the IP addresses of Managed switches in DNA center

After Cisco DNA center first achieves IP connectivity with the managed switches in Branches #1 and #2, it will place them into maintenance mode due to their serial number being different from the one DNA center remember, In addition, their management IP addresses in DNA Center will be automatically changed by appending them with the “.dummy.com” string. As a result, after an initial contact, DNA Center will lose connectivity with the switches unless their management IP addresses are corrected in the DNA center settings.

Correct the IP addresses of managed switches in the DNA center according to the following requirements:

·         Use any host, such as host11, to access the DNA Center GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Execute the provision-Devices- Inventory- Global- Actions-Inventory- Resync Device action in DNA Center on all switches before proceeding further.

·         DNA Center API reference and sandbox is available at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         The /network/device/update-maintenance-device-ip-address API call description and sandbox are available in the Inventory section of the API reference.

·         Use the /network-device/update-maintenance-device-ip address API call to correct the IP addresses of the switches in Branches #1 and #2 by removing the appended text.

Note: These IP addresses cannot be changed from DNA Center GUI directly because they will become automatically invalidated again. This is a built-in DNA Center behavior.

 

2.2                                                                   : Completing VN Configuration in DNA center

Using the DNA Center GUI, perform configuration tasks according to these requirements:

·         Add new virtual Network named IoT for the internet-of-things network on the Branches #1 and #2

·         Create new address pools for the IoT VN named Branch1- For IoT and Branch2-ForIoT on the global level, and branch1-IoT and Branch2-IoT on the Branch level.

·         For Branch #1 loT VN, allocate the subnet 10.4.198.0/24 and the gateway IP address 10.4.198.1.

·         For Branch #2 loT VN, allocate the subnet 10.5.198.0/24, and the gateway IP address 10.5.198.1.

·         Associate the Branch1-loT and Branch2-loT pools with the loT VN on the respective branches.

·         Complete the configuration of the address pools for the Guest VN in the DNA Center so that Branch #1 and Branch #2 can accommodate guest connections. If a new address pool needs to be created and an address range allocated to it, follow the established addressing plan.

·         Correct the addressing information currently defined for the Branch2- For Employees and Branch2- Employees address pool.

·         For all address pools, use the DHCP server 10.2.255.211 to allocate addresses to clients.

On sw211, complete the DHCP server configuration according to these requirements:

·         Create four new DHCP pools for the loT and Employees VNs on respective branches

o   Pool named br1_iot for Branch #1 loT VN

o   Pool named br1_emp for Branch #1 Employees VN

o   Pool named br2_iot for Branch #2 loT VN

o   Pool named br2_emp for Branch #2 Employees VN

·         In each subset, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

2.3                                                                                     : Mapping SDA VNs to SD-WAN VPNs

Using vManage GUI, perform configuration tasks according to these requirements:

·         Use any host, such as host11, to access the vManage GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Create three new SD-WAN VPNs to carry the SDA VN traffic

o   VPN ID 198 for IoT VN

o   VPN ID 199 for Guest VN

o   VPN ID 200 for Employees VN

·         On Branch #1 and Branch #2 vEdges, for each of these VPNs:

o   Create a new sub-interface on the interface toward the SDA border switch. Align the VLAN ID and IP address on the sub interface with the configuration generated by DNA Center on the border switches for the appropriate VN.

o   Peer the vEdge and the SDA border switch using iBGP. Ensure full reachability between all locations of the same VPN.

 

2.4                                                                           : Configuring SD-WAN VPN Route Leaking

To Allow the traditional parts of the FABD2 network to communication with the employees and IOT VPNs/VNs, configure route leaking in SD-WAN according to these requirements:

·         Prefixes in the IoT VPN 198 must be imported into the existing SDA Underlay VPN 999 and tagged with tag value of 198.

·         Prefixes in the Employees VPN 200 must be imported into the existing SDA Underlay VPN 999 and tagged with the tag value of 200

·         Prefixes in the SDA underlay VPN 999 advertised from the DC that are within the 10.4.0.0/15 range must be rejected. Other prefixes in the SDA underlay VPN 999 advertise from DC must be accepted and also imported into IoT VPN 198 and Employees VPN 200.

·         Redistribution from OMP into OSPF on Branches#1 and #2 in VPN 999 must exclude vRoutes tagged with values 198 or 200.

·         Place host41 into Employees VN. Place host51 into IoT VN. Make sure both hosts receive their IP setting from DHCP.

·         Ensure that the IoT and Employees VPNs on Branches #1 and #2 have reachability to Branches #3 and #4. It is allowed to modify the VPN 999 OMP settings to accomplish this requirement.

 

2.5                                                                                                                   : Handling Guest Traffic

The guest VN/VPN on Branches #1 and #2 must remain isolated from the rest of the company network. It ‘s only allowed to reach internet through r23 and r24 in the DC. Enable internet connectivity for the Guest VPN according to these requirements:

·         On Vedge21 and Vedge22, place the ge0/2 interfaces into the Guest VPN 199.

·         On r23 and r24, create a new VRF named Guest using the RD of 65002:199, and place the gi4 interfaces into the VRF.

·         Assign addresses to these Interfaces:

·         R23 Gi4: 10.2.123.1/24

·         R24 Gi4: 10.2.224.1/24

·         Vedge 21 gi0/2: 10.2.123.2/24

·         Vedge 22 Gi0/2: 10.2.224.2/24

·         Peer r23 and vedge21 in the Guest VRF/VPN using iBGP.

·         Peer r24 and vedge22 in the Guest VRF/VPN using iBGP.

·         Ensure that r23 and r24 learn the routes in the Guest VRF/VPN over iBGP.

·         On r23 and r24, configure a static default route in the Guest VRF and point it to the ISP’s IP address 200.99.23.1 or 200.99.24.1 as appropriate. Advertise this default route in iBGP to vedge21 and vedge22.

·         On r23 and r24, configure PAT to allow the Guest VPN to access internet by translating it to the router address on the link toward the ISP. Reuse the NAT ACL already created on the router. Do not use NAT pools. 

Configure r23 as DHCP server for Guest VPN according to these requirements:

·         Create loopback1 interface on r23 associated with the Guest VRF and having the IP address 10.2.255.211/32

·         Advertise this prefix in BGP toward vedge21.

·         Create DHCP Pool named br1_guest for branch#1 Guest subnet.

·         Create DHCP Pool named br2_guest for branch#2 Guest subnet.

·         Explicitly associate both DHCP pools with the VRF guest.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

·         Associate host42 and host52 with guest VN in DNAC, and make sure that both hosts receive the appropriate address.

·         Make sure that host42 and host 52 can ping 8.8.8.8 in the ISP cloud.

 

 

2.6                                                                                   : Support for silent Hosts in Branch #2

The item consists of multiple questions. You may need to scroll down to be able to see all questions. In future, Branch#2 will be equipped with IP-based IoT endpoints operating in speak-when-spoken-to mode also called silent hosts. Which of the following SDA features enables a working connectivity with these IoT endpoints?

·         Native Multicast

·         Endpoint Mobility

·         Layer 2 flooding

·         Layer 2 Extension

In the statement below, select one of the options from the drop-down list to complete the sentence and form a correct statement.

For SDA to support silent hosts,   ---------------------Selection Option----- in the underlay as a prerequisite.

Options:-

·         IP Multicast routing with PIM-SM must be enabled

·         No additional capability aside from unicast IP Connectivity is required.

·         IS-IS must be used as a routing protocol

·         DHCP Snooping must be enabled.

 

3.1: Enabling CLI access to r30

          There is no direct console access provided to the router r30. Moreover, r30 does not accept any remote connections because its VTY lines are configured with transport input non. Using RESTCONF, enable remote access to r30 for all remote access protocols, according to these requirements:

·         You can use host31 to access router r30 using ip address 10.3.11.1

·         You can use any method of accessing the RESTCONF API on r30 from host31, including curl, python, or postman.

·         You must change the input transport protocol on all configurable VTY lines.

·         The input transport protocol value setting must be changed from none to all.

Important Parameters:

·         Username / Password for HTTP authentication

§  admin / admin

§  URL

§ 

This is the hidden content, please

• Sign In
• or
• Sign Up

·         HTTP Method

§  GET

o   HTTP method to modify the configuration

§  PATCH

o   HTTP Headers

§  Content-Type:application/yang-data+json

§  Accept:application/yang-data+json

o   Recommended curl switches

§  -I,-k,-X,-H,-u,-d

 

3.2 Using Guest Shell and Python on r30

On r30, enable guestshell and create a python script name ribdump.py in the guestshell according to these requirements:

·         If an additional IP network is necessary to start guestshell, you are allowed to use addresses from the range 192.168.255.0/24. This range must not be advertised in any routing protocol.

·         The python script must be saved under the name ribdump.py in the home directory of the guestshell user.

·         The purpose of the script is to display the complete contents of all routing tables in non-default VRFs created on the router.

·         The script must execute the show ip route Vrf… or show ipv6 route vrf… command for every non default VRF created on the router, depending on what address families are enabled in that VRF.

·         The script must determine the list of created VRFs and enabled address families dynamically every time it is run using, for example, show vrf brief | include ipv4

·         The script must not attempt to display the VRF routing table for an address family that is not enabled in the VRF.

·         It must be possible to run the script using the guestshell run python ribdump.py command from privileged EXEC mode.

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

Please update the solution like CCIE V5.  I hope everyone will support and update their knowledge to make perfect solution.

 

I will attempt to solve 3.1

 

Thank you for  bringing the questions.

[mrhacker]

On 7/24/2021 at 4:05 PM, Natasha said:

Section 1.1

SW110
  
sw110(config)#spanning-tree mode rapid  
sw110(config)#spanning-tree pathcost method long 
sw110(config)#spanning-tree portfast edge default  

sw110(config)#interface range gi1/2-3  
sw110(config-if-range)#channel-group 2 mode active  

SW101  

sw101(config)#spanning-tree mode rapid 
sw101(config)#spanning-tree pathcost method long 
sw101(config)#spanning-tree vlan 2000 priority 0 
sw101(config)#spanning-tree vlan 1-4094 hello-time 1 

sw101(config)#interface range gi1/2-3  
sw101(config-if-range)#channel-group 1 mode on 

SW102

sw102(config)#spanning-tree mode rapid
sw102(config)#spanning-tree pathcost method long 
sw102(config)#spanning-tree vlan 2001 priority 0 
sw102(config)#spanning-tree vlan 1-4094 hello-time 1  

sw102(config)#interface range gi1/2-3  
sw102(config-if-range)#channel-group 2 mode active

Verification:  

sw110# sh etherchannel summary 
sh spanning-tree vlan 2000   
  
SWll0#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Pol (SU) LACP Gil/O(P) Gil/l(P) 
2 Po2 (SU) LACP Gil/2(P) Gil/3(P)

SWl02#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Po2 (SU) LACP Gil/2(P) Gil/3(P) 
2 Po3 (SU) LACP Gi2/0(P) Gi2/1(P)

SWl01#sh etherchanne 1 summary 
Flags: D - down P - bundled in port-channel 
I - stand-alone s - suspended 
H - Hot-standby (LACP only) 
R - Layer3 S - Layer2 
U - in use N - not in use, no aggregation 
f - failed to allocate aggregator 
M - not in use, minimum links not met 
m - not in use, port not aggregated due to minimum links not met
u- unsuitable for bundling 
w- waiting to be aggregated 

d- default port 
A - formed by Auto LAG 

Number of channel -groups in use: 2 
Number of aggregators: 2 
Group Port-channel Protocol Ports 
------ + -------------+  ----------- +--------------------- 
1 Pol (SU) LACP Gil/2(P) Gil/3(P) 
2 Po2 (SU) LACP Gil/2(P) Gil/3(P)

 

On the 3  switches port channel we need to used below command or not.

spanning-tree link-type point-to-point  ================> this required or not.

[cloudsun]

I havent tried it in a lab to observe RSTP convergence but technical docs explain that  point-to-point is required on half duplex  on switch ports connecting to other switch ports so that rstp can transition fast like the way portfast behaves on edge ports. 

If the switch link ports are full duplex they are treated as point-to-point which defaults to STP message handshake method (STP convergence occurs quickly over a point-to-point link through RSTP handshake messages)

Maybe during exam we just need to verify the switch to switch link ports if they are half or full duplex

 

[Vlaja]

On 7/23/2021 at 1:34 PM, mrhacker said:

Thanks to all Dear's,

Below are the list of question and review and validate the solutions.

 

1.2                                                                                                       : Layer 2 Technologies in HQ

Complete and correct the EtherChannel configuration between switches sw101, sw102, sw110 according to these requirements:

 ·         At the end of the task, all EtherChannel’s between switches sw101, sw102, sw110 must be up and operational including all their physical member links.

·         Do not create new Port- channel interface; reuse those that already exist on the switches.

·         When resolving existing issues, do not change the preconfigured negotiation protocol (if any)

·         On EtherChannel’s that use a negotiation protocol, tune its mode of operation for the shortest link building time possible.

 

Configure spanning tree protocol on switches sw101, sw102, sw110 according to these requirements:

 

·         The STP root for VLAN 2000 must be sw101.

·         The STP root for VLAN 2001 must be sw102.

·         STP roots must be elected based on bridge priorities.

·         On the three switches, have STP perform cost calculations in 32-bit arithmetic.

·         On the three switches, use the Rapid STP version and ensure that it can achieve rapid convergence on all interconnections between the switches.

·         On Sw110, prevent all current and future access mode interfaces from being affected by the proposal/ Agreement process.

 

 

1.2                                                                                  : First Hop Redundancy Protocol in HQ

 

For IPv4, implement an FHRP mechanism on sw101 and sw102 fo rVLANs 2000 and 2001 according to these requirements:

 

·         Use Group number 100 for VLAN 2000 and group number 101 for VLAN 2001.

·         Use the first available IPV4 address in the subnet for the address of the virtual router.

·         For VLAN 2000, sw101 must be preferred gateway; for VLAN 2001, sw102 must be the preferred gateway. Do not rely on the IPv4 addresses of the switches as role tiebreakers. The role must determine by an explicit configuration solely on the intended preferred gateway.

·         Each preferred gateway must monitor the reachability of both routers r11 and r12 using the loopback IPv4 addresses of the routers by an ICMP Echo. The reachability is to be verified every 5 seconds with a timeout of 400 msec. A router must be declared unreachable as soon as it does not respond to three probes in a row. If both r11 an dr12 are declared unreachable from a preferred gateway, the other switch must be allowed to assume the gateway role.

·         Use the FHRP protocol that allows the virtual IPv4 address to match the IPv4 address of a member router.

 

 

1.3                                                                                                    : OSPFv2 between HQ and DC

 

Complete and correct the OSPF configuration on the switches sw101, sw102,sw201 and sw202 according to these requirements:

 

·         Enable OSPFv2 on the redundant interconnections between the DC and HQ sites. Make sure that establishes adjacencies on these interconnections and exchanges routing information between the DC and HQ sites.

·         Protect the authenticity and integrity of the OSPFv2 sessions on the redundant interconnections between DC and HQ with the SHA-384 mechanism. Use key ID 1 and a shared secret of “cci3” (without quotes).

·         Improve the detection of unreachable OSPFv2 neighbors on the redundant interconnections between DC and HQ so that OSPF can detect the loss of a neighbor within 200 msec, with the probes being sent every 100 msec. it is not allowed to modify ODPF timers to accomplish this requirement.

 

 

1.4                                                                                                            : DHCP IPv4 service for HQ

 

Enable hosts in HQ VLAN 2000 and VLAN 2001 to obtain their IP configuration via DHCP according to these requirements:

 

·         On sw211, create IPv4 DHCP pools named hq_v2000 and hq_v2001 for HQ VLANs 2000 and 2001, respectively. In each subnet, assign addresses from .101 upto .254 inclusively, and the appropriate gateway to clients.

·         Enable DHCP snooping on sw110 in VLANs 2000 and 2001 to protect against DHCP-related attacks.

·         Place host11 into VLAN 2000.

·         Place host12 into VLAN 2001.

·         Perform the necessary configuration on switches sw101, sw102, sw110 to enable hosts in VLANs2000 and 2001 to obtain IPv4 configuration through DHCP. The DHCP server running at sw211 in the DC must be referred to by its loopback IPv4 address 10.2.255.211. Do not disable the Option 82 insertion, and do not enable DHCP snooping on other switches.

·         Verify that host11 and host12 have IP connectivity to the Cisco DNA Center, VManage and UCE running in the DC using their internal (In Band Connectivity) addresses.

 

1.5                                                                                                                                             : IPv6 in HQ

 

Implement IPv6 on sw101 and sw102 for switch virtual interfaces (SVIs) Vlan 2000 and Vlan 2001 according to these requirements:

·         sw101

Interface Vlan2000:2001:db:8:1:100::1/64 Interface Vlan2001:2001:db8:1:101::1/64

 

·         sw102

Interface Vlan2000:2001:db8:1:100::2/64 Interface Vlan2001:2001:db8:1:101::2/64

 

·         The configuration must enable hosts in these VLANs to obtain their IPv6 configuration via SLAAC and keep a stable connectivity with other IPv6 networks.

·         Use native IPv6 means to provide gateway redundancy, with sw101 being the preferred gateway in VLAN 2000 and sw102 being the preferred gateway in VLAN 2001. The role must be determined by an explicit configuration solely on the intended preferred gateway.

·         Hosts must be able to detect the failure of the preferred gateway in as little as 3 seconds.

 

1.6                                                                                                                              : IPv6 EIGRP in HQ

 

In HQ, enable EIGRP for IPv6 on r11, r12, sw101 and sw102 according to these requirements:

·         Use process name “ccie” (without the quotes) and AS number 65001.

·         Do not configure any additional IPv6 addresses.

·         IPv6 EIGRP may form adjacencies only over the physical Layer3 interfaces between r11, r12, sw101 and sw102.

·         Prevent IPv6 EIGRP from automatically running on, or advertising attached prefixes from, new IPv6-enabled interfaces in the future unless allowed explicitly.

·         Ensure that the attached IPv6 prefixes on SVIs Vlan2000 and Vlan2001 onsw101 and sw102 are advertised in IPv6 EIGRP and learned on r11 and r12.

·         No route filtering is allowed to accomplish this entire task.

 

1.7                                                                                                                                      : OSPFv2 in DC

 

Configure devices in the DC according to these requirements:

 

·         Switches sw201 and sw202 must establish a stable OSPF adjacency in the FULL state with vedge21 and vedge22 on interface Vlan3999. Any configuration changes and corrections necessary to meet this requirement may be performed only on the switches, and any mismatched parameters causing the issue must be changed to exactly match the configuration of the vEdges.

·         All OSPF speakers in the DC running Cisco IOS and IOS-XE software must be configured to keep the number of advertised internal routes to an absolute minimum while not impacting the reachability of the services. This included the reachability of ISE,DNA center,vManage,vBond and vSmart on their internal (in Band Connectivty) addresses, as well as any existing and future devices in VLAN 4000 and sw201 and sw202. The configuration of this requirement must be completed exclusively within the “router ospf” and “interface vlan” contexts without causing any impact to existing OSPF adjacencies.

·         Router r24 must advertise two prefixes, 10.6.0.0/15 and 10.200.0.0/24, as Type-5 LSAs in OSPFv2 to provide HQ and DC with the reachability to the DMVPN tunnel and branches #3 and #4. The configuration of this requirement must be completed exclusively within the “router ospf” context.

·         Any route from the 10.2.0.0/16 range that keeps being advertised in OSPF must continue being advertised as an intra-area route.

·         It is not allowed to modify existing areas to accomplish this entire task.

 

1.8                                                                     : BGP between HQ/DC and service providers

Configure the BGP peering’s between HQ/DC and Global SP#1 and Global SP#2 according to these requirements:

·         Bring up the BGP peering between HQ r11 and SP#1 r3

·         Bring up the BGP peering between DC r21 and SP#1 r3

·         Bring up the BGP Peering between DC r22 and SP#2

·         Ensure that the routes learned over eBGP sessions and further advertised in iBGP will be considered reachable even if the networks on inter-AS links are not advertised in OSPF. The configuration of this requirement must be completed exclusively within the “router bgp” context.

·         On r11, r21 and r22 perform mutual redistribution between OSPFv2 and BGP. However, prevent routes that were injected into OSPF from BGP to be reinjected back into BGP. This requirement must be solved on r11, r21 and r22 using only a single route-map on each of the routers and without any reference to ACLs, prefix lists, or route types.

·         Prevent HQ and DC from ever communicating through SP#1 r3. All Communication between HQ and DC must occur only over the direct SW101/SW201 and SW102/SW202 interconnections. Any other communication must remain unaffected. This requirement must be solved on r21 and r22 by route filtering based on a well-known mandatory attribute without the use of route maps.

·         No command may be removed from the configuration on r11 to accomplish this entire task.

·         It is allowed to modify existing configuration commands on r21 and r22 to accomplish this entire task.

 

1.9                                                                                           : Bringing up VPNv4/VPNv6 in SP#1

 

Configure routers r3, r4, r5 and r6 in SP#1 according to these requirements:

 

·         Configure r3 through r6 for mutual VPNv4 and VPNv6 route exchange without the use of a route reflector. Use Lo0 IPv4 addresses for peering’s.

·         Configure r3 through r6 to assign (allocate/bind) as few unique MPLS labels to all existing and future VPNv4 and VPNv6 routes as possible.

·         On Routers r3 through r6, prevent any existing and future customer from discovering details about the inner topology of SP#1. It is not allowed to use ACLs to accomplish this requirement.

1.10  : Fixing Broken DMVPN between Dc and Branches #3 and #4

Correct the configuration issues resulting in broken DMVPN tunnel connectivity between DC, Branch3 and Branch4 according to these requirements:

·         The DMVPN must operate in IPsec-protected phase 3 mode.

·         Using the FVRF approach, safeguard the DMVPN operation against any potential recursive routing issues involving the tunnel.

·         Do not create any new VRFs.

·         Do not change the tunnel source commands on Tunnel interfaces.

·         On Spokes, do not add new BGP neighbors; reuse those that are currently up while changing their VRF membership as needed.

·         It is not allowed to modify configuration on DC r24 to complete this entire task.

 

1.11                                               : Tuning EIGRP on DMVPN and DMVPN-enabled Sites

Optimize the DMVPN operation according to these requirements:

·         Ensure that Branches#3 and #4 receive only a default route over EIGRP in DMVPN.

·         The default route origination must be done on DC r24 without the use of any static routes, redistribution, or route filtering.

·         It is not allowed to modify the configuration of r61 and r62 in Branch#3 to accomplish this task;

·         It is allowed to add commands to the configuration of r70 in branch #4 to accomplish this task;

None of the existing configuration on r70 may be removed to accomplish this task.

           

            Configure Sw601 and Sw602 at Branch#3 according to these requirements:

·         Routers r61 and r62 must not send EIGRP queries to SW601 and SW602.

·         Switches SW601 and SW602 must allow advertising any current or future directly connected network to r61 and r62 after the network is added to EIGRP.

·         Switches Sw601 and Sw602 must continue to propagate the default route received from r61 and r62 to each other. To Select the default route, use a prefix list with a “Permit” – type entry only.

·         Switches SW601 and SW602 must not propagate the default route back to r61 and r62.

·         If the prefix list that allows the propagation of selected EIGRP-learned networks between sw601 and sw602 is modified in the future, the same set of networks must be disallowed from being advertised back to r61 and r62 automatically, without any additional commands.

·          

 

1.12                                                                                     : IPv4 Networks on Legacy Branches

 

On sw211 in DC, complete the DHCP server configuration according to these requirements:

 

·         Create IPv4 DHCP pools named br3_v2000 and br3_v2001 for Branch #3 VLANs 2000 (10.6.100.0/24) and 2001 (10.6.101.0/24), respectively.

·         Create IPv4 DHCP pool named br4_v1 for the subnet 10.7.1.0/24 on branch #4.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

On Branch #3; Complete and correct the configuration on switches sw601, sw602 and sw610 to allow HSRP and DHCP relay operation in VLANs 2000 and 2001 according to these requirements:

 

·         HSRP must implicitly use the vMAC address range of 0000. 0c9f.f000 through 0000. 0c9f.ffff

·         The group member must be 100 for VLAN 2000 and 101 for VLAN 2001

·         Sw601 must be the Active gateway for VLAN 2000 with a priority of 110; the Active role ownership must be deterministic

·         Sw602 must be the Active gateway for VLAN 2001 with a priority of 110; the Active role ownership must be deterministic

·         Each active switch must track its uplink interfaces gi0/1 and gi0/2/ if either of these interfaces goes down; the active switch must allow the other switch to become Active. However, it is not allowed for the tracking to modify the HSRP priority to accomplish this requirement.

·         Both sw601 and sw602 must be configured as DHCP relay agents in both VLANs 2000 and 2001, pointing toward the DHCP server 10.2.255.211 at sw211. However, at any time, only the Active router in the particular VLAN should relay the DHCP messages.

·         Place host61 and host62 into VLANs 2000 and 2001, respectively, and make sure they are assigned their correct IPv4 configuration.

It is not permitted to use any kind of scripting to complete this task.

 

On Branch #4, complete the configuration of the router r70 according to these requirements;

 

·         Assign IP address 10.7.1.1/24 to gi0/2

·         Enable DHCP relay on this interface and point it to the DHCP server 10.2.255.211 at sw211

·         It is allowed to add one additional missing command to the r70 configuration to allow DHCP clients connected to gi0/2 obtain their IPv4 configuration.

·         Make sure that host71 and host72 are assigned their correct IPv4 configuration.

 

1.13                                                                                                                       : Multicast in FABD2

FABD2 is preparing to enable PIM Sparse mode multicast routing in its network. As a part of validating the runbooks, FABD2 requires a sanity check to prevent inappropriate use of multicast-related configuration commands on different router types:

·         First Hop Routers – Routers where multicast sources are connected

·         Last Hop Routers- routers where multicast receivers (subscribers) are connected

·         Intermediary Hop Routers- routers on the path between First Hop and Last Hop routers In the Table below, for each configuration command, select all router type where the use of the command is appropriate. (Select all that apply)

 

Router Type
Command	First Hop Router	Intermediary Hop Router	Last Hop Router
Ip pim register-source	ÿ	ÿ	ÿ
Ip igmp version	ÿ	ÿ	ÿ
ip pim spt-threshold	ÿ	ÿ	ÿ
ip pim rp-address	ÿ	ÿ	ÿ
IP pim sparse-mode	ÿ	ÿ	ÿ

 

 1.14                                                                                     : Extending Connectivity to laaS Site

 Extend the IPv6 connectivity from HQ through the SP into the giosk VRF on the laaS site according to these requirements:

 Set up global IPv6 addressing on the link between r11 and r3

·         On r11, assign 2001:2710:311::2/64 to g0/0

·         On r3, assign 2001:2710:311::1/64 to g1

·         Enable the existing IPv4 BGP session between r11 and r3 to also advertise IPv6 prefixes. Do not configure a standalone IPv6 BGP session between these two routers.

·         Perform bidirectional route redistribution between the IPv6 EIGRP and BGP processes on r11.

·         Ensure that all current and future IPv6 prefixes advertised between r11 and r3 will be installed into the RIB of these routers with the next hop address set to the proper global unicast address on their interconnection. Any policy that accomplishes this requirement must be applied in the inbound direction.

·         The giosk VRF on r4 that extends the IPv6 connectivity from r4 to r30 on the laaS site is a separate VRF independent of fabd2 VRF. Any route leaking from fabd2 VRF into giosk VRF must be done on per-site basis and only for those FABD2 sites that need connectivity in the laaS site.

·         By configuring r3 and r4 only, ensure that the HQ FABD2 site will have mutual visibility with the laaS site while preventing

-          Any other FABD2 site from possibly learning about the routes on the laaS site

-          The laaS site from possibly learning about the routes on any other FABD2 site

 Use the minimum amount of commands necessary to accomplish this requirement. Do not remove any existing configuration. If necessary, you are allowed to use an additional route target with the value of 10000:3681.

·         Verify that host11 and host12 can ping 2001:db8:14::1 located at the laaS site. It is permitted to modify one existing configuration command on one of the SP routers to meet this requirement.

 

1.15                                                                                    : Enabling Internet Access for FABD2

 

Enable highly available internet access for the FABD2 company network according to these requirements:

·         On routers r12, r23 and r24, bring up IPv4 BGP peerings with the ISP, make sure that a default route is received over these peerings.

·         On router r12 and r23, inject default route into OSPF if it present in the routing table from a different routing source than the OSPFv2 process 1. On each router, this requirement must be completed using the minimum possible number of commands.

·         On route r24, inject default route into OSPF if any only if it is learned from ISP over BGP, To accomplish this requirement, it is allowed to use a route-map that referenced both a prefix-list and tag. This requirement must be completed using the minimum possible number of commands.

·         Router r12 may be used as an internet exit for the FABD2 company network only if neither r23 nor r24 are advertising the default route in OSPF. This requirement must be accomplished exclusively in “router ospf” mode on router r12 without changing the default parameters on routers r23 and r24.

·         On routers r12, r23 and r24, configure PAT and translate the entire FABD2 internal network 10.0.0.0/8 to the router address on the link toward the ISP. Create a standard ACL named NAT for this purpose. Do not use NAT pools.

Ensure that the internet connectivity of the FABD2 company network makes use of the highly availability provided by r12, r23 and r24.

 

2.1 : Correcting the IP addresses of Managed switches in DNA center

After Cisco DNA center first achieves IP connectivity with the managed switches in Branches #1 and #2, it will place them into maintenance mode due to their serial number being different from the one DNA center remember, In addition, their management IP addresses in DNA Center will be automatically changed by appending them with the “.dummy.com” string. As a result, after an initial contact, DNA Center will lose connectivity with the switches unless their management IP addresses are corrected in the DNA center settings.

Correct the IP addresses of managed switches in the DNA center according to the following requirements:

·         Use any host, such as host11, to access the DNA Center GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Execute the provision-Devices- Inventory- Global- Actions-Inventory- Resync Device action in DNA Center on all switches before proceeding further.

·         DNA Center API reference and sandbox is available at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         The /network/device/update-maintenance-device-ip-address API call description and sandbox are available in the Inventory section of the API reference.

·         Use the /network-device/update-maintenance-device-ip address API call to correct the IP addresses of the switches in Branches #1 and #2 by removing the appended text.

Note: These IP addresses cannot be changed from DNA Center GUI directly because they will become automatically invalidated again. This is a built-in DNA Center behavior.

 

2.2                                                                   : Completing VN Configuration in DNA center

Using the DNA Center GUI, perform configuration tasks according to these requirements:

·         Add new virtual Network named IoT for the internet-of-things network on the Branches #1 and #2

·         Create new address pools for the IoT VN named Branch1- For IoT and Branch2-ForIoT on the global level, and branch1-IoT and Branch2-IoT on the Branch level.

·         For Branch #1 loT VN, allocate the subnet 10.4.198.0/24 and the gateway IP address 10.4.198.1.

·         For Branch #2 loT VN, allocate the subnet 10.5.198.0/24, and the gateway IP address 10.5.198.1.

·         Associate the Branch1-loT and Branch2-loT pools with the loT VN on the respective branches.

·         Complete the configuration of the address pools for the Guest VN in the DNA Center so that Branch #1 and Branch #2 can accommodate guest connections. If a new address pool needs to be created and an address range allocated to it, follow the established addressing plan.

·         Correct the addressing information currently defined for the Branch2- For Employees and Branch2- Employees address pool.

·         For all address pools, use the DHCP server 10.2.255.211 to allocate addresses to clients.

On sw211, complete the DHCP server configuration according to these requirements:

·         Create four new DHCP pools for the loT and Employees VNs on respective branches

o   Pool named br1_iot for Branch #1 loT VN

o   Pool named br1_emp for Branch #1 Employees VN

o   Pool named br2_iot for Branch #2 loT VN

o   Pool named br2_emp for Branch #2 Employees VN

·         In each subset, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

 

2.3                                                                                     : Mapping SDA VNs to SD-WAN VPNs

Using vManage GUI, perform configuration tasks according to these requirements:

·         Use any host, such as host11, to access the vManage GUI website at

This is the hidden content, please

• Sign In
• or
• Sign Up

URL.

·         Create three new SD-WAN VPNs to carry the SDA VN traffic

o   VPN ID 198 for IoT VN

o   VPN ID 199 for Guest VN

o   VPN ID 200 for Employees VN

·         On Branch #1 and Branch #2 vEdges, for each of these VPNs:

o   Create a new sub-interface on the interface toward the SDA border switch. Align the VLAN ID and IP address on the sub interface with the configuration generated by DNA Center on the border switches for the appropriate VN.

o   Peer the vEdge and the SDA border switch using iBGP. Ensure full reachability between all locations of the same VPN.

 

2.4                                                                           : Configuring SD-WAN VPN Route Leaking

To Allow the traditional parts of the FABD2 network to communication with the employees and IOT VPNs/VNs, configure route leaking in SD-WAN according to these requirements:

·         Prefixes in the IoT VPN 198 must be imported into the existing SDA Underlay VPN 999 and tagged with tag value of 198.

·         Prefixes in the Employees VPN 200 must be imported into the existing SDA Underlay VPN 999 and tagged with the tag value of 200

·         Prefixes in the SDA underlay VPN 999 advertised from the DC that are within the 10.4.0.0/15 range must be rejected. Other prefixes in the SDA underlay VPN 999 advertise from DC must be accepted and also imported into IoT VPN 198 and Employees VPN 200.

·         Redistribution from OMP into OSPF on Branches#1 and #2 in VPN 999 must exclude vRoutes tagged with values 198 or 200.

·         Place host41 into Employees VN. Place host51 into IoT VN. Make sure both hosts receive their IP setting from DHCP.

·         Ensure that the IoT and Employees VPNs on Branches #1 and #2 have reachability to Branches #3 and #4. It is allowed to modify the VPN 999 OMP settings to accomplish this requirement.

 

2.5                                                                                                                   : Handling Guest Traffic

The guest VN/VPN on Branches #1 and #2 must remain isolated from the rest of the company network. It ‘s only allowed to reach internet through r23 and r24 in the DC. Enable internet connectivity for the Guest VPN according to these requirements:

·         On Vedge21 and Vedge22, place the ge0/2 interfaces into the Guest VPN 199.

·         On r23 and r24, create a new VRF named Guest using the RD of 65002:199, and place the gi4 interfaces into the VRF.

·         Assign addresses to these Interfaces:

·         R23 Gi4: 10.2.123.1/24

·         R24 Gi4: 10.2.224.1/24

·         Vedge 21 gi0/2: 10.2.123.2/24

·         Vedge 22 Gi0/2: 10.2.224.2/24

·         Peer r23 and vedge21 in the Guest VRF/VPN using iBGP.

·         Peer r24 and vedge22 in the Guest VRF/VPN using iBGP.

·         Ensure that r23 and r24 learn the routes in the Guest VRF/VPN over iBGP.

·         On r23 and r24, configure a static default route in the Guest VRF and point it to the ISP’s IP address 200.99.23.1 or 200.99.24.1 as appropriate. Advertise this default route in iBGP to vedge21 and vedge22.

·         On r23 and r24, configure PAT to allow the Guest VPN to access internet by translating it to the router address on the link toward the ISP. Reuse the NAT ACL already created on the router. Do not use NAT pools. 

Configure r23 as DHCP server for Guest VPN according to these requirements:

·         Create loopback1 interface on r23 associated with the Guest VRF and having the IP address 10.2.255.211/32

·         Advertise this prefix in BGP toward vedge21.

·         Create DHCP Pool named br1_guest for branch#1 Guest subnet.

·         Create DHCP Pool named br2_guest for branch#2 Guest subnet.

·         Explicitly associate both DHCP pools with the VRF guest.

·         In each subnet, assign addresses from .101 up to .254 inclusively, and the appropriate gateway to clients.

·         Associate host42 and host52 with guest VN in DNAC, and make sure that both hosts receive the appropriate address.

·         Make sure that host42 and host 52 can ping 8.8.8.8 in the ISP cloud.

 

 

2.6                                                                                   : Support for silent Hosts in Branch #2

The item consists of multiple questions. You may need to scroll down to be able to see all questions. In future, Branch#2 will be equipped with IP-based IoT endpoints operating in speak-when-spoken-to mode also called silent hosts. Which of the following SDA features enables a working connectivity with these IoT endpoints?

·         Native Multicast

·         Endpoint Mobility

·         Layer 2 flooding

·         Layer 2 Extension

In the statement below, select one of the options from the drop-down list to complete the sentence and form a correct statement.

For SDA to support silent hosts,   ---------------------Selection Option----- in the underlay as a prerequisite.

Options:-

·         IP Multicast routing with PIM-SM must be enabled

·         No additional capability aside from unicast IP Connectivity is required.

·         IS-IS must be used as a routing protocol

·         DHCP Snooping must be enabled.

 

3.1: Enabling CLI access to r30

          There is no direct console access provided to the router r30. Moreover, r30 does not accept any remote connections because its VTY lines are configured with transport input non. Using RESTCONF, enable remote access to r30 for all remote access protocols, according to these requirements:

·         You can use host31 to access router r30 using ip address 10.3.11.1

·         You can use any method of accessing the RESTCONF API on r30 from host31, including curl, python, or postman.

·         You must change the input transport protocol on all configurable VTY lines.

·         The input transport protocol value setting must be changed from none to all.

Important Parameters:

·         Username / Password for HTTP authentication

§  admin / admin

§  URL

§ 

This is the hidden content, please

• Sign In
• or
• Sign Up

·         HTTP Method

§  GET

o   HTTP method to modify the configuration

§  PATCH

o   HTTP Headers

§  Content-Type:application/yang-data+json

§  Accept:application/yang-data+json

o   Recommended curl switches

§  -I,-k,-X,-H,-u,-d

 

3.2 Using Guest Shell and Python on r30

On r30, enable guestshell and create a python script name ribdump.py in the guestshell according to these requirements:

·         If an additional IP network is necessary to start guestshell, you are allowed to use addresses from the range 192.168.255.0/24. This range must not be advertised in any routing protocol.

·         The python script must be saved under the name ribdump.py in the home directory of the guestshell user.

·         The purpose of the script is to display the complete contents of all routing tables in non-default VRFs created on the router.

·         The script must execute the show ip route Vrf… or show ipv6 route vrf… command for every non default VRF created on the router, depending on what address families are enabled in that VRF.

·         The script must determine the list of created VRFs and enabled address families dynamically every time it is run using, for example, show vrf brief | include ipv4

·         The script must not attempt to display the VRF routing table for an address family that is not enabled in the VRF.

·         It must be possible to run the script using the guestshell run python ribdump.py command from privileged EXEC mode.

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

Please update the solution like CCIE V5.  I hope everyone will support and update their knowledge to make perfect solution.

 

Is this the list of question that were on the exam ? 

[Eze]

 

Attempted lab and failed.

Lot of things to discuss will be updating it to all soon here.

Thanks to CC we all were missing you lets discuss guys so that we crack it easily. 

Do not relay on any workbook discussing on every point is must lets provide feedbacks very important to pass for all.
 

 

 

Sorry about that Bro but then it is well just don’t give up I believe you will definitely crack it next attempt 

[Eze]

On 6/14/2021 at 1:29 PM, enterprise said:

Attempted lab and failed.

Lot of things to discuss will be updating it to all soon here.

Thanks to CC we all were missing you lets discuss guys so that we crack it easily. 

Do not relay on any workbook discussing on every point is must lets provide feedbacks very important to pass for all.

 

Sorry about that Bro. I believe next attempt you will crack it. 

[Vlaja]

On 6/14/2021 at 6:29 AM, enterprise said:

Attempted lab and failed.

Lot of things to discuss will be updating it to all soon here.

Thanks to CC we all were missing you lets discuss guys so that we crack it easily. 

Do not relay on any workbook discussing on every point is must lets provide feedbacks very important to pass for all.

 

do you have a list of question that came on the exam ?

[mrhacker]

Sorry to listen Vlaja, you can crack next time. So please can you share your experience about exam. which i share the question is all OK or any changes.

 

Please can you share the percentage also from each Area.

 

[mrhacker]

4 hours ago, Vlaja said:

do you have a list of question that came on the exam ?

 

[Vlaja]

Sorry for confusion, this was more the question for you as you posted these questions.I was wondering if you could share  where did you get them from ? Are they coming from chinesedumps or somewhere else ? Were these questions on the exam ? thank you in advance !

[mrhacker]

2 hours ago, Vlaja said:

Sorry for confusion, this was more the question for you as you posted these questions.I was wondering if you could share  where did you get them from ? Are they coming from chinesedumps or somewhere else ? Were these questions on the exam ? thank you in advance !

Dear Vlaja,

Already this questions available on internet and also one my friend share to me and he also preparing for lab. This question are from 2 to 3 vendors have same questions.

 

regards

[a7s]

Great. Thanks

[kashbangi]

Congrats Not bad

[Vlaja]

anyone taking exam in September ?

[Sherlock007]

Sad to hear you  didn't pass Mate, but thanks for the feedback!

[Vlaja]

On 7/22/2021 at 11:53 PM, Sachiho said:

I will take the exam in the first half of August, but still have many questions.

How did it go ? 

[Joshua]

Thanx

[msncse]

How you guys preparing for design part ? Does anyone has question for design section please ?