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

Manipulate the Advertising of same summary routes over OSPF from 2 routers within the same area 0 because of load sharing

Publication Date:  2012-07-27 Views:  44 Downloads:  0
Issue Description
Network Topology Type: (3G IP-RAN Network)
Network Topology old Situation as showing in attached “Slide 1”:
1. Portion of 3G NodeBs connect over MP-group PPP links (subnets mask=30) over CPOS interfaces to a single aggregator router (NE40-BSC).
2. Every NodeBs has “Application IP” like a loopback address with subnet mask=32.
3. Every NE40-BSC only advertise summary routes about the MP-group PPP links and NodeBs App. IPs, like the following example:
ospf 1
 asbr-summary 10.4.4.0 255.255.255.0
 asbr-summary 192.168.1.0 255.255.255.0 
Notice that:
a. You could notice the subnets overlapping between the first CPOS MP-group PPP links & the second one(example: subnet 10.4.4.0/30 on  CPOS1 while subnet 10.4.4.4/30 on  CPOS2 and so on).
b. Also, you could notice the subnets overlapping between the first CPOS attached NodeBs App. IPs & the second one (example: subnet 192.168.1.1/32 on CPOS1 while subnet 192.168.1.2/32 on CPOS2 and so on).
Network Topology new Situation as showing in “slide 2”:
1. Replace the NE40-BSC with 2 NE40E-BSC to add redundancy & loadsharing mechanism.
2. Distribute the CPOS interfaces on the old NE40-BSC on the new 2 NE40E-BSC.
a.As we can see the 1st CPOS on the NE40E-BSC-1.
b.2nd CPOS on the NE40E-BSC-1.
3. As we notice before the overlapping between the subnets of CPOSs MP-groups we have three option:
a.Don’t add the previous summary routes (rejected by the customer, as aggregation layer may learn thousands of routes from more than one BSC-room).
b.Rearrange the MP-groups over the 2 CPOS to divide everyone summary to 2 summary, (rejected by the customer, as it will require dozens of configuration on both OSN & NE40, which lead to longer cutover with high risky).
c.Use the same old summary routes on the 2 NE40E-BSC with some manipulation.
ospf 1
 asbr-summary 10.4.4.0 255.255.255.0
 asbr-summary 192.168.1.0 255.255.255.0
Alarm Information
Null
Handling Process
1. NE40E-BSC-1 advertise only summary routes with mask=24 about MP-groups PPP links & NodeBs App. IP, so it should be like the following in this example:
ospf 1
asbr-summary 10.4.4.0 255.255.255.0
asbr-summary 192.168.1.0 255.255.255.0
2. NE40E-BSC-2 advertise only summary routes with mask=24 about MP-groups PPP links & NodeBs App. IP, so it should be like the following in this example:
ospf 1
asbr-summary 10.4.4.0 255.255.255.0
asbr-summary 192.168.1.0 255.255.255.0
3. NE40E-BSC1 will also receive these summary routes over OSPF from NE40E-BSC-2 (Eth-trunk) 
display ip routing-table
10.4.4.0/24   O_ASE  150  2           D  NE40E-BSC-2(Eth-trunk)
192.168.1.0/24   O_ASE  150  2           D  NE40E-BSC-2(Eth-trunk) 
4. NE40E-BSC-2 will also receive these summary routes over OSPF  from NE40E-BSC-2 (Eth-trunk) 
display ip routing-table
10.4.4.0/24   O_ASE  150  2           D  NE40E-BSC-1(Eth-trunk)
192.168.1.0/24   O_ASE  150  2           D  NE40E-BSC-1(Eth-trunk) 
5. The first 4 steps will solve point 3 in the cause analysis, as if the NodeB traffic goes from Ne40E-RNC to wrong destination NE40E-BSC, NE40E-BSC will forward it to the other correct NE40E-BSC which have that NodeB (showing in slide 3).
6. For none existence subnets included in summary routes:
a. To compensate the loop, we should drop these traffic from the 2 NE40E-BSC to Null0 by adding static routes for the missing subnets for the 2 NE40E-BSC as in the following example (showing in slide 4):
ip route-static 10.4.4.251 30 null0
7. We have to protect the link between the 2 NE40E-BSC as possible, as if it goes down, this will prevent the 2 NE40E-BSC to correct the path of the loadsharing:
a. We should make that link as an Eth-trunk, so if one link of the Eth-trunk down, the other one should forward the traffic correctly
Note that: we may replace the OSPF peering between the 2 NE40E-BSC by as static routes for the summary routes to the other NE40E-BSC:
NE40E-BSC-1
ip route-static 10.4.4.0 24 Eth-Trunk(NE40E-BSC-2)
ip route-static 192.168.1.0 24 Eth-Trunk(NE40E-BSC-2)
NE40E-BSC-2
ip route-static 10.4.4.0 24 Eth-Trunk(NE40E-BSC-1)
ip route-static 192.168.1.0 24 Eth-Trunk(NE40E-BSC-1)
For the following reasons, it will prefer the these static routes over the OSPF routes transferred over RNC-Routers; also I tested in the lab:
1. As the 2 BSC Routers will receive the 2 summary routes that  transferring over RNC from each other, but with default Huawei preference = 150, because  it consider as an external OSPF(the received routes from RNC as following)
a. 10.4.4.0/24                  O_ASE  150  2           D  NE40E-RNC
b. 192.168.1.0/24           O_ASE  150  2           D  NE40E-RNC
2. If we add static summary routes between the 2 BSC Routers instead of OSPF peering, the 2 routers will have 2 static routes with default preference = 60. For example, NE40E-BSC-1 should have the following static routes in the routing table:
a. 10.4.4.0/24                  Static 60   0          RD  NE40E-BSC-2(Eth-trunk)
b. 192.168.1.0/24           Static 60   0          RD  NE40E-BSC-2(Eth-trunk)
3. If you compare the before result, you will find that static routes has better preference than External OSPF(O_ASE), which makes the 2 NE40E prefer the static routes over the summary OSPF that transfer over the RNC.
Root Cause
By choosing Use the same old summary routes on the 2 NE40E-BSC, we should take care of the following:
1. The 2 NE40E-RNC will receive a double  summary routes with same cost for 10.4.4.0/24 & 192.168.1.0/24 from the 2 NE40E-BSC as the following:
display ip routing-table
10.4.4.0/24   O_ASE  150  2           D  NE40E-BSC-1
                O_ASE  150  2           D  NE40E-BSC-2
192.168.1.0/24   O_ASE  150  2           D  NE40E-BSC-1
                    O_ASE  150  2           D  NE40E-BSC-2
2. Every NE40E-RNC will make loadsharing over the 2 NE40E-BSC.
3. For example, what if NE40E-RNC send traffic to 4.4.4.6/30 over the NE40E-BSC-1, we have to make sure that NE40E-BSC-1 forward again to NE40E-BSC-2 (showing in slide 3).
4. Another example, what if NE40E-RNC send traffic to 4.4.4.251/30 which doesn’t exit, over the NE40E-BSC-1 or NE40E-BSC-2, this may cause a routing loop between the NE40E-BSC till the TTL=0 and then dropped (showing in slide 4), we should prevent that loop.
Suggestions
Fully summary & suggestion included in the attached files.

END