[j-nsp] PE-CE issue with OSPF routes not getting into routing table

[Krasimir Avramski]

Hi,

The route from your output has DN bit set (Opt 0xa2) and it is loop
prevention mechanism as described in rfc4577.

More info from Juniper docs:
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

Best Regards,
Krasi

On Sun, Aug 26, 2018, 05:19 Raymond, Adam via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

> Hi,
>
>         Complex one, so I will try to describe this carefully.
>
>         I have a IPv4 layer 3 MP-BGP VPN. There are two PEs that have an
> OSPF adjacency to CEs inside the VPN. The VPN only has a single OSPF area:
> 0.0.0.0. An external route, 172.16.64.0/20, is inserted into the VPN
> (called IP_ASC_VPN_1) via redistribution from iBGP and into OPSF.
>         The slightly odd thing about this setup compared to a traditional
> VPN is that the PEs have devices connected to them that don't support
> dynamic routing - they are just node with a IP address and default gateway
> configured on them:
>
>   PE3 -- CE5
>   |
>   P --------------------------------------------------------------P
>   |                                                               |
>   P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
>         |                                                   |
>        Node                                                Node
>
> All of this works when all of the network is up and operational, but when
> the link from the P routers to the PEs breaks:
>   PE3 -- CE5
>   |
>   P --------------------------------------------------------------P
>   |                                                               |
>   P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
>          |                                                   |
>         Node                                                Node
>
> Then the Node closest to the break becomes unreachable from CE5. CE5 is
> also the router that inserts 172.16.64.0/20 into the VPN. I can log into
> PE1 by jumping from CE1 and see what is happening on that router. PE1 is
> still learning the 172.16.64.0/20 route via OSPF as you can see it in the
> OSFP database:
> araymond at PE1> show ospf database external extensive lsa-id 172.16.64.0
> instance IP_ASC_VPN_1
>     OSPF AS SCOPE link state database
>  Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
> Len
> Extern   172.16.64.0      172.16.49.68     0x80000001   192  0xa2 0xf2f1
> 36
>   mask 255.255.240.0
>   Topology default (ID 0)
>     Type: 2, Metric: 3000, Fwd addr: 0.0.0.0, Tag: 208.0.255.152
>   Aging timer 00:56:47
>   Installed 00:03:06 ago, expires in 00:56:48
>   Last changed 00:03:06 ago, Change count: 1
>
> where 172.16.49.68 is the router-id of PE2.
>
> The problem is that this route doesn't get added to the
> IP_ASC_VPN_1.inet.0 routing table. There seems to be something that makes
> this route ineligible, but I cannot figure out what it is. Can anyone help
> me with that?
>
> Regards,
>
> Adam Raymond | IP Platform Engineering Team Lead
>
> M: 0410 347 012   D: 03 8623 3638 | ext   E: Adam.Raymond at vocus.com.au
> <mailto:Adam.Raymond at vocus.com.au>
> P: +61 3 8613 3333  W: vocus.com.au
> A: 333 Collins Street, Melbourne, VIC 3000, Australia  |  Follow us:
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>