No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OSPF multipath load balance not achieve because of wrong preference value

Publication Date:  2012-07-27 Views:  42 Downloads:  0
Issue Description
For ensuring the reliability of WiMAX R6 interface (Access Switch BTS traffic to WiMAX WASN gateway) we have implemented OSPF routing protocol. In the Access Switch part already running OSPF 1 (process 1) with other HUB/Aggregation switch for BTS traffic. For that, ensuring this reliability we implement OSPF new process (OSPF 10) with WASN.
Our Topology is attached.
But for the simplified purpose, need to know the following points:

1.All BTS IP is 172.16.0.0/16
2.Acc-SW communicate with WASN using OSPF 10 process. WASN to Access switch communication IP block is 192.168.100.0/24 & 192.168.200.0/24.
3.The ACC-SW01 to ACC-SW02 communicate with OSPF 1 process and All BTS IP 172.16.0.0/16 is learn from OSPF 1 process.
4. Loopback ip of Access_SW01(DH0001_S9306) is 192.168.255.1/32 & Access_SW02(DH0001_S9303) is 192.168.255.2/32

Configuration in Access Switch 9306 [DH0001_S9306]

route-policy wimax_bts permit node 10
if-match ip-prefix BTS1

ip ip-prefix BTS1 index 20 permit 172.16.0.0 16

ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.3

ospf 10
import-route static type 2 route-policy wimax_bts
area 0.0.0.0
network 192.168.100.0 0.0.0.255
network 192.168.200.0 0.0.0.255

ip route-static 172.16.0.0 255.255.0.0 NULL0 preference 255

Configuration in Access Switch 9303[DH0001_S9303]

route-policy wimax_bts permit node 10
if-match ip-prefix BTS1

ip ip-prefix BTS1 index 20 permit 172.16.0.0 16

ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.3

ospf 10
import-route static type 2 route-policy wimax_bts
area 0.0.0.0
network 192.168.100.0 0.0.0.255
network 192.168.200.0 0.0.0.255

ip route-static 172.16.0.0 255.255.0.0 NULL0 preference 255

After configure this OSPF with Access switch with WASN following problematic issue is observe, All forwarding traffic (Feedback from WASN is goes only ACC-SW01[DH0001_S9306] no traffic goes to ACC-SW02[DH0001_S9303]. So the OSPF multipath load balance is not achieved.



 


Alarm Information
Null
Handling Process
We modify this static backhole route preference 255 to 149, in both Access LAN Switch then both learn the BTS IP block from itself. So, multipatch advertisement is happen.

ip route-static 172.16.0.0 255.255.0.0 NULL0 preference 149.

Root Cause

From the WASN we have observed the BTS block learn from only one Access_SW01(DH0001_S9306), Below is the WASN output
disp ospf lsdb
AS External Database
External 172.16.0.0 192.168.255.1 164 36 80000438 1
disp ospf routing
Routing for ASEs
Destination Cost Type Tag NextHop AdvRouter
172.16.0.0/16 1 Type2 1 192.168.100.2 192.168.255.1
172.16.0.0/16 1 Type2 1 192.168.200.2 192.168.255.1

Output from Access_SW01(DH0001_S9306)
disp ospf lsdb
OSPF Process 10 with Router ID 192.168.255.1
Link State Database

AS External Database
Type LinkState ID AdvRouter Age Len Sequence Metric
External 172.16.0.0 192.168.255.1 1565 36 80000437 1
[here 192.168.255.1 is the loopback ip of DH0001_S9306, it had learn the BTS block from itself because of static blackhole route]


Output from Access_SW02(DH0001_S9303)
disp ospf lsdb

OSPF Process 10 with Router ID 192.168.255.2
Link State Database
External 172.16.0.0 192.168.255.1 79 36 80000438 1

Here we observe though the 172.16.0.0/16 have null 0 route in Access_SW02(DH0001_S9303) but still it learn this route from Access_SW01 via WASN.

Cause: When Access_Switch_01(DH0001_S9306) advertise this block to WASN, WASN learn this route via OSPF_ASE (preference 150). This is normal. But the Access_Switch_02(DH0001_S9303) learn this BTS block from Access_Switch_01(DH0001_S9306) via WASN , though the static backhole route (ip route-static 172.16.0.0 255.255.0.0 NULL0 preference 255)is configured. It can not learn this network from it’s NULL0 interface because of preference issue. It learn the BTS block (172.16.0.0/16) from OSPF_ASE because of lower preference.

 


Suggestions
So, if we want to achieve the multipath load balance using any routing protocol, we need to think the all related attribute (like preference value) for avoiding this type of problem.

END