-- Exhibit --
user@R1> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.0.0/24 *[BGP/170] 00:00:47, localpref 100
AS path: 65001 I -
> to 192.168.100.1 via ge-1/1/5.435
200.200.1.0/24 *[BGP/170] 00:00:47, localpref 100
AS path: 65001 I -
> to 192.168.100.1 via ge-1/1/5.435
200.200.2.0/24 *[BGP/170] 00:00:47, localpref 100
AS path: 65001 I -
> to 192.168.100.1 via ge-1/1/5.435
200.200.3.0/24 *[BGP/170] 00:00:47, localpref 100
AS path: 65001 I -
> to 192.168.100.1 via ge-1/1/5.435
user@R2> show route 200.200/16
inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)
Restart Complete -
+ = Active Route, - = Last Active, * = Both
200.200.0.0/24 *[Static/5] 00:09:12
Reject -
200.200.1.0/24 *[Static/5] 00:09:12
Reject -
200.200.2.0/24 *[Static/5] 00:09:12
Reject -
200.200.3.0/24 *[Static/5] 00:09:12
Reject -
200.200.4.0/24 *[Static/5] 00:09:12
Reject -
user@R2> show configuration protocols bgp
export export-200;
group c5 {
neighbor 192.168.100.2 {
export export-200.200;
peer-as 65002;
}
}
user@R2> show configuration policy-options policy-statement export-200.200 term 1 { from { route-filter 200.200.0.0/22 longer;
}
then accept;
}
user@R2> show configuration policy-options policy-statement export-200 term 1 { from { route-filter 200.200.0.0/21 longer;
}
then accept;
}
-- Exhibit --
Click the Exhibit button.
R2 is exporting static routes to R1 using BGP. R1 is not receiving one of the five static routes that is configured on R2.
Referring to the exhibit, what should be changed under the BGP configuration to resolve this issue?
Click on the arrows to vote for the correct answer
A. B. C. D.B
Based on the provided output, R2 is exporting five static routes to R1 using BGP, but R1 is not receiving one of the routes. To resolve this issue, we need to identify the cause of the problem and make the necessary changes in the BGP configuration.
From the output of the command "show route 200.200/16" on R2, we can see that the static routes for 200.200.0.0/24, 200.200.1.0/24, 200.200.2.0/24, 200.200.3.0/24, and 200.200.4.0/24 are all rejected. This indicates that there is a policy in place that is preventing these routes from being advertised to R1 via BGP.
Looking at the BGP configuration on R2, we can see that there is an export policy applied to the neighbor 192.168.100.2, which is the peer address of R1. The export policy is called export-200.200 and is defined in the policy-options hierarchy. The policy statement in this export policy matches on routes that are longer than 200.200.0.0/21, which means that it should allow all routes in the range 200.200.0.0/16 to be exported to R1.
However, we can also see that there is a global export policy defined in the policy-options hierarchy, which is not being used by the BGP configuration. This policy statement matches on routes that are longer than 200.200.0.0/22, which is a smaller range than the one specified in the neighbor export policy.
To resolve the issue of R1 not receiving one of the static routes, we need to ensure that the global export policy is being used by the BGP configuration. Option A, deleting the global export policy, would be incorrect as this would remove the policy that is needed to export the missing static route.
Option B, deleting the neighbor export policy, would also be incorrect as this would remove the policy that is allowing the other four static routes to be exported to R1.
Option C, moving policy export-200 to the group level, would not resolve the issue as this policy is not related to the problem of R1 not receiving one of the static routes.
Therefore, the correct answer is option D, moving policy export-200.200 to the group level. This would ensure that the global export policy is being used by the BGP configuration and that all static routes in the range 200.200.0.0/16 are allowed to be exported to R1.