"ip cef" ospf load balance problem

[nawir]

PROBLEM:

When I trace from PC1 to SVR1, it always goes to R2-R4, unless link between R2-R4 down.

But when lin R2-R4 up again, the traffic will go thru R2-R4 again

PC1# trace 45.0.0.2

I want to use per-destination load balance instead of per-packet because I am using VOIP device.

I am expecting round-robin link

My problem exactly like this

http://blog.ipspace.net/2008/09/load-balancing-quirks.html

QUESTIONS:

1. how to proof I got load balance path from PC1 to SVR1

R1#sh ip route 45.0.0.0

Routing entry for 45.0.0.0/24, 1 known subnets

O        45.0.0.0 [110/801] via 13.0.0.1, 00:18:24, Ethernet0/1

                  [110/801] via 12.0.0.1, 00:18:24, Ethernet0/0

CONFIG

PC1

hostname PC1

ip cef

interface Ethernet0/0

 ip address 10.0.0.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 10.0.0.1

R1

hostname R1

ip cef

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

interface Ethernet0/0

 ip address 12.0.0.2 255.255.255.0

interface Ethernet0/1

 ip address 13.0.0.2 255.255.255.0

interface Ethernet0/2

 ip address 10.0.0.1 255.255.255.0

router ospf 1

 network 1.1.1.0 0.0.0.255 area 0

 network 10.0.0.0 0.0.0.255 area 0

 network 12.0.0.0 0.0.0.255 area 0

 network 13.0.0.0 0.0.0.255 area 0

R2

hostname R2

ip cef

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

interface Ethernet0/0

 ip address 12.0.0.1 255.255.255.0

interface Serial1/0

 bandwidth 128

 ip address 24.0.0.2 255.255.255.0

 serial restart-delay 0

router ospf 1

 network 2.2.2.0 0.0.0.255 area 0

 network 12.0.0.0 0.0.0.255 area 0

 network 24.0.0.0 0.0.0.255 area 0

R3

hostname R3

ip cef

interface Loopback0

 ip address 3.3.3.3 255.255.255.255 !

interface Ethernet0/1

 ip address 13.0.0.1 255.255.255.0

interface Serial1/0

 bandwidth 128

 ip address 34.0.0.2 255.255.255.0

 serial restart-delay 0

router ospf 1

 network 3.3.3.0 0.0.0.255 area 0

 network 13.0.0.0 0.0.0.255 area 0

 network 34.0.0.0 0.0.0.255 area 0

R4

hostname R4

ip cef

interface Loopback0

 ip address 4.4.4.4 255.255.255.255

interface Ethernet0/0

 ip address 45.0.0.1 255.255.255.0

interface Serial1/1

 bandwidth 128

 ip address 24.0.0.1 255.255.255.0

 serial restart-delay 0

router ospf 1

 network 4.4.4.0 0.0.0.255 area 0

 network 24.0.0.0 0.0.0.255 area 0

 network 34.0.0.0 0.0.0.255 area 0

 network 45.0.0.0 0.0.0.255 area 0

SVR1

hostname SVR1

ip cef

interface Ethernet0/0

 ip address 45.0.0.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 45.0.0.1

[Georg Pauwen]

Hello,

try and disable cef (no ip cef) and route-caching on the Ethernet interface (no ip route-cache). CEF does per-destination load balancing by default.

[nawir]

both "ip cef" and "ip route-cache" needed by 

 auto discovery qos trust

 auto qos voip trust

Here the proof

R1(config)#int e0/0
R1(config-if)# auto discovery qos trust
CEF switching needed for AutoQoS Discovery

I must use per-destination because per-packet didn't compatible with VOIP

http://www.cisco.com/c/en/us/td/docs/ios/ipswitch/command/reference/isw_book/isw_i1.html

Per-packet load balancing can result in out-of-sequence (OOS) packet delivery errors on some routers, which can cause applications such as VoIP to malfunction. Therefore, per-packet load balancing is not recommended

[Mark Malone]

per destination can easily result in unequal load balancing with cef as you need a really large destination base in routing table for it to work correctly ,probably better off using eigrp to load balance or cisco pfr they may work better for you , or manually force the traffic down certain paths with pbr routing if cef is not giving you what you need

http://www.cisco.com/c/en/us/products/ios-nx-os-software/performance-routing-pfr/index.html

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html#perper

