From: Hulbert, Jerald (Jerry.Hulbert@flukenetworks.com)
Date: Wed Feb 27 2008 - 18:59:05 ARST
Hi Rik,
I haven't actually tested OER with CBAC running, but it should still
work fine. Of course your CPU tax will increase. If you are also using
NAT, you will need to add the keyword of "oer" to your nat
configuration.
I find that most customers are using OER for differing reasons. Some
want the utilization balancing across their exit interfaces, others want
faster failover. Only a few that I've run into actually want to provide
a performance guarantee for business related traffic, which is what OER
was intended to perform. OER does at least give you some metrics
(throughput, jitter, latency, loss, etc) for your traffic classes, both
on the currently used path, and the available alternate paths. See
below for a report for one traffic class and it's two alternate paths.
Feb 27 20:53:50.347: OER API: Traffic Perf Report: Current PathPFX
10.0.0.128/29 Appl 0 [0, 0][0, 0] 0: br 172.20.88.18, exit
Serial0/0/1:0, ingress bytes 947, egress bytes 930, act delay 0, pas
delay 102, act loss 0, pas loss 0, act unreach 0, pas unreach 0, mos
0, jitter 0, status 1, report freq 5
Feb 27 20:53:50.347: OER API: Traffic Perf Report: Alternate PathPFX
10.0.0.128/29 Appl 0 [0, 0][0, 0] 0: br 172.20.88.18, exit
Serial0/0/0:0, ingress bytes 0, egress bytes 0, act delay 60, pas delay
0, act loss 0, pas loss 14, act unreach 0, pas unreach 1451, mos 0,
jitter 0, status 1, report freq 5
Feb 27 20:53:50.347: OER API: Traffic Perf Report: Alternate PathPFX
10.0.0.128/29 Appl 0 [0, 0][0, 0] 0: br 172.20.77.17, exit Serial0/0,
ingress bytes 0, egress bytes 0, act delay 56, pas delay 0, act loss 0,
pas loss 0, act unreach 0, pas unreach 1879, mos 0, jitter 0, status 1,
report freq 5
It used to be that OER was only used for changing the outgoing interface
for traffic, based on the destination IP. Now, OER allows you to
control with ingress interface that you want traffic to be received on,
. OER does support BGP, EIGRP and Static now, but you could always use
it on OSPF if you redistribute static into OSPF.
Thanks,
Jerry
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Rik Guyler
Sent: Wednesday, February 27, 2008 7:52 AM
To: Hulbert, Jerald
Cc: 'Cisco certification'
Subject: RE: outbound load-balancing
Jerry, a couple of questions if you don't mind.
1) Since you are running both BR and MC functions on a single router,
what about adding a firewall feature (CBAC) to this as well for an
all-in-one solution? Do you know/believe if CBAC will interfere somehow
with the OER function?
2) Assuming you don't run CBAC on this box, are you running a firewall
device behind it? Thinking outside the box a bit here, I've also
considered putting individual small firewalls outside the OER box on
each ISP connection to sort out the NAT issues a bit. Does this make
any sense at all or do you think this could interfere with the OER
function?
I appreciate the real-world input here. I'm having trouble finding any
real detailed information and my contacts at Cisco aren't real familiar
with this feature yet either...although I'm still looking. ;-)
Thanks!
Rik
-----Original Message-----
From: Hulbert, Jerald [mailto:Jerry.Hulbert@flukenetworks.com]
Sent: Tuesday, February 26, 2008 6:24 PM
To: dara tomar; Tony Schaffran (GS)
Cc: Sadiq Yakasai; Rik Guyler; Cisco certification
Subject: RE: outbound load-balancing
Yes, oer can do this for you too, but it will be based on dynamically
and/or manually traffic classes being moved to a different "exit"
interface. The oer mc will do this by adding a longer match to the
route table for the oer controlled routes.
The master controller and border router functions can be on the same
physical router. You would define the maximum transmit utilization on
your exit links and then allow the mc to "route control" your traffic
classes.
On my local PC, I only have an example of an mc with 2 br's with bgp.
Later on, I can convert this to one router with mc/br functions using
static routes.
oer master <=== Designates this router as the MC.
!
border 172.20.77.17 key-chain MD5_OER <=== Identifies this IP
is a BR
interface FastEthernet0/1.478 internal
interface FastEthernet0/0.378 internal
interface Serial0/0 external
max-xmit-utilization percentage 65 <=== specifying the transmit
utilization of the external interface, in % !
border 172.20.88.18 key-chain MD5_OER
interface Serial0/0/1:0 external
max-xmit-utilization absolute 500 <=== specifying the transmit
utilization of the external interface in Kbps.
interface Serial0/0/0:0 external
max-xmit-utilization absolute 250 <=== specifying the transmit
utilization of the external interface in Kbps.
interface GigabitEthernet0/1.478 internal
interface GigabitEthernet0/0.378 internal !
learn
throughput
delay
periodic-interval 0
monitor-period 1
aggregation-type prefix-length 29
no max range receive
api provider 1 priority 1
host-address 192.168.2.9 key-chain MD5_OER priority 1
mode route control <=== Allowing oer to make routing decisions.
mode select-exit best <=== OER will always attempt to move traffic
classes to the best external link, even if the current link is in
profile.
resolve range priority 1
resolve utilization priority 2 variance 10 no resolve delay
Below is the output of a br with oer controlling bgp.
R8#sho ip bgp oer-paths
BGP table version is 3177, local router ID is 150.1.18.18 Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete OER Flags: C -
Controlled, X
- Excluded, E - Exact, N - Non-exact, I - Injected
Network Next Hop OER LocPrf Weight Path
*> 192.168.16.0/29 172.20.58.5 CEI 0 200 100 54 i
*> 192.168.17.0/29 172.20.58.5 CEI 0 200 100 54 i
*>i10.0.0.0/29 172.20.127.2 XN 5000 0 300 100 54 50 60
i
*> 10.0.0.128/29 172.20.68.6 CEI 800 0 100 54 50 60 i
*> 10.1.0.0/29 172.20.58.5 CEI 800 0 200 100 54 i
*> 10.2.0.128/29 172.20.58.5 CEI 0 200 100 54 i
*>i10.3.0.0/29 172.20.127.2 XN 5000 0 300 100 54 i
*> 10.3.0.128/29 172.20.58.5 CEI 800 0 200 100 54 i
*>i10.4.0.0/29 172.20.127.2 XN 5000 0 300 100 54 i
*> 10.4.0.128/29 172.20.58.5 CEI 0 200 100 54 i
*> 10.5.0.0/29 172.20.58.5 CEI 800 0 200 100 54 i
*> 10.5.0.128/29 172.20.58.5 CEI 800 0 200 100 54 i
*> 10.6.0.0/29 172.20.58.5 CEI 0 200 100 54 i
*> 10.6.0.128/29 172.20.58.5 CEI 0 200 100 54 i
R8#
Cheers,
Jerry
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
dara tomar
Sent: Tuesday, February 26, 2008 11:20 AM
To: Tony Schaffran (GS)
Cc: Sadiq Yakasai; Rik Guyler; Cisco certification
Subject: Re: outbound load-balancing
*Tony,
I find the explanation your right.
Does the cisco OER really provides us with any such function??
Because it's quite basic as a requirement, and I don't see this
happening as per the BW difference between the interfaces.
Regards,
Dara*
On Tue, Feb 26, 2008 at 11:42 PM, Tony Schaffran (GS) <
groupstudy@cconlinelabs.com> wrote:
> Actually, I do not think that is load-balancing.
>
> Those are just redundant paths and the primary will always be selected
> as the candidate path unless that interface actually goes down.
>
> If there is a problem in the path and that interface stays up, the
> route (marked with *) will not be deleted and your traffic will not
get out.
>
> That is how I understand what you are showing. If I am wrong, please
> enlighten me.
>
>
> Tony Schaffran
> Network Analyst
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> www.cconlinelabs.com
> Your #1 choice for online Cisco rack rentals.
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Sadiq Yakasai
> Sent: Tuesday, February 26, 2008 9:46 AM
> To: Rik Guyler
> Cc: Cisco certification
> Subject: Re: outbound load-balancing
>
> Hi Rik,
>
> You can actually do unequal cost load-balancing on the outbound using
> static routes. Have a look at this (R1 and R3 are dual hommed to each
> other):
>
> 192.168.1.0/24
> R1 <http://192.168.1.0/24R1> (.1)
> ---------------------------------------------- (.3) R3
> ----------------------------------------------
> 162.1.13.0/24
>
> R1#sh run | i ip route
> ip route 0.0.0.0 0.0.0.0 192.168.1.3
> ip route 0.0.0.0 0.0.0.0 162.1.13.3
> ip route 0.0.0.0 0.0.0.0 10.10.10.1
> ip route 0.0.0.0 0.0.0.0 10.10.10.3
> ip route 0.0.0.0 0.0.0.0 10.10.10.4
> ip route 10.10.10.1 255.255.255.255 192.168.1.3 ip route 10.10.10.2
> 255.255.255.255 192.168.1.3 ip route 10.10.10.3 255.255.255.255
> 192.168.1.3 ip route 10.10.10.4 255.255.255.255 192.168.1.3 R1#sh ip
> route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via
> "static", distance 1, metric 0, candidate default path Routing
> Descriptor Blocks:
> * 192.168.1.3
> Route metric is 0, traffic share count is 1
> 162.1.13.3
> Route metric is 0, traffic share count is 1
> 10.10.10.4
> Route metric is 0, traffic share count is 1
> 10.10.10.3
> Route metric is 0, traffic share count is 1
> 10.10.10.1
> Route metric is 0, traffic share count is 1
>
> A nice trick there!
>
> Sadiq
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2008 - 16:54:50 ARST