DOO 1.4

[ShoIProute]

2 hours ago, jonny18 said:

Yes, was not thinking about this properly also. So all ospf speaking devices on HQ (sw101,102,r11,r12) should switch to area 1 with the exception of the uplinks to DC on sw101/102 eth0/2 interfaces which will be on area 0, then in the ospf process of sw101/102 area range 10.1.0.0 255.255.0.0 will summarize the HQ routes towards DC, tested this and seems connectivty is not lost from any of the branch sites towards 10.1.x.x

that's correct. but also recall on the same task that there is a requirement that the primary path for the traffic between HQ and DC must be the link between sw101 and sw201 and the link between sw102 and sw202 must become the primary path if the primary link fails.

this can be accomplished by advertising the summary route (10.1.0.0/16) on sw102 with a higher (worst) metric then sw101 forcing traffic from DC to HQ to pass thru the sw101/sw201 link. and then for path symmetry i guess u can increase the cost on the sw102's interface leading to sw202. This way traffic from HQ to DC will prefer to pass thru sw101/sw201 (primary) link from that direction. 

[Siscco]

1 : Switch HQ to Area 1 , Except Interlink ( Area 0 )

2 : Increase the metric in Sw102

3 : Increase Summary metric Sw102 

This would do i believe , However have you guys trace any IP from Host12 ??????

[ShoIProute]

1 hour ago, Siscco said:

1 : Switch HQ to Area 1 , Except Interlink ( Area 0 )

2 : Increase the metric in Sw102

3 : Increase Summary metric Sw102 

This would do i believe , However have you guys trace any IP from Host12 ??????

i still have yet to traceroute from the HQ side but in theory it should work. with sw102 having a higher cost to all destination networks in DC, all traffic coming from HQ to DC should pass thru sw101 (primary link)

i know i've done a trace from DC to HQ and i can confirm that the sw201/sw101 is used as the primary link. even if u trace directly from sw202 in the DC, it will pass thru sw201 to get to HQ destination networks

[Siscco]

11 minutes ago, ShoIProute said:

i still have yet to traceroute from the HQ side but in theory it should work. with sw102 having a higher cost to all destination networks in DC, all traffic coming from HQ to DC should pass thru sw101 (primary link)

i know i've done a trace from DC to HQ and i can confirm that the sw201/sw101 is used as the primary link. even if u trace directly from sw202 in the DC, it will pass thru sw201 to get to HQ destination networks

It does work as expected if you trace it from Host11 , R11 and R12 . However try a trace from Host12 . It prefers SW102 . Unless you fixes two Adjoined Areas in 101 and 102 ( Tunnel or VL ) 

[jonny18]

Was noticing this also,  increasing the  ospf cost on the sw102/sw202 link this works on traffic between DC->HQ it ill use sw101/sw201 link , however the HQ->DC wil still use the direct link. if the ospf routes on sw102 are checked they still point to  eth 0/2

and this is because , the HQ is now in area 1 so any route coming from the sw101/sw101 link towards sw102 is going from area 0 to area 1 (via the port channel between Sw101 and Sw102) so the routes will be O*IA which are less preferable that the O routes coming from the direct link regardless the cost that is set

As previously posted an alternative is to setup a virtual-link between sw101 and sw102, this will make the traffic go allways via sw101/201 link as requested, and doesnt go against any statement on the question.

Edited December 20, 2022 by jonny18

[ShoIProute]

12 hours ago, jonny18 said:

this is because , the HQ is now in area 1 so any route coming from the sw101/sw101 link towards sw102 is going from area 0 to area 1 (via the port channel between Sw101 and Sw102) so the routes will be O*IA which are less preferable that the O routes coming from the direct link regardless the cost that is set

As previously posted an alternative is to setup a virtual-link between sw101 and sw102, this will make the traffic go allways via sw101/201 link as requested, and doesnt go against any statement on the question.

 

hey guys, I still havent had a chance to lab this up yet but i'm just thinking for a minute here. did u guys make ur vlan2000 and vlan2001 interfaces passive so that sw101 and sw102 dont form a neighborship with each other between the port-channel? i saw this in some ppls solutions. If u did, im just wondering why? although its best practice in the real world, i don't think it was a requirement on the lab, unless i missed it. What im thinking in theory is that if sw102 receives a better cost route to any DC destination network (in the 10.2.0.0/16 range) from its neighbor, it would prefer that route over its directly connected link with sw202 if another route was available. but if it only had one route to the DC destination subnets, then it will only know how to get there thru it's directly connected link with sw202. but if that link has a higher cost then say, a route advertised by sw101, i'm thinking it would prefer passing thru there then its link with sw202. Also, how high are u increasing the cost on sw102's interface that leads to sw202?

