Re: [j-nsp] set-style config output format is missing some aspects of the configuration

2022-05-18 Thread Alexa Aev via juniper-nsp 

Hello,
Annotate is so 20 century :-)
You can use "apply-macro" feature, it allows multiple param-value pairs 
where value can be free text and is reflected in set format.

Thanks
Alex

On 18 May 2022 17:17:48 (+01:00), Chuck Anderson via juniper-nsp wrote:

> "show configuration | display set" is missing some aspects of the
> configuration, namely annotations (comments). What else is it
> missing? Would Juniper please consider making the entire
> configuration representable in set-style format, including
> annotations?
>
> It is handy for example to annotate prefix-list items, but you can
> apply annotate on almost any part of the configuration:
>
> --
> {master:0}[edit]
> user@router# edit policy-options prefix-list FOO
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# show
> 10.1.1.1/32;
> 20.2.2.2/32;
> 30.3.3.3/32;
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# annotate 10.1.1.1/32 "server 1"
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# annotate 20.2.2.2/32 "peer 2"
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# annotate 30.3.3.3/32 "bad guy 3"
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# show
> /* server 1 */
> 10.1.1.1/32;
> /* peer 2 */
> 20.2.2.2/32;
> /* bad guy 3 */
> 30.3.3.3/32;
>
> {master:0}[edit]
> user@router# top
>
> {master:0}[edit]
> user@router# show | find FOO
> prefix-list FOO {
> /* server 1 */
> 10.1.1.1/32;
> /* peer 2 */
> 20.2.2.2/32;
> /* bad guy 3 */
> 30.3.3.3/32;
> }
> }
>
> {master:0}[edit]
> user@router# show policy-options prefix-list FOO | display set
> set policy-options prefix-list FOO 10.1.1.1/32
> set policy-options prefix-list FOO 20.2.2.2/32
> set policy-options prefix-list FOO 30.3.3.3/32
> --
>
> Tagging configuration items with "deactivate" or "protect" does show
> up in set-style:
>
> --
> {master:0}[edit]
> user@router# edit policy-options prefix-list FOO
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# deactivate 20.2.2.2/32
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# protect 30.3.3.3/32
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# show
> /* server 1 */
> 10.1.1.1/32;
> /* peer 2 */
> inactive: 20.2.2.2/32;
> /* bad guy 3 */
> protect: 30.3.3.3/32;
>
> {master:0}[edit policy-options prefix-list FOO]
> user@router# show | display set
> set policy-options prefix-list FOO 10.1.1.1/32
> set policy-options prefix-list FOO 20.2.2.2/32
> deactivate policy-options prefix-list FOO 20.2.2.2/32
> set policy-options prefix-list FOO 30.3.3.3/32
> protect policy-options prefix-list FOO 30.3.3.3/32
> --
>
> So why not "annotate"?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] set-style config output format is missing some aspects of the configuration

2022-05-18 Thread Chuck Anderson via juniper-nsp 
"show configuration | display set" is missing some aspects of the
configuration, namely annotations (comments).  What else is it
missing?  Would Juniper please consider making the entire
configuration representable in set-style format, including
annotations?

It is handy for example to annotate prefix-list items, but you can
apply annotate on almost any part of the configuration:

--
{master:0}[edit]
user@router# edit policy-options prefix-list FOO

{master:0}[edit policy-options prefix-list FOO]
user@router# show
10.1.1.1/32;
20.2.2.2/32;
30.3.3.3/32;

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 10.1.1.1/32 "server 1"

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 20.2.2.2/32 "peer 2"

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 30.3.3.3/32 "bad guy 3"

{master:0}[edit policy-options prefix-list FOO]
user@router# show
/* server 1 */
10.1.1.1/32;
/* peer 2 */
20.2.2.2/32;
/* bad guy 3 */
30.3.3.3/32;

{master:0}[edit]
user@router# top

{master:0}[edit]
user@router# show | find FOO
prefix-list FOO {
/* server 1 */
10.1.1.1/32;
/* peer 2 */
20.2.2.2/32;
/* bad guy 3 */
30.3.3.3/32;
}
}

{master:0}[edit]
user@router# show policy-options prefix-list FOO | display set
set policy-options prefix-list FOO 10.1.1.1/32
set policy-options prefix-list FOO 20.2.2.2/32
set policy-options prefix-list FOO 30.3.3.3/32
--

Tagging configuration items with "deactivate" or "protect" does show
up in set-style:

--
{master:0}[edit]
user@router# edit policy-options prefix-list FOO

{master:0}[edit policy-options prefix-list FOO]
user@router# deactivate 20.2.2.2/32

{master:0}[edit policy-options prefix-list FOO]
user@router# protect 30.3.3.3/32

{master:0}[edit policy-options prefix-list FOO]
user@router# show
/* server 1 */
10.1.1.1/32;
/* peer 2 */
inactive: 20.2.2.2/32;
/* bad guy 3 */
protect: 30.3.3.3/32;

{master:0}[edit policy-options prefix-list FOO]
user@router# show | display set
set policy-options prefix-list FOO 10.1.1.1/32
set policy-options prefix-list FOO 20.2.2.2/32
deactivate policy-options prefix-list FOO 20.2.2.2/32
set policy-options prefix-list FOO 30.3.3.3/32
protect policy-options prefix-list FOO 30.3.3.3/32
--

So why not "annotate"?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] VXLAN multi-site solution problem

2022-05-18 Thread niklas rehnberg via juniper-nsp 
Hi all,

I have two DCs that work as multi-site , IE all subnets are available in
both DCs.
Using spine/leaf setup, two spines (QFX1) on each site.
Using the Central GW setup, the spines are L3 GWs.
In the overlay BGP a filter has been included so the leafs see only their
own site spines, and will result in the traffic always using the nearest
spine to reach the WAN.
A design problem I have found now is if the return traffic to a leaf in
site1 comes via site2 spines.
The spine in site2 will add a vxlan header and send it leaf in site1, but
the leaf will drop the traffic as the spine is unknown (as I have designed
the solution).

I need suggestions on how to solve this.
A very easy way is to remove the filter so all leafs see all spine, but the
drawback will be that a leaf in site1 can use a spine in site2 as L3 GW.
Cisco has a solution called "VXLAN EVPN Multi-Site Design", I have not seen
any simulare example for juniper.

Thanks Niklas
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp