beautypg.com

Graceful restart scenarios, Ingress lsr specific processing – Brocade Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide (Supporting R05.6.00) User Manual

Page 387

background image

Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide

363

53-1003031-02

MPLS LDP-IGP synchronization

2

Graceful restart scenarios

Re-advertise label to its upstream neighbors

When the restarting router, acting as a transit LSR, can recover a FEC based on the Label Mapping
it receives from its GR helper, and the local forwarding state successfully, it re-advertises the same
label to all of its upstream neighbors.

As part of supporting GR, the Label Management component also makes sure that those labels
that are used to advertise to upstream neighbors before GR happens is not re-used for the new LSP
coming up while GR is in-progress. However, when the previously used label is released because
the LSP has gone down during GR, the label can be re-allocated for the new LSP.

Clearing mpls ldp neighbors

For clear mpls ldp neighbor, the configured reconnect and recovery timer values is sent to the peer
when both are configured with LDP graceful restart. Note that in this scenario, both routers are
acting in helper-only mode. Therefore, after the session comes back up, both routers exchange
their bindings and go through the recovery procedure. There is no traffic loss when the reconnect
and the recovery timers do not time out.

On a Brocade NetIron CES or Brocade NetIron CER or an Brocade MLX series or Brocade NetIron
XMR configured for helper-only mode, clearing mpls ldp neighbor results in immediate reconnect
timeout at the remote end. Therefore, in this scenario all bindings at the remote end associated
with the session are deleted due to reconnect time out. On the local node the recovery timer of 0
results in immediate clearing of the forwarding entries.

Ingress LSR specific processing

VPLS supports failover and must preserve its forwarding state when the LDP tunnel is used to carry
VPLS traffic until the GR has finished. LDP GR attempts to recover both the tunnel labels and the
VC labels. In the case where a VC label cannot be recovered, the corresponding PW is brought
down after GR has finished. In the case where the LDP tunnel cannot be recovered, all the PWs
using the LDP tunnel is brought down due to tunnel down event.

VPLS auto-discovery

BGP GR does not support the L2VPN address family type. Therefore, BGP-based auto-discovery
peer is not preserved across MP failover, even though BGP GR is enabled. As a result, LDP GR
preserves the VC label associated with a VPLS auto-discovery peer only when the peer is relearned
during the LDP GR recovery.

Other applications

On ingress LSR, LDP tunnels are preserved as part of LDP GR (helper-only mode excluded), this
does not benefit non-L2VPN applications (i.e. IPoMPLS, L3VPN, PBR, etc) that do not support MP
failover. There is no coordination between MPLS and those applications attempting to preserve its
CAM entries. Whether its corresponding CAM entries are deleted and re-added or updated is not
guaranteed by LDP GR support.