Central Policy Database

The master controller continuously monitors the network and maintains a central policy database in which collected statistical information is stored. The master controller compares long-term and short-term measurements. The long-term measurements are collected every 60 minutes. Short-term measurements are collected every 5 minutes. The master controller analyzes these statistics to determine which routes have the lowest delay, highest outbound throughput, relative or absolute packet loss, relative or absolute link cost, and prefix reachability to analyze and optimize the performance of monitored prefixes and to distribute the load from overutilized exit links to underutilized exit links. The locations of the exit links on the border routers are shown in the figure above.

Tip	We recommend that the master controller be physically close to the border routers to minimize communication response time in OER-managed networks. If traffic is to be routed between border routers, the border routers also should be physically close each other to minimize the number of hops.

Policy Enforcement Point

The border router is the policy enforcement point. Default or user-defined policies are configured on the master controller to set the performance level for prefixes and exit links. The master controller automatically alters routing in the OER-managed network, as necessary, by sending control commands to the border routers to inject a preferred route. The preferred route is advertised or redistributed through the internal network. The preferred route alters default routing behavior so that out-of-policy prefixes are moved from overutilized exit links to underutilized exit links, bringing prefixes and exit links in-policy, thus optimizing the overall performance of the enterprise network.

Tip

We recommend that if traffic is to be routed between border routers, the border routers should be physically close to each other to minimize the number of hops. The master controller also should be physically close to the border routers to minimize communication response time in OER-managed networks.

Border Router Peering with the Internal Network

The master controller alters default routing behavior in the OER-managed network by injecting preferred routes into the routing tables of the border routers. The border routers peer with other routers in the internal network through BGP peering, BGP or static route redistribution into an IGP, or static routing. The border routers advertise the preferred route to internal peers.

The border routers should be close to one another in terms of hops and throughput and should have a consistent view of the network; routing should be configured consistently across all border routers. The master controller verifies that a monitored prefix has a parent route with a valid next hop before it commands the border routers to alter routing. The border router will not inject a route where one does not already exist. This behavior is designed to prevent traffic from being lost because of an invalid next hop.

Note	When two or more border routers are deployed in an OER-managed network, the next hop on each border router, as installed in the RIB, cannot be an IP address from the same subnet.

BGP Peering with OER

Standard iBGP peering can be established between the border routers and other internal peers. External BGP (eBGP) peering or a default route is configured to the ISP. In an iBGP network, the local preference attribute is used to set the preference for injected routes. Local preference is a discretionary attribute that is used to apply the degree of preference to a route during BGP best-path selection. This attribute is exchanged only between iBGP peers and is not advertised outside of the OER-managed network or to eBGP peers. The prefix with the highest local preference value is locally advertised as the preferred path to the destination. OER applies a local preference value of 5000 to injected routes by default. A local preference value from 1 to 65535 can be configured.

Note	If a local preference value of 5000 or higher has been configured for default BGP routing, you should configure a higher local preference value in OER using the mode command in OER master controller configuration mode.

Note

In Cisco IOS Release 12.4(6)T and prior releases, the IP address for each eBGP peering session must be reachable from the border router via a connected route. Peering sessions established through loopback interfaces or with the neighbor ebgp-multihop command are not supported. In Cisco IOS Release 12.4(9)T and 12.2(33)SRB, the neighbor ebgp-multihop command is supported.

BGP Redistribution into an IGP

BGP redistribution can be used if the border routers are configured to run BGP (for ISP peering for example) and the internal peers are configured to run another routing protocol (such as Enhanced Interior Gateway Routing Protocol [EIGRP], Open Shortest Path First [OSPF] or Routing Information Protocol [RIP]). The border routers can advertise a single, default route or full routing tables to the internal network. If you use BGP to redistribute more than a default route into an IGP, we recommend that you use IP prefix-list and route-map statements to limit the number of redistributed prefixes (BGP routing tables can be very large).

Static Routing and Static Route Redistribution into an IGP

Static routing or static route redistribution can be configured in the internal network. OER alters routing for this type of network by injecting temporary static routes. The temporary static route replaces the parent static route. OER will not inject a temporary static route where a parent static route does not exist. OER applies a default tag value of 5000 to identify the injected static route. In a network where only static routing is configured, no redistribution configuration is required. In a network where an IGP is deployed and BGP is not run on the border routers, static routes to border router exit interfaces must be configured, and these static routes must be redistributed into the IGP.

Caution

Caution must be applied when redistributing OER static routes into an IGP. The routes injected by OER may be more specific than routes in the IGP, and it will appear as if the OER border router is originating these routes. To avoid routing loops, the redistributed OER static routes should never be advertised over a WAN by an OER border router or any other router. Route filtering and stub network configuration can be used to prevent advertising the OER static routes. If the OER static routes are redistributed to routers terminating the OER external interfaces, routing loops may occur.

Split Prefixes Injected into the Routing Table

When configured to control a subset of a larger network, the master controller will add an appropriate route or split prefix to the existing routing table, as necessary. A split prefix is a more specific route that is derived from a less specific parent prefix. For example, if a /24 prefix is configured to be optimized, but only a /16 route is installed to the routing table, the master controller will inject a /24 prefix using the attributes of the /16 prefix. Any subset of the less-specific prefix can be derived, including a single host route. Split prefixes are processed only inside the OER-managed network and are not advertised to external networks. If BGP is deployed in the OER-managed network, the master controller will inject a more specific BGP route. If BGP is not deployed, the master controller will inject a more specific temporary static route.

Application Interface Priority

The OER application interface has three main levels of priority to help resolve conflicts with requests coming from providers, host devices, and policies. In the table below the three priority levels are shown with the scope of the priority, whether the priority level can be configured on the master controller, the range and default values, if applicable.

When multiple providers are registered with OER, an optional priority value can be specified to give OER the ability to order requests coming in from multiple providers. Host devices in a provider network can also be assigned a priority. The lower the priority value, the higher the priority. If you configure a priority, each provider must be assigned a different priority number. If you try to assign the same priority number to two different providers, an error message is displayed on the console. Host devices must also be configured with different priority numbers if a priority is configured. If a priority has not been configured for the provider or host device, the priority is set to the default value of 65535, which is the lowest priority.

The application administrator assigns a priority to all applications. This priority is conveyed to the Network in terms of a policy priority. The lower the application priority number, the higher the priority of the application. Policy priority is handled using the policy sequence number. A policy sequence number--see the table below--is a 64 bit number calculated by placing provider priority in bytes 1 and 2, host priority in bytes 3 and 4, policy priority in bytes 5 and 6 and Session ID in bytes 7 and 8. The policy sequence number is calculated by the OER master controller. An example policy sequence number is 18446744069421203465, representing a provider priority value of 65535, a host priority of 65535, a policy priority of 101, and a session ID of 9.

Use the show oer master policy command to view the policy sequence number. The lower the sequence number, the higher the priority for the policy.

In the situation where an application tries to create two policies with same policy priority; the second policy creation attempt will fail.

OER Application Interface Reporting Deployment

An application communicating through an OER application interface can request performance reports from OER and use the report information to create graphs and charts of the information. The figure below shows a diagram of an example reporting model. In this example, the topology contains multiple sites using OER within the site. Each site has a master controller but the company wants to review reports about activities in each site such as overall inter-site traffic activity, voice and video traffic activity, and data center access reports. An OER application interface solution is implemented with a reporting application--see the figure below--that resides in a central location. The reporting application is registered at each OER master controller and the application initiates a session with each master controller and requests traffic class performance information. The master controller at each site exports information to the application, which consolidates the information and displays graphs and charts. Reports can be requested at specified intervals to keep the information on the reporting application updated.

At each site the master controller can monitor provider activity. Several Cisco IOS command-line interface (CLI) commands allow you to view provider information including details about dynamic policies created by the application. Reporting can also be implemented for a single site.

In summary, the OER application interface provides an automated method for networks to be aware of applications and provides application-aware performance routing.

Perform this task at each border router to configure iBGP peering on the border routers managed by OER. The master controller implements policy changes by altering IP routing behavior in the OER-managed network. If iBGP peering is enabled on the border routers, the master controller will inject iBGP routes into routing tables on the border routers. The border routers advertise the preferred route through standard iBGP peering.

The local preference attribute is used to set the preference for injected BGP prefixes. If a local preference value of 5000 or higher has been configured for default BGP routing, you should configure a higher value in OER. Default local preference and static tag values are configurable with the mode command in OER master controller configuration mode.

All OER injected routes remain local to an autonomous system. The no-export community is automatically applied to injected routes to ensure that they are not advertised to external networks. Before injecting a route, the master controller verifies that a parent route with a valid next hop exists. This behavior is designed to prevent traffic from being lost.

This task explains how to redistribute BGP routes into an IGP in an OER-managed network. Some of the examples in the Detailed Steps section of this task show redistribution into OSPF, but EIGRP, IS-IS, or RIP could also be used in this configuration.

When redistributing BGP routes into any IGP, be sure to use the ip prefix-list and route-map command statements to limit the number of prefixes. Redistributing full BGP routing tables into an IGP can have a detrimental effect on IGP network operation.

This task shows how to redistribute static routes into an IGP in an OER-managed network. This task should be performed on the border routers.

OER applies a default tag value of 5000 to injected temporary static routes. The static route is filtered through a route map and then redistributed into the IGP. If you use the tag value of 5000 for another routing function, you should use a different tag value for that function, or you can change the default static tag values by configuring the mode command in OER master controller configuration mode.

Before injecting a route, the master controller verifies that a parent route with a valid next hop exists. This behavior is designed to prevent traffic from being lost.

If static routing is configured in your network and no IGP is deployed, OER will inject temporary static routes as necessary. No redistribution or other specific network configuration is required.

The following IGPs are supported; EIGRP, OSPF, Intermediate System-to-Intermediate System (IS-IS), and RIP.

Caution

Caution must be applied when redistributing OER static routes into an IGP. The routes injected by OER may be more specific than routes in the IGP, and it will appear as if the OER border router is originating these routes. To avoid routing loops, the redistributed OER static routes should never be advertised over a WAN by an OER border router or any other router. Route filtering and stub network configuration can be used to prevent advertising the OER static routes. If the OER static routes are redistributed to routers terminating the OER external interfaces, routing loops may occur.

Note	OER supports static route redistribution into EIGRP; however, it is configured differently. Proceed to the Redistributing Static Routes into EIGRP in an OER-Managed Network task for more information.

This task explains how to redistribute static routes into EIGRP. For EIGRP configurations, a tag is applied to the static route and the tag is then filtered through a route map. Two route map sequences are configured in this task. A route map named BLUE is configured to permit both configured static routes and OER static routes, and BLUE is the route map used to redistribute both types of static routes into EIGRP. A route map named RED is configured to permit only the configured static routes and implicitly deny the OER static routes. A distribute list uses the RED route map to filter outbound advertisements on the Ethernet 0 and Ethernet 1 egress interfaces. By denying the OER static route outbound advertisements, routing loops can be avoided.

OER applies a default tag value of 5000 to injected temporary static routes. The static route is filtered through a route map and then redistributed into the IGP.

Before injecting the temporary static route, the master controller verifies that a parent static route with a valid next hop exists. This behavior is designed to prevent traffic from being lost.

Caution

Caution must be applied when redistributing OER static routes into an IGP. The routes injected by OER may be more specific than routes in the IGP, and it will appear as if the OER border router is originating these routes. To avoid routing loops, the redistributed OER static routes should never be advertised over a WAN by an OER border router or any other router. Route filtering and stub network configuration can be used to prevent advertising the OER static routes. If the OER static routes are redistributed to routers terminating the OER external interfaces, routing loops may occur.

Perform this task at a master controller to register an application interface provider with the master controller and to configure host devices. In Cisco IOS Release 12.4(15)T the OER application interface was introduced. The OER application interface defines the mode of communication and messaging between applications and the network for the purpose of optimizing the traffic associated with the applications. A provider must be registered with an OER master controller before the application can interface with OER.

Multiple providers can be registered and multiple host devices can be configured under each provider, but a host device cannot be configured under multiple providers. The OER application interface has a maximum number of five concurrent sessions. After the provider is registered using this task, an application running on a host device can initiate a session with the master controller.

To view information about providers and any default policies created by applications using the OER application interface, see the Displaying Information about Application Interface Provider Activity. For more details about the OER application interface, see OER Application Interface.

