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

[Raymond, Adam via juniper-nsp]

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:
***@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: ***@vocus.com.au<mailto:***@vocus.com.au>
P: [phone] W: vocus.com.au
A: 333 Collins Street, Melbourne, VIC 3000, Australia | Follow us:



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

[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 <

Post by Raymond, Adam via juniper-nsp
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
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
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
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
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
P: [phone] W: vocus.com.au
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexander Arseniev via juniper-nsp]

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

Post by Raymond, Adam via juniper-nsp
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.
PE3 -- CE5
|
P --------------------------------------------------------------P
| |
P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
| |
Node Node
PE3 -- CE5
|
P --------------------------------------------------------------P
| |
P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
| |
Node Node
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
P: [phone] W: vocus.com.au
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jayaraj Shantharam]

Hi,Did you check the igp between the p and peRegards, Jay



From: "Raymond, Adam via juniper-nsp" &lt;juniper-***@puck.nether.net&gt;
Sent: Sun, 26 Aug 2018 07:49:35 GMT+0530
To: juniper-nsp &lt;juniper-***@puck.nether.net&gt;
Subject: [j-nsp] PE-CE issue with OSPF routes not getting into routing table

Hi,



&nbsp; &nbsp; &nbsp; &nbsp;Complex one, so I will try to describe this carefully.



&nbsp; &nbsp; &nbsp; &nbsp;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.

&nbsp; &nbsp; &nbsp; &nbsp;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:



&nbsp;PE3 -- CE5

&nbsp;|

&nbsp;P --------------------------------------------------------------P

&nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&nbsp;P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P

&nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&nbsp; &nbsp; &nbsp; Node &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;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:

&nbsp;PE3 -- CE5

&nbsp;|

&nbsp;P --------------------------------------------------------------P

&nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&nbsp;P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P

&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&nbsp; &nbsp; &nbsp; &nbsp;Node &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;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:

***@PE1&gt; show ospf database external extensive lsa-id 172.16.64.0 instance IP_ASC_VPN_1

&nbsp; &nbsp;OSPF AS SCOPE link state database

Type &nbsp; &nbsp; &nbsp; ID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Adv Rtr &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Seq &nbsp; &nbsp; &nbsp;Age &nbsp;Opt &nbsp;Cksum &nbsp;Len

Extern &nbsp; 172.16.64.0 &nbsp; &nbsp; &nbsp;172.16.49.68 &nbsp; &nbsp; 0x80000001 &nbsp; 192 &nbsp;0xa2 0xf2f1 &nbsp;36

&nbsp;mask 255.255.240.0

&nbsp;Topology default (ID 0)

&nbsp; &nbsp;Type: 2, Metric: 3000, Fwd addr: 0.0.0.0, Tag: 208.0.255.152

&nbsp;Aging timer 00:56:47

&nbsp;Installed 00:03:06 ago, expires in 00:56:48

&nbsp;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 &nbsp; D: 03 8623 3638 | ext &nbsp; E: ***@vocus.com.au&lt;mailto:***@vocus.com.au&gt;

P: [phone] &nbsp;W: vocus.com.au

A: 333 Collins Street, Melbourne, VIC 3000, Australia &nbsp;| &nbsp;Follow us:







_______________________________________________

juniper-nsp mailing list juniper-***@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jayaraj Shantharam]

Hi, I did not read this mail. The dn bit is set indicating routing loop Regards, Jay



From: Krasimir Avramski &lt;***@smartcom.bg&gt;
Sent: Sun, 26 Aug 2018 14:47:33 GMT+0530
To: "Raymond, Adam" &lt;***@nextgengroup.com.au&gt;
Subject: Re: [j-nsp] PE-CE issue with OSPF routes not getting into routing table

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 &lt;

juniper-***@puck.nether.net&gt; wrote:



&gt; Hi,

&gt;

&gt; &nbsp; &nbsp; &nbsp; &nbsp; Complex one, so I will try to describe this carefully.

&gt;

&gt; &nbsp; &nbsp; &nbsp; &nbsp; I have a IPv4 layer 3 MP-BGP VPN. There are two PEs that have an

