Why do egress policies configured on the RR not take effect

15

The route reflection attribute of the reflector is the route attribute determined by the ingress policy and is not affected by either the egress policy or the peer { group-name | ipv4-address | ipv6-address } next-hop-local command.

Other related questions:
Why does the egress policy configured on an RR not take effect on S series switches
Q: Why does the egress policy configured on an RR not take effect? A: The route reflection attribute of the reflector is the route attribute determined by the ingress policy and is not affected by either the egress policy or the peer { group-name | ipv4-address | ipv6-address } next-hop-local command.

Why do some routing policies not take effect for a routing protocol on S series switches
When a routing policy contains the routing attribute modification action, the routing policy does not take effect because the routes advertised by the routing protocol cannot carry the attribute. For example, a routing policy is configured to modify the next-hop attribute of OSPF external routes, the routing policy does not take effect because DD packets used to advertise routes do not carry the next-hop attribute. Some routing policies only take effect for certain protocols. For example, the policy where community attributes are matched can only be applied to BGP. In addition, the BGP protocol runs based on point-to-point neighbor relationships; therefore, some policies can be used only on a peer device.

Why a traffic policy does not take effect on an AR
Pay attention to the following points when configuring a traffic policy so that the traffic policy can take effect: - In a traffic behavior, when the permit action is configured with other actions, the device performs these actions one by one. The deny action cannot be used with other actions (except traffic statistics and traffic mirroring); even if they are configured together, only the deny action takes effect. - When packets are filtered based on an ACL rule, if the rule is configured to permit, the action taken on the packets is decided by the deny or permit action configured in the traffic behavior. If the rule is configured to deny, packets are discarded no matter whether the deny or permit action is configured in the traffic behavior. - A traffic policy that contains the following traffic behaviors can be applied only in the outbound direction of a WAN interface: traffic shaping, adaptive traffic shaping, congestion management, and congestion avoidance. - After fragmentation is configured on an AR, if the rule of the traffic classifier contains the non-first-fragment field, the rate limiting or statistics collection function cannot be configured for the fragmented packets sent to the AR. - If a traffic behavior is bound to an ACL that has no rule configured, the traffic policy referencing the ACL does not take effect.

Why do ACLs sometimes not take effect
The device delivers access control lists (ACLs) to MAC-based users only after the IP addresses are learned.

Why do configuration commands not take effect on CE series switches
After configuring commands in two-stage mode on CE series switches, you need to run the commit command to make the configurations take effect. In the two-stage mode, the system configuration process is divided into two stages: Stage 1: Enter a configuration command and edit the configuration. Stage 2: Run the commit command to submit the configuration so that the new configuration takes effect in the current system. In V100R003 and later versions, if a user modifies a configuration in two-stage mode but does not submit the configuration, the system prompt changes from ~ to *, reminding the user that the configuration has not been submitted. The system prompt will change back to ~ after the user runs the commit command. Uncommitted configurations will not be saved in the configuration file.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top