ShoIProute

I think I finally found the link. And it looks like the answer is Auto RP: [Hidden Content]

Hey Bengini, I hope ur doing well, "In my opinion it should be a specific request, such as: Ospf should be on L3 links as it is for the Ipv6 EIGRP and make sure that there is an alternative way for traffic if other Ospf areas will be added in a future" I agree with u 100% here. But this comment is only relevant to whether or not u configure the vlan2000-2001 SVIs as "passive-interfaces" or not. To respond to ur comment about whether the Virtual-Link is necessary or not, as an experiment, can u please post a traceroute to sw211 (10.2.255.211) from host12 without the Virtual-Link configured and tell us all which path it takes? And then can u do a "show ip route ospf" on sw102 without the Virtual-Link configured and tell us what the next hop is for all of the DC prefixes? (For everything in the 10.2.0.0/16 range). Then u can let us know what the Primary path for traffic from HQ to the DC is. Does it fulfil the requirement in the Task where it says: The primary traffic path must be the link between sw101 & sw201 and the link between sw102 & sw202 must become primary path during primary link failover. Does host 11, host12, sw101, sw102, r11 and r12 all take the Primary Path? (sw101-sw201) with ur configuration (the one without the virtual-link)? Please post those traceroutes and the output for the routing table on sw102 🙂

This is actually incorrect. Configuring "no passive-interface vlan 2000 (and 2001)" will not prevent traffic from the DC to go thru sw201/sw101 link. Whether u configure those SVIs as passive or not passive will have no bearing on which path the DC devices take to enter into HQ, since they those devices will always seek to take the path with the lowest cost. Advertising a more attractive metric (For example: sw101 advertise 10.1.0.0/16 with the lowest cost and sw102 will advertise 10.1.0.0/16 with a higher cost) will fulfil that requirement. Because the DC will always want to enter into HQ via the sw201/sw101 link. On the other side, traffic from HQ going into the DC, will need to see a more attractive path to the DC on the sw101/sw201 link, but the problem is that traffic from host12 will always hit sw102 and from there it will exit out of sw102's g0/2 interface directly connected with sw202 because sw102 is receiving INTRA-Area (Area 0) LSAs from its link with sw202. Therefore, it will always prefer going out of its directly connected link to reach the DC, instead of forwarding the packets to sw101, since it will only see INTER-Area LSAs (In Area 1) from sw101. And in OSPF: Intra-Area LSAs always wins over Inter-Area. In order to solve this dilemma, sw102 needs to form a Virtual-Link with sw101 in order to receive Intra-Area Backbone routes from the DC via sw101. With this accomplished, u can now configure a higher cost on sw102's g0/2 interface so that it prefers to route thru sw101 to send packets to the DC. Without the Virtual-Link, it would only go thru its directly connected link with sw202. Whether or not the Data Plane forwards packets thru routers r11 and r12 is of no consequence and does not matter. The Task is not concerned with whether or not the solution is "optimal" or "suboptimal", even tho, passing the packets thru r11 and r12 instead of going thru the directly connected VLAN 2000 and 2001 Interfaces is actually suboptimal to me in my opinion, because those VLANs are directly connected between sw101 and sw102. Sending the packets downstream to the routers is adding an extra hop to the entire path. But my point is, whether or not u decide to configure the vlan 2000 and vlan 2001 interfaces as passive or not, it shouldn't really matter. It's configuring the Virtual-Link between sw101 and sw102 that will help u accomplish ur goal of making the link between sw101 and sw201 the primary link for traffic destined to the DC. It doesn't matter which path inside of HQ that the packets take in order to get to sw101. And yes, the task states that we are not allowed to touch sw201 or sw202 to accomplish this task: "The primary traffic path must be the link between sw101 & sw201 and the link between sw102 & sw202 must become primary path during primary link failover. For achieving this requirement you are not allowed to configure on sw201 & sw202"

I agree with not making the interfaces passive, although I'm not sure if it really makes a big difference in terms of what they want us to accomplish. And I think u mean adding the cost of 100 to the g0/2 interface of sw102, since we're not allowed to modify sw201/sw202 to solve that requirement.

Yup, that's exactly why. And the fact that u made the vl2000-2001 interfaces passive, so the data traffic can't pass thru that link, so it can only go thru r11/r12. Recall that a Virtual-Link is a Control Plane solution (for exchanging routing information). No data traffic can actually pass thru it. The actual packets still have to route hop by hop to the destination and cannot route thru the logical Virtual-Link.

