Routing

in order to prevent loop,pe will attach down-bit in prefix advertised to CE,how to check this down-bit,I can't find it

 

 

 

 

 

Hi Rob,

 

You need to derive this from the Options value for that LSA.

 

suryak@CE2# run show ospf database logical-system sys1 lsa-id 6.6.6.6
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   6.6.6.6          172.169.1.1      0x80000002   570  0xa2 0x414a  36

 

0xa2 === 10100010

 

And the most significant bit is set 1 which indicates that DN bit.

 

The packet captue on PE-CE interface:

 

          LSA #2
          Advertising Router 172.169.1.1, seq 0x80000001, age 3600s, length 16
            External LSA (5), LSA-ID: 6.6.6.6
            Options: [External, Demand Circuit, Up/Down]
            Mask 255.255.255.255
                topology default (0), type 2, metric 0, tag 208.0.0.100
            0x0000: ffff ffff 8000 0000 0000 0000 d000 0064

 

Regrads

Surya

what confuse me a lot is : for external ospf,PE will add vpn tag to it,to prevent loop what is the difference between this mechanism and vpn tag?

Please refer Section 3 of RFC 4576

 

   When a PE generates an AS-external LSA, it could use a distinct tag
   value to indicate that the LSA is carrying information about an
   address prefix for whom the path includes a PE router.  However, this
   method is not available in the case where the PE generates a Summary
   LSA.  Per [VPN-OSPF], each PE router must function as an OSPF area 0
   router.  If the PE-CE link is an area 0 link, then it is possible for
   the PE to receive, over that link, a summary LSA that originated at
   another PE router.  Thus, we need some way of marking a summary LSA
   to indicate that it is carrying information about a path via a PE
   router.

 

suryak@CE2# run show route protocol ospf logical-system sys1    

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

6.6.6.6/32         *[OSPF/10] 00:03:22, metric 2
                    > to 172.169.1.1 via ge-3/1/3.0
10.10.10.10/32     *[OSPF/150] 00:03:22, metric 0, tag 3489661028
                    > to 172.169.1.1 via ge-3/1/3.0
10.255.178.58/32   *[OSPF/10] 00:03:22, metric 2
                    > to 172.169.1.1 via ge-3/1/3.0
172.168.1.0/30     *[OSPF/150] 00:03:22, metric 0, tag 3489661028
                    > to 172.169.1.1 via ge-3/1/3.0
224.0.0.5/32       *[OSPF/10] 1d 20:52:11, metric 1
                      MultiRecv

suryak@CE2# run show ospf database logical-system sys1          

Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *7.7.7.7          7.7.7.7          0x80000039  2476  0x22 0x70a   36
Router   172.169.1.1      172.169.1.1      0x80000039  2013  0x22 0xddb8  36
Network  172.169.1.1      172.169.1.1      0x80000037   814  0x22 0x5f82  32
Summary  6.6.6.6          172.169.1.1      0x80000001   217  0xa2 0x8ac0  28
Summary  10.255.178.58    172.169.1.1      0x80000001   217  0xa2 0x2943  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   10.10.10.10      172.169.1.1      0x80000001   217  0xa2 0x8af1  36
Extern   172.168.1.0      172.169.1.1      0x80000001   217  0xa2 0x8ec2  36

 

 

Regards

Surya

hmmm,Surya

 

I still can't get it

 

would u like to explain a little more

Hi Rob,

 

Basically in a VPN domain, we don't want a PE to re-advertise the BGP route back to BGP domain.

 

Please refer

http://tools.ietf.org/html/rfc4576#section-3

 

So if the routes from CE has OSPF-TAG macthing VPN-Route-Tag or D/N bit set, the PE will not advertise it as VPN prefix to BGP domain.

 

Regards

Surya

Hi,surya

 

I don't understand this part:

 

However, this
   method is not available in the case where the PE generates a Summary
   LSA.  Per [VPN-OSPF], each PE router must function as an OSPF area 0
   router.  If the PE-CE link is an area 0 link, then it is possible for
   the PE to receive, over that link, a summary LSA that originated at
   another PE router.    

 

 

it seems it say summary LSA can't use this route tag(which is used by external LSA)

Hi Rob,

 

By default, external lsa route can be tagged however the same is not available for summary lsa route.

Hence in case of summary lsa route we rely on D/N bit to avoid re-advertisement of core routes back to BGP domain.

 

Having said that, as per the RFC 4577, D/N bit can be used to avoid loop prevention in case of both Type-5/Type-3 LSA.

 

Section : 4.2.5

http://www.ietf.org/rfc/rfc4577.txt

 

Regards

Surya

I know that this blog post is not a Juniper specific post, but as your question is mainly about the function of the OSPF Down bit, I recommend you to take a look at:

 

http://blog.initialdraft.com/archives/2558/ - OSPF::Down Bit

 

Regards

Network Faculty

The configuration and inclusion of the VPN Route Tag is required for
   backward compatibility with deployed implementations that do not set
   the DN bit in type 5 LSAs.  The inclusion of the VPN Route Tag may be
   disabled by configuration if it has been determined that it is no
   longer needed for backward compatibility.

 

 

I think this is the reason

 

thanks for all the great posts

And JUNOS support the same

 

http://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/vpns-configuring-routing-between-pe-and-ce-routers-in-layer-3-vpns.html#id-10954391

 

To prevent routing loops when a domain ID is used as an alternate route preference for the OSPF or OSPFv3 external routes generated by the PE router, the DN bit of the LSA being distributed by the PE router must be set. If the route is distributed in a Type 5 LSA and the DN bit is not supported by the PE router, the VPN tag is used instead.

You can set a VPN tag for the OSPF external routes generated by the PE router to prevent looping. By default, this tag is automatically calculated and needs no configuration. However, you can configure the domain VPN tag for Type 5 LSAs explicitly by including the domain-vpn-tag statement:

• [edit routing-instances routing-instance-name protocols ospf]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

The range is 1 through 4,294,967,295 (2³² – 1). If you set VPN tags manually, you must set the same value for all PE routers in the VPN.

To clear the VPN tag when it is no longer needed (when the DN bit is supported on the PE router), include the no-domain-vpn-tag statement:

The DN bit is not currently supported in OSPFv3.

 

Regards

Surya

To prevent routing loops when a domain ID is used as an alternate route preference for the OSPF or OSPFv3 external routes generated by the PE router, the DN bit of the LSA being distributed by the PE router must be set. If the route is distributed in a Type 5 LSA and the DN bit is not supported by the PE router, the VPN tag is used instead.

You can set a VPN tag for the OSPF external routes generated by the PE router to prevent looping. By default, this tag is automatically calculated and needs no configuration. However, you can configure the domain VPN tag for Type 5 LSAs explicitly by including the domain-vpn-tag statement:

• [edit routing-instances routing-instance-name protocols ospf]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

The range is 1 through 4,294,967,295 (2³² – 1). If you set VPN tags manually, you must set the same value for all PE routers in the VPN.

To clear the VPN tag when it is no longer needed (when the DN bit is supported on the PE router), include the no-domain-vpn-tag statement:

The DN bit is not currently supported in OSPFv3.