[j-nsp] Multi Core on JUNOS?

Stepan Kucherenko twh at megagroup.ru
Fri Oct 23 05:11:23 EDT 2015



On 22.10.2015 22:37, Phil Shafer wrote:
> Stepan Kucherenko writes:
>> What else...oh, annotate ! It's clunky and not very easy to use.
> 
> Yes, annotate is a sore spot.  I made the grammar production:
> 
>      K_ANNOTATE annotate_target T_STRING
> 
> with the expectation that I'd be able to coerce a path into the
> target, but it didn't happen.  I should have done it as:
> 
>      K_ANNOTATE T_STRING annotate_target
> 
> and then allow anything as a target, like:
> 
>      cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address 1.2.3.4/5
> 
> but can't make that work without making a new command ("comment"?).
> 
>> I wish we could just add a comment in the end of a line instead, like
>> "set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and
>> then see "x.x.x.x/y //client X" and the same line when asking for
>> |display set.
> 
> We generate line comments in JUNOS, so we need to discard them (and
> comments before close braces) to prevent out-of-date comments from
> getting loaded as real annotations.
> 
> Hmm....  I should make a M-, keybinding to copy all arguments from the
> previous command so you can:
> 
>      [edit interfaces ge-0/0/0 unit 0]
>      cli# set family inet address 1.2.3.4/5
> 
>      [edit interfaces ge-0/0/0 unit 0]
>      cli# comment "Client X" [ESC-,]
> 
> and it will insert the "family inet address 1.2.3.4/5" from
> the previous "set" command.
> 
> This is similar to the existing M-. and M-/ bindings.

So when we say show interfaces ge-0/0/0.0 we'll see something like

family inet {
    /* Client X */
    address 1.2.3.4/5;
}

But let's say we want to add another address for another client

[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 6.7.8.9/10

[edit interfaces ge-0/0/0 unit 0]
сli# comment "Client Y" [ESC-,]

family inet {
    /* Client Y */
    address 1.2.3.4/5;
    address 6.7.8.9/10;
}

Correct ?

I was thinking of something like that:

[edit]
cli# set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 // Client X //

[edit]
cli# set interfaces ge-0/0/0.0 family inet address 6.7.8.9/10 // Client Y //

[edit]
cli# show interfaces ge-0/0/0.0
family inet {
address 1.2.3.4/5;   // Client X //
address 6.7.8.9/10;   // Client Y //
}

Or maybe set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 comment "Client X"  instead of "//", or /* Client X */ in "show" output, whatever, it'll be cosmetic anyway.

Basically the same as descr command but available at any hierarchy level for any element but which doesn't use a separate line. Configurations are way too big already and separate line comments will eat into precious screen real estate.


It'll be easier to parse, easier to work with, will stay in the configuration with the same rules as everything else, it'll be deleted after deleting the element it comments and it won't be necessary to say "edit interfaces ge-0/0/0.0" first to work with it, you'll be able to do it from top (inability to do that probably annoys me the most in annotate).




Maybe even something like 

set protocols bgp group ix-v4 type external import [ reject-some-prefixes ///don't like them// set-community //for further filtering// ] peer-as X neighbor 1.2.4.5 //location// export customers-only //please don't delete this//

then if we say show protocols bgp group ix-v4 we'll get:

type external;
import [ reject-some-prefixes ///don't like them// set-community //for further filtering// ];
peer-as X;
neighbor 1.2.4.5 //location// {
    export customers-only; //please don't delete this//
}


Or with |display set:

set protocols bgp group ix-iv type external
set protocols bgp group ix-iv import reject-some-prefixes ///don't like them//
set protocols bgp group ix-iv import set-community //for further filtering//
set protocols bgp group ix-iv peer-as X
set protocols bgp group ix-iv neighbor 1.2.4.5 //location// 
set protocols bgp group ix-iv neighbor 1.2.4.5 export customers-only //please don't delete this//

Makes sense ? 




More information about the juniper-nsp mailing list