Yes: Administration>Identity Management/Settings>User Authentication Settings Uncheck everything that would prevent u from using the username and pw that they want us to use.

Like what??

What were some of the new questions that u ran into? 🤨

Congratulations bro!!!

I think it would be ridiculous for them to expect u to open each Task/Section before u configure it. What if u took the exam already and ur anticipating what the questions will be? I can see what visasman is saying about all Tabs need to be in "unread" status. That makes sense. Because if u never opened up the Task or Section, how would u know exactly what the question is asking and what u need to do? Maybe they modified a question and have some variation. I think they would be suspicious if u didn't look at some of the Tasks or Sections and just entered in configurations for everything.

@benginiHave u actually done a debug and tested how long it takes for the Routers to failover? Can u post a debug with the Timestamp? The config that I posted above was actually tested. Do u not need to still lower the RA Lifetime in order for the Node to consider that particular Router unreachable? Have u tested the failover urself?

Hey @bengini I disagree with ur suggestion for Task 1.6 Check out this blog: [Hidden Content] and this one: [Hidden Content] For the reason why.

Right, what I'm saying is that if u reference a route-map that matches the prefixes, then u break the restrictions and miss the requirement, because u have to configure the entire solution in the "router ospf" mode, similar to the example that u provided. But I think if u reference a route-map, u won't get the points, since part of ur solution is configured outside of the route-map. I so have one problem with that config tho. I'm wondering why u guys are tagging the EIGRP/DMVPN routes??? I don't think that's necessary, because there are no requirements to filter those routes.

Interesting that u did everything similar to visasman's solutions and still failed. If u used a route-map for Task 1.8 then u definitely lost 4 points, because the requirement says: "The configuration of this requirement must be completed exclusively within the router ospf and interface vlan context " So the route-map breaks that requirement. 2 Questions for u: Were u at least close to passing the DOO module according to ur score? did u pass the Design module on that attempt or did u Fail it?

Congratulations!!! And thanks for the solutions and tips!!

That's what I thought LazerFokus. Tagging the EIGRP routes feels redundant and unnecessary to me.

