Operation

If a FEC is received over a session of a specified community, it is assumed to be associated with that community and is only broadcast to peers using sessions of that community. Likewise, a FEC received over a session with no community is only broadcast over other sessions with no community.

If a FEC is received over a session that does not have an assigned community, the FEC is treated as if it was received from a session with a differing assigned community. In other words, any particular FEC must only be received from sessions with a single, assigned community or no community. In any other case (from sessions with differing communities, or from a combination of sessions with a community and sessions without a community), the FEC is considered to have a community mismatch.

The following procedures apply.

1. The system remembers the first community (including no community) of the session that a FEC is received on.

2. If the same FEC is subsequently received over a session with a differing community, the FEC is marked as mismatched and the system raises a trap indicating community mismatch.

   Note:

   Subsequent traps because of a mismatch for a FEC arriving over a session of the same community (or no community) are squelched for a period of 60 seconds after the first trap. The trap indicates the session and the community of the session, but does not need to indicate the FEC itself.

3. After a FEC has been marked as mismatched, the FEC is no longer advertised over sessions (or resolved to sessions) that differ either from the original community or in whether a community has been assigned. This can result in asymmetrical leaking of traffic between communities in specific cases, as illustrated by the following scenario. It is therefore recommended that FEC mismatches be resolved as soon as possible after they occur.

   Consider a triangle topology of Nodes A-B-C with iLDP sessions between them, using community=RED. At bootstrap, all the adv-local-lsrId FECs are exchanged, and the FECs are activated correctly as per routing. On each node, for each FEC there is a [local push] and a [local swap] as there is more than one peer advertising such a FEC. At this point all FECs are marked as being RED.

   • Focusing on Node C, consider:

     • Node A-owned RED FEC=X/32

     • Node B-owned RED FEC=Y/32

   • On Node C, the community of the session to node B is changed to BLUE. The consequence of this on Node C follows:

     • The [swap] operation for the remote Node A RED FEC=X/32 is de-programmed, as the Node B peer now BLUE, and therefore are not receiving Node A FEC=X/32 from B. Only the push is left programmed.

     • The [swap] operation for the remote Node B RED FEC=Y/32, is still programmed, even though this RED FEC is in mismatch, as it is received from both the BLUE peer Node B and the RED peer Node C.

4. When a session community changes, the session is flapped and the FEC community audited. If the original session is flapped, the FEC community changes as well. The following scenarios illustrate the operation of FEC community auditing.

   • Scenario A

     • The FEC comes in on blue session A. The FEC is marked blue.

     • The FEC comes in on red session B. The FEC is marked ‟mismatched” and stays blue.

     • Session B is changed to green. Session B is bounced. The FEC community is audited, stays blue, and stays mismatched.

   • Scenario B

     • The FEC comes in on blue session A. The FEC is marked blue.

     • The FEC comes in on red session B. The FEC is marked ‟mismatched” and stays blue.

     • Session A is changed to red. The FEC community audit occurs. The ‟mismatch” indication is cleared and the FEC is marked as red. The FEC remains red when session A comes back up.

   • Scenario C

     • The FEC comes in on blue session A. The FEC is marked blue.

     • The FEC comes in on red session B. The FEC is marked

       ‟mismatched” and stays blue.

     • Session A goes down. The FEC community audit occurs. The FEC is marked as red and the ‟mismatch” indication is cleared. The FEC is advertised over red session B.

     • Session A subsequently comes back up and it is still blue. The FEC remains red but is marked ‟mismatched”. The FEC is no longer advertised over blue session A.

The community mismatch state for a prefix FEC is visible through the show>router>ldp>bindings>prefixes command output, while the community mismatch state is visible via a MIB flag (in the vRtrLdpNgAddrFecFlags object).

The fact that a FEC is marked ‟mismatched” has no bearing on its accounting with respect to the limit of the number of FECs that may be received over a session.

The ability of a policy to reject a FEC is independent of the FEC mismatch. A policy prevents the system from using the label for resolution, but if the corresponding session is sending community-mismatched FECs, there is a problem and it should be flagged. For example, the policy and community mismatch checks are independent, and a FEC should still be marked with a community mismatch, if needed, per the rules above