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@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.raym...@vocus.com.au<mailto:adam.raym...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to