Task 1.8: OSPFv2 in DC

[Dunkle]

The solution I have seen appears incorrect around the vedges. Simply changing the MTU does stabilize the neighbor ship between vedge and vlan 3999 however all or most of the routes learned at the vedge on vpn999 become inactive. Does it violate condition of the task to change the OSPF process for vlan3999 and perform a mutual redistribution between the new process and the existing process to solve this task?

[smak]

"Do not redistribute unless specifically told to" - From the exam rules

 

I would suggest configuring the mtu and shut/no shut on the vlan 3999. This should stabilize the routes. 

Edited June 23, 2022 by smak

[MrPlinkett]

FYI - there's an issues around OSPF if the RID for the vEdge is the same for both VPN 999 and VPN 0.

I highly suspect this is the instability you talk about, and this is not a problem in the exam.

[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...

 

[MrPlinkett]

Exact same thing happened to me in the first lab - where I was missing certain routes from the SD-WAN site across VPN 999.

Similar to you, I bounced the VLAN interface and that seemed to fix the problem. Tragically I only had 5 minutes left on the lab.

[kat]

Do you set the configs below?

int vlan 3999

ip mtu 1496

ip ospf prefix-suppression disable 

 

[CCIEval23]

On 9/12/2022 at 1:17 PM, kat said:

Do you set the configs below?

int vlan 3999

ip mtu 1496

ip ospf prefix-suppression disable 

 

this is the only config i've found to solve the issue of routes not installing, but im not sure whether this satisfies the question requirements.

the other methods,  clear ospf process, change ospf priority,  bounce vlan interface only work until the devices are restarted.   

anyone have another solution on this?  or are we happy with the config above?

[ShoIProute]

On 9/12/2022 at 8:17 AM, kat said:

Do you set the configs below?

int vlan 3999

ip mtu 1496

ip ospf prefix-suppression disable 

 

 

On 1/15/2023 at 11:02 AM, CCIEval23 said:

this is the only config i've found to solve the issue of routes not installing, but im not sure whether this satisfies the question requirements.

the other methods,  clear ospf process, change ospf priority,  bounce vlan interface only work until the devices are restarted.   

anyone have another solution on this?  or are we happy with the config above?

hey guys, honestly I always thought that int vlan 3999 should have the prefix-suppression disabled, but all the solutions I've seen don't include this for some reason. I haven't had a chance in a long time to do a lab with the vEdge powered on and check to see how this effects reachability, but I think it depends on who becomes the DR for that segment. If the IOS router (sw201 or sw202) has prefix-suppression enabled and becomes the DR, it might cause some problems, since with a broadcast network-type, the DR generates a network LSA for the link and advertises /32 as the subnet mask of the associated subnet in order to hide the transit-only network. I'm not 100% sure if this is what is occurring, but I suspect it might be. I will lab this up soon. Let me know wat u guys think.

[johnnyboy]

On 1/23/2023 at 10:38 PM, ShoIProute said:

 

hey guys, honestly I always thought that int vlan 3999 should have the prefix-suppression disabled, but all the solutions I've seen don't include this for some reason. I haven't had a chance in a long time to do a lab with the vEdge powered on and check to see how this effects reachability, but I think it depends on who becomes the DR for that segment. If the IOS router (sw201 or sw202) has prefix-suppression enabled and becomes the DR, it might cause some problems, since with a broadcast network-type, the DR generates a network LSA for the link and advertises /32 as the subnet mask of the associated subnet in order to hide the transit-only network. I'm not 100% sure if this is what is occurring, but I suspect it might be. I will lab this up soon. Let me know wat u guys think.

I my opinion the 3999 would be like any other ospf interface handling a point to point adjacency.  The interface is just transit like an adjacency to another router.  Why would you need to have reachability from another router to that link?.  4000 handles the management traffic for the vEdge (right?) which would require reachability from a remote network.  

[ShoIProute]

3 hours ago, johnnyboy said:

I my opinion the 3999 would be like any other ospf interface handling a point to point adjacency.  The interface is just transit like an adjacency to another router.  Why would you need to have reachability from another router to that link?.  4000 handles the management traffic for the vEdge (right?) which would require reachability from a remote network.  

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.

Edited February 4, 2023 by ShoIProute

[Himura]

Thanks for sharing your comments, now I can see things in other perspective.  I have to test it in my home lab. 

By the way,  Anyone have the preconfig of sdwan devices for this lab ??  I have seen the labs+preconfig for router/switch but I can`t find the one for sdwan+dnac+ise