Again, i havent had the chance to test this out yet, i'm just walking thru it in my head and thinking in terms of theory. im out of town for a few days but once i get back i will lab it up

Let me know if ur allowing sw101 and sw102 to form an ospf adjacency thru their vlan2000 and vl2001 interface

Hey jonny18. ur totally spot on. I had to think about that last part that u said once again and remembered that intra-area routes will always be prefferred over inter-area routes.  that was a nice "gotcha". What a bummer. i was hoping there would be a more "eloquent" solution other than creating a tunnel or VL because im not sure if thats allowed, but i dont think it goes against any general requirements. i'll be labbing this up once i get back and playing around with it some more to see if theres any alternatives but it doesnt look like it at this point.

Edited December 20, 2022 by ShoIProute

[jonny18]

Same, initially the purpose of the virtual-link here eluded me, but i guess in this case is there to transform the inter-area routes into intra-area routes so the ospf cost can work in both cases.

Edited December 21, 2022 by jonny18

[ShoIProute]

On 12/20/2022 at 1:17 AM, Siscco said:

It does work as expected if you trace it from Host11 , R11 and R12 . However try a trace from Host12 . It prefers SW102 . Unless you fixes two Adjoined Areas in 101 and 102 ( Tunnel or VL ) 

Thanks Siscco. i finally had a chance to lab this up and u guys are definitely correct about that. Either a VL or rfc5185 (multi-area adjacency in area 0 on the vl2000-2001 interfaces but they have to be changed to point-to-point first) would do the trick. i would probably stay away from tunnelling as much as possible on the exam eventho there was no restriction specifically not to use it. i would just avoid tunneling unless they specifically ask u to.
 

[Siscco]

31 minutes ago, ShoIProute said:

Thanks Siscco. i finally had a chance to lab this up and u guys are definitely correct about that. Either a VL or rfc5185 (multi-area adjacency in area 0 on the vl2000-2001 interfaces but they have to be changed to point-to-point first) would do the trick. i would probably stay away from tunnelling as much as possible on the exam eventho there was no restriction specifically not to use it. i would just avoid tunneling unless they specifically ask u to.
 

So do i ,, no more tunnelling 🙂

[johnnyboy]

On 12/23/2022 at 11:33 PM, ShoIProute said:

Thanks Siscco. i finally had a chance to lab this up and u guys are definitely correct about that. Either a VL or rfc5185 (multi-area adjacency in area 0 on the vl2000-2001 interfaces but they have to be changed to point-to-point first) would do the trick. i would probably stay away from tunnelling as much as possible on the exam eventho there was no restriction specifically not to use it. i would just avoid tunneling unless they specifically ask u to.
 

So we think a VL is required for this task?

[ShoIProute]

58 minutes ago, johnnyboy said:

So we think a VL is required for this task?

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?

[johnnyboy]

9 hours ago, ShoIProute said:

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?

Yeah I get what you're saying.  I guess it just depends on how the automation tests the exam. 

Is the automated grading going to shut down the physical interfaces 0/0-1 and see if the track objects go down? If so then the vlan adjacencies will still carry that traffic and the grading may cause a fail on the task when those objects stay UP.

[ShoIProute]

2 hours ago, johnnyboy said:

Yeah I get what you're saying.  I guess it just depends on how the automation tests the exam. 

Is the automated grading going to shut down the physical interfaces 0/0-1 and see if the track objects go down? If so then the vlan adjacencies will still carry that traffic and the grading may cause a fail on the task when those objects stay UP.

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:

1.    A route to r11's loopback from r11 itself on its g0/0 interface advertised by r11 itself
2.    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?

Edited February 12, 2023 by ShoIProute

[nadeem]

If the links between SW101/SW201 and SW102/SW202 was in area 0 (you can say if the link between HQ and DC was in area 0) we will need make SW102 cost is worst including the area range command plus WE NEED TO USE virtual link because without virtual link as mentioned before SW102 will prefer O that coming from directly connected SW202 routes over O IA routes that will come from SW101, however if the links between SW101/SW201 and SW102/SW202 was in area 1 (link between HQ and DC was in area 1)  we just need make SW102 cost is worst including the area range without the need of virtual link because all routes now are  O IA.

