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!
1 Like
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
1 Like
Hi,
I spotted the same two errors as above and another, I think:
3.4.9.1 Requirement prefix 102.64.0.0/18
The first part of this task is to prevent the 102.64.0.0/18 network from being advertised from R1 to R2, R3, or R4.
However, the solution prevents 102.64.0.0/18 from being advertised by R2/R3/R4 to their neighbours, and not from R1 advertising it to R2/R3/R4, as per challenge. So the route-map needs to be applied to the ISP router, not R1.
I also have a question. I noticed that when you use an ACL to identify a specific prefix, you set the wildcard mask to something other than 0.0.0.0. e.g. For 3.4.11 BGP Transit AS, you use
R2(config-std-nacl)#deny 175.45.200.0 0.0.7.255
Whilst I used a wildcard mask of 0.0.0.0 because I was checking for an exact match. Where as 0.0.7.255 could result in other matches on a range of prefixes between 175.45.200.0 - 175.45.207.255, regardless of the mask. Which method would you say is better?
Great lab, btw, and please do more, especially an EIGRP one.
Thanks,
Sam
Hello Samir
You are correct, in order to achieve what is being asked for, the route map should be applied in an outbound direction on the ISP router, or in an inbound direction on the R1 router for the peering between the ISP and R1 routers. I will arrange with Rene to have this corrected. Thanks for pointing that out!
When filtering BGP routes using access lists (in combination with distribute lists as in this particular section of the lab), it is important to note that the network address and subnet mask combination must match the route that you are trying to filter. Remember, BGP advertised routes include the network address and the prefix or subnet mask. In this particular task, you are asked to filer out the 175.45.200.0/21 network being advertised by BGP. In order for this to work, it must match the network address and subnet mask combination. Otherwise, if you use 0.0.0.0, you wonāt match the specific prefix. Does that make sense?
I hope this has been helpful!
Laz
1 Like
Hi,
Iām stuck on this step: āConfigure AS23 to receive IPv6 routes over the IPv4 eBGP peerings with R1.ā Am I being asked to configure whatever is necessary for routers R2 and R3 to receive the IPv6 networks originated from the ISP and be able to route to them? I canāt work out how to do this.
Typically, I have practiced with networks using both IPv6 and IPv4 addressing. In such scenarios, the solution is to change the next-hop address to an IPv6 address using a route-map. Here, I donāt know what Iām supposed to do. The updates reach R3 and R4 fine, but with the wrong next-hop (itās the IPv4-mapped address ::FFFF:192.168.13.1).
I can think of a messy way to resolve this using static routes, but Iām sure thatās not what youāre after
Regards
Hello Raul
The idea is to prepare AS 23 to receive IPv6 routes via an IPv4 eBGP peering. You have already established IPv4 peering between R1 in AS1 and R2 and R3 in AS23. You are asked to configure that IPv4 peering in such a way that IPv6 routes can be exchanged over it. This is done using multi-protocol BGP (MP-BGP) and, specifically, by activating the IPv6 address family. This is shown in detail in the following lesson:
You can also see the solution to the specific task in the lab itself, in section 3.3.3.3:
The point here isnāt to be able to ping the destination necessarily but to have BGP share those IPv6 routes so that they appear in the BGP tables of R2 and R3.
I hope this has been helpful!
Laz
hi , the typo is still there. The mistake is in the task . it should read " Configure MED on R3 so that the path via R2 is preferred over the path via R3.
Ensure no other networks are influenced."
Hello Raul
Thanks for the heads up, I will let @ReneMolenaar know to make the appropriate modifications.
Laz
It has been fixed, thanks!