DOO 1.4

[mbjelo]

If interfaces are not passive we have direct neighborship between sw101 and 102 and we do not have traffic going through routers which is suboptimal. I did not know that requirement is not to change cost on sw202. In that case configuring  no passive vlan interfaces lead to not fulfillment requirement that all traffic from DC goes through sw201 sw101 link so we must make vlan interfaces passive and traffic going through routers.

[ShoIProute]

On 4/8/2023 at 3:28 PM, mbjelo said:

If interfaces are not passive we have direct neighborship between sw101 and 102 and we do not have traffic going through routers which is suboptimal. I did not know that requirement is not to change cost on sw202. In that case configuring  no passive vlan interfaces lead to not fulfillment requirement that all traffic from DC goes through sw201 sw101 link so we must make vlan interfaces passive and traffic going through routers.

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"

 

[bengini]

3 hours ago, ShoIProute said:

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 don't see any benefit to have virtual link between SW101-102 and neither is required on the topic, as it is not required to have SVI on vlan2000-1 on passive, the only command that does the trick is increasing Ospf cost on the interface SW102 toward DC. Don't understand why these commands are inserted. 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, smth like this 🙂

[ShoIProute]

5 hours ago, bengini said:

I don't see any benefit to have virtual link between SW101-102 and neither is required on the topic, as it is not required to have SVI on vlan2000-1 on passive, the only command that does the trick is increasing Ospf cost on the interface SW102 toward DC. Don't understand why these commands are inserted. 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, smth like this 🙂

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 🙂

 

[NTWMaster]

Does anyone have an updated WB they wouldn't mind sharing?  The WB I have doesn't mention anything about primary/secondary paths for question 1.4.  I can assume what I have isn't the latest, then.  Below is what I have.  

 

SECTION 1.4: OSPFv2 between HQ and DC (3 Points) For Complete and correct the OSPF configuration on the switches sw101, sw102, sw201 and sw202 according to these requirements: 
 1. Enable OSPFv2 on the redundant interconnections between the DC and HQ sites. Make sure that OSPF establishes adjacencies on these interconnections and exchange routing information between the DC and HQ sites  

2. Protect the authencity 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 

3. 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 300 msec, with the probes being sent every 100 msec. It is not allowed to modify OSPF timers to accomplish these requirements.

 

Thanks

 

 

 

 

[imhungry]

I'm getting only the same workbook too.

Has anyone the updated version? It would be appreciated very much if anyone could send this over.