Per-Destination and Per-Packet Load Balancing

You can set load-balancing to work per-destination or per-packet. Per-destination load balancing means the router distributes the packets based on the destination address. Given two paths to the same network, all packets for destination1 on that network go over the first path, all packets for destination2 on that network go over the second path, and so on. This preserves packet order, with potential unequal usage of the links. If one host receives the majority of the traffic all packets use one link, which leaves bandwidth on other links unused. A larger number of destination addresses leads to more equally used links. To achieve more equally used links use IOS software to build a route-cache entry for every destination address, instead of every destination network, as is the case when only a single path exists. Therefore traffic for different hosts on the same destination network can use different paths. The downside of this approach is that for core backbone routers carrying traffic for thousands of destination hosts, memory and processing requirements for maintaining the cache become very demanding.

Per-packet load-balancing means that the router sends one packet for destination1 over the first path, the second packet for (the same) destination1 over the second path, and so on. Per-packet load balancing guarantees equal load across all links. However, there is potential that the packets may arrive out of order at the destination because differential delay may exist within the network. In Cisco IOS software, except the release 11.1CC, per packet load balancing does disable the forwarding acceleration by a route cache, because the route cache information includes the outgoing interface. For per-packet load balancing, the forwarding process determines the outgoing interface for each packet by looking up the route table and picking the least used interface. This ensures equal utilization of the links, but is a processor intensive task and impacts the overall forwarding performance. This form of per-packet load balancing is not well suited for higher speed interfaces.

Per-destination or per-packet load-balancing depends on the type of switching scheme used for IP packets. By default, on most Cisco routers, fast switching is enabled under interfaces. This is a demand caching scheme that does per-destination load-balancing. To set per-packet load-balancing, enable process switching (or disable fast switching), use these commands:

[nawir]

https://supportforums.cisco.com/document/32216/load-balancing-using-performance-routing-pfroer

One user has problem which is outgoing traffic via ISP2 but incoming traffic using ISP1.

How to test outgoing session traffic and incoming, using the same ISP.

I can use extended ping or extended traceroute + record.

The problem is if in between has firewall, the result will be shown as * * * *

Any other alternative to test that

tq

[Mark Malone]

Are you using BGP at ISP level you can make alter the traffic directions incoming and outgoing with the BGP path attributes per subnet

Can you not allow icmp and trace through the firewall while you test

[nawir]

ISP only give me few ip.

I can't control their BGP.

You are right regarding allowing icmp in firewall.

Back to my question.

If I using PFR without BGP.

How to set so that outgoing and incoming session using the same ISP.

Remember I have 2 ISPs

That is important for Internet Banking activities.

After set.

Do you think to test that session only by using extended ping or extended traceroute

tq

[Mark Malone · Accepted solution]

if you have an ebgp peering with them on both ISPs you can use AS PATH to control what path the routes come in from them by setting more AS PATHs you can make one 1 ISP less preferred for certain subnets , you cant control their BGP but you can control how you learn it in from them

heres an example of oer with no bgp , you should lab it up in gns3 or couple fo spare routers before putting anything into production

http://www.dslreports.com/faq/13355

Do you think to test that session only by using extended ping or extended traceroute-- yes that's the main method along with checking routing paths for IGP and BGP what way there routing

[nawir]

https://nbctcp.wordpress.com/2016/10/07/cisco-pfr/

After test, I found that in Unetlab for PfR. I need to use serial for connection leaving R1.

If I use ethernet even after I set bandwidth, I didn't get load balanced as expected.

Maybe in real live won't be like that.

@Mark, do you ever configure PfR with VOIP?

Do you think by setting these in every interface of R1 would be enough

auto discovery qos trust

auto qos voip trust

tq

[Mark Malone]

Maybe in real live won't be like that.

shouldn't be we only have Ethernet and PFR works fine , serial is legacy these days in real world used for low end backup links or primary rates voice , most circuits now even in mpls would be 10mb up to 1gb

@Mark, do you ever configure PfR with VOIP?

We use PFRv3 with IWAN and LiveAction so we have a different setup , we balance traffic based on DSCP markings only , so I cant say we have set it up for voice specifically

But I do have layer2 and layer 3 qos every device and we do use auto qos voip trust on some platforms