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

RPR negotiate fault when cutover 1G normal ring to 2.5G RPR ring

Publication Date:  2012-07-27 Views:  34 Downloads:  0
Issue Description
Old network with 1G normal ring :
NE40-1(old) ---- NE40-2(old )------NE40-3(old)-----NE40-1(old)
The topology after cutover to 2.5G RPR :
NE40-1(old)----Ne40-2(new)-------NE40-3(new)----NE40-4(new)-----NE40-1(old)
First we made a RPR connnection between NE40-4(new) and NE40-1(old),then between NE40-4(new) and NE40-3(new), found that the RPR between NE40-4(new) and NE40-3(new) runs well ,but NE40-4(new) can't see the ip address  of NE40-1(old) when we use "disp RPR ring"
information as following :
[ATS464-NE40-Rpr3/0/0]disp rpr ring                                              
Topology Information for Interface Rpr3/0/0 :                                   
  Nodes on the ring: 2, Default Ring: Outer Ring                                
  Current Topology Map                                                          
  MAC-Address       Hops   RID   Wrap   IP-Address       Nodename               
  00e0-fc7c-91f7      0     0      1    10.0.1.129       NA                     
  00e0-fc7c-8ae9      1     0      1    NA                    NA                     
  Dynamic Ring Selection Table                                                  
  RID      MAC-Address     IP-Address                                           
  Static Ring Selection Table                                                   
  RID      IP-Address                                                           
  Topology packet sent after every 5 seconds                                    
  (next pkt. after 2 sec.)  
Then we try to cutover the other device to 2.5G RPR ring ,found that all the other device can't get a normal connection to NE40-1(old),others are OK .
      
      
Alarm Information
Null
      
Handling Process
1. For reason 1. the chance is very low ,because all the links to NE40-1(old) can't be all go wrong at the same time , and we all use old link except NE40-4(new) to NE40-1(old) and NE40-3(new)
2. For reason 2 ,after we checked ,the configuraton is normal .
3. For reason 3 ,the SYNC light on the board all are normal .
4. We" disp version" on NE40-1(old) and other new NE40 ,the versions all show as follow : 
Huawei Versatile Routing Platform Software 
VRP (R) software, Version 3.10, RELEASE 2321 
          
But when we use" disp bootload", found that :
In the new routes :
Boot file on flash is: flash:/8011V100R002B03D021SP12Usr.bin .
Boot file on hard disk is: hd:/8011V100R002B03D021SP12Usr.bin .
Hard disk is the default boot device.
In the old route NE40-1 :
Boot file on flash is: flash:/8011v100r002b03d017usr.bin .
Boot file on hard disk is: hd:/8011v100r002b03d017usr.bin .
Hard disk is the default boot device.
It is not the same .after we upgrade to 8011V100R002B03D021SP12Usr.bin, all RPR connections  run well .
                               
      
      
Root Cause
possible reasons:
1. the link resource is not good . 
2. the IP address are not in one segment , or with wrong mask . 
3. the two RPR boards are not synchronized.
4. the software .
Suggestions
 Null
      

END