Tag :: OSPF

The General Router ID configuration provides the ability to configure a common Router ID for all routing protocols

The EOS implementation of OSPF uses an alternate Area Border Router (ABR) behavior. This is implemented as an optimization over the standard OSPF so that the packets would not be dropped when a router loses Active backbone connection which could otherwise be successfully forwarded. As per this new behavior, when an ABR loses active backbone connection, it is allowed to consider summary-lsa from non-backbone area during SPF calculation and the subsequent route installation process thus ensuring improved connectivity. The EOS implementation of OSPFv3 also inherits the same behavior.

This feature adds the support for OSPF multi-site domains described in RFC 4577(OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) ) and enables routes BGP VPN routes to retain their original route type if they are in the same OSPF domain. Two sites are considered to be in the same OSPF domain if it is intended that routes from one site to the other be considered intra-network routes.

An OSPF router can attract all traffic towards itself from within the OSPF network, by advertising a default route. Often it is desirable to advertise this default route conditionally, for instance, only when there is a connection to an upstream router or when a default route is learnt through other protocols like BGP. OSPF conditional default-originate provides the above functionality.

This feature introduces metric profiles to OSPF metric configurations. Metric profiles allow multiple metric configurations to be applied on the interface at the same time. When the interface speed drops below certain thresholds, the interface will automatically change the metric it uses based on the configurations in the metric profile.

This feature introduces the support for OSPF routes over GRE tunnels under default as well as non-default VRFs. The feature is disabled by default. 

This feature introduces the support for OSPF routes over GRE tunnels under default as well as non default VRFs. The

Configuring OSPF as PE-CE protocol enables us to distinguish between the “real external routes” and intra network routes between the sites that are stretched across VPN.  But the problem arises when VPN sites are in the same area and have a backdoor connection. With OSPF as PE-CE protocol redistribution, CE routers end up getting inter-area routes(assuming the VRFs on the PE devices that connect the CE sites, are configured with the same OSPF domain id) that actually belong to the same area and just happen to be multihomed to the backbone. 

Section 9.5 of RFC2328 “OSPF Version 2” states that the mask in Hello packets should be set to 0.0.0.0 when

An OSPF router can attract all traffic towards itself from within the OSPF network, by advertising a default route. Often it is desirable to set a route tag in this default route. This feature will add a CLI parameter to default-information originate that allows an external route tag to be set on the default route for both unconditional and conditional modes.

In an OSPFv2 Area Border Router (ABR), area filters may be used to prevent specific prefixes from being announced by an area as Type 3 Summary LSAs or routes to AS boundary routers as Type-4 ASBR summary LSAs.

The OSPFv2 Secure Hash Algorithms (SHA) Authentication support as defined in RFC 5709 supports the configuration of

OSPF supports all of RFC3630 and parts of RFC4203. When configured, OSPF generates the following information in

Configuring OSPF as PE-CE protocol enables us to distinguish between the “real external routes” and intra network routes between the sites that are stretched across VPN.  But the problem arises when VPN sites are in the same area and have a backdoor connection. With OSPFv3 as PE-CE protocol redistribution, CE routers end up getting inter-area routes (assuming the VRFs on the PE devices that connect the CE sites, are configured with the same OSPFv3 domain id) that actually belong to the same area and just happen to be multihomed to the backbone.

This feature may be used for redistributing OSPFv2 leaked and non leaked routes from one instance to another when

TStarting from EOS-4.17.0F, the capability of advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions, as described in the Extended Next Hop Encoding capability in RFC5549, is supported. This document describes the feature that allows the redistribution of such routes into OSPF.

This document describes the feature that allows the redistribution of VRF leaked BGP routes into OSPFv2 and OSPFv3.

VRF Route leaking can be used when routes from one VRF are required in another VRF (e.g. in case of shared services). If VrfLeak Agent is being used to leak routes, the leaked routes (in destination VRF) can be redistributed into IGPs.

When there are multiple VRFs on the device and there is a need to share routes between them, typically for shared

Segment Routing provides a mechanism to define end-to-end paths within a topology by encoding paths as sequences of sub-paths or instructions. These sub-paths or instructions are referred to as “segments”. OSPF Segment Routing (henceforth referred to as OSPF SR) provides means to advertise such segments through OSPF protocol.

This document describes the OSPFv2 feature that allows the setting of “Down” (DN) bit in type-5 and type-7 LSAs. The DN Bit is a loop prevention mechanism implemented when OSPF is used as CE - PE IGP protocol. Its usage in OSPF is explained by RFC4576. By default, OSPF honors the DN-bit in type-3, type-5 or type-7 LSAs in non-default VRFs.

Topology Independent Fast Reroute, or TI-LFA, uses OSPF SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence.