This topic is to discuss the following lesson:
Iām really loving this new addition to the courses with these labs. They truly help us bridge everything together and provide a better understanding of the concepts, which is crucial for our education and careers. The hands-on experience is indispensable. I can only hope you continue to develop more labs like this, focusing on BGP, MPLS, IGPs, DMVPNs, and other key technologies. These labs allow us to experiment and fully advance our knowledge. Keep up the great work!
Hello Sahakt
Your feedback is invaluable. Itās great to hear that these labs are so useful to you and the whole community. There are plans to create more such labs so that the skills you learn in the lessons can be applied in a hands-on and practical way.
Thanks again!
Laz
Hey all, Iām loving this lab! Have a quick question regarding 3.4.10 BGP Route Filtering. Looks like the task is to filter out all /22 and above but the output of R9 shows routes with both /22 and /23. My mask and wildcard differed from the solution and I filtered out any prefix with a mask of /22 or greater. I was just wondering if I misunderstood the ask. Thanks again for the lab!
Notice that all prefixes ranging from /22 to /32 have been removed from the BGP table. The task is complete.
R9#show ip bgp
BGP table version is 15, local router ID is 9.9.9.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 9.0.0.0 0.0.0.0 0 32768 i
*> 12.34.0.0/16 5.5.5.5 0 4567 23 1 999 ?
*> 23.45.0.0/16 5.5.5.5 0 4567 1 999 ?
*> 66.77.0.0/17 5.5.5.5 0 4567 1 999 i
*> 175.45.200.0/21 5.5.5.5 0 4567 1 999 ?
*> 176.0.0.0/4 5.5.5.5 0 4567 1 999 i
*> 192.168.23.0 5.5.5.5 0 4567 23 i
*> 195.225.0.0/19 5.5.5.5 0 4567 1 999 ?
*> 199.10.192.0/22 5.5.5.5 0 4567 1 999 ?
*> 210.45.128.0/23 5.5.5.5 0 4567 1 999 ? !<------shouldn't this be removed
*> 212.12.16.0/21 5.5.5.5 0 4567 1 999 ?
*> 216.80.192.0/22 5.5.5.5 0 4567 1 999 ?
*> 220.85.200.0/23 5.5.5.5 0 4567 1 999 ? !<------shouldn't this be removed
*> 221.25.0.0/19 5.5.5.5 0 4567 1 999 ?
Good morning Joshua
Thanks for pointing this out. Those two routes should indeed be removed. Iām not sure why they werenāt at that particular point during the preparation of this lab. I have to own this error , since I had put this lab together. As we prepare these labs we often go back and forth and sometimes the copying and pasting may contain a typo because it comes from a slightly different point in time. Those should be removed, and I will let Rene know to make the correction.
However, I would like to ask, beyond the output as it appears in the lab, do you find that you are getting incorrect results in your lab based on the suggested commands? If so let me know so I can go back and take a look to correct any errors that may be there.
In any case, Iām really glad that you find these labs useful!
I hope this has been helpful!
Laz
Morning Lazarus!
I have learned so much with this lab! The only incorrect result that Iāve noticed thus far is the mac and wildcard for this particular solution (3.4.10) and it could still be that I just misapplied the answer. I used deny ip 0.0.0.0 255.255.255.255 255.255.252.0 0.0.3.255
to catch and deny anything ge /22
and my output is this:
R9# show ip route bgp
!***OMITTED***
Gateway of last resort is not set
12.0.0.0/16 is subnetted, 1 subnets
B 12.34.0.0 [20/0] via 5.5.5.5, 1d17h
23.0.0.0/16 is subnetted, 1 subnets
B 23.45.0.0 [20/0] via 5.5.5.5, 1d17h
66.0.0.0/17 is subnetted, 1 subnets
B 66.77.0.0 [20/0] via 5.5.5.5, 1d17h
175.45.0.0/21 is subnetted, 1 subnets
B 175.45.200.0 [20/0] via 5.5.5.5, 1d17h
B 176.0.0.0/4 [20/0] via 5.5.5.5, 1d17h
B 195.225.0.0/19 [20/0] via 5.5.5.5, 1d17h
B 212.12.16.0/21 [20/0] via 5.5.5.5, 1d17h
B 221.25.0.0/19 [20/0] via 5.5.5.5, 1d17h
R9#show access-list 100
Extended IP access list 100
10 deny ip any 255.255.252.0 0.0.3.255 (29 matches)
20 permit ip any any (6 matches)
R9#
Thank you again so much for this and the other routing labs you guys have put together! I love working through these!
Hello Joshua
Ah, OK. First of all after taking a closer look at section 3.4.10, I see that there are two tasks. The first is to filter out any routes with a prefix of /18 , using prefix lists, and in the output, everything seems to be in order.
As for the second task, it was to filter out routes with prefixes ranging from /22 to /32 using extended access lists. The output is correct but the command is incorrect. It reads:
R9(config-ext-nacl)#deny ip 0.0.0.0 255.255.255.255 255.255.255.192 0.0.0.63
when it should read:
R9(config-ext-nacl)#deny ip 0.0.0.0 255.255.255.255 255.255.252.0 0.0.3.255
as you very correctly suggested. The output as it appears in the lab lesson is correct for filtering /22 to /32, but the command itself is incorrect. Iāll let Rene know to make the correction.
Based on your last post, your command as well as your output looks correct. Thanks for pointing this out!
I hope this has been helpful!
Laz
Afternoon Laz
Absolutely loving this lab as it pulls together all the bits and pieces of BGP but in manageable chunks. Can I just ask about two sections - 2.4.6 & 2.4.7?
In 2.4.6 the task is to āsee network 66.77.0.0/17 with an origin code similar to a network that is injected with redistributionā which I believe would then show up with a ā?ā in the sh ip bgp
denoting redistribution, but isnāt this network already redistributed into the network from the other routersā perspective? Isnāt the task aimed at showing the network being injected with the origin code āiā? So the task point should in fact read - "see network 66.77.0.0/17 with an origin code similar to a network that is not injected with redistribution (or words similar to this?).
For 2.4.7, I believed the task was to prefer a route via R3 not R2 (āConfigure MED on R3 so that the path via R3 is preferred over the path via R2ā) yet the solution reads as if you are making R2 the preferred route as it advertises the route via R3 (from R1ās perspective) with a greater MED value, making R3 the less desirable route. Prior to this step my lab had the preferred route via 192.168.12.2, so I in fact had to create the MED route map on R2 to increase the metric to satisfy the task, i.e. R3 is preferred over R2. From the output it already shows that your route via R3 (192.168.13.3) is the best route, so it is already preferred over R2.
Apologies if I have got these completely wrong! But still think it is a phenomenal lab - many thanks.
Hello Mihael
Glad that the lab is so helpful for you! Thanks for the feedback on these two sections.
The 2.4.6 task as described in that section should indeed be reworded as it is incorrect. Specifically, it should ask to change the origin code to be similar to a network that is injected using the network command. The solution as it is stated in 3.4.6 I believe is correct.
The 2.4.7 task also has a typo. Although the task asks to modify the MED so that the path via R3 is preferred, but in the solution (3.4.7) R2 is configured to be preferred. I am not sure if the task or the solution is incorrect, but based on your labbing, I tend to agree that the solution is incorrect. I will go over it in the coming days with Rene to make sure it is resolved.
Thanks so much for your feedback, and weāre thrilled that you find the lab so useful!
I hope this has been helpful!
Laz