L3 MPLS VPN - Hub & Spoke with OSPF as PE-CE protocol

Unanswered Question
Mar 5th, 2009
User Badges:

Hi all,

This question regards a very specific corner of the OSPF PE-CE implementation in Hub & Spole topology on L3 MPLS VPN

Concerning the area of ospf on each and every pe-ce connection between the spokes and the hub CE's to the PE's.

In this scenarion a single vrf is configured per CE-PE and 2 vrf are configured for Hub-PE & Hub-CE connection

one vrf for import ,and one for export.

on all PE-CE links i have OSPF configured.

each connection is in a differnet OSPF area.

Alegedly, there should not be any problem - it shoudln't matter which ospf area is configured on the links - except in the case of Hub-PE to Hub-CE connection. - and here is why....

from now on i'm refering only to the HUB-PE vrf's.(import &export)

The OSPF instance under the import vrf is redistributing routes from BGP to OSPF and advertises them to the HUB-CE.

in the case of L3 vpn there is a special behaviour that makes the HUB-PE ospf vrf instance become ABR area 0 in order to advertise routes learned from the BGP to OSPF as internal T3 routes instead of external T5.

The Hub-CE accepts those routes as summary LSAs and advertises them as T3 to his neighbors in the same area !!

***know that the OSPF area on both vrf is any area other then area 0 !!

The OSPF instance on the export vrf is in the same area as the import vrf OSPF.

So, routes are advertised back to the OSPF instance on the export vrf.

However - those T3 lsa are not selected in the route table of the export VRF -they exist in the database , but they are not used as routes. -therefore the export vrf dosen't perform it's destiny and no prefixes from the spokes are returned back to the network through the HUB-PE.


When im configuring the OSPF area as 0 on both links of HUB-PE to HUB-CE it works.


LSAs are exactly the same and distribution is the same - the only differnce is the activation of those routes on the export vrf.


I've attached the layout of the network for easier understanding , and i've attached a CCIE MPLS example of this scenarion

You can see that in the CCIE example - there is area 0 configured in the HUB-PE HUB-CE links and not a different area.


this scenario is not regarding DN bit/route-type/domain-Tag ... on every implementation i've configured the same, and disabled the loop checking mechanism of OSPF(regarding the DN,route0type,domain-tag..and so on)


I haven't found any documentation regarding Hub & Spoke scenarios with attention to OSPF areas on the HUB links.


I've read RFC4577, and rosen-draft (ppvpn,ospf-bgp-mpls)but i haven't found any relation to that specific case.


In my opinion it is caused from wrong implementation of OSPF as PE-CE protocol on the vrf - and it requires OSPF area 0 connected to it.


LINK TO CCIE MPLS studycase : http://fengnet.com/book/IOS_MPLS/ch14lev1sec7.html


Best regards

Yuval



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Thu, 03/05/2009 - 07:51
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Yuval,


>> The Hub-CE accepts those routes as summary LSAs and advertises them as T3 to his neighbors in the same area !!


OSPF is supposed to do so.


But if area is <> 0 it doesn't work in your scenario.


about the MPLS superbackbone feature it requires the usage of area 0 for PE-CE links.


The OSPF PE-CE protocol is emulated using specialized extended communities and route targets to carry OSPF routes from site to site.

The best result you can achieve is to see the remote site routes as O IA routes.


http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ospf_un_sw_vrfs_ps6017_TSD_Products_Configuration_Guide_Chapter.html#wp1054074



for dealing with backdoor links between sites you need to use sham links


http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ospfshmk.html



You use two VRFs at HUB site to implement a Central Services: you want traffic coming from spokes to exit and then come back.


Probably you are right and you have hit a limitation of OSPF as PE-CE protocol.


However, I may be wrong but using OSPF area 0 on pe-ce links doesn't look like a great limitation


Hope to help

Giuseppe


mosheyuval Thu, 03/05/2009 - 15:34
User Badges:

Hello Giuseppe,


I'm familiar with sham links- there are helpful as you said in the case of backdoor links between 2 CE routers which are in the same area.

Regarding OSPF superbackbone - it is created when in fact we are using area 0 in PE-CE links(ppvpn rosen-draft), but this is not the case i've encountered.


According to documentation there is no limitation to using areas <> 0 .

The only special behaviour is when redistributing routes from BGP to vrf ospf instance.

In that case the ospf router becomes an ABR router in area 0

in the case of the spoke links , we can use other areas , because the routes are advertised from the vrf ospf ABR area 0 towards the spoke-ce ospf area <>0 .

But when i want traffic to come back again to the import vrf ospf instance it should be advertised back to area 0 .


This is based on the assumption that configuring ospf under vrf it is automatically set as area 0 - even when there is no redistribution from BGP to ospf on the import vrf.


Perhaps in order to distinguish between ospf areas and to create that logical seperation on the PE router it is done that way.


Over all , i couldn't find any documentation to that behaviour.


and refarding the disadvantages of using area 0 - imagin an operation CE with OSPF as the routing protocol and he has all kind of areas configured - and he wants to implement HUB &SPOKE between different areas - it will cause a serious problem - because he doesn't want any routes from area 0 leaking to other areas through the IPVPN network to all other spokes.



Thank you for your help.


Best regards

Yuval

Actions

This Discussion