Re: [j-nsp] DHCP SERVER in m7i

[Chad Myers]

I just dug through the dhcp server tracelog and old install logs.  It looks 
like I ran into that in 12.1R3 so it may not be a problem on 11.4.  When 
running with traceoptions, this is what I found in the log that pointed out the 
problem:
Aug  9 17:32:21 [NOTE]  jdhcpd_packet_handle: RECEIVE DISCOVER: stats_safd 0x0 
, safd 0x88fe000 ge-0/3/1.999
Aug  9 17:32:21 [NOTE] [ge-0/3/1.999] jdhcpd_packet_handle: -- Switchover 
recovery not completed-: dropping DISCOVER on ifindex 72

After it was fixed these appeared instead after the config was (re)loaded:
Aug 29 20:52:06.944830 Graceful Switchover not configured
Aug 29 20:52:06.944958 Maintain-subscriber not configured
Aug 29 20:52:06.948862 Config read ended in status 1
Aug 29 20:52:06.949652 === Reloading configuration DONE[1673] ===

As for the dhcp config itself, you don't need family iso for it.  The config 
looks ok, although it's missing some key entries like the gateway address.  
Here's what's on my device snippets from my device:
# the dhcp server itself.  The pool-match-order was to explicitly deal with 
running the server on multiple interfaces / subnets.
set system services dhcp-local-server pool-match-order ip-address-first
set system services dhcp-local-server group Lab-254 interface ge-0/3/1.254

# the dhcp pool; note the "range" option you were looking for
set access address-assignment pool lab-254 family inet network 192.168.254.0/24
set access address-assignment pool lab-254 family inet range 210-239 low 
192.168.254.210
set access address-assignment pool lab-254 family inet range 210-239 high 
192.168.254.239
set access address-assignment pool lab-254 family inet dhcp-attributes 
maximum-lease-time 28800
set access address-assignment pool lab-254 family inet dhcp-attributes 
grace-period 3600
set access address-assignment pool lab-254 family inet dhcp-attributes 
name-server 8.8.8.8
set access address-assignment pool lab-254 family inet dhcp-attributes 
name-server 4.2.2.1
set access address-assignment pool lab-254 family inet dhcp-attributes router 
192.168.254.1


-Chad

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Sebastian Bermeo
Sent: Monday, November 09, 2015 8:16 PM
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] DHCP SERVER in m7i

If this device not support this service, what kind of configuration may I
use to run this function?  I need a example, I'm learning over junos.


On Monday, 9 November 2015, Chad Myers <chad.my...@theice.com> wrote:

> There was a version of Junos where the dhcp server simply wouldn't work on
> a M7i.  Digging into traceoptions found that it was because it was trying
> to synchronize with the dhcp process on the backup routing engine to
> determine who should be active.  Minor detail that the M7i can't have a
> second RE was overlooked so the dhcp server never went active.
>
> I don't remember the specific code version I was running at the time, but
> I think it was something in 11.4 or 12.1.
>
> -Chad
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net
> <javascript:;>] On Behalf Of Sebastian Bermeo
> Sent: Monday, November 09, 2015 3:48 PM
> To: juniper-nsp@puck.nether.net <javascript:;>
> Subject: [j-nsp] DHCP SERVER in m7i
>
> Hi
>
> I was trying  to configure a dhcp server in a m7i, something like this:
>
> set interfaces ge-0/0/0 unit 7 description visits
> set interfaces ge-0/0/0 unit 7 vlan-id 7
> set interfaces ge-0/0/0 unit 7 family inet address 192.168.7.1/24
> set interfaces ge-0/0/0 unit 7 family iso
>
> set system services dhcp-local-server group dhcp-visitas interface
> ge-0/0/0.7
> set access address-assignment pool pool-visitas family inet
> set access address-assignment pool pool-visitas family inet network
> 192.168.7.0/24
> set access address-assignment pool pool-visitas family inet dhcp-attributes
> name-server 192.168.1.3
>
> Its correct this configuration?
>
> In addicion in this range of address, I need to start the first
> dhcp-address in 192.168.7.64 and end in 192.168.7.254, exists a sentence
> may I use to configure this?
>
> I use JUNOS OS 11.4R7.5.
>
> Thanks for any answer.
>
> Regards.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net <javascript:;>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> 
>
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you have reason
> to believe you are not an intended recipient of this message, please delete
> it and notify the sender. This message may not represent the opinion of
> Intercontinental Exchange, Inc. (ICE), its subsidiaries or affil

Re: [j-nsp] VC on a QFX5100 won't go away

[Chad Myers]

Aside from being in linecard mode, that status looks correct for a standalone 
qfx.
===
{master:0}
cmyers@lab-qfx5100-1> show virtual-chassis

Virtual Chassis ID: 79a5.39fa.6314
Virtual Chassis Mode: Enabled
Mstr   Mixed Route 
Neighbor List
Member ID  Status   Serial NoModel  prio  Role  Mode  Mode ID  
Interface
0 (FPC 0)  Prsnt qfx5100-48s-6q 128   Master*  N  VC

Member ID for next new member: 1 (FPC 1)
===

The "request virtual-chassis reactivate", and possibly a reboot after, should 
get it where you want it to be.


It is a little bit confusing at first, but it is always operating as a 
virtual-chassis.  It simplifies development and testing by treating standalone 
as "virtual-chassis with 1 member" case rather than having "virtual-chassis 
with 1-n members" mode and a separate "standalone" mode.  The EX4200/EX8200 do 
the same thing, although not as obviously.

-Chad


On Nov 13, 2015, at 1:11 PM, Michael Loftis  wrote:

> Oh also... request virtual-chassis recycle member-id N for old member IDs
>
> On Fri, Nov 13, 2015 at 10:08 AM, Michael Loftis  wrote:
>> It might be it's in split mode?  request virtual-chassis reactivate ?
>> It's odd that it shows itself as a linecard but also master role.  The
>> other thing you could do is maybe explicitly set it as a routing
>> engine?  in config set virtual-chassis member 0 serial-number XXX role
>> routing-engine
>>
>> Whatever is going on is just software having to do with it previously
>> being in a line card role.
>>
>> On Fri, Nov 13, 2015 at 9:38 AM, Dave Peters - Terabit Systems
>>  wrote:
>>> That's another weird part. It's not connected to anything, and there's no 
>>> vc-port recognized:
>>>
>>> root> show virtual-chassis
>>>
>>> Virtual Chassis ID: 1517.c443.48e0
>>> Virtual Chassis Mode: Enabled
>>>Mstr   Mixed Route 
>>> Neigh
>>> bor List
>>> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode 
>>> ID  I
>>> nterface
>>> 0 (FPC 0)  PrsntTR0214440089 qfx5100-48c-6q 128   Master*  N  VC
>>>
>>> Member ID for next new member: 1 (FPC 1)
>>>
>>> {linecard:0}
>>> root> show virtual-chassis vc-port
>>> fpc0:
>>> --
>>>
>>> {linecard:0}
>>> root>
>>>
>>> I think I've got a lemon, here, but as always, I really appreciate 
>>> everyone's input.
>>>
>>> Thanks much.
>>>
>>> --Dave Peters
>>>
>>> -Original Message-
>>> From: Alexandre Guimaraes [mailto:alexandre.guimar...@ascenty.com]
>>> Sent: Friday, November 13, 2015 8:22 AM
>>> To: Dave Peters - Terabit Systems; juniper-nsp@puck.nether.net
>>> Subject: RES: VC on a QFX5100 won't go away
>>>
 show virtual-chassis
>>>
>>> Preprovisioned Virtual Chassis
>>> Virtual Chassis ID: cf12.a99f.e63b
>>> Virtual Chassis Mode: Enabled
>>>Mstr   Mixed Route 
>>> Neighbor List
>>> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode 
>>> ID  Interface
>>> 0 (FPC 0)  PrsntTA3714071234 qfx5100-48s-6q 129   Master*  N  VC   
>>> 2  vcp-255/0/50
>>> 
>>> 1  vcp-255/0/51
>>> 1 (FPC 1)  PrsntTA3714141234 qfx5100-48s-6q 129   Backup   N  VC   
>>> 0  vcp-255/0/50
>>> 
>>> 2  vcp-255/0/51
>>> 2 (FPC 2)  PrsntTA3714141234 qfx5100-48s-6q   0   Linecard N  VC   
>>> 1  vcp-255/0/50
>>> 
>>>0  vcp-255/0/51
>>>
>>>
>>> See vcp-255/0/51 ports:
>>>
 show virtual-chassis vc-port
