Re: [j-nsp] EX 3300 vs EX 3400 for access layer

[Harald F. Karlsen]

On 15.09.2017 10:52, Phil Mayers wrote:
You haven't mentioned it, but worth noting that the EX3300 cannot 
filter IPv6. This is a hardware limitation, and caused us to reject 
the EX3300 in favour of the (frankly rather overkill) EX4300. 
Due to this the EX3300 doesn't have (and probably never will have) 
RA-guard. It does have ipv6 source-guard, dhcpv6-snooping and nd-inspect 
thought.


I'd pick the EX3400 over the EX3300 any day (as long as it supports the 
features you need).


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

Re: [j-nsp] EX2300 Supply Delays?

[Harald F. Karlsen]

On 27.08.2016 19:13, Giuliano Medalha wrote:

Harald

What kind of bugs did you find in EX2300 ?

Just to mention a few I noticed the first couple days;
* Sflow reports completely wrong values. I have not had time to dig 
further into this. I know there's a PR where it says sflow doesn't work 
on egress traffic, but this is also affects ingress.
* J-web doesn't work and entering the web gui makes httpd consume 100% 
cpu and makes the entire box unresponsive.

* Commit confirmed doesn't always roll back correctly.
* NTP is broken. My device believes it's 2038-01-19 04:14:07 CET now and 
with "Time Source: NTP CLOCK".


This is just the ones I can think of right now. I know there are more as 
well.


Is it critical ? Some basic functions not working at all ?
That's up to you to decide. I'd say a few of them is pretty basic and 
critical.


 Also quite a few other features are missing at FRS. Just mentioning some:
* ip-source-guard.
* mld-snooping (Really, it's 2016. All switches should support and run 
this by default at FRS. At least when IGMP-snooping is supported and 
enabled by default).

* ipv6-source-guard (and a lot of IPv6 first-hop security stuff).

Needless to say, I wouldn't recommend putting these boxes into 
production yet.


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

Re: [j-nsp] EX2300 Supply Delays?

[Harald F. Karlsen]

On 26.08.2016 15:31, Skeeve Stevens wrote:

Does anyone know if the EX2300 has been delayed?
Not sure about the other switches in the series, but I recieved my order 
of three EX2300-Cs for lab-use two weeks ago.


Quite a lot of bugs in the software though.

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

Re: [j-nsp] ldp transport address 0.0.0.0

[Harald F. Karlsen]

On 08.08.2016 15:25, Mohammad Salbad wrote:

yes router id is configured
I'm suspecting that there is something preventing each router to send its
loopback address during the ldp session establishment, nothing that I have
already deactivated re-protect filter with no luck...
currently I'm thinking of rebooting acx..but since it is already in
operation, I'm trying to find out what might cause this behavior..


Have you enabled LDP on the lo0 interface?

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

Re: [j-nsp] juniper router reccomendations

[Harald F. Karlsen]

On 29.07.2016 14:43, Jim Troutman wrote:

"Turbo FIB" is an internal Juniper name for some speed optimizations in a
version of the 15.1F6 code base, that only work on 64-bit REs.The test
results I saw (a powerpoint presentation) showed a greater than 10% speed
increase from the previous release for installing prefixes into the FIB
from RIB.  I don't know if this is a public release yet, I will ask our SE
team.  I didn't pay close attention because we don't have any 64-bit REs
yet.
The numbers I heard was around 30% increased install speed to the FIB in 
16.1 and long-term target about 10-15x increased install speed from 15.x 
on the MX. Please note that these are numbers some SE casually mentioned 
(and no details on linecards/REs) so take them with a grain of salt, but 
with 15x increased FIB install rate you'll be able to load the full 
table to FIB in less than 10 seconds. I got no idea if these numbers 
only applies for installing new entries to the FIB or also for 
updating/deleting entries as well.


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

Re: [j-nsp] Dealing with multihomed customer BGP primary/backup links

[Harald F. Karlsen]

On 14.07.2016 15:14, Cydon Satyr wrote:

Hi,

I understand, but if you are forcing customer to always use primary link
if it is up, and customer advertises his routes over backup link ONLY,
then he can go around uRPF restriction.
With uRPF you are assuming he advertises all of his routes over primary
link where router can prioritize them. Correct?



Sure, if the customer have several prefixes he can chose to split it up 
and announce some of them over each link, but also lose redundancy.


IMO this should rather be solved with a clause in your customer 
contract. I'm pretty sure this is not something you will se very often.


It will be interesting to hear which solution you end up with and how 
it's working out. Good luck!


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

Re: [j-nsp] Dealing with multihomed customer BGP primary/backup links

[Harald F. Karlsen]

On 14.07.2016 01:43, Cydon Satyr wrote:

uRPF check doesn't work since customer can just advertise his routes over
backup link.
I had some hopes for conditional bgp advertisement and SCU/DCU but I don't
think it works not to mention it's like trying to kill a bee with a hammer.


I'm talking about uRPF *strict* mode, not loose.

