Re: OSPF in MPLS vpn

Carlos,

The reason why the PE ignores inter-area routes is OSPF's loop prevention
logic. To begin with, let's make two definitions:

1) ABR is an OSPF router that has an IP interface in OSPF area 0 (backbone)
and the interface is not in DOWN state (Cisco's definition, extended RFC
2328's)
2) Attached ABR is an ABR that has at least one FULL adjacency formed over
area 0 interface (compare this to ISIS ATT bit signaling)

Only ABRs are allowed to generate inter-area prefixes and inject them into
adjacent areas. Furthermore, attached ABR is required to ignore an
inter-area prefix learned across non-transit area. Area is considered
transit if it is either a backbone area or has virtual link across itself,
connecting the ABRs. The idea of this rule is to stop inter-area routes from
looping back into the backbone area. This rule effectively means the ABR
will not re-generate the inter-area prefix into other areas unless the
prefix was learned over a transit area. The corresponding LSA may still be
flooded within the area where it has been received, per the normal flooding
guidelines.

The above loop prevention rules are enough for a single backbone OSPF
deployment. With MPLS VPNs, you have two levels of backbones - one
super-backbone and "regular" backbone areas. Therefore, there is a need to
distinguish the ABR attached to normal backbone and super-backbone. There
are no "adjacency" in the super-backbone, but every time you associate OSPF
process with a VRF you tell it that is has a connection to it. An OSPF
process connected to super-backbone performs the following loop prevention
steps:

1) Ignores summary LSA for routing if they are not learned over a transit
area (either a super-backbone or regular OSPF transit area). This is in
accordance with normal OSPF loop prevention behavior. In the database, such
LSAs are displayed without the routing bit set. The routing bit is local
marking, not propagated in the LSA.
2) Ignores summary LSAs that have the DOWN bit set. This bit designates LSAs
learned from super-backbone - OSPF process adds this marking to LSAs
generates based on MP-BGP routes.
3) Ignores external LSA that have the route tag matching the local BGP
process number. OSPF process automatically sets the tag based on local BGP
process AS # for routes learned from MP-BGP and injected as external.

When you enable "capability vrf-lite" you effectively tell OSPF process that
there is no "super-backbone" connection. The router may still have
connection to "regular" area 0 and perform the basic loop prevention checks
as described above. If there is no "regular" area 0 present, the router
completely loses ABR status (per the definition above), and all of the
loop-prevention checks are ignored. This is normally done on vrf-lite CE
devices.

Lastly, disabling "capability vrf-lite" on a PE device is "safe", as long as
you don't have any topological loops, e.g. backdoor links. I have a more
detailed write-up on the loop prevention issues in OSPF plus some examples
in the following blog post:

http://blog.ine.com/2011/01/01/understanding-inter-area-loop-prevention-caveats-ospf-protocol/

HTH

-- 
Petr Lapukhov, petr_at_INE.com
CCIE #16379 (R&S/Security/SP/Voice)
CCDE #20100007
Internetwork Expert, Inc.
http://www.INE.com <http://www.ine.com/>
Toll Free: 877-224-8987
Outside US: 775-826-4344
2011/4/9 Carlos G Mendioroz <tron_at_huapi.ba.ar>
> Petr,
> yes, that's the issue, though I didn't fully understand how it works.
> Now it seems I got it, would like to check:
>
> Routes are coming to the PE2 as IA. As part of the vrf - OSPF integration,
> IA routes are assumed to come from another PE and
> get the routing bit cleared, thus no set in the RIB (iBGP should
> win).
>
> There is another way to fix this that is by setting capability vrf-lite.
> That disables the down bit and the clearing of the route bit.
> As long as you have sham links, this holds.
>
> Any downsides ?
> -Carlos
>
> Petr Lapukhov @ 08/04/2011 20:23 -0300 dixit:
>
>> Carlos,
>>
>> Not sure if I understand the topology correctly, but I see the situation
>> as PE2 ignoring the inter-area prefixes originated by CE2 and not
>> redistributing it into MP-BGP. This is a normal behavior, since PE devices
>> assume to be connected to the OSPF super-backbone, and therefore ignore the
>> inter-area prefixes for routing, though they still flood the corresponding
>> type-3 LSAs over the sham-link. You may resolve this issue by configuring a
>> virtual-link connecting CE2 and PE2 - this will connect area 0 and the
>> superbackbone.
>>
>> HTH
>> --
>> Petr Lapukhov, petr_at_INE.com
>> CCIE #16379 (R&S/Security/SP/Voice)
>> CCDE #20100007
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com <http://www.ine.com/>
>>
>> Toll Free: 877-224-8987
>> Outside US: 775-826-4344
>>
>> 2011/4/8 Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>>
>>
>>    Hi,
>>    I've run into a situation that is giving me a hard time :(
>>
>>    CE1 - PE1 ... PE2 - CE2 - R
>>
>>    CE-PE links are using OSPF area 1, CE2 - R is OSPF area 0.
>>    To get area 1 routes as intra area, a sham link is set between PE1
>>    and PE2.
>>
>>    Now here's the catch. R routes get to CE2 (an ABR) and type 3 LSRs
>>    do get to CE1 over the sham link. So CE1 sees R routes.
>>    But PE2 and PE1 do not.
>>
>>    I fail to understand why... wouldn't mind a litle help :)
>>
>>
>>    --     Carlos G Mendioroz  <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar
>> >>
>>
>>     LW7 EQI  Argentina
>>
>>
>>    Blogs and organic groups at http://www.ccie.net
>>
>>    _______________________________________________________________________
>>    Subscription information may be found at:
>>    http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> --
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net