Re: [j-nsp] 208v power and 110...

[Justin M. Streiner]

On Thu, 10 May 2018, David B Funk wrote:

auto-sensing is pretty ubiquitous, you'll find it in many consumer devices 
such as the wall-wart for charging your phone/PDAs.


Look at the power input rating label on a device, if it says "100-240" then 
it's auto-sensing and you're good to go.


Be careful with wall-warts.  If it doesn't explicitly say that it will 
work at 240V, or it's not clear that it will, don't try to plug into a 
higher voltage outlet. Many wall-warts are still floating around that 
don't work at >120 VAC and will instantly release their magic smoke...


The other thing is if you use PDUs that have IEC C13 connectors for 120V 
devices, you might need IEC-C14 <-> NEMA 5-15R adapter cords, an 
appropriate PDU with NEMA 5-15R or 5-15/20R recaptacles, or some NEMA 
5-15/20R convenience outlets to provide a place to plug in those wall-warts.


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

Re: [j-nsp] 208v power and 110...

[David B Funk]

Date: Wed, 9 May 2018 14:26:13 -0700
From: mike+j...@willitsonline.com
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] 208v power and 110...

On 05/09/2018 10:52 AM, Scott Martin wrote:
> Almost all equipment these days will run on 208V, in fact, everything
> I've seen over the last ~10 years will auto switch from 100V - 240V
> single phase 50/60Hz. (unless 208V is the minimum voltage, of course...)
>
> 208V is the way to go, imho. If you have high density racks, 8kVa or
> larger, I'd go with 415V 3? which is 240V phase to neutral if that is
> an option.

Thanks (and to you other kind folks who replied). I feel a lot better
now. Just didn't want to be stupid here and have wrong and dangerous
ideas about how or what to do. No idea about the auto-switching but I
guess that makes good sense (bad pun?).


Mike-


Given that many places in the world have standard wall-outlet voltage of 
230-240, most manufacturers support higher voltage.


In the really old days you had to spec the appropriate PS for the voltage in 
your target area. In the not-so-old days there was a little switch on the back 
of the PS that selected 115/230 volts input range.


For almost everything these days the additional cost of the auto-sensing 
switching circuitry is at parity with the cost of the mechanical switch and the 
improvement in customer satisfaction makes it the clear win.
(customer neglects to set switch, plugs it in, magic smoke escapes, customer is 
unhappy ;).


auto-sensing is pretty ubiquitous, you'll find it in many consumer devices such 
as the wall-wart for charging your phone/PDAs.


Look at the power input rating label on a device, if it says "100-240" 
then it's auto-sensing and you're good to go.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP

[Vincent Bernat]

Hey!

Some update which may be useful to future readers.

I had to add back the "ingress-node-replication" to the
vlans. Otherwise, when a VNI has more than a handful VTEPs (30 in my
case), replication doesn't seem to be done at all.

I have also hit another surprising limitation: the outer MAC address for
remote VTEP was wrong (same MAC address for all VTEP, despite the
next-hop database on both FPCs being correct) when not doing replication
(it was correct for broadcast packets). I am using external loopback
cables with a separate instance for routing to workaround the
issue. This is not pretty, but it is OK for my use case.

I am using the QFX5100 in a virtual-chassis (cannot use BGP EVPN type-1
routes due to interoperability issues). Maybe this is the source of the
problems (as this is not an usual setup to run BGP EVPN on). I am
currently on 17.4R1-S2.2. rpd on 14.1X53-D46.7 was crashing when I added
more remote VTEPs. Didn't had any other difference from 15.1 to 18.1.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain

 ――― Original Message ―――
 From: Nitzan Tzelniker 
 Sent: 11 avril 2018 21:02 GMT
 Subject: Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP
 To: Vincent Bernat
 Cc: juniper-nsp@puck.nether.net

> Try to remove the  "ingress-node-replication" from the vlans and add " set
> protocols evpn multicast-mode ingress replication "
> few months ago a TAC engineer told it to me
>
> "This knob will add all the remote VTEPs under the VNIs on local device
> even though the remote devices do not have these VNIs configured. This
> causes unnecessary flooding from local device to the remote."
>
> But to be honest I didn't check it yet
>
> Thanks
>
> Nitzan
>
> On Tue, Apr 10, 2018 at 12:42 PM Vincent Bernat  wrote:
>
>> Hey!
>>
>> I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes
>> that all VTEP have all the local VNIs. For example, on the local system,
>> I have VNI 654, 655 and 656. However, on the remote VTEP, I have only
>> 654 and 655. However, the local system still assumes VNI 656 should be
>> present:
>>
>> juniper@QFX1> show version
>> fpc0:
>> --
>> Hostname: QFX1
>> Model: vqfx-1
>> Junos: 17.4R1.16 limited
>> JUNOS Base OS boot [17.4R1.16]
>> JUNOS Base OS Software Suite [17.4R1.16]
>> JUNOS Crypto Software Suite [17.4R1.16]
>> JUNOS Online Documentation [17.4R1.16]
>> JUNOS Kernel Software Suite [17.4R1.16]
>> JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16]
>> JUNOS Routing Software Suite [17.4R1.16]
>> JUNOS jsd [i386-17.4R1.16-jet-1]
>> JUNOS SDN Software Suite [17.4R1.16]
>> JUNOS Enterprise Software Suite [17.4R1.16]
>> JUNOS Web Management [17.4R1.16]
>> JUNOS py-base-i386 [17.4R1.16]
>> JUNOS py-extensions-i386 [17.4R1.16]
>>
>> {master:0}
>> juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote
>> Logical System Name   Id  SVTEP-IP IFL   L3-Idx
>>  0   192.0.2.11   lo0.00
>>  RVTEP-IP IFL-Idx   NH-Id
>>  192.0.2.13   570   1749
>> VNID  MC-Group-IP
>> 656   0.0.0.0
>> 655   0.0.0.0
>> 654   0.0.0.0
>>
>> {master:0}
>> juniper@QFX1> show route table default-switch.evpn.0
>>
>> default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown,
>> 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 1:192.0.2.11:1::010101010101010101::0/192 AD/EVI
>>*[EVPN/170] 00:03:49
>>   Indirect
>> 2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:02:43
>>   Indirect
>> 2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:01:20
>>   Indirect
>> 2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:03:54
>>   Indirect
>> 2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:41, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:04, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 3:192.0.2.11:1::654::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:08
>>   Indirect
>> 3:192.0.2.11:1::655::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>>   Indirect
>> 3:192.0.2.11:1::656::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>>   Indirect
>> 3:192.0.2.13:1::654::192.0.2.13/248 IM
>>*[BGP/170] 00:03:55, localpref 100, from 

[j-nsp] using lo0 unit 1 as a vrf endpoint

[Aaron Gould]

I forget. is there something tricky with using a subinterface on lo0 (like
lo0.1) as a vrf pe endpoint ?

 

I see that it's been advertised into the mpls l3vpn across the network, but
I can't ping it 

 

-Aaron

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