uRPF strict should work. The customer will advertise his routes over 
both the primary and the backup link, but you will decide to use only 
the primary (using local pref) and with no active route in the 
forwarding table toward the customers backup link, uRPF strict will deny 
any traffic on that link.


If the primary link goes down, the routes in the forwarding table are 
moved to the backup link and uRPF strict will start accepting traffic on 
that link.


To me this seems like the simplest and most secure solution.

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

Re: [j-nsp] Dealing with multihomed customer BGP primary/backup links

[Harald F. Karlsen]

On 13.07.2016 10:36, Cydon Satyr wrote:

Any other suggestions maybe?



What about uRPF strict mode on the customer-facing interfaces? This will 
prevent the customer from sending traffic on the "backup" interface as 
long as the primary circuit is up and preferred on your end.


That being said I support Marks point that this should be solved 
comercially, not technically.


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

Re: [j-nsp] Junos Fusion Provider Edge

[Harald F. Karlsen]

On 06.06.2016 16:11, Saku Ytti wrote:

On related note, is no one making reasonable 1GE aggregation device,
with full DFZ? If MX104 and ASR9001 are best we have, then situation
seems dire. I don't need NPU/run-to-completion level intelligence,
some pipeline basic low-touch box would be sufficient, but isn't
anyone making those?


Have you checked out the Huawei NE40-M2F? There's not really a whole lot 
of information publicly available about it, but it does seem to meet 
your requirements.


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

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Harald F. Karlsen]

On 02.05.2016 22:26, Saku Ytti wrote:
> On 2 May 2016 at 13:20, Mark Tinka  wrote:
>> When reviewing Metro-E boxes back in 2009, the MX80 was just being
>> developed. I "convinced" Juniper to make a 1U MX Metro-E switch with 40
>> - 48 ports, that could do everything the larger MX chassis could, since
>> the MX80 was simply too big and too costly.
>
> I don't see the logic here. Just because it's 1RU, does not mean it'll
> become cheaper. If anything, it's more expensive due to more NRE
> needed to solve thermal issues.
> If they'll make 1RU Trio box, there is no reason to suspect price
> point would be significantly cheaper than MX80/MX104. If you need
> cheaper box, you need to go low-touch/pipeline/asic style
> forwarding-logic.
>
I would say it depends on the market they aim for. If they could price a 
small form-factor Trio-based device to compete with the smaller ASRs (or 
even ME switches) they could ramp up production and hence decrease 
production cost. I really think a lot of service providers want MPLS 
closer to the edge and I think it's a big market for anyone who makes a 
MPLS-capable device with a proper FIB, decent control-plane and proper 
MPLS features (P2MP LSPs would be nice). Someone smarter than me should 
figure out how to create such a device without cannibalizing their 
existing products.


TLDR; I want to replace my metro switches with proper MPLS routers and 
only spend marginally more on it. I personally think there's a big 
market for whoever makes such a device.


> Does 1RU/2RU/3RU really matter that much? To me MX104 is better option
> than MX80 due to being less deep, depth of MX80 was an issue, not the
> RU.
>
I agree. Lower height and depth is of course better, but I agree that 
depth is the biggest concern for a lot of telcos. For datacenters, 
height is usually the biggest concern. A lot of SPs operate in both 
domains so it's all about finding the best compromise (or maybe two 
different SKUs?).


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

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Harald F. Karlsen]

On 30.04.2016 11:49, Mark Tinka wrote:

When the vendors figure out how to deliver cheap 10Gbps ports on custom
chips in a 1U chassis, I'll be the first one to buy.


+1

I'd love to see a 1U (or 2U 300mm deep) TRIO-based metro device with >20 
1/10G interfaces (with proper buffers and QoS) and 2-4 40/100G 
interfaces. Preferably with a decent control-plane as well (Intel Atom 
or Xeon) and at a competitive price.


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

Re: [j-nsp] purpose of "commit check"?

[Harald F. Karlsen]

On 28.09.2015 23:24, Martin T wrote:

Hi,

when I commit the candidate configuration in Junos, I tend to execute
"commit check" and if configuration check succeeds, then I execute
"commit comment ". However, when I think about it, "commit
(comment)" itself should perform those very same checks that "commit
check" does. If yes, then what is the point of "commit check"? Only
purpose I could see is to check the validity of the candidate
configuration in the middle of the configuration process, i.e. to
check if the changes made in candidate configuration so far are fine
but the candidate configuration is not ready to be committed.



You can use "commit check" to confirm a "commit confirmed" action. That 
way you don't create a new configuration file in your rollback log every 
time you cancel a pending rollback.


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

Re: [j-nsp] warning: dhcp-service subsystem not running - not needed by configuration

[Harald F. Karlsen]

On 07.07.2014 11:03, Victor Sudakov wrote:

Colleagues,

I am trying to configure an EX4200-24T as a DHCP server, but all I
get is the warning: dhcp-service subsystem not running - not needed
by configuration message.


The error message you're getting indicates you're using show dhcp 
server which is for the new DHCP configuration. Try show system 
service dhcp instead. This is for the legacy DHCP configuration.


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