Want to enable Feature EPFT with “routing-protocols-enable”. However ,it is throwing an error and ask to configure the following command: “non-subscriber-interfaces mac” which once enabled drops the traffic without any penalty.
EPFT for routing-protocols can be enabled with “non-subscriber-interfaces mac” command only which means bad actor identification will be done on mac basis .When a bad actor is identified based on mac there will be complete drop no penalty policing will be done for penalty policing to happen please change the config as “non-subscriber-interfaces”.
The complete drop is for traffic from bad actor. All other mac on the interface should be able to pass traffic via the interface.
My understanding of enabling ‘routing-protcols-enable’ for EPFT is that it prevents routing protocols (eg: BGP) from triggering any ‘bad actor’ condition; Is that correct?
Without enabling "routing-protocols-enable" command:
> EPFT functionality bypasses all routing protocols by default. This is done to explicitly avoid dropping of necessary control-plane packets like route updates. Control-plane is already protected via LPTS.
> By default EPFT is not enabled, thus BGP packets <updates> will not fall under penalty as per design. By default LPTS has configured rate for BGP packets to be policed if it goes over the limit.
The correct command to check the same is following:
show lpts pifib hardware police location <>
show lpts pifib dynamic-flows statistics location <>
show lpts pifib hardware entry location <> | be <SIP>
SIP > Source IP with which peering is done and who sent big updates to check the rate of traffic.
Once EPFT for routing protocols is enabled:
lpts punt excessive-flow-trap non-subscriber-interfaces mac^ routing-protocols-enable
> EPFT, if enabled for routing-protocols can cause issues with dropping the traffic from bad actor<which can be updates if sent at a very high rate, and are not expected>. Usually normal updates are never identified as bad actor.
* Bad actor is a term to state a user sending huge amount of “for-us” traffic
^ The reason for using mac keyword is to avoid the problem where if 1 user sends a bad flow, then other users sharing the same IFH will also get penalised.
To check if the protocol is configured under EPFT, following command can be used:
show lpts punt excessive-flow-trap
To enable it, we have to configure “routing-protocols-enable” under lpts punt excessive-flow-trap” and following logs are seen to confirm if it is enabled or not:
Command:Show lpts punt excessive-flow-trap trace
Sep 8 01:06:45.688 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_verify_enable_nonsubscribers, event: 0x3, batch size: 1, item #: 1 Sep 8 01:06:45.695 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_ nonsubscribers, event: 0x3 Sep 8 01:06:45.695 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_nonsubscribers, flow trap ENABLED Sep 8 01:06:45.695 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_config_apply_func: item 1 of 1 = last in batch Sep 8 01:06:45.695 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_spp_msg_send: Added 0 ifh to exclude list Sep 8 01:07:18.516 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_verify_enable_routing_protocols, event: 0x3 , batch size: 1, item #: 1 Sep 8 01:07:18.522 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_routing_protocols, event: 0x3 Sep 8 01:07:18.522 flowtrap/event 0/RSP0/CPU0 t1 Sending packet to spp classifier routing_protocol_enable=1 Sep 8 01:07:18.522 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_config_apply_func: item 1 of 1 = last in batch
lpts punt excessive-flow-trap
non-subscriber-interfaces >>> without mac keyword routing-protocols are not enabled.
Sep 8 01:08:29.890 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_verify_enable_nonsubscribers, event: 0x2, batch size: 1, item #: 1 Sep 8 01:08:29.897 flowtrap/error 0/RSP0/CPU0 t1 sub_copp_config_verify_func: backend_verify item nonsubscribers, 'infra_flowtrap' detected the 'warning' condition 'Code(22)' Sep 8 01:08:50.092 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_verify_enable_routing_protocols, event: 0x4, batch size: 1, item #: 1 Sep 8 01:08:50.098 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_routing_protocols, event: 0x4 Sep 8 01:08:50.098 flowtrap/event 0/RSP0/CPU0 t1 Sending packet to spp classifier routing_protocol_enable=0 Sep 8 01:08:50.098 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_config_apply_func: item 1 of 1 = last in batch Sep 8 01:08:50.098 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_spp_msg_send: Added 0 ifh to exclude list Sep 8 01:08:50.106 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_verify_enable_nonsubscribers, event: 0x2, batch size: 1, item #: 1 Sep 8 01:08:50.114 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_nonsubscribers, event: 0x2 Sep 8 01:08:50.114 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_apply_enable_nonsubscribers, flow trap ENABLED Sep 8 01:08:50.114 flowtrap/event 0/RSP0/CPU0 t1 sub_copp_config_apply_func: item 1 of 1 = last in batch
My understanding is also that it’s correct behaviour for the above knob to only be useable in conjunction with ‘non-subscriber-interfaces mac’ enabled.
The EPFT feature for routing protocols is supported only with non subscriber mac interfaces.
It only supports source based MAC filtering.
Once a bad actor is identified all the traffic with that particular source will be dropped for penalty-timeout which can be modified as follows:
lpts punt excessive-flow-trap
penalty-rate arp 10
penalty-rate icmp 0
penalty-rate igmp 50
penalty-rate ip 100
penalty-timeout ospf 0
penalty-timeout bgp 0
exclude interface <back_bone_interface> // Can exclude both physical and sub-interface
Want to confirm why the default parameters are set <seen by the output of command “show lpts punt exc info” >though EPFT is not configured?
The output of this command is just to let us know that once EPFT is enabled than following parameters will be set which can be changed by using commands. If we want to see whether EPFT is enabled or not. It can be confirmed via following command:
- Show lpts punt excessive-flow-trap trace | in Elephant
- Show lpts punt excessive-flow-trap trace | in routing_protocol_enable >> it should have value =1
>> The output will show Elephant trap enabled or disabled and it will also show various parameters for which it is enabled once configured.
... View more
Please add the following command if it's still not working: " snmp-server group grupo v3 auth read sisa write sisa notify sisa" The above command will enable write read and notification(traps or informs) for the specified users belonging to this group and thus if the " snmp-server host statetement is configured with teh same user, you will recieve the traps on the specified Server.
... View more
Hi Justin, If we would define bandwidth on tunnel interface it will manipulate routing decisions also and tunnel recursiuon issue could also occur where tunnel would see that the best way to reach teh destination is via tunnel itself. Beside taht the actual bandwidth used by the tunnel is based on the physical interface associated with it.
... View more
Resolution Summary:Checked the dcmaService.log and found the following recurring statements. com.cisco.nm.xms.xdi.pkgs.LibCommon.common.CommonUtility,getMinSupportedVersion,406,Descr = 12.2(50)SE [ Tue Oct 26 15:58:45 CDT 2010 ],DEBUG,[main],com.cisco.nm.xms.xdi.pkgs.LibCommon.common.CommonUtility,getMinSupportedVersion,405,suppSysId = .188.8.131.52.184.108.40.206.927 [ Tue Oct 26 15:58:45 CDT 2010 Checked that the device IOS was well above the version specified in the logs, so thought may be an issue with the device packages. Checked the mdf version was 1.25 which came as default when we install LMS 3.2, so upgraded the mdf version to 1.45. Still the issue didn't got solved, so upgraded the RME device packages and now the archive job was successful. Message was edited by: Dheeraj Gera
... View more