Configuring OMP

Configure OMP Graceful Restart

OMP graceful restart allows OMP peers to continue operating if one of the peers becomes unavailable for some reason. If a vSmart controller becomes unavailable, its peer vEdge router continues to forward traffic, using the last-known good routing information received from the vSmart controller. Similarly, if a vEdge router becomes unavailable, its peer vSmart controller continues to use the last-known good routing information that it received from that vEdge router.

OMP graceful restart is enabled by default on vSmart controllers and vEdge routers. The default graceful restart time is 43,200 seconds (12 hours).

When OMP graceful restart is enabled, a vEdge router and a vSmart controller (that is, two OMP peers) cache the OMP information that they learn from their peer. This information includes OMP routes, TLOC routes, service routes, IPsec SA parameters, and centralized data policies. When one of the OMP peers is no longer available, the other peer uses the cached information to continue operating in the network. So, for example, when a vEdge router no longer detects the presence of the OMP connection to a vSmart controller, the router continues forwarding data traffic using the cached OMP information. The router also periodically checks whether the vSmart controller has again become available. When it does come back up and the vEdge router re-establishes a connection to it, the router flushes its local cache and considers only the new OMP information from the vSmart controller to be valid and reliable. This same scenario occurs when a vSmart controller no longer detects the presence of a vEdge router.

OMP graceful restart has a timer that tells the OMP peer how long to retain the cached advertised routes. When this timer expires, the cached routes are considered to be no longer valid, and the OMP peer flushes them from its route table. The default timer is 43,200 seconds (12 hours), and the timer range is 1 through 604,800 seconds (7 days). To modify the default timer value:

Viptela(config-omp)# timers graceful-restart-timer seconds

The graceful restart timer is set up independently on each OMP peer; that is, it is set up separately on each vEdge router and vSmart controller. To illustrate what this means, let's consider a vSmart controller that uses a graceful restart time of 300 seconds, or 5 minutes, and a vEdge router that is configured with a timer of 600 seconds (10 minutes). Here, the vSmart controller retains the OMP routes learned from that router for 10 minutes—the graceful restart timer value that is configured on the router and that the router has sent to the vSmart controller during the setup of the OMP session. The vEdge router retains the routes it learns from the vSmart controller for 5 minutes, which is the default graceful restart time value that is used on the vSmart controller and that the controller sent to the router, also during the setup of the OMP session.

While a vSmart controller is down and a vEdge router is using cached OMP information, if you reboot the vEdge router, it loses its cached information and hence will not be able to forward data traffic until it is able to establish a control plane connection to the vSmart controller.

To disable OMP graceful restart:

Viptela(config-omp)# no omp graceful-restart

Advertise Routes to OMP

By default, a vEdge router advertises connected, static routes, and OSPF inter-area and intra-area routes to OMP, and hence to the vSmart controller responsible for the vEdge router's domain. The router does not advertise BGP or OSPF external routes to OMP.

To have the vEdge router advertise these routes to OMP, and hence to the vSmart controller responsible for the vEdge router's domain, use the advertise command:

To configure the routes that the vEdge router advertises to OMP for all VPNs configured on the router:

vEdge(config-omp)# advertise (bgp | connected | ospf type | static)

To configure the routes that the vEdge router advertises to OMP for a specific VPN on the router:

vEdge(config-vpn-omp)# advertise (aggregate prefix [aggregate-only] | bgp | connected | network prefix | ospf type | static)

For OSPF, the route type can be external.

The bgp, connected, ospf, and static options advertise all learned or configured routes of that type to OMP. To advertise a specific route instead of advertising all routes for a protocol, use the network option, specific the prefix of the route to advertise.

For individual VPNs, you can aggregate routes from the specified prefix before advertising them into OMP. By default, the aggregated prefixes and all individual prefixes are advertised. To advertise only the aggregated prefix, include the aggregate-only option.

Route advertisements that you set with the omp advertise command apply to all VPNs configured on the router. Route advertisements that you set with the vpn omp advertise command apply only to the specific VPN. If you configure route advertisements with both commands, they are both applied.

By default, when BGP advertises routes into OMP, BGP advertises each prefix's metric. BGP can also advertise the prefix's AS path:

vEdge(config)# vpn vpn-id router bgp
vEdge(config-bgp)# propagate-aspath

