Route load balancing

Unicast Load balancing


This cisco document has a good discussion on load balancing. In summary:

The number of paths used is limited by the number of entries the routing protocol puts in the routing table. Four entries is the default in IOS for most IP routing protocols with the exception of Border Gateway Protocol (BGP), where one entry is the default. Six different paths configured is the maximum number.

The IGRP and EIGRP routing processes also support unequal cost load-balancing.

show ip route command output to a particular subnet that has multiple routes. Notice there are two routing descriptor blocks. Each block is one route. There is also an asterisk (*) next to one of the block entries. This corresponds to the active route that is used for new traffic. The term 'new traffic' corresponds to a single packet or an entire flow to a destination, depending on the type of switching configured.

• For process-switching—load balancing is on a per-packet basis and the asterisk (*) points to the interface over which the next packet is sent.
  
• For fast-switching—load balancing is on a per-destination basis and the asterisk (*) points to the interface over which the next destination-based flow is sent.
  
  
  
  

  M2515-B# show ip route 1.0.0.0
  Routing entry for 1.0.0.0/8
    Known via "rip", distance 120, metric 1
    Redistributing via rip
    Advertised by rip (self originated)
    Last update from 192.168.75.7 on Serial1, 00:00:00 ago
    Routing Descriptor Blocks:
    * 192.168.57.7, from 192.168.57.7, 00:00:18 ago, via Serial0
        Route metric is 1, traffic share count is 1
      192.168.75.7, from 192.168.75.7, 00:00:00 ago, via Serial1
        Route metric is 1, traffic share count is 1

  
  BGP Multipath does not affect bestpath selection. For example, a router still designates one of the paths as the best path, according to the algorithm, and advertises this best path to its neighbors.
  These are the BGP Multipath features:
  
  
• eBGP Multipath—maximum-paths n
  
• iBGP Multipath—maximum-paths ibgp n
  
• eiBGP Multipath—maximum-paths eibgp n
  
  
  

  R5#show ip bgp vpnv4 vrf VPN_A 0.0.0.0
  BGP routing table entry for 100:1:0.0.0.0/0, version 9
  Paths: (2 available, best #1, table VPN_A)
  Multipath: eiBGP
  Flag: 0x820
   Not advertised to any peer
   103 101
     10.3.3.3 (metric 30) from 10.3.3.3 (10.3.3.3)
       Origin incomplete, metric 0, localpref 100, valid, internal, multipath, best
       Extended Community: RT:100:1
       mpls labels in/out nolabel/20
   107 106
     10.7.7.7 (metric 30) from 10.7.7.7 (10.7.7.7)
       Origin incomplete, metric 0, localpref 100, valid, internal, multipath
       Extended Community: RT:100:1
       mpls labels in/out nolabel/29

Multicast Load balancing

Having said this, when you are running PIM multicast in the network and you have two (or more) equal cost paths back to the  network, PIM will choose the path with this highest ip address. It will NOT load balance the traffic. The main reason for this is to prevent traffic from looping around.

BGP 4 Byte AS

Standard AS are 16 bits (2 bytes long). The new ASs are 4 bytes. They are represented in either these two formats:

ASDOT - <higher2bytes in decimal>.<lower2bytes in decimal>
                 eg: 1.10 = AS65546 or 0.1221 = AS1221

ASPLAIN - <32 bit number>
                    eg AS70000

BGP Peers negotiate with each other (using capability codes) if they support 4 byte AS. If a peer does not support the feature then it will see the new AS numbers as AS23456.

For example:

84.205.64.0/24 - 23456  18508 19151 1103 1125 23456  12654  (2 byte view)
                           393222 18508 19151 1103 1125 196613 12654 (4 byte view)

This means that the AS path length will always be the same.  

A side effect from the compatibility between OLD and NEW BGP speakers is that the usage of "23456" as the local BGP AS number is not possible. If an OLD BGP speaker would be configured to belong to AS23456, then this OLD BGP speaker will see other instances of AS23456 in the AS path and due to AS-Path loop detection drop the BGP routes. This would result in an incomplete view from the OLD BGP speaker perspective.

An additional side effect could be if the NEW BGP speaker belongs AS100.100 and the OLD BGP speaker to AS200. If the OLD BGP Speaker was wrongly configured as belonging to AS23456, then instead of an eBGP peering, an iBGP peering would be established. This would result in the wrong BGP behavior.

Netflow v9 supports 4 byte AS number reporting. IF you are using an older version of netflow then expect to see lots of AS23456.

 4 Byte AS is enabled by default.

BGP Path Selection

From ODOM:

N
WLLA
OMNI
RIP

0) N           - valid next-hop
1) W          - weight (highest) (default 0 - learned routes, 32768 - injected routes)
2) L           - local preference (highest) (default 100)
3) L           - locally injected routes (I<E<? where I was added by network command and ? was redistributed in)
4) A           - AS path (shortest)
5) O           - origin (IGP (i) < EGP (e) < Incomplete (?))
6) M          - med (lowest) (default 0)
7) N           - neighbour type (ebgp is better than ibgp)
8) I            - IGP metric for next hop is compared
9) R          - BGP Router ID (RID) (lowest)
10) IP       - IP Address of bgp session (lowest)