Perform this task on a master controller to display information about providers and any default policies created by applications using the OER application interface. In Cisco IOS Release 12.4(15)T the OER application interface was introduced. The OER application interface defines the mode of communication and messaging between applications and the network for the purpose of optimizing the traffic associated with the applications. This task can be used after a provider is registered with an OER master controller using the Registering an Application Interface Provider and Configuring Host Devices task and an application on a host device initiates a session. The show commands can be entered in any order.

The following configuration example, starting in global configuration mode, shows the minimum configuration required to configure a master controller process to manage the internal network. A key-chain configuration named OER is defined in global configuration mode.

Router(config)# key chain OER
 
Router(config-keychain)# key 1
 
Router(config-keychain-key)# key-string KEYSTRING2 
Router(config-keychain-key)# end 

The master controller is configured to communicate with the 10.100.1.1 and 10.200.2.2 border routers. The keepalive interval is set to 10 seconds. Route control mode is enabled. Internal and external OER-controlled border router interfaces are defined.

Router(config)# oer master
 
Router(config-oer-mc)# keepalive 10 
Router(config-oer-mc)# logging
 
Router(config-oer-mc)# border 10.100.1.1 key-chain OER 
Router(config-oer-mc-br)# interface Ethernet 0/0 external
 
Router(config-oer-mc-br)# interface Ethernet 0/1 internal 
Router(config-oer-mc-br)# exit
Router(config-oer-mc)# border 10.200.2.2 key-chain OER 
Router(config-oer-mc-br)# interface Ethernet 0/0 external
 
Router(config-oer-mc-br)# interface Ethernet 0/1 internal 
Router(config-oer-mc)# exit

The following configuration example, starting in global configuration mode, shows the minimum required configuration to enable a border router. The key-chain configuration is defined in global configuration mode.

Router(config)# key chain OER 
Router(config-keychain)# key 1 
Router(config-keychain-key)# key-string KEYSTRING2 
Router(config-keychain-key)# end

The key-chain OER is applied to protect communication. An interface is identified to the master controller as the local interface (source) for OER communication.

Router(config)# oer border
 
Router(config-oer-br)# local Ethernet 0/1 
Router(config-oer-br)# master 192.168.1.1 key-chain OER 
Router(config-oer-br)# end 

The following configuration example configures a master controller to allow OER to control traffic with static routing in a network using NAT. This example shows how to use a pool of IP addresses for the NAT translation.

In the diagram above there is a combined master controller and border router that is connected to the Internet through two different ISPs. The configuration below allows OER to optimize traffic classes while permitting the internal users access to the internet. In this example the traffic classes to be translated using NAT are specified using an access list and a route map. The use of a pool of IP addresses for NAT translation is then configured and the oer keyword is added to the ip nat inside source command to configure OER to keep existing traffic classes flowing through the interface that is the source address that was translated by NAT. New NAT translations can be given the IP address of the interface that OER has selected for the packet.

Note	The OER static routing NAT solution is a single box solution and configurations with interfaces on multiple routers using NAT and managed by OER are not supported.

Router(config)# access-list 1 permit 10.1.0.0 0.0.255.255
Router(config)# route-map isp-2 permit 10BGP permit 10 
Router(config-route-map)# match ip address access-list 1
Router(config-route-map)# match interface serial 2/0
Router(config-route-map)# exit
Router(config)# ip nat pool ISP2 209.165.201.1 209.165.201.30 prefix-length 27
Router(config)# ip nat inside source route-map isp-2 pool ISP2 oer
Router(config)# interface FastEthernet 3/0
Router(config-if)# ip address 10.1.11.8 255.255.255.0
Router(config-if)# ip nat inside
Router(config-if)# exit
 
Router(config)# interface serial 1/0
Router(config-if)# ip address 192.168.3.1 255.255.255.0
Router(config-if)# ip nat outside
Router(config-if)# exit
 
Router(config)# interface serial 2/0
Router(config-if)# ip address 172.17.233.208 255.255.255.0
Router(config-if)# ip nat outside
Router(config-if)# end

For more details about configuring NAT, see the Configuring NAT for IP Address Conservation chapter of the Cisco IOS IP Addressing Services Configuration Guide .

The following example, starting in global configuration mode, shows how to establish peering between two routers in autonomous system 65534 and to configure standard community exchange:

Border Router Configuration

Router(config)# router bgp 65534 
Router(config-router)# neighbor 10.100.1.3 remote-as 65534
 
Router(config-router)# address-family ipv4 
Router(config-router-af)# neighbor 10.100.1.3 activate 
Router(config-router-af)# neighbor 10.100.1.3 send-community standard
 

Internal Border Peer Configuration

Router(config)# router bgp 65534 
Router(config-router)# neighbor 10.100.1.2 remote-as 65534
 
Router(config-router)# address-family ipv4 
Router(config-router-af)# neighbor 10.100.1.2 activate
 
Router(config-router-af)# neighbor 10.100.1.2 send-community standard
 

The following example, starting in global configuration mode, shows how to configure BGP to OSPF redistribution from the border router. Although this example shows redistribution into OSPF, EIGRP, IS-IS, or RIP could also be used in this configuration.

Note	When redistributing BGP routes into any IGP, be sure to use the ip prefix-list and route-map command statements to limit the number of prefixes. Redistributing full BGP routing tables into an IGP can have a detrimental effect on IGP network operation.

Border Router Configuration

Router(config)# ip prefix-list PREFIXES seq 5 permit 10.200.2.0/24
 
Router(config)# ip prefix-list PREFIXES seq 10 deny 0.0.0.0/0 
Router(config)# ! 
Router(config)# route-map BGP permit 10 
Router(config-route-map)# match ip address prefix-list PREFIXES 
Router(config-route-map)# exit
 
Router(config)# router bgp 65534 
Router(config-router)# bgp redistribute-internal
 

IGP Peer Configuration

Router(config)# router ospf 1
 
Router(config-router)# redistribute bgp 65534 route-map BGP subnets
 

The following example, starting in global configuration mode, shows how to configure static redistribution to allow the master controller to influence routing in an internal network that is running RIP. The match tag command is used to match OER-injected temporary static routes. The set metriccommand is used to set the preference of the injected static route.

Border Router Configuration

Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 0 
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 1 
Router(config)# route-map STATIC permit 10 
Router(config-route-map)# match tag 5000 
Router(config-route-map)# set metric -10
 
Router(config-route-map)# exit
 
Router(config)# router rip 
Router(config-router)# network 192.168.0.0
 
Router(config-router)# network 172.16.0.0 
Router(config-router)# redistribute static route-map STATIC
 

Internal Border Peer Configuration

Router(config)# route rip 
Router(config-router)# network 192.168.0.0 
Router(config-router)# network 172.16.0.0 

The following example, starting in global configuration mode, shows how to configure static redistribution to allow the master controller to influence routing in an internal network that is running EIGRP. Two route map sequences are configured in this example. A route map named BLUE is configured to permit both configured static routes and OER static routes, and BLUE is the route map used to redistribute both types of static routes into EIGRP. A route map named RED is configured to permit only the configured static routes and implicitly deny the OER static routes. A distribute list uses the RED route map to filter outbound advertisements on the Ethernet 0 and Ethernet 1 egress interfaces. By denying the OER static route outbound advertisements, routing loops can be avoided.

Border Router Configuration

Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 0 tag 10
 
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 1 tag 10
 
Router(config)# route-map BLUE permit 10 
Router(config-route-map)# match tag 5000
 
Router(config-route-map)# match tag 10
 
Router(config-route-map)# exit 
Router(config)# route-map RED permit 20
 
Router(config-route-map)# match tag 10 
Router(config-route-map)# exit 
Router(config)# route eigrp 1
 
Router(config-router)# no auto-summary
 
Router(config-router)# 
redistribute static route-map BLUE
 
Router(config-router)# network 10.0.0.0 
Router(config-router)# network 172.16.0.0
 
Router(config-router)# network 192.168.0.0
 
Router(config-router)# distribute-list route-map RED out Ethernet 0
 
Router(config-router)# distribute-list route-map RED out Ethernet 1 

Internal Border Peer Configuration

Router(config)# route eigrp 1 
Router(config-router)# no auto-summary 
Router(config-router)# network 10.0.0.0 
Router(config-router)# network 172.16.0.0 
Router(config-router)# network 192.168.0.0 
Router(config-router)# end
 

The figure below shows an OER-managed network with two border router processes and a master controller process deployed separately on Cisco routers.

Figure 10

Master Controller Deployed with Two Border Routers

The master controller performs no routing functions. BGP is deployed on the border routers and internal peers in the OER-managed network. Each border router has an eBGP peering session with a different ISP. The eBGP peers (ISP border routers) are reachable through connected routes. Injected prefixes are advertised in the internal network through standard iBGP peering.

OER MC Configuration

The following example, starting in global configuration mode, shows the master controller configuration.

Router(config)# key chain OER
 
Router(config-keychain)# key 1 
Router(config-keychain-key)# key-string CISCO 
Router(config-keychain-key)# exit
 
Router(config)# oer master 
Router(config-oer-mc)# border 10.100.1.1 key-chain OER 
Router(config-oer-mc-br)# interface Ethernet 0/0 external
 
Router(config-oer-mc-br-if)# exit
 
Router(config-oer-mc-br)# interface Serial 1/1 internal 
Router(config-oer-mc-br-if)# end
Router(config-oer-mc)# border 10.200.2.2 key-chain OER 
Router(config-oer-mc-br)# interface Ethernet 2/2 external
 
Router(config-oer-mc-br-if)# exit
 
Router(config-oer-mc-br)# interface Serial 3/3 internal
 
Router(config-oer-mc-br-if)# end

BR1 Configuration

The following example, starting in global configuration mode, shows the configuration for BR1. eBGP peering is established with ISP1 (192.168.1.1 AS2). Standard community exchange and iBGP peering are established with BR2 (10.200.2.2) and internal peers (in the 10.150.1.0/24 network).

Router(config)# key chain OER
 
Router(config-keychain)# key 1
 
Router(config-keychain-key)# key-string CISCO 
Router(config-keychain-key)# exit
 
Router(config-keychain)# exit
 
Router(config)# oer border 
Router(config-oer-br)# master 172.16.1.1 key-chain OER 
Router(config-oer-br)# local Serial 1/1 
Router(config-oer-br)# exit
 
Router(config)# router bgp 1
 
Router(config-router)# neighbor 192.168.1.1 remote-as 2 
Router(config-router)# neighbor 10.200.2.2 remote-as 1
 
Router(config-router)# neighbor 10.150.1.1 remote-as 1
 
Router(config-router)# neighbor 10.150.1.2 remote-as 1 
Router(config-router)# neighbor 10.150.1.3 remote-as 1
 
Router(config-router)# address-family ipv4 unicast
 
Router(config-router-af)# neighbor 192.168.1.1 activate 
Router(config-router-af)# neighbor 10.200.2.2 activate
 
Router(config-router-af)# neighbor 10.200.2.2 send-community standard 
Router(config-router-af)# neighbor 10.150.1.1 activate
 
Router(config-router-af)# neighbor 10.150.1.1 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.2 activate
 
Router(config-router-af)# neighbor 10.150.1.2 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.3 activate
 
Router(config-router-af)# neighbor 10.150.1.3 send-community standard
 
Router(config-router-af)# end 

BR2 Configuration

The following example, starting in global configuration mode, shows the configuration for BR2. eBGP peering is established with ISP2 (192.168.2.2 AS1). Standard community exchange and iBGP peering is established with BR2 (10.100.1.1) and internal peers (in the 10.150.1.0/24 network).

Router(config)# key chain OER 
Router(config-keychain)# key 1
 
Router(config-keychain-key)# key-string CISCO
 
Router(config-keychain-key)# end
Router(config)# oer border
 
Router(config-oer-br)# master 172.16.1.1 key-chain OER 
Router(config-oer-br)# local Serial 1/1
 
Router(config-oer-br)# exit
 
Router(config)# router bgp 1 
Router(config-router)# neighbor 192.168.2.2 remote-as 3
 
Router(config-router)# neighbor 10.100.1.1 remote-as 1 
Router(config-router)# neighbor 10.150.1.1 remote-as 1
 
Router(config-router)# neighbor 10.150.1.2 remote-as 1
 
Router(config-router)# neighbor 10.150.1.3 remote-as 1
 