what you guys think ?

Edited February 23, 2023 by nadeem

[LazerFokus]

3 hours ago, nadeem said:

If the link between SW101/SW102 and SW201/202 was in area 0 we will need make SW102 cost is worst including the area range command plus virtual link because without virtual link as mentioned before SW102 will prefer O routes over O IA routes that will come from SW101, however if the link between SW101/SW102 and SW201/202 was in area 1  we will need make SW102 cost is worst including the area range without virtual link because all routes now are  O IA.

what you guys think ?

You would still need virtual link I think, because the connection between 102/202 is still in area 0 so traffic leaving 102 will prefer this path out. 

To test this out lab it up and traceroute from host 11 and 12, if you find a good method we haven't thought of here please let us know.

[nadeem]

1 hour ago, LazerFokus said:

You would still need virtual link I think, because the connection between 102/202 is still in area 0 so traffic leaving 102 will prefer this path out. 

To test this out lab it up and traceroute from host 11 and 12, if you find a good method we haven't thought of here please let us know.

well I mentioned that we don't need virtual link in case the connections between  switches 101/201 & switches 102/202 was in area 1 so in this case switches SW201/SW202 will become the ABRs.

Edited February 21, 2023 by nadeem

[LazerFokus]

1 hour ago, nadeem said:

well I mentioned that we don't need virtual link in case the connections between  switches 101/201 & switches 102/202 was in area 1 so in this case switches SW201/SW202 will become the ABRs.

Im not following you, that doesn't line up with your earlier post

[nadeem]

On 2/21/2023 at 8:15 PM, LazerFokus said:

Im not following you, that doesn't line up with your earlier post

I modified my original post to be more clear , hope you will get what I mean now.

[LazerFokus]

12 minutes ago, nadeem said:

I modified my original post to be more clear , hope you will get what I mean now.

Ah - I get what you mean now. I have not taken the lab to see the specific writing of the task. Does it limit our ability to change the area at all? That would be my only concern.

[Ademix]

Hello guys. The path from HQ to DC should also choose main path via sw101-201? If you trace from R11 to R21 for example. In my case it doe ECMP via 2 paths. 

R11#tracer 10.2.255.21 source Lo0 
Type escape sequence to abort.
Tracing the route to 10.2.255.21
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.10.2 0 msec
    10.1.13.2 0 msec
    10.1.10.2 1 msec
  2 10.2.242.1 0 msec
    10.2.241.1 1 msec
    10.2.242.1 0 msec
  3 10.2.10.1 1 msec
    10.2.13.1 0 msec *

Edited February 23, 2023 by Ademix

[nadeem]

20 hours ago, LazerFokus said:

Ah - I get what you mean now. I have not taken the lab to see the specific writing of the task. Does it limit our ability to change the area at all? That would be my only concern.

as far I know that they mentioned DC in area 0 and HQ in area 1 but link between them they did not mention anything about it.

[mbjelo]

Hello all,

Configuration with VL make all traffic goes through sw101-sw201 link but we have different traceroute from h11and h12 again(picture below).

I think it is because of virtual link goes through routers r11 and r12.

 

 

Edited April 5, 2023 by mbjelo

[ShoIProute]

15 hours ago, mbjelo said:

Hello all,

Configuration with VL make all traffic goes through sw101-sw201 link but we have different traceroute from h11and h12 again(picture below).

I think it is because of virtual link goes through routers r11 and r12.

 

 

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.

Edited April 5, 2023 by ShoIProute
clarification

[mbjelo]

I think vlan interfaces should not be passive, you could make it active and enable adjacency between sw102 and 102 through it. In that case trace route from hosts would be ok but int that case you have two routes to 10.1.0.0 on sw 202, with same metric, one through sw201 and second through sw102 which is in collision with requirements. But, it could be solved by adding cost 100 on gi1/2 link on sw202.

[ShoIProute]

1 hour ago, mbjelo said:

I think vlan interfaces should not be passive, you could make it active and enable adjacency between sw102 and 102 through it. In that case trace route from hosts would be ok but int that case you have two routes to 10.1.0.0 on sw 202, with same metric, one through sw201 and second through sw102 which is in collision with requirements. But, it could be solved by adding cost 100 on gi1/2 link on 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.