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>


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


The ignorence of the MPLS impact to a corporate's Intranet OSPF design caused routes lost

Publication Date:  2012-07-27 Views:  65 Downloads:  0
Issue Description
one customer bought our NE40 routers then made a network design by themself. They reported that their ABR NE40 routers lost their pop's routing info. They are using ospf internally. They were complaining our NE40 routers' functionalities.
The topology is attached. Chile, Peru, Montreal, Mexico are inter-connected by MPLS service provider. they are running ospf with MPLS service provider as CE router.
1. The NYC or backbone routers can see backbone routes as well as miami routers' area 7 routes.
2. The Chile, Mexico, Peru,Montreal routers as CE under MPLS network can see each other routes, but they can't see the upper backbone area 0 routes.
3. Customer put a default route in NYC, then redistributed it into ospf process, all routers can see the default routes.
Alarm Information
Showing Ip routing table in NYC NE40 router indicated just it has only the upper area 0 backbone routes as well as Miami area 7 routes except others.
Handling Process
1. since our NE40 routers can't support multi-process ospf, I have to merge the two area 0.
2. I can't force MPLS provider to creat a virtual link between NYC and Miami services providers' PE router, accordedly I had to change the links between Miami and NYC and miami between MPLS service provider's PE to be area 0.
3. MPLS service provider changed their Miami PE router vrf with our miami NE40 to be area 0, we can see other chile, mexico, peru, montreal pop's routing info right away in the upper backbone routers.
Root Cause
obviously all the issues are focused on the ABR ospf processing. so first of all, I checked the ABR ospf database.
1. Check ospf database of NYC NE40 ABR router, found there're snet records. Snet means inter-area lsa 3 type from Miami  router.
2. Why maima router has lsa 3 type since it's not a ABR. apparently the routes come from the routers under MPLS network cloud. they used network command to propogate their network segment, so it should be lsa 2 type, but we can see it became lsa 3 type in Miami router. it seems the mpls network changed the lsa type.
3. As far as I know the MPLS cloud is a super area 0 as long as ce is running ospf between PE. so the mpls could is a area 0, that's why we could see lsa 3 in miami router.
4. Right now it becomes clear that the problem is shooted in the inter-operability work with MPLS super area 0 and upper ospf area 0 above NYC router. for one ospf process, there are two non-consistent area 0. that's the key.
5.As far as the default route, it will be seen since it was redistributed into routing table as ospf external type 2 except stub , nssa areas.
1. be aware of the MPLS PE backbone's super area 0 availability in running ospf vrf.
2. Be aware of the NE40 VRP3.1 inability to support multi-ospf processes.
3. Redistributing direct network is also a walk-away methoad just in case.