&gt; OSPF adjacency to CEs inside the VPN. The VPN only has a single OSPF area:

&gt; 0.0.0.0. An external route, 172.16.64.0/20, is inserted into the VPN

&gt; (called IP_ASC_VPN_1) via redistribution from iBGP and into OPSF.

&gt; &nbsp; &nbsp; &nbsp; &nbsp; The slightly odd thing about this setup compared to a traditional

&gt; VPN is that the PEs have devices connected to them that don't support

&gt; dynamic routing - they are just node with a IP address and default gateway

&gt; configured on them:

&gt;

&gt; &nbsp; PE3 -- CE5

&gt; &nbsp; |

&gt; &nbsp; P --------------------------------------------------------------P

&gt; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&gt; &nbsp; P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P

&gt; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&gt; &nbsp; &nbsp; &nbsp; &nbsp;Node &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Node

&gt;

&gt; All of this works when all of the network is up and operational, but when

&gt; the link from the P routers to the PEs breaks:

&gt; &nbsp; PE3 -- CE5

&gt; &nbsp; |

&gt; &nbsp; P --------------------------------------------------------------P

&gt; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&gt; &nbsp; P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P

&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |

&gt; &nbsp; &nbsp; &nbsp; &nbsp; Node &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Node

&gt;

&gt; Then the Node closest to the break becomes unreachable from CE5. CE5 is

&gt; also the router that inserts 172.16.64.0/20 into the VPN. I can log into

&gt; PE1 by jumping from CE1 and see what is happening on that router. PE1 is

&gt; still learning the 172.16.64.0/20 route via OSPF as you can see it in the

&gt; OSFP database:

&gt; ***@PE1&gt; show ospf database external extensive lsa-id 172.16.64.0

&gt; instance IP_ASC_VPN_1

&gt; &nbsp; &nbsp; OSPF AS SCOPE link state database

&gt; &nbsp;Type &nbsp; &nbsp; &nbsp; ID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Adv Rtr &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Seq &nbsp; &nbsp; &nbsp;Age &nbsp;Opt &nbsp;Cksum

&gt; Len

&gt; Extern &nbsp; 172.16.64.0 &nbsp; &nbsp; &nbsp;172.16.49.68 &nbsp; &nbsp; 0x80000001 &nbsp; 192 &nbsp;0xa2 0xf2f1

&gt; 36

&gt; &nbsp; mask 255.255.240.0

&gt; &nbsp; Topology default (ID 0)

&gt; &nbsp; &nbsp; Type: 2, Metric: 3000, Fwd addr: 0.0.0.0, Tag: 208.0.255.152

&gt; &nbsp; Aging timer 00:56:47

&gt; &nbsp; Installed 00:03:06 ago, expires in 00:56:48

&gt; &nbsp; Last changed 00:03:06 ago, Change count: 1

&gt;

&gt; where 172.16.49.68 is the router-id of PE2.

&gt;

&gt; The problem is that this route doesn't get added to the

&gt; IP_ASC_VPN_1.inet.0 routing table. There seems to be something that makes

&gt; this route ineligible, but I cannot figure out what it is. Can anyone help

&gt; me with that?

&gt;

&gt; Regards,

&gt;

&gt; Adam Raymond | IP Platform Engineering Team Lead

&gt;

&gt; M: 0410 347 012 &nbsp; D: 03 8623 3638 | ext &nbsp; E: ***@vocus.com.au

&gt; &lt;mailto:***@vocus.com.au&gt;

&gt; P: [phone] &nbsp;W: vocus.com.au

&gt; A: 333 Collins Street, Melbourne, VIC 3000, Australia &nbsp;| &nbsp;Follow us:

&gt;

&gt;

&gt;

&gt; _______________________________________________

&gt; juniper-nsp mailing list juniper-***@puck.nether.net

&gt; https://puck.nether.net/mailman/listinfo/juniper-nsp

&gt;

_______________________________________________

juniper-nsp mailing list juniper-***@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

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