Well actually this command enables MPLS IGP sync however what I am seeking for is the holddown timer. As you know with MPLS IGP sync, IGP only comes up after LDP is up however for LDP to be up its need to know loopback routes from IGP. Normally this is solved with holddown timer "mpls ldp igp sync holddown" @ IOS
For XR logging synchrononus, this does not seems to be the case especially when I enable debug or logging console
Forgot to comment on that Sherif. Here is some detail that may explain.
LDP-IGP Sync: Is there any equivalent config in IOS-XR for IOS's
IGP Sync hold-down time ? The short answer is, No.
IOS IGP defers adj formation on an upcoming interface until LDP sync
status is achieved on the interface. To limit this adj holddown, an
"holddown" config is provided in IOS to limit/cap this [adj] holddown
period. IOS-XR implementation for LDP-IGP Sync is different from IOS as
IOS-XR IGPs do not tie-up their adj formation on a given interface to
intf LDP sync status. Instead, IGP still form their adj [as they will
form in the absence of this feature], but advertise max-metric for given
interface if LDP sync is not achieved yet. Due to this reason, there is
no "holddown" cfg required/implemented in IOS-XR IGP for LDP-IGP Sync
feature. Please note this will NOT cause any inter-op issues as LDP-IGP
sync is a local feature.
How MPLS LDP IGP Sync Works
Synchronization means that the LDP session is up across the link and the LDP label bindings have been learned. In that case, the interface can be used as outgoing interface in the RIB by the IGP.
When synchronization is not achieved – this means typically that the LDP session is down, there are 2 cases:
either the IGP makes the link the least favorable link or unusable
either the IGP is held down on that interface
2 triggers for LDP IGP Sync:
Link comes up:
If the LDP peer is reachable (an alternate route exists), then the IGP adjacency is held down on the link
If the LDP peer is not reachable (no alternate route exists), then the IGP adjacency is brought up on the link and advertises max-metric to reach the neighbor through that link
LDP session goes down:
The IGP advertises max-metric to reach the neighbor through that link
The link is made the least favorable link by OSPF by advertising it with a maximum link metric (65536 of hex 0xFFFF). This leads to having no routes/paths through this interface where LDP is broken, unless it is the only path available.
ISIS uses the same method, the link/IP prefix is advertised with link metric 16777214 (MAX LINK METRIC – 1) when metric-style wide is in use or 63 (MAX LINK METRIC) when metric-style narrow is in use, in the ISIS LSP.
Alternatively, the IGP session across the link can be held down purposely, as long as synchronization is not achieved. The reason for keeping the IGP adjacency down, instead of bringing it up and using the maximum link metric, is to minimize the number of additional SPFs and link advertisement flooding which must be performed by the IGP. This maximizes the probability that only one SPF is required to respond to the interface UP event and therefore isolates this mechanism from delays which may occur due to SPF holddown timers.
This is different in IOS-XR. In the case where the link comes up and the LDP peer is reachable, IOS-XR does bring up the IGP adjacency and uses advertise max-metric.
Another difference in IOS-XR is the following. IOS-XR has also uses the LDP IGP sync feature to make TE tunnel participate in routing or forwarding only when the LDP targeted session corresponding to the TE tunnel is converged. This is configurable under IGP (OSPF or ISIS) as "mpls ldp sync-igp-shortcuts".
The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application Engineered...
Internet security is important with the increasing attacks that are happening every day. Many internet and browsing security solutions exist, but some are not very easy to use or maybe the question is how can I enable them?
Cisco Software Manager Server
This document describes the programmatic interfaces, RESTful APIs, which are supported by Cisco Software Manager Server (CSM Server).
CSM Server supports a set of finite RESTful APIs. The fir...