07-21-2010 03:55 PM - edited 03-04-2019 09:08 AM
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
08-12-2010 08:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide