Refer to the exhibit. An engineer implemented CoPP but did not see OSPF traffic going through it. Which configuration resolves the issue?
Refer to the exhibit. An engineer implemented CoPP but did not see OSPF traffic going through it. Which configuration resolves the issue?
To resolve the issue of OSPF traffic not going through the implemented CoPP, the correct configuration is to apply the service-policy to the control plane. The command 'control-plane service-policy input COPP' ensures that the control plane policies are applied correctly, allowing the OSPF traffic to be processed as intended. Without this configuration, the control plane policing policy wouldn't be active, which is why OSPF traffic was not being properly managed.
"A" and "D" are already applied, "B" is not required as traffic only needs to be captured and not limited, so "drop" is incorrect. "C" is correct, however it would be enough to set the appropriate source and destination IP pairs, as Aikat and others wrote.
https://community.cisco.com/t5/switching/ospf-dies-when-apply-acl/td-p/794381 This thread suggested to use "permit ospf any any" for simplicity, because of the multicast addressing.
this is mcast and in addition look carefully at R1 R2 R3 interface ip addresses only C can solve it from the listed answers and will catch bot R1<-R2 and R2<->R3
seems like ..... should be C because of the multicast.. I'm not very sure but I vote for C https://community.cisco.com/t5/routing/access-list-ospf/td-p/781095
Given answer is correct tested on GNS3
The configured policy map must be assigned in the control plan https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/control_plane_policing_copp.pdf
why? i see the COPP is already config? the first two line of the left picture...
definitely C
100 %%% is "C"
C is correct
Verified in GNS3: exact configuration without option C: R1#show policy-map control-plane Control Plane Service-policy input: COPP Class-map: OSPF (match-all) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: access-group name OSPF police: cir 8000 bps, bc 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit conformed 0000 bps, exceeded 0000 bps Class-map: class-default (match-any) 46 packets, 6244 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any
With option C: R1#show policy-map control-plane Control Plane Service-policy input: COPP Class-map: OSPF (match-all) 14 packets, 1316 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: access-group name OSPF We see packets now. The reason: There are no ospf control plane packets between routers R4 and R3 in the diagram. However when adding option C to the acl we now match control plane packets destined to our router.
if the acl wasnt right then why we have full ospf adj?....i mean we have hellos exhange full/bdr and right ospf process. if we hasnt full state then the right answer will be the c but i think the copp policy must be configured A
Remember than when the traffic do not match the policy it simply does not apply the policy and the traffic is treated normally. That is why we have full adjacencies between the routers.
pay attention to IP pairs: - 10.2.2.4 <> 10.2.2.1 - 10.1.1.1 <> 10.1.1.3 then check what's allowed in the ACL. Answer is C