Apparently a few years back in the community there were ppl who resolved this using EEM Scripts. But the solution that their looking for u to use is the "ip helper redundancy" or (Virtual Router Groups - VRG) feature which will make the UDP forwarding done by the DHCP Relay Agent "HSRP aware". With this configured, only the HSRP Router who is ACTIVE for a particular group will do the forwarding of the DHCP packets. In order to take advantage of this feature, a VRG (Virtual Router Group) must be configured in HSRP - (standby [group #] name [group name]) and then that same group name must be referenced in the DHCP relay agent config in order to keep track of the HSRP Active/Standby state on the router - (ip helper-address x.x.x.x redundancy [group name]) For example: interface vlan 2000 standby name HSRP_GROUP_2000 <- (Creates the Virtual Router Group) ip helper-address 10.2.255.211 redundancy HSRP_GROUP_2000 <- (Allows the DHCP Relay Agent to track the state of the Active HSRP router)

I think that might be a typo from the workbook where u got that from. I can confirm for sure on the exam that it was definitely 10.6.0.0/15 so u should be good.

^^^^ This is exactly how I configure the route-targets on r3 and r4 as well. Be careful not to simply use "route-target (both) 10000:3681" on r3 and r4, because u will end up with 4 commands instead of 3. It would look like this in the running-config: (On r3): vrf definition fabd2 route-target export 10000:3681 route-target import 10000:3681 (On r4): vrf definition fabd2 route-target export 10000:3681 route-target import 10000:3681 U want to use the minimum number of commands for this solution

I think this makes sense in a way. Because if r3 is importing RT 10000:414 (giosk vrf routes), then wouldn't that give all of the fabd2 sites reachability to the IPv4 prefixes from the IaaS site? And I think r4 is importing IPv4 and IPv6 prefixes from all of the Fabd2 sites by using the "route-target import 10000:3681" since it's not specifying an address-family. Can anyone confirm if any of the other fabd2 sites receive the IaaS prefixes and vice versa? I'm not where I can test this out right now at the moment. If they do receive the prefixes, then I guess there needs to be some way to filter them from getting to the IaaS site in order to fulfil the requirement: "Prevent the IaaS site from possibly learning about the routes on any other FABD2 site" And it still has to meet the requirement: "Use the minimum number of commands necessary to accomplish this requirements. Do not remove any existing configuration." With that solution, if r4 advertises only prefixes from HQ's IPv4 space (10.1.0.0/16), then the IaaS site would never learn about any other FABD2 sites (except for HQ), fulfilling the requirement. If I'm thinking about this right.

I get what ur saying to. I was referring to the conditions required for Task 1.4, but I think ur referring to the impact that this decision would have on what we configure in Task 1.3 Task 1.3 is always tricky for me as well. But in response to ur question above: "Is the automated grading going to shut down the physical interfaces 0/0-1 and see if the track objects go down?" I don't know, but I would say this depends. please recall that although they are using a script to grade the exam, the proctor also goes thru our configs to see if we have configured a solution that meets the requirement. It's not 100% automated. I have heard in the past that the proctor even tries to find ways to give u points if u came up with a solution that they didn't think of and it meets the requirements and doesn't break any constraints. Remember that theres more then 1 way to solve these tasks, and they consider that as long as it doesn't break any of the constrains. So with that said, Task 1.3 is very tough, AND VAGUE! because it doesn't specify the nature in how the loopbacks on r11 and r12 should be considered "unreachable". All it says is this: "If both r11 and r12 are declared unreachable from a preferred gateway, the other switch must be allowed to assume the gateway role." That's it! It doesn't say "if both r11 and r12 are declared unreachable from X interface or Y interface" or "if all paths to r11 and r12's loopbacks are lost, then that router is considered unreachable" or "if u lose 1 out of the 3 paths to the loopback, then it should be considered unreachable" It doesn't specify anything. Which is what makes that requirement even harder in my opinion. Also, keep in mind that u will always have 2 routes to get to either r11 or r12's loopbacks. Because even if u don't allow sw101 and sw102 to form an OSPF adjacency, let's take sw101 for example - sw101 will receive: A route to r11's loopback from r11 itself on its g0/0 interface advertised by r11 itself Another route to r11's loopback that is advertised by r12 on it's g0/1 interface So there will always be multiple paths to either router. Obviously, if u shut down r11 or r12's loopback, then it will become unreachable. But I'm not sure if it matters HOW sw101 and sw102 lose reachability to the router's loopbacks, but I think the most important thing is that IF they lose ALL available paths to the loopback, then the tracking object for that particular router should be considered "down". But also keeping in mind that BOTH routers need to be considered "down" in order for the switch to give up it's Active role (and this is why we're configured the "boolean or" track list) Hopefully that makes sense. What do u guys think? Does that sound like its in the ballpark?

The only reason why I would agree with configuring a VL is because of the requirement (and very vague requirement at that): "The primary traffic path for the traffic between HQ and DC must be the link between sw101 and sw102 and the link between sw102 and sw202 must become the primary path if the primary link fails" And if u ping the DC from host 12, it will hit sw102 and exit out of its directly connected link with sw202, which could be considered as breaking the requirement. If it wasn't for that, then I would probably say it's not necessary. But I'm not sure, what do u guys think?

Has anyone taken the lab recently? In particular, this month? I heard there might be some new questions for the Design section can anyone confirm? Any new changes?

I agree with everything except for the tagging of the redistributed EIGRP routes for the DMVPN branches. May I ask why we are tagging those?

Yeah, I agree with ur train of thought, but my point was in terms of accomplishing the goal of the task, in the context of the lab exam. Because the situation is that u have a BROADCAST adjacency between the vedges and sw201/202, (it's not p2p in the lab) so the behavior will be different when u enable prefix-suppression globally on sw201/202. That's what I was pointing out. By default on a vedge, the OSPF network type is Broadcast and not P2P, just like on IOS devices. If u want to change this (not sure if u can change it on the vEdges), then u can avoid the issue with the IOS switches becoming the DR and possibly filtering routes. What I was explaining was I think that might be the issue some have run into and it would make sense why when they force the vedges to be the DR, (either explicitly or by clearing the OSPF process) it resolves the issue. I have not yet had the chance to test this, but I was just looking at it from a technical perspective, thinking about the behavior of the OSPF protocol. I agree with ur philosophy of filtering the transit link between the vedges and switches 201/202, but I think the key is, in order for that to work without issues, u need to do 1 of 3 things. U either: 1. Make the ospf network-type of the link point-to-point 2. IF its Broadcast, make sure the vedges are the DR/BDR...OR 3. Simply DISABLE prefix-suppression for the interfaces leading to the vedges on switches 201/202 explicitly I think either one of the solutions should allow us to achieve the Task without running into any issues with other Routers receiving the SD-WAN Branch routes. If I'm not mistaken.