Using OSPF really complicates

promise kumalo · ‎01-05-2016

Hi all

i have 2 routers (R1 and R2) connected to each other using 2x 4Mb links from 2 different service providers. i have configured OSPF to load balance traffic on both links, but the router is not load balancing. it is sending all traffic to one link. Please see below the configurations for both routers.

####################### ROUTER A CONFIG ############################

no ipv6 cef

ip source-route
ip cef
!
!
!
interface Loopback1
ip address 192.168.44.1 255.255.255.255
ip ospf network point-to-point
!
interface Tunnel0
bandwidth 4096
ip address 20.20.20.10 255.255.255.252
ip mtu 1600
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip tcp adjust-mss 1360
ip ospf mtu-ignore
tunnel source 10.255.9.41
tunnel mode ipip
tunnel destination 10.255.9.42
!
!
interface Tunnel3
bandwidth 4096
ip address 172.9.9.1 255.255.255.252
ip mtu 1600
ip tcp adjust-mss 1360
ip ospf mtu-ignore
tunnel source 10.255.9.10
tunnel mode ipip
tunnel destination 10.255.9.9
!

!
interface GigabitEthernet0/0
description xxxxxx
mtu 9000
ip address 10.255.9.10 255.255.255.252
ip ospf mtu-ignore
duplex auto
speed auto
!
interface GigabitEthernet0/1
description xxxxxxxx
mtu 9000
ip address 10.255.9.41 255.255.255.252
ip ospf mtu-ignore
duplex auto
speed auto
!

interface Vlan10
ip address 10.13.3.1 255.255.255.0 secondary
ip address 10.12.17.1 255.255.255.0
!

router ospf 221
area 13 nssa
redistribute connected subnets
redistribute static subnets
passive-interface default
no passive-interface Loopback1
no passive-interface Tunnel0
no passive-interface Tunnel2
no passive-interface Tunnel3
network 20.20.20.10 0.0.0.0 area 13
network 172.9.9.0 0.0.0.3 area 13
!
ip forward-protocol nd
!

!
ip route 168.58.205.1 255.255.255.255 10.12.17.206
ip route 168.58.209.0 255.255.255.0 10.12.17.209
!

##############################################################

################################# Router B Config ############################

ip ospf mtu-ignore
tunnel source 10.255.9.9
tunnel destination 10.255.9.10
tunnel mode ipip
end

interface Tunnel33
description xxxxxxxxxx
bandwidth 3072
ip address 20.20.20.9 255.255.255.252
ip mtu 1600
ip tcp adjust-mss 1360
ip ospf cost 10
ip ospf mtu-ignore
tunnel source 10.255.9.42
tunnel destination 10.255.9.41
tunnel mode ipip

interface GigabitEthernet0/2.1066
description Gweru-Liquid
encapsulation dot1Q 1066
ip address 10.255.9.9 255.255.255.252
ip ospf mtu-ignore
no cdp enable

interface GigabitEthernet0/2.3573
description Telone_gweru
encapsulation dot1Q 3573
ip address 10.255.9.42 255.255.255.252
ip flow ingress
ip flow egress
ip ospf mtu-ignore
no cdp enable

router ospf 221
log-adjacency-changes
area 13 nssa default-information-originate no-summary
passive-interface default
no passive-interface Loopback5
no passive-interface Tunnel33
no passive-interface Tunnel62
network 20.20.20.9 0.0.0.0 area 13
network 172.9.9.0 0.0.0.3 area 13
maximum-paths 3
default-information originate

#####################################################################

ROUTER B#sh ip route 10.12.17.206
Routing entry for 10.12.17.0/24
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 10
Last update from 172.9.9.1 on Tunnel62, 01:47:06 ago
Routing Descriptor Blocks:
* 172.9.9.1, from 192.168.44.1, 01:47:06 ago, via Tunnel62
Route metric is 20, traffic share count is 1

Mark Malone · ‎01-05-2016

Hey

If the metrics don't match exactly with ospf it wont load balance as the LSDB will prefer the better path as its equal cost LB, so the route path of both links has to have a metric of 20 and distance of 110 etc for that route, setting cost and things like that will manipulate the metrics as well and make them uneven

Your going across 2 ISPs its unlikely they have exact same physical media etc , if you lab that up between 2 Cisco switches it will prob LB ok , the fact your going out across ISPs is what more than likely causing the issue as there metrics/path are unlikely equal. Shut down one link and when the other takes over see if they have the same values for that route this should highlight where the issue is

If you want unequal cost LB use EIGRP with variance

promise kumalo · ‎01-05-2016

Hi Mark

i have done a show ip route with both links open, and another show ip route with best path shut. below are the results. below i have put in bold the difference i can see in the forward metric. how can i manipulate that so that they are equal?

ROUTER A#sh ip route 192.168.44.1
Routing entry for 192.168.44.1/32
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 10
Last update from 172.9.9.1 on Tunnel62, 1w6d ago
Routing Descriptor Blocks:
* 172.9.9.1, from 192.168.44.1, 1w6d ago, via Tunnel62
Route metric is 20, traffic share count is 1

ROUTER A#sh ip route 192.168.44.1
Routing entry for 192.168.44.1/32
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 42
Last update from 20.20.20.10 on Tunnel33, 00:00:00 ago
Routing Descriptor Blocks:
* 20.20.20.10, from 192.168.44.1, 00:00:00 ago, via Tunnel33
Route metric is 20, traffic share count is 1

Mark Malone · ‎01-06-2016

Hey

You can change your cost and distance but I don't think you can manipulate the forward metric, that metric is calculated based on the distance/calculation to reach the ABR/ASBR of the ISP that's why its so hard to LB across multiple providers with ospf on the wan. The forward metric is only used in E2 routes and base on whats upstream path

You could speak to them and explain what your trying to do they may be able to tweak something on their end to lower the metric but I don't think anything you change on your side will change the forward metric calculation.

Masoud Pourshabanian · ‎01-09-2016

Hello,

Did you change the output of show IP route?

ROUTER A#sh ip route 192.168.44.1 (the output is not for router B?)

192.168.44.1 is set on router A, but your output shows something else. Forward metric is the cost to ASBR router. Try to change IP ospf cost under interface tunnel to see whether any change on forwarding metric. If you make the forwarding metric equal, both routes will sit inside the routing table.

In tunnel 62

ip ospf cost (larger number) check the forwarding metric

Rolf Fischer · ‎01-10-2016

Forward metric is the cost to ASBR router. Try to change IP ospf cost under interface tunnel to see whether any change on forwarding metric. If you make the forwarding metric equal, both routes will sit inside the routing table.

In my previous post I tried to explain why this won't work in this special scenario.

RFC 2328 16.4. Calculating AS external routes
(3) Call the destination described by the LSA N.
(...)
this LSA describes an AS external path to destination N.
Examine the forwarding address specified in the AS-external-LSA.
This indicates the IP address to which packets for the destination should be forwarded.
If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself.
(...)
If the forwarding address is non-zero, look up the forwarding address in the routing table.
(...)

R2#show ip route 192.168.44.1
Routing entry for 192.168.44.1/32
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 10
Last update from 172.9.9.1 on Tunnel62, 00:00:34 ago
Routing Descriptor Blocks:
* 172.9.9.1, from 192.168.44.1, 00:00:34 ago, via Tunnel62
      Route metric is 20, traffic share count is 1

R2#show ip ospf int br
Interface    PID   Area            IP Address/Mask    Cost State Nbrs F/C
Tu62         221   13              172.9.9.2/30       10    P2P   1/1
Tu33         221   13              20.20.20.9/30      10    P2P   1/1

R2#show ip ospf border-routers
i 192.168.44.1 [10] via 172.9.9.1, Tunnel62, ASBR, Area 13, SPF 3
i 192.168.44.1 [10] via 20.20.20.10, Tunnel33, ASBR, Area 13, SPF 3

R2#show ip ospf database nssa-external 192.168.44.1
            OSPF Router with ID (172.9.9.2) (Process ID 221)
                Type-7 AS External Link States (Area 13)
Routing Bit Set on this LSA
LS age: 154
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 192.168.44.1 (External Network Number )
Advertising Router: 192.168.44.1
LS Seq Number: 80000002
Checksum: 0xC3E4
Length: 36
Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 172.9.9.1
        External Route Tag: 0

R2#show ip route 172.9.9.1
Routing entry for 172.9.9.0/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel62
      Route metric is 0, traffic share count is 1

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface Tu62
R2(config-if)#shut

%OSPF-5-ADJCHG: Process 221, Nbr 192.168.44.1 on Tunnel62 from FULL to DOWN, Neighbor Down: Interface down or detached

