briansmith41

@MrPlinkett, I ran across something similar to this in my last lab. Once I had prefix suppression enabled at DC, the vEdge was not advertising routes that it received from upstream IOS neighbors. What I found was that if the upstream IOS devices connected to vEdge were the DR and BDR in VLAN 3999, prefix-suppression was causing the vEdge to not advertise routes it received. If I flipped the OSPF priority on the sw201 and sw202 so they would never become DR/BDR, and the vEdges took over as the DR and BDR, everything went back to normal, and the vEdges advertised routes into OMP from DC. According to the OSPF RFC for prefix-suppression, PS enabled devices connected to NON-PS enabled devices shouldn't run into issues like this. But it seems to be happening nonetheless...

How is everyone creating the control policy/topologies for this route leaking? The way I see it, you could: #1 - create two topologies, one for branches to leak 198/200 into VPN 999, and apply it directly to the branch site-ids....and another topology for the DC to leak VPN 999 into 198/200, applied directly to the DC site-id OR #2 - create one topology, and make your entries more specific to reference a site-id for branches and a site-id for DC, relevant to what the task asks for...and then attach both branch and DC to the policy Both seem to work fine...just trying to figure out if one of them is the "wrong" way to do it based on the task.

When creating the IoT VN in task 2.x, do we think that we NEED to create an SGT as well, based on what the task asks for? You can assign switchports to a VN without an SGT and it will work fine, and the task doesn't ask for SGTs....but I'm not 100%. Any thoughts?

Does anyone know if there's an implicit requirement to have reachability to ALL IP's/interfaces in the CCIE EI lab? I.e advertise any loopbacks, connected interfaces, etc. Taking into account if the question asks for them not to be advertised...thinking of OSPF prefix suppression. Thoughts guys?

If I recall correct, it's basically identical to the v1.0 of task 1.4 + the addition of area 1 at HQ + area 1 summarization + ospf traffic engineering. Were you just looking for specifics on that?

Awesome, that at least leads me to believe my method is correct...ish

LACP fast switchover IS available on that image Dunkle. But that command only applies when max-bundling is used with it....so I really don't think the solution is valid. It has to be "mode active" despite it not making tons of sense.

Sorry all, looks like I can't post the group here, as it violates the rules. Please PM me if you are interested in joining.

For those interested, I've created a skype group here: XXXXXXX WARNING READ THE RULES BEFORE POSTING. FINAL WARNING ORELSE YOU WILL GET BANNED

Hello, looking to get a CCIE Lab discussion post. I have a few specific tasks from the lab that I have questions on. Anyone else in the same boat and interested in discussion?

This question asks for etherchannels to use the "shortest link bundling time possible". I realized that seems to simply mean that any LACP enabled ports should be using "mode active". Make sense to anyone else? I believe I got this wrong on the last attempt by not using "mode active"