[c-nsp] OSPF equal cost load balancing

[James Bensley]

On 2 September 2017 at 07:21, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
>
> Just a quick update to this - Was in the process of converting 2 of the links to a port-chan (Removed IP address from the  port taking majority of the traffic (gi0/0/20), and noticed it started lad-balancing over the now "3" ECMP links far better:
>
>
> sh interfaces gigabitEthernet 0/0/21 | include 30 sec
>   30 second input rate 33251000 bits/sec, 8355 packets/sec
>   30 second output rate 265517000 bits/sec, 30692 packets/sec
> #sh interfaces gigabitEthernet 0/0/22 | include 30 sec
>   30 second input rate 26199000 bits/sec, 4643 packets/sec
>   30 second output rate 84239000 bits/sec, 13864 packets/sec
> #sh interfaces gigabitEthernet 0/0/23 | include 30 sec
>   30 second input rate 12839000 bits/sec, 3794 packets/sec
>   30 second output rate 56293000 bits/sec, 7668 packets/sec
>
> As soon as I re-add the 4th port, balancing goes to crap again, and all is sent via gi0/0/20:
>
>
> #sh interfaces gigabitEthernet 0/0/20 | include 30 sec
>   30 second input rate 16863000 bits/sec, 5516 packets/sec
>   30 second output rate 405225000 bits/sec, 52284 packets/sec
> #sh interfaces gigabitEthernet 0/0/21 | include 30 sec
>   30 second input rate 26944000 bits/sec, 4450 packets/sec
>   30 second output rate 3366000 bits/sec, 417 packets/sec
> #sh interfaces gigabitEthernet 0/0/22 | include 30 sec
>   30 second input rate 17212000 bits/sec, 3911 packets/sec
>   30 second output rate 6943000 bits/sec, 866 packets/sec
> #sh interfaces gigabitEthernet 0/0/23 | include 30 sec
>   30 second input rate 20943000 bits/sec, 4190 packets/sec
>   30 second output rate 518000 bits/sec, 94 packets/sec
>
> So, it does not like balancing over 4 links - 3 links is far better.
>
> So, I also tried reducing it to 2 links - And balance is also much better (Not perfect, but much better than with 4 links)
>
> sh interfaces gigabitEthernet 0/0/22 | include 30 sec
>   30 second input rate 57711000 bits/sec, 8997 packets/sec
>   30 second output rate 109940000 bits/sec, 20114 packets/sec
> sh interfaces gigabitEthernet 0/0/23 | include 30 sec
>   30 second input rate 40999000 bits/sec, 9508 packets/sec
>   30 second output rate 346398000 bits/sec, 35224 packets/sec
>
> sh interfaces gigabitEthernet 0/0/22 | include 30 sec
>   30 second input rate 52511000 bits/sec, 8699 packets/sec
>   30 second output rate 126974000 bits/sec, 21239 packets/sec
> sh interfaces gigabitEthernet 0/0/23 | include 30 sec
>   30 second input rate 37910000 bits/sec, 9901 packets/sec
>   30 second output rate 334954000 bits/sec, 34687 packets/sec
>
> If it can maintain those type of ratios, I can live with it.....why it doesnt like 4 ports, and originally didnt like 2 ports, but now appears to balance over 2 "better", Id love to know
>
> Cheers.

So weird. What IOS-XE version are you running on the ASR920? Based on
the output from your previous email it seems like a bug to me. When
you said FRR was also running I though that might be interfering.
We've had issues where when running feature X and Y, it mostly seems
to work with some minor issue, but actually the two features together
(after much TAC debating) aren't supported together and it isn't
documented anywhere that this combination isn't supported.

I'd been keen to see what TAC say, seems like a bug, I wonder if a
reboot of the ASR920 would have fixed this?

Perhaps you can squeeze some better commands out of TAC for
troubleshooting this sort of thing. You had multiple paths in CEF in
both software and hardware as far as I can tell (I'm not expert on the
ASR920). As far as I know there is no "test ..." command to test
load-balancing specifically on the ASR920.

Cheers,
James.