• Author : Jeff Hornsberger



Description LSPs formed by LDP normally follow IGP routing. The LDP speaker selects the downstream LSR for a particular prefix as the LDP peer that advertises it with the best IGP metric using the interface address that is the IGP next hop for the prefix. This process is described in section 2.7 of RFC 5036. However there are cases where it is either desirable to use a non-adjacent router as the next hop, or to use a different adjacent router as the LDP next hop than the IGP next hop. An example is tunneling LDP traffic over a mesh of...
Continue reading →

LDP End-of-LIB

Description LDP End-of-LIB is a signaling enhancement defined in RFC 5919 to allow an LDP speaker to notify a neighbor when it has completed advertising all labels from its Label Information Base (LIB). Although End-of-LIB is a standalone feature, it is useful primarily as an enhancement to other features. In the absence of End-of-LIB some LDP procedures use timer expiration as a heuristic to determine when all of a neighbor’s label bindings have been received. Use of a timer for this purpose is wasteful and potentially error-prone since the timer must be sufficiently large to accommodate known worst case scenarios....
Continue reading →

LDP Hello Redundancy

Description LDP Hello Redundancy uses the LDP Extended Discovery Mechanism to establish a redundant targeted Hello adjacency for each neighbor discovered through the Basic Discovery Mechanism. Hello Redundancy can save significant session reestablishment time when links flap after exchanging a large number of FEC label bindings. LDP Basic Discovery operates by sending Link Hello messages to the “all routers on this subnet” group multicast address. Receipt of such a Link Hello message establishes a Hello adjacency. Devices with Hello Redundancy enabled will begin sending Targeted Hello messages to the Transport Address found in the received Link Hello message. The Targeted...
Continue reading →

Per-port VLAN to VNI via OVSDB

This release adds support for mapping 802.1Q tags to VNIs on a per-port basis through OVSDB when using the Hardware Switch Controller Service on CVX. The OVSDB Hardware VTEP Schema specifies VLAN bindings separately for each port. This implies that these bindings may differ from one port to another. Previously this was not supported. An attempt to map different VLANs to the same VNI or the same VLAN to different VNIs on different interfaces through OVSDB would result in the conflicting mappings being ignored. The feature must be enabled through the CVX CLI and supported by the client switch hardware. In that...
Continue reading →


Get every new post on this blog delivered to your Inbox.

Join other followers: