Troubleshooting shows EVPN reachability to a remote VTEP is healthy, yet application flows between two groups still fail. What GBP-related explanation should be considered?
Select an answer to reveal the explanation.
Short Explanation
The map says the road exists, but the badge reader still says no. Routing reachability and GBP permission are different gates—fix both when apps fail with healthy EVPN.
Full Explanation
When troubleshooting shows EVPN reachability to a remote VTEP is healthy yet application flows between two groups still fail, a GBP-related explanation that should be considered is that connectivity can fail due to GBP policy deny even when EVPN routing reachability exists. Operators must separate “can the fabric advertise and forward to the remote VTEP?” from “does group policy allow this session?” Healthy EVPN routes do not guarantee GBP cannot drop traffic between those endpoints. GBP is not evaluated only after the underlay TTL expires, so routing need not be broken first for policy to matter. Type-5 presence also does not automatically override all group deny policies; IP-prefix reachability and group denies address different control layers. Exam caveat: on describe troubleshooting items, keep EVPN reachability and GBP allow/deny as independent failure domains. Operational check: confirm EVPN Type-2 or Type-5 reachability and VTEP connectivity for the two civic endpoints, then inspect GBP group membership and inter-group policy for an explicit deny; temporarily allow in a change window only if policy intent permits, and document whether the application recovers to prove GBP was the blocker.