07-01-2016 10:31 AM - edited 03-05-2019 04:20 AM
can we do load balancing using static routing ??
07-01-2016 10:38 AM
Load-balancing on Cisco routers is per-flow based and not per packet based. So you can still have two static routes but the load will be shared between the two links based on per flow. Also note, you need to have two paths towards the destination.
07-01-2016 11:03 AM
sorry @vinit , i did nt understand waht u mean by flow based and packet based ?? wen i configured two static routes towards same destination with same ad value the ping was something like !.!..!.! means it was dropping some packets ....can u xplain me why?? btw i used packet tracer.
07-01-2016 11:19 AM
so when we say flow based, it means that one flow (src and destination pair) will take the path from one particular link even if there are two paths available. With per-packet load-balancing, one packet is sent out from one interface and the other is sent out via the other.
I am not sure what your configuration is, but here is an example from may lab devices:
(1.1.1.1)R1 ======= R2 (2.2.2.2)
ip route 2.2.2.2 255.255.255.255 12.12.12.2
ip route 2.2.2.2 255.255.255.255 21.21.21.2
based on the above configuration, the routing table and CEF table would look like below:
Router#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 21.21.21.2
Route metric is 0, traffic share count is 1
12.12.12.2
Route metric is 0, traffic share count is 1
Router#
Router#
Router#ping 2.2.2.2 rep 100 source 1.1.1.1
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/2/4 ms
Router#sh ip cef 2.2.2.2
2.2.2.2/32
nexthop 12.12.12.2 GigabitEthernet0/1
nexthop 21.21.21.2 GigabitEthernet0/2
but the packet only flows out of one interface
Router#show ip cef exact-route 1.1.1.1 2.2.2.2 det
1.1.1.1 -> 2.2.2.2 =>IP adj out of GigabitEthernet0/1, addr 12.12.12.2
the above output shows that if we ping from 1.1.1.1 towards 2.2.2.2, the flow takes the packet out of Gi0/1 interface having the next-hop as 12.12.12.2
Hope this explains.
Regards
Vinit
07-01-2016 03:53 PM
Hi Vinit,
Load-balancing on Cisco routers is per-flow based and not per packet based.
To my best knowledge, at least on some platforms, this might actually be different. I believe that at least ISR G1 and G2 platforms support per-packet load balancing with CEF with the ip load-sharing per-packet interface command.
Best regards,
Peter
07-01-2016 06:41 PM
Hello Peter
Good to see you.. :) thanks for rectifying me.
I think i would edit my statement (based on most of the troubleshooting we do these days, its mostly hardware switched platforms and thus my thought process). per-packet load-balancing would be possible on software switched platforms like ISR G1/G2 but not on hardware switched platforms such as 7600, ASR1k, GSR (Engine 2 / Engine 5 line cards), ASR9k, etc.
Again, with software switched, it will be done at a cost of system resources and not a good option to go for.
Regards
Vinit
07-25-2016 06:42 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Again, with software switched, it will be done at a cost of system resources and not a good option to go for.
I haven't seen per-packet CEF forwarding make much of difference on small software based routers regarding system resource usage, but it does set you up for all the issues that might arise when a flow's packets are delivered out of sequence.
BTW, unlike per-packet CEF, MLPPP avoids the out-of-sequence packet delivery issues but it can cause system resource issues.
07-25-2016 04:45 AM
peter please share ur email id so that i can send u the pkt file ......as it is not allowing me to attach the file here.....in that file i have configured the topology with static route load balancing in which if we are pinging from pc to pc the packets are nt getting dropped but if we are pinging from router to pc or pc to router some packets are getting dropped...why is this happening i want to know.....
07-25-2016 04:53 AM
Hi,
Please try storing your PKT file into a ZIP archive and upload it here as a ZIP file.
Be cautioned that if you are doing your experiments in Packet Tracer, its behavior may be different (sometimes, significantly different) to real routers. It does not implement the IOS code, rather, it only mimics it - and every now and then, this simulation does not behave in the same way the real IOS does.
Best regards,
Peter
07-25-2016 07:04 AM
sir it is not uploading the zip file also .....plz suggest sme other way....
07-26-2016 06:09 AM
Hi,
I have sent you an e-mail to your GMail account - please check it out.
Best regards,
Peter
07-30-2016 07:28 AM
08-02-2016 12:09 AM
Hi,
I apologize for responding late - the last days have been busy for me.
The problem with your topology in Packet Tracer is that you did not configure the static routes always in the direction of the shortest path, and for some destinations, you have actually created routing loops that are the primary reason of your packet loss.
Take R1, for example, and the route to 192.168.2.0/24. There is only a single shortest path from R1 to 192.168.2.0/24, and that is from R1 to R2 directly. However, you have also configured R1 with a path to 192.168.2.0/24 through R3 which is not the shortest path - but R1 thinks that both these paths are equal.
On R3, you did the same, and you have configured R3 with two paths to 192.168.2.0/24, one through the R2, and one through the longer route through R1. R3 thinks that these two paths are equal even though they are not.
Packet Tracer does not seem to implement/emulate CEF, and what it appears to do is simple per-packet load balancing.
When you ping 192.168.2.1 from R1, it load balances its packets through R2 and R3. Packets sent to R2 directly are properly received because to R2, 192.168.2.1 is on a directly connected network, but packets sent through R3 undergo the same load balancing procedure - some of them will be sent to R2, some of them will be sent back to R1 where they came from - and voila, you've got a routing loop.
This, in a somewhat simplified form, is the reason you are getting packet losses.
With static routes, it is possible to perform load balancing but only over equal-cost paths, and you must take care to always configure static routes in the "downstream" direction only, always following the shortest path to the destination and pointing back to routers that are upstream.
Best regards,
Peter
08-01-2016 12:15 AM
Hi Vinit,
I believe when you are Pinging from a Cisco router itself, the packets should be load-balanced per packet?
See the Cisco CEF book http://www.ciscopress.com/store/cisco-express-forwarding-9781587052361
saying "When a router generates packets locally, such as routing updates or pings, it will process-switch those packets. Process-switched packets are load shared on per-packet basis." in Chapter 6.
(You can simply check by running traceroute to the same destination, the first hop should alter.)
Best regards,
Milan
08-02-2016 12:17 AM
Hi Milan,
Agreed - documentation states firmly that packets locally originated on a router are process-switched, but I vaguely recall seeing on occassions that this did not seem to be entirely true, and some locally originated packets appeared to have been CEF-switched. I could never find out the exact rule.
Technically, there is no problem in subjecting even locally-originated packets to CEF switching, at least on software-based routers. It's just the question of the code path and the placement of the code that originates packets and hands them over to the transmit function. Software CEF is usually invoked from an interrupt handler, but its functions are nonetheless available to the entire IOS code (it's a monolithic kernel).
Best regards,
Peter
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