Re: OSPF Down bit

Thanks Roy - If I am not running OSPF on both CE, do I still need to worry
about OSPF domain ID. For instance, If I am running OSPF between CE1 and PE1
and EIGRP between CE2 and PE2. Does I need to do match domain ID's.

Regards,

Bilal Hansrod

On Wed, May 4, 2011 at 10:59 PM, Roy Waterman <roy.waterman_at_gmail.com>wrote:

> Hi Bilal
>
> You are correct, PE1 sets the OSPF down bit on VPNv4 routes learned from
> PE2 (for those VPNv4 routes that carry the bgp extended community attribute
> identifying the routes are Type 3 LSA's).
> If you are going to test this, ensure that the domain ID's match on both
> PE's. If they don't match, all OSPF routes that were redistributed from OSPF
> into ipv4 vrf BGP on PE2, will be injected by PE1 as OSPF external routes.
> As external LSA's don't support the Down Bit, you will not see the Downward
> bit attached to such routes when viewing the ospf database for the route in
> question.
> To ensure the domain IDs match, either use the same OSPF process id on PE1
> & PE2 (*router 2 vrf xyz* on both eg), or manually set the same domain id
> under *router x vrf y* on both PE1 & PE2, using *domain-id a.b.c.d.*
>
> Hope this helps
>
> Regards
> Roy
> @routeleaker
>
> On 4 May 2011 12:31, Bilal Hansrod <bilal.hansrod_at_gmail.com> wrote:
>
>> Thank you Dr.Fleming & Gary, I just wanted to understand the traffic flow
>> and when is LSA is marked as DN. I read Cisco documentation and INE blog,
>> but unable to get my head around.
>>
>> For example:
>>
>> CE_A1 {OSPF} PE1{iBGP} -> P -> {iBGP) PE2 {OSPF} CE_A2 (1.1.1.0/24)
>>
>> CE_A1 is connected to PE1 via OSPF
>> PE1 is connected to PE2 via iBPG
>> PE2 is connected to CE_A2 via OSPF
>>
>>
>> So, if CE_A2 advertises 1.1.1.0/24 routes via OSPF to PE2. PE2 will
>> redistribute OSPF into MBGP and advertises to iBGP neighbour (PE1). The DN
>> bit will be set here after MBGP is redistributed into OSPF. Is this the
>> place when Down bit is set, to avoid loop. If somehow CE1 leaks to any PE
>> and if the down bit is enabled, than route will be discarded.
>>
>> I apologise if the above scenario is not very clear. I will also lab it
>> up,
>> but not sure if I can see Down bit via any show command or need to capture
>> via wireshark.
>>
>> Thanks again guys-
>>
>> Bilal Hansrod
>>
>>
>> On Wed, May 4, 2011 at 9:05 PM, garry baker <baker.garry_at_gmail.com>
>> wrote:
>>
>> > http://www.ietf.org/rfc/rfc4577.txt
>> >
>> > OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
>> Private
>> > Networks (VPNs)
>> > 4.1.5. Prevention of Loops
>> >
>> > If a route sent from a PE router to a CE router could then be
>> > received by another PE router from one of its own CE routers, it
>> > would be possible for routing loops to occur. To prevent this, a PE
>> > sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE
>> > ignores any LSA received from a CE that already has the DN bit sent.
>> > Older implementations may use an OSPF Route Tag instead of the DN
>> > bit, in some cases. See Sections 4.2.5.1 and 4.2.5.2
>> >
>> > 4.2.5. Loop Prevention
>> >
>> > 4.2.5.1. The DN Bit
>> >
>> > When a type 3 LSA is sent from a PE router to a CE router, the DN bit
>> > [OSPF-DN] in the LSA Options field MUST be set. This is used to
>> > ensure that if any CE router sends this type 3 LSA to a PE router,
>> > the PE router will not redistribute it further.
>> >
>> > When a PE router needs to distribute to a CE router a route that
>> > comes from a site outside the latter's OSPF domain, the PE router
>> > presents itself as an ASBR (Autonomous System Border Router), and
>> > distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be
>> > set in these LSAs to ensure that they will be ignored by any other PE
>> > routers that receive them.
>> >
>> > There are deployed implementations that do not set the DN bit, but
>> > instead use OSPF route tagging to ensure that a type 5 LSA generated
>> > by a PE router will be ignored by any other PE router that may
>> > receive it. A special OSPF route tag, which we will call the VPN
>> > Route Tag (see Section 4.2.5.2), is used for this purpose. To ensure
>> > backward compatibility, all implementations adhering to this
>> > specification MUST by default support the VPN Route Tag procedures
>> > specified in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. When it is no
>> > longer necessary to use the VPN Route Tag in a particular deployment,
>> > its use (both sending and receiving) may be disabled by
>> > configuration.
>> >
>> >
>> >
>> > --
>> > Garry L. Baker
>> >
>> > "With sufficient thrust, pigs fly just fine..." - RFC 1925
>> >
>> >
>> >
>> > On Wed, May 4, 2011 at 4:12 AM, Bilal Hansrod <bilal.hansrod_at_gmail.com
>> >wrote:
>> >
>> >> Hello Everyone,
>> >>
>> >> Can anyone kind enough to clarify my theoretical doubts about OSPF Down
>> >> bit.
>> >> This is what I believe; please correct me if I am wrong
>> >> CE1 advertise OSPF routes to PE1
>> >>
>> >> PE1 redistributes OSPF routes into MBGP
>> >>
>> >> PE2 redistributes MBPG routes into OSPF and set Down bit and advertises
>> to
>> >> CE2
>> >>
>> >> CE2 advertises back same route to PE1 via additional connection and it
>> is
>> >> discarded as Down bit is set to prevent loop.
>> >>
>> >>
>> >> The Down bit can only be set for LSA 2,3,7. LSA 5 doesn t support Down
>> >> bit,
>> >> so we use route tag to perform the same operation.
>> >>
>> >> Thanks,
>> >>
>> >> Bilal
>> >>
>> >>
>> >> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards
> Roy

Blogs and organic groups at http://www.ccie.net
Received on Thu May 05 2011 - 10:04:14 ART