Router(config-router)# address-family ipv4 unicast
 
Router(config-router-af)# neighbor 192.168.2.2 activate
 
Router(config-router-af)# neighbor 10.200.2.2 activate 
Router(config-router-af)# neighbor 10.200.2.2 send-community standard 
Router(config-router-af)# neighbor 10.150.1.1 activate
 
Router(config-router-af)# neighbor 10.150.1.1 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.2 activate
 
Router(config-router-af)# neighbor 10.150.1.2 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.3 activate 
Router(config-router-af)# neighbor 10.150.1.3 send-community standard 
Router(config-router-af)# end
 

Internal Peer Configuration

The following example, starting in global configuration mode, shows the internal peer configuration. Standard full-mesh iBGP peering is established with BR1 and BR2 and the internal peers in autonomous system 1.

Router(config)# router bgp 1 
Router(config-router)# neighbor 10.100.1.1 remote-as 1 
Router(config-router)# neighbor 10.200.2.2 remote-as 1 
Router(config-router)# neighbor 10.150.1.1 remote-as 1
 
Router(config-router)# neighbor 10.150.1.2 remote-as 1 
Router(config-router)# neighbor 10.150.1.3 remote-as 1 
Router(config-router)# address-family ipv4 unicast
 
Router(config-router-af)# neighbor 10.100.1.1 activate 
Router(config-router-af)# neighbor 10.100.1.1 send-community standard 
Router(config-router-af)# neighbor 10.200.2.2 activate
 
Router(config-router-af)# neighbor 10.200.2.2 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.1 activate
 
Router(config-router-af)# neighbor 10.150.1.1 send-community standard 
Router(config-router-af)# neighbor 10.150.1.2 activate 
Router(config-router-af)# neighbor 10.150.1.2 send-community standard
 
Router(config-router-af)# neighbor 10.150.1.3 activate 
Router(config-router-af)# neighbor 10.150.1.3 send-community standard 
Router(config-router-af)# end 

The diagram below shows an OER-managed network with two border routers. BR1 is configured to run a master controller and border router process.

BR2 is configured as a border router. The internal network is running OSPF. Each border router peers with a different ISP. A static route to the egress interface is configured on each border router. The static routes are then redistributed into OSPF. Injected prefixes are advertised through static route redistribution.

BR1 Configuration: Master Controller and Border Router on a Single Router with Load Distribution Policy

The following example, starting in global configuration mode, shows the configuration of BR1. This router is configured to run both a master controller and a border router process. BR1 peers with ISP1. A traffic load distribution policy is configured under the master controller process that is applied to all exit links in the OER-managed network.

Router(config)# key chain OER 
Router(config-keychain)# key 1 
Router(config-keychain-key)# key-string CISCO
 
Router(config-keychain-key)# exit
Router(config-keychain)# exit
Router(config)# oer border
 
Router(config-oer-br)# master 10.100.1.1 key-chain OER 
Router(config-oer-br)# local Loopback 0
 
Router(config-oer-br)# exit
 
Router(config)# oer master 
Router(config-oer-mc)# logging 
Router(config-oer-mc)# border 10.100.1.1 key-chain OER
 
Router(config-oer-mc-br)# interface Serial 0/0 external
 
Router(config-oer-mc-br-if)# exit 
Router(config-oer-mc-br)# interface Ethernet 1/1 internal 
Router(config-oer-mc-br-if)# exit
 
Router(config-oer-mc-br)# exit
Router(config-oer-mc)# border 10.200.2.2 key-chain OER
 
Router(config-oer-mc-br)# interface Serial 2/2 external 
Router(config-oer-mc-br-if)# exit 
Router(config-oer-mc-br)# interface Ethernet 3/3 internal
 
Router(config-oer-mc-br-if)# exit
Router(config-oer-mc-br)# exit
 
Router(config-oer-mc)# exit
 
Router(config)# ip route 0.0.0.0 0.0.0.0 Serial 0/0 
Router(config)# !
 
Router(config)# route-map STATIC
 
Router(config-route-map)# match tag 5000
 
Router(config-route-map)# set metric -10 
Router(config-route-map)# exit 
Router(config)# router ospf 1
 