>>> fpc0:
>>> --
>>> Interface   Type  Trunk  Status   SpeedNeighbor
>>> or ID (mbps)   ID  Interface
>>> PIC / Port
>>> 0/50Configured -1Up   42   
>>> vcp-255/0/51
>>> 0/51Configured -1Up   41   
>>> vcp-255/0/50
>>>
>>> fpc1:
>>> --
>>> Interface   Type  Trunk  Status   SpeedNeighbor
>>> or ID (mbps)   ID  Interface
>>> PIC / Port
>>> 0/50Configured -1Up   40   
>>> vcp-255/0/51
>>> 0/51Configured -1Up   42   
>>> vcp-255/0/50
>>>
>>> fpc2:
>>> --
>>> Interface   Type  Trunk  Status   Speed

Re: [j-nsp] DHCP SERVER in m7i

[Chad Myers]

There was a version of Junos where the dhcp server simply wouldn't work on a 
M7i.  Digging into traceoptions found that it was because it was trying to 
synchronize with the dhcp process on the backup routing engine to determine who 
should be active.  Minor detail that the M7i can't have a second RE was 
overlooked so the dhcp server never went active.

I don't remember the specific code version I was running at the time, but I 
think it was something in 11.4 or 12.1.

-Chad

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Sebastian Bermeo
Sent: Monday, November 09, 2015 3:48 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] DHCP SERVER in m7i

Hi

I was trying  to configure a dhcp server in a m7i, something like this:

set interfaces ge-0/0/0 unit 7 description visits
set interfaces ge-0/0/0 unit 7 vlan-id 7
set interfaces ge-0/0/0 unit 7 family inet address 192.168.7.1/24
set interfaces ge-0/0/0 unit 7 family iso

set system services dhcp-local-server group dhcp-visitas interface
ge-0/0/0.7
set access address-assignment pool pool-visitas family inet
set access address-assignment pool pool-visitas family inet network
192.168.7.0/24
set access address-assignment pool pool-visitas family inet dhcp-attributes
name-server 192.168.1.3

Its correct this configuration?

In addicion in this range of address, I need to start the first
dhcp-address in 192.168.7.64 and end in 192.168.7.254, exists a sentence
may I use to configure this?

I use JUNOS OS 11.4R7.5.

Thanks for any answer.

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



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Chad Myers]

Since I rekindled this once already...

I don't get what the benefit of "load  interactive" would be over just 
doing normal set commands.  Putting everything on a single line with inline 
comments like that seems like a recipe for headaches.  Each time I look at it I 
have to go back over it again 2-3 times to make sense of what is a comment, 
what is a setting, and how they actually link together.  Could just be me 
having a hard time grasping it quickly.

On a related note, this reminded me of something in the behavior of "load 
terminal" that bit me once and I'm wondering if it bit anyone else.  When using 
load merge terminal, and likely replace and override as well, if you break out 
using ctrl-C to abort the load instead of ctrl-D to save it,  it doesn't 
actually abort the load.  Anything that parsed successfully up to that point is 
now part of the candidate configuration, exactly the same as if you used ctrl-D 
to exit "load terminal" normally.  Anyone else learn that unexpectedly?

-Chad

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Stepan Kucherenko
Sent: Saturday, October 24, 2015 3:23 PM
To: Phil Shafer
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Multi Core on JUNOS?

> This would allow set-ish style (since the UI really doesn't need the
> braces on input) as well as allowing the placement of comments:
>
> [edit]
> cli# load terminal merge interactive
> [Type ^D at a new line to end input]
> protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
> /* You can also put braces here */
> protocols {
> bgp {
>/* goo is not */
>group goo { local-as 51; }}}
> ^D
> load complete
>

Is it possible to delete last line(s) ? If yes then this way of
configuring something will become the only one I will use all the time. :-)

I think it's great.

>
> But I need to work out what (and how) would get redrawn when you
> type "?" deep under braces (like at the "51" above).  I can't emit
> the [edit] line, but just redrawing the current line doesn't give
> the context the way I'd like it to.  Perhaps a distinct key to give
> the content-as-edit-line?

I'd be happy even with the current line. But maybe someone else will
have more ideas ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Chad Myers]

On Oct 9, 2015, at 10:08 AM, Jeff Haas  wrote:

> Adam,
>
>> On Oct 9, 2015, at 9:45 AM, Adam Chappell  wrote:
>>>
>> I can imagine that making rpd MT is probably hard to the point of almost
>> not being worth the benefit (with current REs), unless one can adequately
>> break down the problem into divisable chunks of work that are insensitive
>> to execution order.  BGP peer route analysis, comparison against import
>> policy and current RIB might fall into that category, but not without a lot
>> of locking and potential for races.
>
> It is non-trivial work.  But it is also somewhat easier to incrementally 
> introduce threading than it is to split large hunks of code and workflow into 
> multiple processes.
>
> We're not going into deep technical detail on mailing lists such as these at 
> the moment.  The work is in progress.

Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
completely independent and isolated from the others.  It is extremely helpful 
to be able to do things like put communities on static routes.  Even protocols 
that don't use communities can leverage them in the export policy, the 
community just isn't announced.  Ditto for import policies.

Sacrificing that flexibility and simplicity to multithread rpd and shifting to 
explicit route redistribution with limited route attributes per protocol would 
be a huge loss.

-Chad



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Chad Myers]

On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:

> hey,
>
>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K
>
> Thats what I had in mind as well.

I'm for that method as well.




This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Chad Myers]

On Oct 21, 2015, at 3:34 PM, Saku Ytti  wrote:
> Hey Chad,
>
>> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
>> completely independent and isolated from the others.  It is extremely 
>> helpful to be able to do things like put communities on static routes.  Even 
>> protocols that don't use communities can leverage them in the export policy, 
>> the community just isn't announced.  Ditto for import policies.
>>
>> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
>> to explicit route redistribution with limited route attributes per protocol 
>> would be a huge loss.
>
> You don't need to worry, these two issues have nothing in common. What
> you're talking about is very high level concept and it implies nothing
> about the underlaying architecture.

True, but I also know a good bit about the underlying architecture and have a 
good grasp of general system and programming concepts.  Definitely not a 
developer though so I don't typically know the specifics on how something is 
implemented.

>From a general view it seems that the simplest and fastest method to get rpd 
>to leverage multicore systems better is splitting apart the different 
>protocols.  That opens up having to deal with contention amongst the different 
>protocols trying to access a single global route table simultaneously.  It can 
>be done but it could also be sidestepped entirely by having per protocol 
>tables rather than a single global table.  I would hope that isn't the path 
>taken, but I've already dealt with various groups within Juniper and elsewhere 
>that have made design decisions ranging from fantastic to questionable to 
>absolutely horrible.  My request is just trying to prevent seeing Junos core 
>do something really bad, either inadvertently or on purpose.

> Having said that, why on earth no tags/communities on direct/connected
> routes on any(?) platform. It dilutes usefulness in static routes as
> well, as you're still going to need to have logic to provision
> prefix-lists, so might as well do it same way for statics and directs.

Adding that would be on the fantastic side of design decisions.

As would getting the group that handles spd to adhere to the same standards as 
the rest of Junos with regard to naming conventions, inheritance, and 
prefix-list expansions.  And finally putting commas in the monitor interface 
traffic output.

-Chad



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Loopback Filter - NTP Question

[Chad Myers]

If it requires an address, you can put the loopback address 127.0.0.1/32 on the 
loopback interface itself.

It is possible to add disable monitor to /var/etc/ntp.conf to disable the 
monlist command.  The caveat is that a full commit (or rollback) will recreate 
ntp.conf and delete the entry.  Picking up a hint from another thread on the 
list I set up a cron job in /etc/crontab.sys to check the config file every few 
minutes.  If the entry is missing, it puts it back and pokes ntp to reread its 
configuration.  Works quite nicely although I think crontab.sys may get 
rewritten on upgrade.

crontab.sys entry:
*/5 *   *   *   *   rootsh 
/var/home/cmyers/xntp-disable_monitor.sh

Do a commit full after adding the entry to crontab.sys to get it picked up.
===
% cat xntp-disable_monitor.sh

# Basic stuff
NTP_CONF=/var/etc/ntp.conf
NTP_PROC=$(ps ax | grep xntpd | grep -v grep | awk '{printf $1}')
CHECK_ONLY=0
VERBOSE=0
my_id=$(id -u)

Print_Help ()
{
echo Usage: $(basename ${0}) [-q|-v] [-c]
echo  -q: quiet, no status messages
echo  -v: verbose, display status messages
echo  -c: check current configuration only, no changes [0=config is 
correct, 1+=missing config]
exit 255
}

# # Get command line options
# if test ${#} -eq 0
# then
#   # No command line option specified.
#   Print_Help
# fi

while getopts qvc opt
do
case ${opt} in
q) VERBOSE=0 ;;
v) VERBOSE=1 ;;
c) CHECK_ONLY=1  VERBOSE=1 ;;
*) Print_Help ;;
esac
done

