Tag :: OSPF

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

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.

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

In an OSPFv2 Area Border Router (ABR), area filters may be used to prevent specific prefixes from being announced by an

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

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.

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

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.

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.