Refer to the exhibit.
The service provider operations team was alerted that hub site traffic from BGP AS 65101 to AS 65201 uses a non-primary path via the R5-R6 link. IBGP peering between R1 and R2 is up, and no fiber failure has been reported on the R2-R3 link. The team determined that the traffic flow between 10.10.10.1 and 192.168.30.1 is not considering the R1-R2-R3-R4 path.
Which action resolves this issue?
To resolve the issue of the non-primary path being used for traffic flow between R1 and R5, it is necessary to adjust the local-preference attribute. Setting the local-preference to 50 with neighbor 10.10.10.5 on R1 will make the paths received from R5 less preferable than the paths received from R2, which have a default local-preference value of 100. This will ensure that the path via R1-R2-R3-R4 is preferred.
It makes sense to make the change from D on R2, not R1
I disagree, setting the local pref to 50 on R1 towards R5 will make the routes from it appear less preferable than the default local pref of 100 towards R2, making R2 the preferred path out
After looking more this actually seems correct, R2 isnt even advertising a path from R5 to R1 because its ibgp -> ibgp, so unless R2 thinks its path is the best, it will never advertise one to R1
D would be correct if it's on R2, not R1. A & B are incorrect because local pref is the 2nd highest priority in route selection so meddling with metric will do nothing. C is incorrect because lowering the local pref of neighbor 10.10.10.3 on R3 will also do nothing as it's already lower than 10.10.10.5.
C is incorrect because lowering the local pref of neighbor 10.10.10.3 on "R2" - sorry about that.