Why does an SA filtering policy fail to take effect on the MSDP peer originating SA messages


The reason why the configuration of the peer peer-address sa-policy export [ acl advanced-acl-number ] command cannot take effect to filter the SA messages to be sent is:

In the MSDP view, the import-source [ acl acl-number ] command creates a policy to filter local source information sent to other peers, whereas the peer peer-address sa-policy { export | import } [ acl advanced-acl-number ] configures a policy to filter SA messages to be forwarded.

Therefore, the peer peer-address sa-policy export [ acl advanced-acl-number ] command cannot be used to filter locally originated SA messages. To configure an SA filtering on the RP where SA messages are originated, use the import-source [ acl acl-number ] command.

Other related questions:
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.

Does the traffic-policy or traffic-filter command first take effect
The traffic-filter command is supported from V200R002C00. When the traffic-policy and traffic-filter commands are simultaneously executed, the traffic-filter command takes effect first.

Problem and solution when an OSPF route filtering policy does not take effect
The reason that an OSPF route filtering policy does not take effect is as follows: For example: User ---------- MA5200F ---------- Firewall---------- NE80 ---------- Internet Open Shortest Path First (OSPF) is run on three devices, and the firewall acts as the NAT device. The NE80E cannot learn routes to private network segments. Firewall configurations are as follows: acl number 2999 rule 5 deny source /*Filtered private network segments*/ rule 10 deny source /*Filtered private network segments*/ rule 15 permit ospf 1 filter-policy export 2999 area network The routing table of the NE80 still has routes to private network segments. [JSNJ-MB-CMNET-RT01-HJL_NE80]display ip routing-table Destination/Mask Protocol Pre Cost Nexthop Interface O_ASE 50 1 Ethernet5/0/13 STATIC 40 0 GigabitEthernet1/0/ The route policy in the OSPF view of the firewall that uses the VRP3.30 platform takes effect only for local routes, not the LSA transmitted by the firewall to the NE80. In conclusion, because OSPF is a dynamic routing protocol based on link status and routing information is expressed through link status, OSPF cannot filter advertised or received LSAs. The filter-policy import command filters the routes calculated by OSPF. Only routes that match the filtering conditions are added to the routing table. The filter-policy export command enables a device to filter routes advertised by the device. Only routes that match the filtering conditions can be advertised.

Why does the state of the MSDP peer keep down though the MSDP peer relationship is set up
You can run the peer peer-address connect-interface interface-type interface-number command on two ends to set up an MSDP peer relationship. The address of the interface specified by interface-type interface-number in the locally configured peer connect-interface command must be consistent with peer-address specified in the peer connect-interface command run on the remote end.

Why does IPSG fail to take effect
The possible causes are as follows: --Invalid binding entries A static binding table is created using the user-bind static command. A dynamic binding table is generated only after the DHCP snooping function is enabled. --IPSG not enabled on the specified interface or VLAN After a binding table is generated, the IPSG function must be enabled in the interface or VLAN view using the ip source check user-bind enable command. IPSG takes effect only on the interface or VLAN where it is enabled, and IPSG check is not performed on the interfaces or VALNs without IPSG enabled. Therefore, if IPSG does not take effect on an interface or in a VLAN, the IPSG function may not be enabled on this interface or in this VLAN. --Insufficient hardware ACL resources The hardware ACL resources are shared by IPSG and other services. If the ACL resources are insufficient, IPSG cannot take effect. For example, you can run the display dhcp static user-bind all verbose command to view the IPSG status corresponding to static binding entries. If the value of IPSG Status is ineffective, IPSG of this entry does not take effect. The possible reason is that hardware ACL resources are insufficient. --Conflict between IPSG and QoS traffic policy This situation may only occur in V1R6C05. When a QoS traffic policy conflicts with IPSG, the traffic behavior in the QoS traffic policy takes effect.

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