R2(config-if)#do show ip route 172.9.9.1
Routing entry for 172.9.9.0/30
Known via "ospf 221", distance 110, metric 34, type intra area
Last update from 20.20.20.10 on Tunnel33, 00:00:07 ago
Routing Descriptor Blocks:
* 20.20.20.10, from 192.168.44.1, 00:00:07 ago, via Tunnel33
      Route metric is 34, traffic share count is 1

R2(config-if)#do show ip route 192.168.44.1
Routing entry for 192.168.44.1/32
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 34
Last update from 20.20.20.10 on Tunnel33, 00:00:23 ago
Routing Descriptor Blocks:
* 20.20.20.10, from 192.168.44.1, 00:00:23 ago, via Tunnel33
      Route metric is 20, traffic share count is 1

To achieve load sharing for (NSSA) external networks in such a scenario you could try to achieve load sharing for the Forwarding Address network. It can be somewhat tendious to explain all the rules how the FA is elected, in this particular case you could make the IP address of a Looback interface OSPF-enabled. To demonstrate this, I create another Loopback interface on Router-A:

R1(config)#int loop0
R1(config-if)#ip addr 1.1.1.1 255.255.255.255

R1(config)#router ospf 221
R1(config-router)#network 1.1.1.1 0.0.0.0 area 13

R1#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost State Nbrs F/C
Lo0          221   13              1.1.1.1/32         1     LOOP 0/0
Tu3          221   13              172.9.9.1/30       24    P2P   1/1
Tu0          221   13              20.20.20.10/30     24    P2P   1/1

R2#show ip ospf database nssa-external 192.168.44.1
            OSPF Router with ID (172.9.9.2) (Process ID 221)
                Type-7 AS External Link States (Area 13)
Routing Bit Set on this LSA
LS age: 823
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 192.168.44.1 (External Network Number )
Advertising Router: 192.168.44.1
LS Seq Number: 80000005
Checksum: 0x94CC
Length: 36
Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 1.1.1.1
        External Route Tag: 0

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 221", distance 110, metric 11, type intra area
Last update from 172.9.9.1 on Tunnel62, 00:14:52 ago
Routing Descriptor Blocks:
    172.9.9.1, from 192.168.44.1, 00:14:52 ago, via Tunnel62
      Route metric is 11, traffic share count is 1
* 20.20.20.10, from 192.168.44.1, 00:14:53 ago, via Tunnel33
      Route metric is 11, traffic share count is 1

R2#show ip route 192.168.44.1
Routing entry for 192.168.44.1/32
Known via "ospf 221", distance 110, metric 20, type NSSA extern 2, forward metric 11
Last update from 20.20.20.10 on Tunnel33, 00:15:05 ago
Routing Descriptor Blocks:
* 172.9.9.1, from 192.168.44.1, 00:21:23 ago, via Tunnel62
      Route metric is 20, traffic share count is 1
    20.20.20.10, from 192.168.44.1, 00:15:05 ago, via Tunnel33
      Route metric is 20, traffic share count is 1

Rolf Fischer · ‎01-09-2016

Hi,

I guess you had your reasons to choose such a setup ...

that metric is calculated based on the distance/calculation to reach the ABR/ASBR

This is only true when the forwarding address of an (nssa) external LSA is set to 0.0.0.0, which is what we usually see in reguar areas.

However, in the case of an ASBR in a NSSA the forwarding address of self-generated Type-7 LSAs are always set to a non-zero IP address. You can see them in the output of the 'show ip ospf database nssa-external' command.

In your scenario, the only possible IPs for the forwarding addresses are the tunnel addresses, so even if the peer router has equal costs to the ASBR through both of the tunnel interfaces ('show ip ospf border-routers'), only the path through the tunnel with the network belonging to the forwarding address will be installed in the routing table.

This is much easier to explain by a practial example, so if still interested, share Router-B's output of the following commands:

show ip ospf border-routers

show ip ospf database nssa-external 192.168.44.1 ! (Router-A Loopback1)

show ip route <forwarding-address shown in the previous command>

HTH
Rolf

syed kazim abbas · ‎01-09-2016

Hi,

Its difficult to gain load balancing through OSPF. I have solution if you like. you can use PBR.

Regards,

Kazim Abbas

Philip D'Ath · ‎01-10-2016

Using OSPF really complicates this. Have you considered using the much simpler EIGRP?

Rolf Fischer · ‎01-10-2016

Using OSPF really complicates this.

Not really.

Redistributing connected networks [especially in a NSSA] and enabling OSPF only on the Tunnel interfaces is what complicates this.

IMHO not really a recommendable setup, but we don't know why the original poster decided to implement it this way ...

OSPF Load balancing not working