Re: OSPF in MPLS vpn

It does help. Really appreciate it.
Thanks,
-Carlos

Petr Lapukhov @ 09/04/2011 18:07 -0300 dixit:
> 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

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net