[c-nsp] Restrictions on topology when running OSPF with thecustomer inside VRF

[Oliver Boehmer (oboehmer)]

Junaid <> wrote on Saturday, July 12, 2008 10:23 PM:

> Hi,
> 
> I need some clarification as to what topology in which we can run OSPF
> with our customer inside VRF. I ran OSPF on one PE-CE link in area 6.
> I could only see in my VRF/OSPF table the intra-area routes and
> external routes that were injected by the CE router via
> redistribution. The CE router was also connected to other customer
> routers via area 0 and other areas. In PE's VRF/OSPF routing table, I
> could not see any inter-area route nor other external routes that
> other customer routers were injecting via redistribution although I
> could see them in my (PE router's) OSPF database. Funny thing is, when
> I removed VRF configuration and configured OSPF with the customer in
> the global routing table, I was able to see all routes getting
> installed in the routing table. Consulting a book, I hit across the
> following:
> 
> "When backbone areas are used within a VPN customer topology, the only
> caveat to be aware
> of is that any site configured to run an OSPF backbone area must be
> attached directly with
> the MPLS VPN Superbackbone, either through a direct link or a virtual
> link. This is mandatory
> because the PE routers always act as Area Border Routers (ABRs) and
> need to be able to
> exchange intra-area information with other ABR or backbone area
> routers." 
> 
> Does this mean that the PE always need connectivity to Area 0? Is
> there any way around? What am I missing?

well, you don't miss anything. As mentioned in the quoted text, any
MPLS-VPN PE will always consider itself as an ABR, and, as such, will
ignore any summary LSAs arriving from a non-backbone area (the PE-CE in
area 6, in your case).
Rather than working with virtual links, I would just put the PE-CE link
into area 0, or use a different PE-CE routing protocol. Difficult to
recommend something without knowing the VPN customer's topology..

	oli