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
Received on Wed May 04 2011 - 21:31:29 ART
This archive was generated by hypermail 2.2.0 : Wed Jun 01 2011 - 09:01:11 ART