EVPN Type 3 Processor

The EVPN Type 3 Processor tracks the health of EVPN Type‑3 (Inclusive Multicast Ethernet Tag) routes across the fabric. Leaf switches use these routes to build their VXLAN flood lists for BUM traffic (broadcast, unknown unicast, multicast) within a VNI.

For each VXLAN virtual network deployed on leaf devices, the processor determines expected Type‑3 routes. Each leaf hosting a VNI advertises a route identified by its route distinguisher, route target, and VTEP address. Other leafs hosting the same VNI import these routes. The processor then compares expected routes with observed routes and categorizes each route as follows:

• Expected: The route is required and present, indicating a normal healthy state.
• Missing: The route is required but not observed on the device, possibly due to a missing peer VTEP in the leaf's flood list, blocking BUM traffic.
• Unexpected: The route is observed but is not required. While not problematic, it deviates from from modeled expectations.

The Processor: EVPN Type 3 Routes page includes Type 3 processor information about the EVPN routing table, missing routes, sustained missing routes, and total number of sustained anomalies. The following table describes the processor parameters:

Table 1: Processor: EVPN Type 3 Route Parameters

Parameter	Description
Monitored L2 VNIs	What L2 VNIs are to be monitored. Specify "*" to monitor all L2 VNIs, or list the desired VNIs, such as "1-3, 6, 8, 10-13". The number of L2 VNIs cannot exceed 10. This filter applies only in the "polling" collection type.
Collection type	*Any: The service starts by selecting the best match among the collector definitions for that service (default setting). Interval-based (CLI): Data is collected periodically by using CLI commands (not recommended). We recommend using gRPC/gNMI collection types which are faster and more scalable than polling CLI-based collectors. Interval-based (gNMI Periodic): Data is collected periodically through gNMI. Event-based (gNMI OnChange): Data is collected asynchronously through gNMI subscriptions, where updates are sent only when relevant events or value changes occur. Monitoring can be scoped to specific VNIs instead of the entire fabric to reduce collection overhead.
Service Interval	Determines how frequently the service collects data.
Missing Routes Check Interval	Interval, in seconds, at which missing EVPN routes are recomputed. The default is 2 minutes. Applies to every collection type except interval-based (CLI) and interval-based (gNMI periodic), for which missing routes are recomputed on every device telemetry round.

*Apstra automatically selects the optimal collection method when the collection type is set to "any" (default setting). This selection determines the Junos version and selects the most appropriate collection type.

The processor has two output stages:

• EVPN Table: provides a list of every type 5 route in the fabric, detailing the system ID, endpoint, next hop, route distinguisher (rd) and route target (rt).

  

• Number of missing routes: Provides details on the number of missing routes for each system and VNI, specifying how many expected routes are currently missing. This information helps you dentify leaf device VNIs with incomplete flood lists.