# Check the config file
if [ -r ${NTP_CONF} ]
then
egrep ^disable monitor[ \t]*$ ${NTP_CONF} 21 /dev/null
CFG_Status=$?
else
echo ERROR: Unable to read ${NTP_CONF}
exit 2
fi

if [ ${CFG_Status} -eq 0 ]
then
[ ${VERBOSE} -eq 1 ]  echo ${NTP_CONF} contains the 'disable 
monitor' entry already.
exit 0
fi

# Option is missing
[ ${VERBOSE} -eq 1 ]  echo ${NTP_CONF} is missing the 'disable monitor' 
entry.
[ ${CHECK_ONLY} -eq 1 ]  exit 1

# Need to be root to change anything
[ ${my_id} -ne 0 ]  echo ERROR: You must be root to make any changes!  
exit 1

[ ${VERBOSE} = 1 ]  echo Adding the 'disable monitor' entry
echo   ${NTP_CONF}
echo disable monitor  ${NTP_CONF}
[ ${VERBOSE} = 1 ]  echo Sending SIGHUP to xntpd (pid ${NTP_PROC}) so it 
re-reads its configuration.
kill -HUP ${NTP_PROC}
[ ${VERBOSE} = 1 ]  echo Done.
exit 0
===


Cheers!

-Chad


On Feb 4, 2014, at 2:43 PM, Paul Stewart wrote:

 Hi there

 We are still finding some JunOS devices vulnerable in our network to the NTP
 issue.  For devices with an IP address on the loopback this has proven to be
 just an update to existing firewall filters where we allow the remote NTP
 servers we query from and include the loopback IP itself.

 Most of the remaining devices do not have an IP address on the loopback
 which has presented a new challenge we were not expecting.  If we apply an
 updated loopback firewall filter and attempt to filter NTP only to specific
 sources it will fail every time if there is no actual IP address on the
 loopback.

 Juniper says we must put an IP address on the loopback to work around this
 issue so I am wondering what other folks are doing in these specific
 situations?

 There are several options which to me the best would be to have Juniper
 actually fix this issue with a proper NTP implementation

 Thanks for any input

 Paul




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



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of IntercontinentalExchange, 
Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract 
or guarantee. Unencrypted electronic mail is not secure and the recipient of 
this message is expected to provide safeguards from viruses and pursue 
alternate means of communication where privacy or a binding message is desired.


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

Re: [j-nsp] NTP Reflection

[Chad Myers]

Loopback address isn't explicitly assigned to an interface.  Assigning it 
resolves various issues.  See 
http://forums.juniper.net/t5/Ethernet-Switching/NTP-Not-working/m-p/224757.
set interfaces lo0.0 family inet address 127.0.0.1/32



As for NTP, and other stuff for the RE itself, I use same approach by 
explicitly putting 127.0.0.1/32 in the prefix-list.  I originally did it 
because not all of the apply-path lists had the underlying configuration, 
resulting in an empty prefix-list that matched anything.  Now, almost any 
apply-path based prefix list will have the loopback address specified.

set policy-options prefix-list MY-NTP_SERVERS 127.0.0.1/32
set policy-options prefix-list MY-NTP_SERVERS apply-path system ntp server *

-Chad


On Jan 14, 2014, at 7:04 AM, Olivier Benghozi wrote:

 But due to another ridiculous way of implementing that, the Juniper KB 
 article suggests to also allow:
 router-loopback-address;
 and not only your favorite ntp servers...

 Because if you don't do it, you'll obtain some nice Server Timeout if you 
 want to issue a show ntp status or show ntp associations.
 So:
 - Junos doesn't use 127.0.0.1 to locally communicate with ntpd
 - In you filters you're obliged to manually authorize internal private IP 
 traffic used by the CLI and that doesn't even leave the RE

 Another fine design...


 --
 Olivier


 Le 14 janv. 2014 à 03:10, John Kristoff j...@cymru.com a écrit :

 On Tue, 14 Jan 2014 12:38:12 +1100
 Mark Tees markt...@gmail.com wrote:

 Can we get detailed lo0 filters listed too please?

 Hi Mark,

 While I'll defer to Juniper for their recommendations, we've had this
 for some time (scroll down to the Juniper section):

 http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html


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



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of IntercontinentalExchange, 
Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract 
or guarantee. Unencrypted electronic mail is not secure and the recipient of 
this message is expected to provide safeguards from viruses and pursue 
alternate means of communication where privacy or a binding message is desired.


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