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

Alexander Arseniev arseniev at btinternet.com
Sun Aug 26 05:22:32 EDT 2018


Hello,

LSA  172.16.64.0   has DN-bit set : "Opt 0xa2" xlates to 1010 0010

https://tools.ietf.org/html/rfc4576#page-4

As to whether You want DN bit cleared (which is possible) to fix Your 
problem - please carefully review Your design and make an informed 
decision afterwards, not before.

HTH

Thx

Alex


On 26/08/2018 03:18, Raymond, Adam via juniper-nsp 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



More information about the juniper-nsp mailing list