When you configure BGP to propagate AS path information, the router sends AS path information to routers that are behind the vEdge router (in the service-side network) that are running BGP, and it receives AS path information from these routers. If you are redistributing BGP routes into OMP, the AS path information is included in the advertised BGP routes. If you configure BGP AS path propagation on some but not all vEdge routers in the overlay network, the routers on which it is not configured receive the AS path information but they do not forward it to the BGP routers in their local service-side network. Propagating AS path information can help to avoid BGP routing loops.

In networks that have both overlay and underlay connectivity—for example, when vEdge routers are interconnected by both a Viptela overlay network and an MPLS underlay network—you can assign as AS number to OMP itself. For vEdge routers running BGP, this overlay AS number is included in the AS path of BGP route updates. To configure the overlay AS:

vEdge(config)# omp
vEdge(omp)# overlay-as as-number

You can specify the AS number in 2-byte ASDOT notation (1 through 65535) or in 4-byte ASDOT notation (1.0 through 65535.65535). As a best practice, it is recommended that the overlay AS number be a unique AS number within both the overlay and the underlay networks. That use, select an AS number that is not used elsewhere in the network.

If you configure the same overlay AS number on multiple vEdge routers in the overlay network, all these routers are considered to be part of the same AS, and as a result, they do not forward any routes that contain the overlay AS number. This mechanism is an additional technique for preventing BGP routing loops in the network.

Configure the Number of Advertised Routes

vEdge routers advertise the routes that they learn from their local site to the vSmart controller, and the vSmart controller redistributes this routes to other vEdge routers in the overlay network. The routes advertised are actually a tuple consisting of the route and the TLOC associated with that route.

A vEdge router can have up to six WAN interfaces, and each WAN interface has a different TLOC. (A WAN interface is any interface in VPN 0 that is configured as a tunnel interface. Both physical and loopback interfaces can be configured to be tunnel interfaces.) The vEdge router advertises each route–TLOC tuple to the vSmart controller.

The vSmart controller redistributes the routes it learns from vEdge routers, advertising each route–TLOC tuple. If, for example, a local site as two vEdge routers, a vSmart controller could potentially learn eight route–TLOC tuples for the same route.

By default, vEdge routers and vSmart controllers advertises up to four equal-cost route–TLOC tuples for the same route. You can configure them to advertise from 1 to 16 route–TLOC tuples for the same route:

Viptela(config-omp)# send-path-limit number

If the limit is lower than the number of route–TLOC tuples, the vEdge router or vSmart controller advertises the best routes.

Configure the Number of Installed OMP Paths

vEdge routers install OMP paths that they received from the vSmart controller into their local route table. By default, a vEdge router installs a maximum of four unique OMP paths into its route table. You can modify this number:

vEdge(config-omp)# ecmp-limit number

The maximum number of OMP paths installed can range from 1 through 16.

Configure the OMP Hold Time

The OMP hold time determines how long to wait before closing the OMP connection to a peer. If the peer does not receive three consecutive keepalive messages within the hold time, the OMP connection to the peer is closed. The default OMP hold time is 60 seconds. To modify the OMP hold time interval:

Viptela(config-omp)# timers holdtime seconds

The hold time can be in the range 0 through 65535 seconds.

The keepalive timer is one-third the hold time and is not configurable.

If the local device and the peer have different hold time intervals, the higher value is used.

If you set the hold time to 0, the keepalive and hold timers on the local device and the peer are set to 0.

The hold time must be at least two times the hello tolerance interval set on the WAN tunnel interface in VPN 0. To configure the hello tolerance interface, use the hello-tolerance command.

Configure the OMP Update Advertisement Interval

By default, OMP sends Update packets once per second. To modify this interval:

Viptela(config-omp)# timers advertisement-interval seconds

The interval can be in the range 0 through 65535 seconds.

Configure the End-of-RIB Timer

After an OMP session goes down and then comes back up, an end-of-RIB (EOR) marker is sent after 300 seconds (5 minutes). After this maker is sent, any routes that were not refreshed after the OMP session came back up are considered to be stale and are deleted from the route table. To modify the EOR timer:

Viptela(config-omp)# timers eor-timer seconds

The time can be in the range 1 through 3600 seconds (1 hour).

Additional Information

show omp peers
show omp routes
show omp services
show omp summary
show omp tlocs
Unicast Overlay Routing Overview