Router(config-router)# network 10.0.0.0 0.0.0.255 area 0 
Router(config-router)# redistribute static route-map STATIC subnets
 
Router(config-router)# end
 

BR2 Configuration

The following example, starting in global configuration mode, shows the configuration of BR2. This router is configured to run only a border router process.

Router(config)# key chain OER
 
Router(config-keychain)# key 1 
Router(config-keychain-key)# key-string CISCO 
Router(config-keychain-key)# exit
 
Router(config-keychain)# exit 
Router(config)# oer border
 
Router(config-oer-border)# master 10.100.1.1 key-chain OER
 
Router(config-oer-border)# local Ethernet3/3
 
Router(config-oer-border)# exit
 
Router(config)# ip route 0.0.0.0 0.0.0.0 Serial 2/2 
Router(config)# ! 
Router(config)# route-map STATIC permit 10
 
Router(config-route-map)# match tag 5000 
Router(config-route-map)# set metric -10
 
Router(config-route-map)# exit 
Router(config)# router ospf 1 
Router(config-router)# network 10.0.0.0 0.255.255.255 area 0 
Router(config-router)# redistribute static route-map STATIC
 
Router(config-router)# end 

Internal Peer Configuration

The following example, starting in global configuration mode, configures an OSPF routing process to establish peering with the border routers and internal peers. No redistribution is configured on the internal peers.

Router(config)# router ospf 1 
Router(config-router)# network 10.0.0.0 0.255.255.255 area 0
 
Router(config-router)# redistribute static route-map STATIC subnets 
Router(config-router)# end
 

The figure below shows a SOHO network in which the master controller and border router process are set up on a single router.

Figure 12

OER Deployed on a Single Router in a SOHO Configuration

The router connects the SOHO network with two ISPs. OER is configured to learn prefixes based on highest outbound throughput and lowest delay. Prefixes with a response time longer than 80 milliseconds are out-of-policy and moved if the performance on the other link conforms to the policy.

Master Controller and Border Router Configuration on a Single Router

The following example, starting in global configuration mode, shows an OER master controller and border router process deployed on a single router:

Router(config)# key chain OER
 
Router(config-keychain)# key 1 
Router(config-keychain-key)# key-string KEYSTRING2 
Router(config-keychain-key)# exit 
Router(config-keychain)# exit
 
Router(config)# oer border 
Router(config)# logging 
Router(config-oer-br)# master 10.100.1.1 key-chain OER 
Router(config-oer-br)# local Loopback 0 
Router(config-oer-br)# exit
 
Router(config)# oer master 
Router(config-oer-mc)# logging 
Router(config-oer-mc)# border 10.100.1.1 key-chain OER 
Router(config-oer-mc-br)# interface Ethernet 0/0 external
 
Router(config-oer-mc-br-if)# exit
 
Router(config-oer-mc-br)# interface Ethernet 1/1 external
 
Router(config-oer-mc-br-if)# exit 
Router(config-oer-mc-br)# interface Ethernet 2/2 internal
 
Router(config-oer-mc-br-if)# exit
 
Router(config-oer-mc-br)# exit
 
Router(config-oer-mc)# exit
 
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 0/0
 
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 1/1
 
Router(config)# end 

The following configuration example shows how to register a provider on a master controller. In this example, more than one provider is configured, so the priority is set for each provider. For the single host device configured for provider 1, no priority is set and the default priority value of 65535 is assigned giving this host device a lower priority than both the host devices configured for provider 2. After the provider is registered and an application on a host device initiates a session, some show commands can be entered on the master controller to help you track provider activity.

Router(config)# oer master
Router(config-oer-mc)# api provider 1 priority 3000
Router(config-oer-mc-api-provider)# host-address 10.1.2.2 key-chain OER_HOST
Router(config-oer-mc-api-provider)# exit
Router(config-oer-mc)# api provider 2 priority 4000
Router(config-oer-mc-api-provider)# host-address 10.2.2.2 key-chain OER_HOST
priority 3000
Router(config-oer-mc-api-provider)# host-address 10.2.2.3 key-chain OER_HOST
priority 4000
Router(config-oer-mc-api-provider)# end
!
Router# show oer api provider detail
Router# show oer master policy dynamic
Router# show oer master prefix 10.1.1.0/24 report