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 Protocol Route Floods Wrongly

Publication Date:  2012-07-27 Views:  52 Downloads:  0
Issue Description
Narrowband users at 4XXX of A site cannot access network. The network segment X.21.172.0/24 � X.21.175.0/24 is problematic. Locate with tracert and find that the route reaches the egress of MAN CXXXX2 and cannot be at upstream. Check route table at CXXXX6 and there is no route information of four C network segments. Check through show ip ospf database External X.21.172.0 and match TYPE 5 LSA. Temporarily add four static route and link CXXXX2. The problem is temporarily solved.
Alarm Information
Null
Handling Process
Delete rollup route at CXXXX2 and then threw is detailed route about problematic network at CXXXX6 and inter-domain route of FA address, the problem is solved. 
 CXXX6>show ip route X.134.126.39
Routing entry for X.134.126.32/27
  Known via "ospf 100", distance 110, metric 62, type inter area
  Last update from 202.99.226.137 on POS2/7, 01:16:43 ago
  Routing Descriptor Blocks:
  * X.21.129.2, from X.21.154.242, 01:16:43 ago, via POS7/0
      Route metric is 62, traffic share count is 1
    X.99.226.133, from X.21.154.242, 01:16:43 ago, via POS2/8
      Route metric is 62, traffic share count is 1
    X.99.226.137, from X.21.154.242, 01:16:43 ago, via POS2/7
      Route metric is 62, traffic share count is 1
  
CXXXX6>show ip route X.21.172.0
Routing entry for X.21.172.0/24, 5 known subnets
  Variably subnetted with 2 masks
O E2    X.21.172.64/26 [110/20] via X.99.226.137, 01:38:01, POS2/7
                         [110/20] via X.99.226.133, 01:38:01, POS2/8
                         [110/20] via X.21.129.2, 01:38:01, POS7/0
O E2    X.21.172.0/26 [110/20] via X.99.226.137, 01:38:01, POS2/7
                        [110/20] via X.99.226.133, 01:38:01, POS2/8
                        [110/20] via X.21.129.2, 01:38:01, POS7/0
S       X.21.172.0/24 [1/0] via X.21.129.2
O E2    X.21.172.192/26 [110/20] via X.99.226.137, 01:38:01, POS2/7
                          [110/20] via X.99.226.133, 01:38:01, POS2/8
                          [110/20] via X.21.129.2, 01:38:01, POS7/0
O E2    X.21.172.128/26 [110/20] via X.99.226.137, 01:38:01, POS2/7
                          [110/20] via X.99.226.133, 01:38:01, POS2/8
                          [110/20] via X.21.129.2, 01:38:01, POS7/0
Why there is no problem before? 
Before MAN cutover of A site, X.134.126.39 at NE80 does not roll up. Inter-domain route of  X.134.126.32/27 can still be learnt at CXXXX6. The forwarding of problematic network segment is not influenced. The MAN cutover of A site rolls up this network. So there is external route of FA address at CXXXX6. External route is lost. 
Cancel ABR rollup of X.134.126.0 at NE80 to ensure the forwarding of route.
The main reason is that C4XXX uses direct network and re-distribute with redistribute connected command. Then there are two LSA advertisements.
Root Cause
(With X.21.172.64/26 as an example)
Check OSPF DATABASE at GXXXX2 and GXXXX6. It is found that LSA points to X.21.172.64, but GXXXX2 put this LSA into route table. GXXXX6 does not. 
GXXXX6>show ip ospf database external X.21.172.64
OSPF Router with ID (X.21.154.239) (Process ID 100)
   Type-5 AS External Link States
  LS age: 1768
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: X.21.172.64 (External Network Number )
  Advertising Router: X.21.154.32
  LS Seq Number: 80000002
  Checksum: 0x8D60
  Length: 36
  Network Mask: /26
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: X.134.126.39
        External Route Tag: 0
The forwarding of external route depends on Forward Address of DATABASE. Check related CISCO document, instructions are as follows: (Forward Address is short as FA)
OSPF is operated at next hop interface of ASBR;
The next hop interface of ASBR is not configured as passive interface; 
The next hop interface of ASBR is not OSPF P2P or P2MP;
The next hop interface address of ASBR is within network range of OSPF protocol; 
FA is written as 0.0.0.0 in other cases.
Narrowband users at C4XXX are not P2P, the value of Forward Address is written IP interface address, not 0.0.0.0. (According to the explanation of RFC2328: If forwarding address is set as 0.0.0.0, it should be forwarded to ASBR. If the forwarding address is not set as 0, check FA at route table. Matched route entry of FA must be within domain or path in the domain. If there is no proper entry, disable LSA. OSPF is a non-loop link protocol and inter-domain non-loop is guaranteed by SPT, but inter-domain non-loop is guaranteed by connection between non-backbone area and backbone area. It ensures the reliability of internal AS route computation. OSPF cannot control the reliability of external AS route information. FA itself is to forward external network. Use external route to iterate FA and compute, there may be problem in route. Forwarding external OSPF route with FA address learnt by external route is unreasonable. So FA must learn within the domain or interdomain.
Check CXXXX2 configuration of MAN of A site and find route list to X.134.126.39 of FA is:
CXXXX2>show ip route X.134.126.39
Routing entry for X.134.126.32/27
  Known via "ospf 100", distance 110, metric 61, type intra area
  Last update from X.138.107.126 on GigabitEthernet4/0, 01:26:39 ago
  Routing Descriptor Blocks:
  * X.138.107.126, from X.21.154.32, 01:26:39 ago, via GigabitEthernet4/0
      Route metric is 61, traffic share count is 1
But at CXXXX6 
 CXXXX6>show ip route X.134.126.39
Routing entry for X.134.126.32/27
  Known via "ospf 100", distance 110, metric 81, type extern 1
  Last update from X.21.129.2 on POS7/0, 01:16:25 ago
  Routing Descriptor Blocks:
  * X.99.226.137, from X.21.154.32, 01:16:25 ago, via POS2/7
      Route metric is 81, traffic share count is 1
    X.99.226.133, from X.21.154.32, 01:16:25 ago, via POS2/8
      Route metric is 81, traffic share count is 1
    X.21.129.2, from X.21.154.32, 01:16:25 ago, via POS7/0
      Route metric is 81, traffic share count is 1
CXXXX6 should have detailed route between the areas of X.134.126.32/27, in fact not. It has one external OSPF route of X.134.126.0/27. During the check of database, FA is learnt by external route. For the route of problematic network X.21.172.64/27, it is not be put in route table. Why there is not detailed route of X.134.126.32/27 at CXXXX6? Check at CXXXX2 and there is rollup at CXXXX2. Rollup X.134.126.0 as 24-bit mask and report, the type is inter-domain. It should be a proper FA address, but CXXXX6 receives external route of X.134.126.32/27 that is more accurate than 24-bit mask. During the check of FA address, regard X.134.126.32/27 as the basis and check and not put X.21.172.64/26 into route table.
Suggestions
1. Do not use redistribute connected and use network to distribute.
2. Use passive-interface x/x/x at OSPF, passive all interfaces that do not need establish neighbor with OSPF. Enable it not send OSPF Hello. Th ecommand of our products is silent-interface x/x/x .
 

END