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

NE20 Enables OSPF at GRE Tunnel Interface and Interrupts at Scheduled Time

Publication Date:  2012-07-27 Views:  38 Downloads:  0
Issue Description
Topology: NE20A-----Partner's C6509A-----(IP network)-----Partner's C6509B-----NE20B
Two NE20 routers pass through public network and build GRE tunnel. They both configure default route to corresponding partner's device C6509. Two C6509 and intremediate network start OSPF protocol.
Phenomenon Description: Configure OSPF protocol at two NE20 and import static route and direct route. Divide in the same area and at tunnel interface enable (IP network segment network) OSPF.
It is found that the tunnel sometimes is problematic. It can be reachable in every one minutes and lasts few seconds.
Alarm Information
Null
Handling Process
1. Delete OSPF configuration at NE20. The interface of both sides of the tunnel can be pinged. It is related with OSPF configuration. 
2. In order that NE20 and OSPF device of public network not form loop after starting OSPF, Use process ID as 100 when starting OSPF at NE20. It is still problematic.
3. Delete the import of static route and it is still problematic. 
4. Delete the import of direct route and the problem is solved. Both sides of the tunnel can ping. Direct route results in the problem. 
5. Importing direct route at OSPF is to distribute local direct route to OSPF neighbor (device of another port of the tunnel). Private network segment connecting NE80 can be distributed through OSPF protocol. Route is learnt and the data of private network interconnects through tunnel. 
6. Reasons: set NE20A as example, besides private direct route, NE20A has the following two routes:
I Default route, the next hop points to direct interface address of C6509.
II Direct route of public network, destination address and next hop are direct interface of C6509. NE20A and NE20B build OSPF neighborhood through GRE tunnel (GRE tunnel route is loaded at route of public network, but it is regarded as direct route logically), and learn OSPF external route distributed by NE20B (including public route and private route). Besides default route, NE20A recognizes that it can reach the interface connecting NE20B and C6509B trough GRE tunnel. Regarding accurate match principle, the route learnt from NE20B is prior to default route, so NE20A chooses tunnel route when it accesses NE20B. In fact, GRE tunnel interface is logical interface. The tunnel is built based on reachable public network. Once the route of public network is discarded, the route of public network is not reachable and the tunnel interface cannot ping. Hello packet of OSPF cannot continue to send. With the lapse of death period (40S), OSPF dies. The route learnt from NE20B does not exist. Access NE20B and it chooses default route, tunnel interface can be pinged and OSPF neighborhood is built...it cycles, one period in every one minute. The problem occurs. 
7. Imparting direct route cannot be done. It can be replaced with the following ways:
I Enable interface of private network (network segment) and distribute route.
II Not use OSPF dynamic route protocol and configure static route.
Root Cause
1. OSPF configuration is false.
2. NE20 starts OSPF and route device of public network also starts OSPF. It can form route loop.
3. Imported route of OSPF results in route loop.
Suggestions
When configuring GRE tunnel, the route of related private network is configured with static one (simple and reliable). If it is configured with dynamic route protocol (OSPF or others), not impart direct route.

END