Firewall filters have a "log" statement to understand the action taken on a packet. However, the output is slightly misleading or confusing in the case of the DHCP scenario.
Below is the configuration of a simple DHCP filter with a log action on a policer for DHCP packets.
test@MX960# show interfaces ae3
aggregated-ether-options {
minimum-links 4;
link-speed 1g;
lacp {
active;
periodic fast;
}
}
unit 0 {
demux-source inet;
family inet {
filter {
input test-dhcp; <<<<<<<<<<<<<<
}
address 10.23.103.2/24;
}
}
test@MX960> show configuration firewall filter test-dhcp
interface-specific;
term 10 {
from {
protocol udp;
destination-port [ 67 68 ];
}
then {
policer DHCP; <<<<<<<<<<<
log;
}
}
...
test@MX960# show firewall policer DHCP
filter-specific;
if-exceeding {
bandwidth-limit 64k;
burst-size-limit 2k;
}
then discard;
Firewall logs are shown below.
test@MX960> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
11:55:50 pfe A ae3.0 UDP 10.0.255.253 10.0.0.3 >>>> actually discarded by the policer
11:55:50 pfe R ae3.0 UDP 10.0.255.253 10.0.0.3
>>>> forwarded to the DHCP server
...
Also, at the PFE level, the same outputs are shown:
NPC4(MX960 vty)# show filter log
Filter Log:
16358041+09:23:51 filter 0 R ae3.0 udp 10.0.255.253:67 10.0.0.3:67 >>>> forwarded to the DHCP server
...
For the DHCP packets that are actually forwarded, the action shows R(reject) in the show firewall log
command output.
For the DHCP packets that are discarded by the policer, the action shows A(accept) in the show firewall log
command output.
The action seen in the firewall log as R/Reject is confusing but correct when interpreted from the PFE (Packet Forwarding Engine) level. In this case, DHCP packets are sent from the PFE (rejected at the PFE level) to the RE (punted to the Routing Engine or RE) for further processing by the jdhcp daemon. We can safely ignore the “R/Reject” in these logs as the packet is not completely rejected (rejected at the PFE level but processed at the RE level).