[MX] Syslog message - DDOS_PROTOCOL_VIOLATION_SET: Protocol resolve:ucast-v4 for the MS-MPC (services card)

Summary:

This article gives the reason for distributed denial of service (DDoS) violation logs with the message “Protocol resolve:ucast-v4” were reported for MS-MPC (services card) to be reported on MX Series routers, and indicates what must be done to resolve the violation.

Note: This article is relevant where the syslog server is directly connected.

Symptoms:

The following message logs were reported on a periodic basis for the FPC (MS-MPC service card).

"jddosd[2264]: DDOS_PROTOCOL_VIOLATION_SET: Protocol resolve:ucast-v4 is violated at fpc 5 for 7 times, started at 2017-12-07 17:15:12 GMT"

Note: FPC 5 in this case is MS-MPC (services card).

The "resolve:ucast-v4" component, which is seen in the logs, indicates requests that are internally generated by the FPC CPU and sent to the Routing Engine (RE) so that the RE can send an Address Resolution Protocol (ARP) request out.

resolve: The following packet types are available for unclassified resolve packets (indicated in the log message above), which are sent to the host due to a traffic request resolve action:

mcast-v4—Unclassified IPv4 multicast resolve packets
mcast-v6—Unclassified IPv6 multicast resolve packets
ucast-v4—Unclassified IPv4 unicast resolve packets <<<<<<<<<<<<<<<<<<
ucast-v6—Unclassified IPv6 unicast resolve packets
other—All other unclassified resolve packets

You can enable flow detection as per the explanation in KB29408 - [MX/T] Configuring ddos-protection flow-detection to log interface and source address information to try and check the source hosts for which the violation occurred.

Cause:

Because these logs are related to the MS-MPC card, let us have a look at the configuration related to this card. From the configuration of the router, you see that system logging is enabled at the individual service set and the syslog server IP address is as per the configuration shown below:

service-set sfw-rim {
        syslog {
            host 172.16.1.2 { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
                services any;
                log-prefix JUNIPER-CGNAT;
                class {
                    session-logs;
                }
                source-address 172.16.1.1;
            }
        }

From the above configuration, you see that the syslog messages will be sent to the syslog server at 172.16.1.2 with the source address 172.16.1.1.

In this case, the syslog server's IP address is supposed to be resolved directly via irb.40.

irb { 
unit 40 {
            description "NAT logging";
            family inet {
                address 172.16.1.1/27;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
            }
        }

However when you execute show arp, there is no entry for that IP address, which is why the Routing Engine is not able to resolve the IP address:

root@MX-re0> show arp no-resolve | match 172.16.1.2

As you see, there is no arp for the syslog server.

Solution:

To resolve this issue, ensure that the syslog server is reachable so that its IP address can be resolved via the directly connected interface (in this case, irb.40).

Knowledge Base