DESIGN section answered

[bboycoi]

Thanks

[Himura]

Hi,
Could someone explain about  Q21

 

Q21: Doubts I think E - The end host coult not locate their
DHCPv6 server and F - The end host did not have...


I`m not 100% sure when I have to go with ipv6  😁

[bengini]

Can you please share the Design material in this thread, I see you are discussing for different questions, but where is the material?

[Himura]

7 hours ago, bengini said:

Can you please share the Design material in this thread, I see you are discussing for different questions, but where is the material?

Hi @bengini,  You have to look for it in Offer section.

Regrds

[zshengh]

thanks

[ShoIProute]

On 11/20/2021 at 8:04 AM, Jocantaro said:

I will paste all solutions I have, in some of them I have doubts or maybe the solutions are wrong, It will be appreciated If anyone contributes to solve it, I spend a lot of hours searching info and only one person answered 😕

  Hide contents

Question 2: C - Configure ports toward end hosts as edge ports

Question 3: B - Trunk ports are not considered as edge ports unless explicitly configured to.

Question 4: EIGRP DMVPN

Question 5: Static (provides shortest, L3 and L2 support, LB), LACP ( misscabling, widest vendor, L3, L2, misconfig, LB)

Question 6: A - L2/L3/L4

Question 7: Decrease Dead int (only a failure...), Decrease hello (only a revival ¿? DOUBTS maybe BOTH?), BFD (both), decrese initial SPF (both ¿?)

Question 8.1: B- Distribute lists E - Prefix suppression

Question 8.2: Distribute List ( most cases...), Multi Areas (control dist, most cases config and forget), Summ (most cases requ.), Prefix supp (Control dist, Most cases...) Filter-List (most cases...) 

Question 8.3: A - Incorrect deployment of distribute lists may cause permanent routing loops D - Distribute links in OSPF have no influence on the contents of the CEF FIB on the router

Question 9.1:  C - sw101, sw102, sw110 and sw211

Question 9.2: A - Port channels toward sw101 and sw102

Question 9.3: B - On switches performing DHCP Snooping, disable Option 82 insertion A? - On IOS based DHCP servers and relay agents, accept DHCP messages containing Option 82
having all-zero giaddr

Question 10: A - Shortcut switching is enabled on the DMVPN tunnel of r62 and r70 C - NHRP Redirects are enabled on the DMVPN tunnel of r24

Question 11: F - Private VLANs with an isolated and a community secondary VLAN

Question 12: R24 -> Create parent Shaper, Create child QoS, apply the parent Qos policy....-> R70 Configure NHRP QoS Group name

Question 13: I have doubts R3 is RR for R4 R5 and R6, R3 knows both paths to Branch#3 but as a RR only passes the bestpath to its clients not all paths, If we configure multipath? (C) I think It´s E) on R4 (RR client) bgp max path settings increased

Question 14: D - 239.2.1.1 G - 239.1.1.1

Question 15: Option B in both sw101 and sw102

Question 16: B - R11 D - R21

Question 17: B - Loopback0 prefixes of all PE and P Routers

Question 18: E - LDS advertisement filter applied to PE and PE routers

Question 19: B - MPLS TTL Propagation disabled on PE routers

Question 20: C - The M-Flag was not set in RA

Question 21: Doubts I think E - The end host coult not locate their DHCPv6 server and F - The end host did not have...

Question 22: B - Enable RA Guard

Question 23.1: Non prop VRRP IPv6RA, active role can coupled HSRP, transparent to end host (HSRP, VRRP), BFD (HSRP, VRRP)

Question 23.2: DOUBTS D - VRRP only, ipv6 RA???

Question 24: B - E and doubts ( C or D)

Question 25: A - On the link..... C - Config a backup

Question 26: C and D

Question 27: D and doubts between A and C

Question 28: E - one /25 subnet

Question 29: ¿?

Question 30: C and doubts

Question 31: DNA GUI (SNMPv3, TACACS, Port Sec, App policy, anycast), DNA template (UDLD, MSTP,...) DOUBTS

Question 32: E - Set up fabric SGACLs... and A - Utilize and external FW...

Question 33: E - Use the DNA Center application policy.... ¡'

Question 34: C - D

Question 35: Requieres Guestshell (EEM python, EEM applet), Allow sharing (EEM applet), Allow sche (all), Allos trigger (EEM py, EMM app), Allows running (Standar python...)

Question 36: D

Question 37.1: B

Question 37.2: B

Question 37.3: A

Question 38: Doubts

            

 

 

Just wanted to revive this thread and see if we can all collaborate to crack the design section. there are new questions out but i wanted to go over some of the original ones that are still there. If anyone passed recently hopefully you can chime in.

I went over Jocantaro's solutions (quoted) and picked out the ones that are still relevant but there are still some questions that im not sure about. i'll leave out some of the ones that i agree with and only address the ones that i have a different opinion about:

 

Question 8.3 (two disadvantages of using distribute list to control the routing table contents):

- Incorrect deployment of distribute lists may cause permanent routing loops
- Administrative overhead will grow since distribute lists must be deployed on all OSPF routers

i wouldnt choose "Distribute links in OSPF have no influence on the contents of the CEF FIB on the router" because since distribute lists control which OSPF routes from the LSDB are allowed to be installed in the RIB, which ultimately affects the FIB then that answer can't be correct.

 

Question 9.1 (which switch or switches must perform DHCP Snooping to avoid DHCP-related incidents in the HQ?):

here I would choose sw110 only because according to the design "all current and future end hosts on HQ will be connected ONLY TO SW110". The main point of DHCP Snooping is to protect DHCP clients by verifying that messages coming from DHCP servers are coming in through the proper ports.
Ports where DHCP clients are plugged into should only send DHCP DISCOVER and REQUEST messages. it probably wouldnt make sense to configure DHCP snooping on the distribution switches that wont have end hosts plugged into them. Typically DHCP OFFERS and ACKs would be coming from that direction, so theres probably less of a need to configure dhcp snooping there because theres no end hosts to protect on those switches. thats just my take on it

 

Question 12 (Drag the QoS configuration action):

I would say,

R24 -> step #1 - Create child QoS policy Handling traffic, classes, step #2 - Create parent QoS policy with 10Mbps shaper, step #3 Associate the child QoS policy with the parent QoS policy, step #4 Apply the parent QoS policy as an NHRP-mapped policy on the tunnel

R70 -> Configure NHRP QoS Group name (agreed with Jocantaro)

 

Question 13 (What change is required to the BGP configuration in the environment of Global SP #1 so that r4 learns about multiple paths to networks at Branch #3?):

I think the answer is "On r5 and r6, unique RDs need to be configured". Since according to the design "RD 10000:1 on all PEs", when r3 (the RR) receives that prefix from both r5 and r6 it would place it into its BGP table with the same RD value and would have to select only the prefix with the best path. It will only send the best path to its RR clients (RFC 1966 Section 5: "When a route is received by a RR, it selects the best path based onits path selection rule.")
configuring BGP Multipath on r3 would only allow r3 to loadshare traffic destined to that prefix, but wouldnt effect r4. The maximum-paths setting would only dictate how many of the multiple paths are allowed to be selected and installed in the routing table. configuring unique RDs on r5 and r6 would be similar to what the "BGP Add-Path" feature does but instead of the RD it uses a concept called the "Path-ID":

"The BGP Additional Paths feature is implemented by adding a path identifier to each path in the NLRI. The
path identifier (ID) can be considered as something similar to a route distinguisher (RD) in VPNs, except that
a path ID can apply to any address family. Path IDs are unique to a peering session and are generated for each
network"

 

Question 17 (What prefixes, along with their label bindings must be advertised by LDP in the MPLS 
mock lab to enable MPLS L3VPN services?):

i agree with Jocantaro on this one because you need the label bindings for the PE and P routers for a complete label switch path. If you dont have labels for the P routers even in this topology you would break the LSP. in OSPF the loopbacks for each PE and P routers will be exchanged and any router with LDP enabled will generate a label for that loopback and they will forward packets to their next hop router based on the remote label binding advertised for that loopback. especially since the MPLS LDP session is established using the Loopback IP of the P and PE routers. all other labels are unnecesary for MPLS L3VPN.

 

Question 18 (What mechanism and type of deployment would be the most appropriate to accomplish 
the label filtering goals as requested?):

here I would say LDP advertisement filter just for the P routers only -  (LDP advertisement filter applied to P routers) 
The requirement is that they dont want to break IP connectivity and they want to allow all labels except the training department's 200 loopbacks. if according to the design only r1 and r2 (the "P" routers) are configured with the loopback interfaces then they would be the only ones that would need an LDP advertisement configured i think. in order to prevent any other routers from receiving the labels for the training department loopbacks. and prefix-suppresion would break IP connectivity to the transit links

 

Question 21 (Given the description of the issue, what are the two reasons for the absence of RAs breaking the IPv6 connectivity?): 

im still on the fence about this one and not sure. but I think its this:

- The end hosts could not locate their default gateway
- The end host did not have the necessary information for an autoconfiguration mechanism"

Anyone who knows care to chime in?

 

Question 22 (What would be the proper approach to meet the security requirement as stated by Travis?):

i think the answer is - Implement IPv6 Secure Neighbor Discovery(SeND)

The requirement according to the design is for hosts to continue using DHCPv6 so they would need the global prefix information from the RAs so if the routers stop sending RAs they wont get that critical information.
they want to prevent hackers from eavesdropping on the prefix information from the RAs. enabling RA Guard and Suppressing prefix information would prevent the hosts from getting the necessary information for DHCPv6.
What they want is to obscure the prefix information in the RAs from anyone who is not authorized to see it and that is what "SeND" would do. SeND encrypts the RA messages using RSA keys or PKI

Question 23.2 (Given Travis preference, what would be the first hop redundancy mechanism of choice?):

i think its "VRRP only" because one of the requirements is that the solution "does not inundate the end hosts with excess traffic to process, and whole inner workings are simple."
The more you tune IPv6 RA message frequency the more messages you will be sending to the end hosts and since they speak IPv6 they will have to process those message and possibly overburden the CPU. since they dont speak VRRP, they would ignore those packets. Also, vrrp counts as an "open" protocol and is able to switch over to another gateway within 1 second -

"One thing-I definitely prefer open protocols"

"we would like to pick and tune the protocol to allow end hosts to switch over to another gateway within 1 second is most"

 

Question 24 (When building the overall SD-WAN policy to meet the Payment Card Industry requirements for the Point Of Sale(POS) terminals at Branch #1 and Branch #2, what three steps must be accomplished in vManager?):

- Create POS VPN AND VPN interface feature templates and apply them to Branch #1 and Branch #2 device templates 
- Apply the policy outbound to the Site IDs of Branch #1 and Branch #2
- Create a policy to set the TLOCs for Branch #1 and Branch #2 POS OMP routers to the DC TLOC(s)

you want to apply the policy outbound to Branch 1 and 2 so that they can receive the TLOCs for each others prefixes pointing to the DC instead of directly to the other Branch in order to fulfill the requirement: 

"Under no circumstances may POS terminals on Branch #1 communicate directly with POS terminals on Branch #2 and vice versa. Any such communication be instead routed through the data center where we have the necessary firewalls in place"

 

Question 28 (Given the intended scope of SDA fabric deployment on Branch #2, which option represent the smallest applicable IP pool in DNA Center to support LAN Automation on Branch #2):

this one gives me a lot of trouble. I have no idea how to answer this question or what documentation backs up the actual answer. Is this just simple basic subnetting/VLSM? im not sure if this is particular to SD-Access or just basic subnetting. Anyone who passed the design section care to chime in?

 

Question 29 (Which option represents the smallest applicable IP pool in DNA Center to support the planned Layer3VN handoffs on Branch#2): 

I have the same issue with this as Question 28. not sure if its something specific to SD-Access or if its just plain old basic subnetting???

 

Question 30 (Which two design options are applicable to provide transit between planned SDA fabrics in Branch#1?):

This one seems obvious:

- Deploy IP Transit between Branch #1 and Branch#2
- Use BGP as a handover protocol between SDA border nodes and SD-WAN vEdge routers

but im not sure if its a trick question and im missing something?

 

Question 32 (What are two possible ways of ensuring that authorized local administrators in the Employee VN on Branch #1 or Branch #2 can still access the local SDA border nodes using their loopback 
addresses through in-band SSH access?:

i got:

- Utilize an external firewall for controlled inter-VN communication. 
- Utilize a vEdge router as a fusion router

SGACLs would be more relevant for INTRA* VN communication (microsegmentation)

 

Question 33 (Refer to the new resource(s) available. What are the two valid design options for deploying QoS on the SDA branches that will meet FABD2 requirement?):

i agree. I got:

- Use the DNA Center to define business-irrelevant application sets.
- Use the DNA Center application policy to rebuild the QoS policy.

They want to be able to mark down business-irrelevant apps and they would like to take the SDA approach. in DNAC you can use the application policy to do this. i dont think its "extending the existing queing model into a new 4/5 class model" since i believe they're pretty much already using that.

 

For questions 34-37 i wasn't sure. not too strong with automation/programmability. Hopefully someone who is can chime in

hopefully my inputs helps. i dont know if my answers are correct but together we can crack that design section

[johnnyboy]

On 12/5/2022 at 11:57 PM, ShoIProute said:

Just wanted to revive this thread and see if we can all collaborate to crack the design section. there are new questions out but i wanted to go over some of the original ones that are still there. If anyone passed recently hopefully you can chime in.

I went over Jocantaro's solutions (quoted) and picked out the ones that are still relevant but there are still some questions that im not sure about. i'll leave out some of the ones that i agree with and only address the ones that i have a different opinion about:

 

Question 8.3 (two disadvantages of using distribute list to control the routing table contents):

- Incorrect deployment of distribute lists may cause permanent routing loops
- Administrative overhead will grow since distribute lists must be deployed on all OSPF routers

i wouldnt choose "Distribute links in OSPF have no influence on the contents of the CEF FIB on the router" because since distribute lists control which OSPF routes from the LSDB are allowed to be installed in the RIB, which ultimately affects the FIB then that answer can't be correct.

 

Question 9.1 (which switch or switches must perform DHCP Snooping to avoid DHCP-related incidents in the HQ?):

here I would choose sw110 only because according to the design "all current and future end hosts on HQ will be connected ONLY TO SW110". The main point of DHCP Snooping is to protect DHCP clients by verifying that messages coming from DHCP servers are coming in through the proper ports.
Ports where DHCP clients are plugged into should only send DHCP DISCOVER and REQUEST messages. it probably wouldnt make sense to configure DHCP snooping on the distribution switches that wont have end hosts plugged into them. Typically DHCP OFFERS and ACKs would be coming from that direction, so theres probably less of a need to configure dhcp snooping there because theres no end hosts to protect on those switches. thats just my take on it

 

Question 12 (Drag the QoS configuration action):

I would say,

R24 -> step #1 - Create child QoS policy Handling traffic, classes, step #2 - Create parent QoS policy with 10Mbps shaper, step #3 Associate the child QoS policy with the parent QoS policy, step #4 Apply the parent QoS policy as an NHRP-mapped policy on the tunnel

R70 -> Configure NHRP QoS Group name (agreed with Jocantaro)

 

Question 13 (What change is required to the BGP configuration in the environment of Global SP #1 so that r4 learns about multiple paths to networks at Branch #3?):

I think the answer is "On r5 and r6, unique RDs need to be configured". Since according to the design "RD 10000:1 on all PEs", when r3 (the RR) receives that prefix from both r5 and r6 it would place it into its BGP table with the same RD value and would have to select only the prefix with the best path. It will only send the best path to its RR clients (RFC 1966 Section 5: "When a route is received by a RR, it selects the best path based onits path selection rule.")
configuring BGP Multipath on r3 would only allow r3 to loadshare traffic destined to that prefix, but wouldnt effect r4. The maximum-paths setting would only dictate how many of the multiple paths are allowed to be selected and installed in the routing table. configuring unique RDs on r5 and r6 would be similar to what the "BGP Add-Path" feature does but instead of the RD it uses a concept called the "Path-ID":

"The BGP Additional Paths feature is implemented by adding a path identifier to each path in the NLRI. The
path identifier (ID) can be considered as something similar to a route distinguisher (RD) in VPNs, except that
a path ID can apply to any address family. Path IDs are unique to a peering session and are generated for each
network"

 

Question 17 (What prefixes, along with their label bindings must be advertised by LDP in the MPLS 
mock lab to enable MPLS L3VPN services?):

i agree with Jocantaro on this one because you need the label bindings for the PE and P routers for a complete label switch path. If you dont have labels for the P routers even in this topology you would break the LSP. in OSPF the loopbacks for each PE and P routers will be exchanged and any router with LDP enabled will generate a label for that loopback and they will forward packets to their next hop router based on the remote label binding advertised for that loopback. especially since the MPLS LDP session is established using the Loopback IP of the P and PE routers. all other labels are unnecesary for MPLS L3VPN.

 

Question 18 (What mechanism and type of deployment would be the most appropriate to accomplish 
the label filtering goals as requested?):

here I would say LDP advertisement filter just for the P routers only -  (LDP advertisement filter applied to P routers) 
The requirement is that they dont want to break IP connectivity and they want to allow all labels except the training department's 200 loopbacks. if according to the design only r1 and r2 (the "P" routers) are configured with the loopback interfaces then they would be the only ones that would need an LDP advertisement configured i think. in order to prevent any other routers from receiving the labels for the training department loopbacks. and prefix-suppresion would break IP connectivity to the transit links

 

Question 21 (Given the description of the issue, what are the two reasons for the absence of RAs breaking the IPv6 connectivity?): 

im still on the fence about this one and not sure. but I think its this:

- The end hosts could not locate their default gateway
- The end host did not have the necessary information for an autoconfiguration mechanism"

Anyone who knows care to chime in?

 

Question 22 (What would be the proper approach to meet the security requirement as stated by Travis?):

i think the answer is - Implement IPv6 Secure Neighbor Discovery(SeND)

The requirement according to the design is for hosts to continue using DHCPv6 so they would need the global prefix information from the RAs so if the routers stop sending RAs they wont get that critical information.
they want to prevent hackers from eavesdropping on the prefix information from the RAs. enabling RA Guard and Suppressing prefix information would prevent the hosts from getting the necessary information for DHCPv6.
What they want is to obscure the prefix information in the RAs from anyone who is not authorized to see it and that is what "SeND" would do. SeND encrypts the RA messages using RSA keys or PKI

Question 23.2 (Given Travis preference, what would be the first hop redundancy mechanism of choice?):

i think its "VRRP only" because one of the requirements is that the solution "does not inundate the end hosts with excess traffic to process, and whole inner workings are simple."
The more you tune IPv6 RA message frequency the more messages you will be sending to the end hosts and since they speak IPv6 they will have to process those message and possibly overburden the CPU. since they dont speak VRRP, they would ignore those packets. Also, vrrp counts as an "open" protocol and is able to switch over to another gateway within 1 second -

"One thing-I definitely prefer open protocols"

"we would like to pick and tune the protocol to allow end hosts to switch over to another gateway within 1 second is most"

 

Question 24 (When building the overall SD-WAN policy to meet the Payment Card Industry requirements for the Point Of Sale(POS) terminals at Branch #1 and Branch #2, what three steps must be accomplished in vManager?):

- Create POS VPN AND VPN interface feature templates and apply them to Branch #1 and Branch #2 device templates 
- Apply the policy outbound to the Site IDs of Branch #1 and Branch #2
- Create a policy to set the TLOCs for Branch #1 and Branch #2 POS OMP routers to the DC TLOC(s)

you want to apply the policy outbound to Branch 1 and 2 so that they can receive the TLOCs for each others prefixes pointing to the DC instead of directly to the other Branch in order to fulfill the requirement: 

"Under no circumstances may POS terminals on Branch #1 communicate directly with POS terminals on Branch #2 and vice versa. Any such communication be instead routed through the data center where we have the necessary firewalls in place"

 

Question 28 (Given the intended scope of SDA fabric deployment on Branch #2, which option represent the smallest applicable IP pool in DNA Center to support LAN Automation on Branch #2):

this one gives me a lot of trouble. I have no idea how to answer this question or what documentation backs up the actual answer. Is this just simple basic subnetting/VLSM? im not sure if this is particular to SD-Access or just basic subnetting. Anyone who passed the design section care to chime in?

 

Question 29 (Which option represents the smallest applicable IP pool in DNA Center to support the planned Layer3VN handoffs on Branch#2): 

I have the same issue with this as Question 28. not sure if its something specific to SD-Access or if its just plain old basic subnetting???

 

Question 30 (Which two design options are applicable to provide transit between planned SDA fabrics in Branch#1?):

This one seems obvious:

- Deploy IP Transit between Branch #1 and Branch#2
- Use BGP as a handover protocol between SDA border nodes and SD-WAN vEdge routers

but im not sure if its a trick question and im missing something?

 

Question 32 (What are two possible ways of ensuring that authorized local administrators in the Employee VN on Branch #1 or Branch #2 can still access the local SDA border nodes using their loopback 
addresses through in-band SSH access?:

i got:

- Utilize an external firewall for controlled inter-VN communication. 
- Utilize a vEdge router as a fusion router

SGACLs would be more relevant for INTRA* VN communication (microsegmentation)

 

Question 33 (Refer to the new resource(s) available. What are the two valid design options for deploying QoS on the SDA branches that will meet FABD2 requirement?):

i agree. I got:

- Use the DNA Center to define business-irrelevant application sets.
- Use the DNA Center application policy to rebuild the QoS policy.

They want to be able to mark down business-irrelevant apps and they would like to take the SDA approach. in DNAC you can use the application policy to do this. i dont think its "extending the existing queing model into a new 4/5 class model" since i believe they're pretty much already using that.

 

For questions 34-37 i wasn't sure. not too strong with automation/programmability. Hopefully someone who is can chime in

hopefully my inputs helps. i dont know if my answers are correct but together we can crack that design section

Thanks for the discussion on this.  Any new questions you can remember?

[ShoIProute]

On 1/8/2023 at 4:54 PM, johnnyboy said:

Thanks for the discussion on this.  Any new questions you can remember?

 

Thanks, the only ones I can remember from memory are the ones that I had placed in another  post:

Check those out. I'll try to remember some of the others and let u all know as they come to my memory.

[aceHossy]

thanks

[maxdieng]

HELLO