Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

OER BR 'External' Requirement

I have read several of the OER docs - reading more as we speak - and they have said the BR should be an iBGP peer with the Master and MUST have an eBGP neighbor on a directly-connected interface.  Does anyone know if this is actually implemented that way?  I have an OER site with 4 BRs (one combo Master) and three of them are eBGP peered to ISPs or my other site.  The fourth is an iBGP peer but has its 'external' interface towards an MPLS provider which uses OSPF.  We redist the OSPF-BGP to each other (before you ask the MPLS provider will NOT do eBGP with us on this link).

When I check OER it seems to say the BR is validly configured:

oermaster1#sh oer master border detail
Border           Status   UP/DOWN             AuthFail  Version
1.2.3.247        ACTIVE   UP       1w0d          0  2.2
Gi0/0           EXTERNAL UP            
Gi0/1           INTERNAL UP
            

External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)                        
---------           --------      ------   ------- ------- ------           ------
Gi0/0           Tx      6000        6000      1459      24 UP                    6
                 Rx                  6000      3242      54
--------------------------------------------------------------------------------
Border           Status   UP/DOWN             AuthFail  Version
1.2.3.251        ACTIVE   UP       1w0d          0  2.2
Gi0/0           INTERNAL UP            
Gi0/1           EXTERNAL UP            

External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)                        
---------           --------      ------   ------- ------- ------           ------
Gi0/1           Tx     10000        7500       119       1 UP                    3
                 Rx                 10000       459       4
--------------------------------------------------------------------------------
Border           Status   UP/DOWN             AuthFail  Version
1.2.3.252        ACTIVE   UP       1w0d          0  2.2
Gi0/0           EXTERNAL UP            
Gi0/1           INTERNAL UP            

External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)                        
---------           --------      ------   ------- ------- ------           ------
Gi0/0           Tx     30000       22500     10142      33 UP                    2
                 Rx                 30000     10700      35
--------------------------------------------------------------------------------
Border           Status   UP/DOWN             AuthFail  Version
1.2.3.253        INACTIVE DOWN                       0  0.0
GigabitEthernet EXTERNAL Unverified    
GigabitEthernet INTERNAL Unverified    

External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)                        
---------           --------      ------   ------- ------- ------           ------
oermaster1#

FYI 1.2.3.247 is the BR in question, BR 1.2.3.253 has a link to an ISP we use only in emergencies.  OER appears to be working, its primary function now is to keep the MPLS circuit in BR 1.2.3.247 from being overrun because its routes appear much better than the eBGP routes from the other peers.

Thanks for looking.

Paul

Everyone's tags (4)
1 REPLY
Community Member

Re: OER BR 'External' Requirement

Paul,

I would like to see your topology to better understand what you are trying to implement. The common implementation for PfR/OER technology is the following:

Topology:

ISP-A                                             ISP-B

|                                                      |

EBGP                                            EBGP

|                                                      |

MC/BR-1<=====IBGP=====>BR-2

Here is further information on the operation of PfR/OER:

OER can learn prefixes dynamically through the traffic statistics from the NetFlow cache. Both TCP and non-TCP traffic can be learned based on highest throughput. Delay learning is limited to TCP-only traffic, but throughput can be calculated for non-TCP traffic. Network prefixes can be manually defined and learning need not be configured, or prefixes can both be learned dynamically and configured statically. In any of these use cases, a parent route is required to manage a network prefix or application. Parent routes are routes injected into the routing table by either eBGP or static routes which OER then augments with more specific routes (or uses policy-based routing (PBR)) to manage traffic across the external interfaces. Through an assumed definition, the parent routes must therefore be of equal cost and administrative distance so that more than one path for the parent route exists in the routing table of the border router at the same time.

OER learns prefixes that fall under a parent route, the least specific parent route is a default route (0/0), or more specific networks and masks may be configured. For example 10.0.0.0/8 could be used as a parent route. The learning of network prefixes that fall within the parent route is a function of NetFlow. NetFlow is enabled automatically by OER, however it does not appear in the running or startup configuration.
In the current implementation of OER, external BGP or static routes can serve as parent routes with external interfaces being point-to-point or multipoint interfaces (Ethernet) with a single next hop. In other words, multipoint GRE interfaces (as with a DMVPN configuration) that has multiple next hops reachable from the mGRE interface are not supported. Additionally, Ethernet interfaces with multiple next hops, which is a common BGP peering deployment topology, is not currently supported.

IP routing is not required on the MC, it simply must communicate with the BRs. The MC may be protected by firewall or access control lists. The MC and BRs communicate with each other on TCP port 3494 by default, but this is configurable. The MC listens on TCP port 3494 and the BRs initiate the TCP connection.

By default OER manages external interfaces by priority of WAN performance (delay), then loading (utilization). This means, therefore, that one exit point may be more fully used than another, if that exit point exhibits lower (better) application latency (delay) than an other exit point.

In learn mode, delay (and reachability) is determined by observing TCP flows. Round trip delay is determined by the amount of delay observed in TCP flows during session setup; the TCP first two exchanges of the TCP three-way handshake. The client active open is a TCP SYN to the server. In response, the server replies with a SYN-ACK. This level of visibility into TCP flows is obtained by observing flows (through the NetFlow cache) traversing the border routers.

When OER is configured in learn mode/passive, TCP flows must be observed by the border routers to manage prefixes. This means to test OER in a lab environment, some tool to generate actual TCP/UDP traffic and another to introduce delay, loss, etc,. is necessary to observe meaningful results.

There are limitations that the network manager must be aware of in order to successfully implement OER. Cisco Express Forwarding (CEF) must be enabled on all border routers. Up to 10 border routers and a total of 20 external interfaces are supported per master controller. If using BGP as parent routes, the border routers must have external BGP neighbors on directly connected interfaces. That neighbor cannot be an iBGP neighbor, although the border router(s) must be iBGP neighbors with other routers in the network to advertise the exit point of the OER managed routes. Static routes are supported as parent routes.

Best Regards,


Steve Lyons - Cisco

927
Views
0
Helpful
1
Replies
CreatePlease to create content