Re: [j-nsp] IPSEC VPN

[Mohammad Khalil]

Hi all and thanks for the reply
I have the policy in place but forgot to add it:
set security zones security-zone untrust interfaces st0.1
host-inbound-traffic system-services snmp
set security zones security-zone untrust interfaces st0.1
host-inbound-traffic system-services snmp-trap

set security zones security-zone untrust host-inbound-traffic
system-services snmp
set security zones security-zone untrust host-inbound-traffic
system-services snmp-trap


On 17 April 2018 at 13:00, Louis Kowolowski 
wrote:

> On Apr 17, 2018, at 2:03 AM, Mohammad Khalil  wrote:
>
>
> Hi all
>
> I have configured an IPSEC between my SRX210 and a provider who will
> provide monitoring services
> The IPSEC is up and running and I can reach from my internal servers (LAN)
> to their monitoring servers (remote LAN) via ICMP , but they cannot pull
> any data through my SNMP
> I have configured the needed (I guess!) and do not know what is blocking
> data polling
>
> *set snmp community bbc2k4 clients 65.198.233.4/32
> set security zones security-zone untrust interfaces
> st0.1 host-inbound-traffic system-services snmpset security zones
> security-zone untrust interfaces st0.1 host-inbound-traffic system-services
> snmp-trap*
>
> If you don't have it, I think you probably need some security policy to
> allow the traffic through the SRX.
>
>
> --
> Louis Kowolowskilou...@cryptomonkeys.org
> Cryptomonkeys:   http://www.cryptomonkeys.
> com/
>
> Making life more interesting for people since 1977
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Going Juniper

[Ross Halliday]

Indeed, I remember our discussions on the topic before! I still haven't made 
much headway. It's worth pointing out, though, that the "not configured" state 
can pop up when you least expect it, such as an aggregate filtering action 
applied after a broadcast storm (which you THOUGHT you fixed, but for some 
reason a bunch of stuff doesn't work still and you can't get into the box and 
aren't sure why). Good to watch out for since a network where unexpected things 
don't happen isn't connected to anything and certainly doesn't have any 
administrators ;)

 - Ross

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: Tuesday, April 17, 2018 7:39 PM
To: Saku Ytti
Cc: Ross Halliday; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Going Juniper



> On Apr 17, 2018, at 7:02 PM, Saku Ytti  wrote:
> 
> 
> DDoS protection out-of-the-box is for all practical purposes not
> configured at all, which is unfortunate as that is what most people
> run. When configured correctly Trio has best CoPP I know of in the
> market, certainly better than Cisco or Arista have.

I do wish that Juniper would look at what IOS-XR has done to make
configuring it much easier out of the box.  An ASR 9K w/ default LPTS
is much nicer than a Juniper with default firewall filters.

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

Re: [j-nsp] Going Juniper

[Jared Mauch]

> On Apr 17, 2018, at 7:02 PM, Saku Ytti  wrote:
> 
> 
> DDoS protection out-of-the-box is for all practical purposes not
> configured at all, which is unfortunate as that is what most people
> run. When configured correctly Trio has best CoPP I know of in the
> market, certainly better than Cisco or Arista have.

I do wish that Juniper would look at what IOS-XR has done to make
configuring it much easier out of the box.  An ASR 9K w/ default LPTS
is much nicer than a Juniper with default firewall filters.

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

Re: [j-nsp] Going Juniper

[Saku Ytti]

Hey Ross,

> The low-end MXes can do a lot of things, but that doesn't mean you SHOULD 
> necessarily do them. Anything CPU-heavy is a good example. Convergence time 
> on three full feeds takes about 10-15 minutes in my experience, say in the 
> case a major upstream drops. This isn't a big deal for everyone and for my 
> employer certainly not enough to justify a bigger box on its own. One of the 
> platform's strengths is also its weakness, in that the MX104 is essentially 
> fabricless. Each of the "PIC" slots is a carved out chunk of a single 
> forwarding engine. This is why they're limited to the 2-XFP MICs for 10 GbE 
> options, unlike bigger MXes that take MICs with a much greater port density 
> and support more than 4 SFP+es. This is also why you have things that will 
> affect the entire chassis at once, such as one of my favourite optics bug 
> (plug in an SFP too slowly and all SFPs reset) and the DDoS Protection 
> feature (blackholes an entire class of traffic on ALL ports). They are not 
> suitable for core use for 
 th

DDoS protection out-of-the-box is for all practical purposes not
configured at all, which is unfortunate as that is what most people
run. When configured correctly Trio has best CoPP I know of in the
market, certainly better than Cisco or Arista have.

DDoS protection has many levels 1. aggregate 2. per-npu 3.
per-physical-interface 4. per-logical-interface 5. per-subscriber
(session).

5. is dubious, as it's easy to congest the policer counts (Attacker
changes SPORT). But 3-4 should protect you from issue you describe. If
you limit each IFL or IFD, then single IFL or IFD won't congest whole
NPU, and having for example BGP down in the IFL which is violating the
BGP policer is entirely acceptable.

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

Re: [j-nsp] Going Juniper

[Ross Halliday]

A little late to the party, but I've been accused of worse. 

We transitioned our network from Cisco 6500 platform to MX104s, and at the same 
time converged our Internet Edge onto those MXes too. It's the only Juniper 
router I'm aware of that actually fits *nicely* into a two-post rack, and they 
draw little power for what they are (approx. 150W on DC at idle at lower 
temperatures).

The low-end MXes can do a lot of things, but that doesn't mean you SHOULD 
necessarily do them. Anything CPU-heavy is a good example. Convergence time on 
three full feeds takes about 10-15 minutes in my experience, say in the case a 
major upstream drops. This isn't a big deal for everyone and for my employer 
certainly not enough to justify a bigger box on its own. One of the platform's 
strengths is also its weakness, in that the MX104 is essentially fabricless. 
Each of the "PIC" slots is a carved out chunk of a single forwarding engine. 
This is why they're limited to the 2-XFP MICs for 10 GbE options, unlike bigger 
MXes that take MICs with a much greater port density and support more than 4 
SFP+es. This is also why you have things that will affect the entire chassis at 
once, such as one of my favourite optics bug (plug in an SFP too slowly and all 
SFPs reset) and the DDoS Protection feature (blackholes an entire class of 
traffic on ALL ports). They are not suitable for core use for th
 is reason. 

They are very handy but less than great. MX104 is really made for telecom 
remotes and small COs with limited floor plans. MX80 and variants would be a 
convenient solution if you got one from the used market and have a 4-post rack. 
Both are really intended as 1 GbE aggregation routers. The MX104 is better 
since it has redundant REs, and if you just need some stuff off of an MS-MIC 
then it'd be a reliable low-maintenance box. But be aware that you're paying a 
premium for the form factor and not for something that will be in your network 
for a long time as they have very limited upgradability.  We were originally 
pretty excited but we're replacing a lot now since they just can't deliver the 
10G port density we need. Heck I think you can get smart lightbulbs these days 
that come with 10GbE ports...


Based on things I see in the mailing list, I'd take a serious look at splitting 
things up into more scalable components, such as the vMX and maybe an MX204 - 
systems that have real upgrade potential - although I have no idea what the 
pricing is like since we're going the "Big MX" route.


On Wednesday, April 11, 2018 5:32 AM, Saku Ytti wrote:
> 
> On 11 April 2018 at 04:31, Chris via juniper-nsp
>  wrote:
>
> > Since the MX104 has user replacable RE's I really wish Juniper would at
> > least offer a different option with a more beefy CPU/RAM but I don't think
> > that would ever happen...
>
> I think JNPR believes MX204 is the 'next gen MX104'. I bet if there
> was MX204 with 2xQSFP28 + 24-48xSFP+, sold attractively priced with BW
> license, so that SFP+ as 1GE and sub would make sense, those would
> sell really well.

Indeed it would. Even better if they hardened up the MX204 so it could be 
installed in the same environments.

> New RE for MX104 was on the table early on in the MX104 history, but
> then JNPR changed tracks, citing XEON not being thermally possible on
> it.

I would bet money that this has as much to do with it as planned limited 
lifetime of the platform. Maybe two thirds of our MX104s have baked PEM0 (the 
most down-wind power supply) out of existence. Any better CPU in there would 
have to be something like an ARM to keep the thing from roasting both power 
supplies simultaneously.

> I suspect more correct reason is that they don't see sufficient market
> potential in device like MX104. I think Cisco and Juniper are very
> confused about market, they appear to think entire market consists
> solely of large scale DC providers. That only addressable market is
> market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is
> almost dead.

I have noticed this as well. A lot of noise about ultra-dense machines that 
take up way too much space (depth) and need half a rack's worth of break-out 
cables to do anything interesting. That is, as long as "interesting" means 
"inside the building". I think vendors are taking "cloud" too seriously, as it 
seems that everybody's forgotten that the access and aggregation layers 
actually exist. Err I mean to say, just use hyperconverged Next Gen 5G. It's 
magic! Right?



On Thursday, April 12, 2018 3:58 AM, James Harrison wrote:
>
> On 11/04/2018 10:51, James Bensley wrote:
> > I would agree with
> > you that low port coun't, good, and reasonably priced mixed 1G/10G
> > devices aren't plentiful in choice from vendors. We open a lot of
> > small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for
> > us but each with their own caveats.
>
> Particularly if you include the requirement for temperature hardening -
> we deploy a lot of street c

Re: [j-nsp] IPSEC VPN

[Louis Kowolowski]

On Apr 17, 2018, at 2:03 AM, Mohammad Khalil  wrote:
> 
> Hi all
> 
> I have configured an IPSEC between my SRX210 and a provider who will
> provide monitoring services
> The IPSEC is up and running and I can reach from my internal servers (LAN)
> to their monitoring servers (remote LAN) via ICMP , but they cannot pull
> any data through my SNMP
> I have configured the needed (I guess!) and do not know what is blocking
> data polling
> 
> *set snmp community bbc2k4 clients 65.198.233.4/32
> set security zones security-zone untrust interfaces
> st0.1 host-inbound-traffic system-services snmpset security zones
> security-zone untrust interfaces st0.1 host-inbound-traffic system-services
> snmp-trap*
> 
If you don't have it, I think you probably need some security policy to allow 
the traffic through the SRX.


--
Louis Kowolowskilou...@cryptomonkeys.org 

Cryptomonkeys:   http://www.cryptomonkeys.com/ 


Making life more interesting for people since 1977

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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Luis Balbinot]

> This issue is my turning up new MX960's that are simply connected together 
> with Ciena 6500 DWDM for me to have an MTU issue via DWDM is actually a 
> surprise to me.  I pretty much always envisioned wave/lamda dwdm as darn near 
> like having an actual fiber cable... no, not the case apparently... I'm 
> surprised that the ciena dwdm service in this case is actually imposing an 
> Ethernet mtu limitation !  wow, the more I think on it, the more I'm 
> surprised about it... previously my older asr9k 15-node mpls ring was via 
> fujitsu flashwave dwdm and I don't recall this occurring

DWDM is kind of agnostic in the core but for packet networks there are
OTU frames (max size = 16,320 bytes) and there is also the interface
line card that imposes the actual MTU for the Ethernet interface (9600
is a well-known value for DWDM networks). If you have, say, a 100G
transponder and a 10x10G line card then you have to frame all those
ports, they won't become light as 10G channels. Even 10G channels on a
regular 10G non-coherent network must be framed for FEC and everything
else.

If you have a colored interface directly from your router to the DWDM
system then you might skip that limitation (that depends on the
platform and linecard configuration).

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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Chuck Anderson]

It depends if the DWDM gear is purely L1 or if it is doing OTN switching (it 
will be doing OTN if you are mapping 1 or more lower rate client side signals 
into 1 or more higher rate line side signals).  The latter deals with framing 
and would have MTU limits.  The former would have a 1:1 mapping from each 
client side wave to a each line side wave.

On Tue, Apr 17, 2018 at 07:24:41AM -0500, Aaron Gould wrote:
> This issue is my turning up new MX960's that are simply connected together 
> with Ciena 6500 DWDM for me to have an MTU issue via DWDM is actually a 
> surprise to me.  I pretty much always envisioned wave/lamda dwdm as darn near 
> like having an actual fiber cable... no, not the case apparently... I'm 
> surprised that the ciena dwdm service in this case is actually imposing an 
> Ethernet mtu limitation !  wow, the more I think on it, the more I'm 
> surprised about it... previously my older asr9k 15-node mpls ring was via 
> fujitsu flashwave dwdm and I don't recall this occurring 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Aaron Gould]

Thanks for all feedback

I've decided to make my east/west mx960 100 gig ring mtu 9216... to jive with 
much of the rest of my network

Thanks again

-Aaron

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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Aaron Gould]

Lukas, I am learning and continue to learn and continue to ask questions even 
if I thought I understood it before and realize maybe I don't understand it the 
way that I did previously... factor into that bad memory, getting older, 
forgetting, then what you have is a human.

This issue is my turning up new MX960's that are simply connected together with 
Ciena 6500 DWDM for me to have an MTU issue via DWDM is actually a surprise 
to me.  I pretty much always envisioned wave/lamda dwdm as darn near like 
having an actual fiber cable... no, not the case apparently... I'm surprised 
that the ciena dwdm service in this case is actually imposing an Ethernet mtu 
limitation !  wow, the more I think on it, the more I'm surprised about it... 
previously my older asr9k 15-node mpls ring was via fujitsu flashwave dwdm and 
I don't recall this occurring 

So... with all that said, I asked more MTU questions

Back in November the triple posting was an emergency given that I actually had 
cell towers down! And I needed help asap ... and I trust and appreciate the 
level of expertise/real-world experience I get from my x-nsp/nanog 
mail-lists... and yes I also started a PRI-1 (net down) TAC case, but you guys 
usually out-do the TACs!  feel the love ?

I typically am more focused with my postings to the appropriate mail list, but 
when cell towers are down, I do what I gotta do !

Hope we are still cool brother  :)

-Aaron



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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Gert Doering]

Hi,

On Tue, Apr 17, 2018 at 12:34:18PM +0300, Saku Ytti wrote:
> On 17 April 2018 at 11:25, James Bensley  wrote:
> 
> > Also you say you have OSPF and LDP up but if you bring up BGP over
> > this link you may have issues. BGP packs UPDATE messages up to the TCP
> > MSS (derived from the link MTU). If you are carrying the full table
> 
> BGP messages are limited to 4096.

Which does not stop TCP from coalescing two messages into one 8 kbyte packet.

(As in "I have had a link that was transported over someone else's packet
network, and when they re-routed in an outage, I lost 8 bytes MTU, 
resulting in TCP failing across a 9200-minus-8-byte-link...")

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Lukas Tribus]

Hello Aaron,


On 16 April 2018 at 21:58, Aaron Gould  wrote:
> See juniper interface MTU is set to max 16000 bytes. but when I ping I can
> only get 9584 bytes through to the other side of the link.  This mx960 is
> linked to another mx960, but Ciena 6500 dwdm is in between the mx960's.
>
>
>
> Is there any reason why I should be concerned that currently Ciena tells us
> that they only support 9600 byte MTU and that I have 16000 set on my MX960's
> ?
>
>
>
> Is there an issue that could arise with this scenario ?

I don't see how you can still ask this question, given that you just
triple posted OSPF/MTU problems to nanog/c-nsp/j-nsp lists back in
November for this exact reason:

http://seclists.org/nanog/2017/Nov/150
https://lists.gt.net/cisco/nsp/198415
https://lists.gt.net/nsp/juniper/63232


What is the reason you keep rejecting the fact that inconsistent and
wrong MTU configurations have an actual impact?

The MTU has to be correctly configured, period. It is really as simple
as that. And no, you do not workaround MTU problems with commands like
"ignore-mtu". You configure the MTU correctly.



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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Saku Ytti]

Hey James,

On 17 April 2018 at 11:25, James Bensley  wrote:

> Also you say you have OSPF and LDP up but if you bring up BGP over
> this link you may have issues. BGP packs UPDATE messages up to the TCP
> MSS (derived from the link MTU). If you are carrying the full table

BGP messages are limited to 4096.

Having said that, OPs configuration is broken, and should be fixed.
MTU can only change inside router, not inside a link or a switch, it's
non-recoverable configuration error.

Best MTU practice:
a) configuration MTU on physical interface as large are reasonable
(you can choose some reasonable LCD, if that's large enough)
b) on logical interfaces, configure protocol MTU to what ever MTU
desired by far-end and supported by transport

Some MTU calculations for what is '1500B MTU'

L3 MTU == 1500B
L2 MTU == 1518B (6 + 6 + 2 + L3 + 4)
L1 MTU == 1538B (1 + 7 + L2 + 12)
JNPR MTU == 1514 (6 + 6 + 2 + L3)
JNPR ICMP == 1547 (L3 - 20 - 8)

All of these are same MTU, and people are using them exchangeably
without actually knowing if A and B end agree on the MTU. So not
rarely, but actually typically A and B ends on large MTU networks have
different MTU configured, when non-standard 1500B MTU is used, as A-B
parties are unable to communicate to each other what is the correct
number that needs to be configured.
Mostly this brokenness is not visible to anyone, because routers are
not offered large frames, but if they were, they'd be blackholed. It's
damn shame we didn't fix this win ARP/ND, as we seem unable to
configure MTU correctly manually.


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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Krasimir Avramski]

>
> If you are carrying the full table for example, then you could end up with
> BGP UPDATE messages 16000
> bytes long they won't cross the link. Y


Just to mention that rfc4271 states maximum bgp message size of 4096,
although there is a draft
https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-24 that
could change this in the future.

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

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[James Bensley]

On 16 April 2018 at 20:58, Aaron Gould  wrote:
> See juniper interface MTU is set to max 16000 bytes. but when I ping I can
> only get 9584 bytes through to the other side of the link.  This mx960 is
> linked to another mx960, but Ciena 6500 dwdm is in between the mx960's.

Hi Aaron,

I think MTU consistency is important. It will make for a support
issues if the two devices has 16,000 byte MTU configured and that
can't actually be achieved. Will the Level1 support/NOC guys know to
check the Ciene device too and will they be able to work out the
problem? You don't issue being escalated for what is the "normal"
behavior.

Also you say you have OSPF and LDP up but if you bring up BGP over
this link you may have issues. BGP packs UPDATE messages up to the TCP
MSS (derived from the link MTU). If you are carrying the full table
for example, then you could end up with BGP UPDATE messages 16000
bytes long they won't cross the link. You end up with BGP establishing
and after $timeout flapping because no UPDATES were received and this
process loops round indefinitely until you bodge the TCP MSS, use
PMTUD or (preferred choice) correct the MTU issue.

Another issue you may face is that it's best to have consistent MTUs
across you entire network, not just this point-to-point link. If other
parts of your network don't have this size MTU you may have some
hard-to-debug issues further down the road when a customer joins to
two different parts of the network with disparate MTU sizes.

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

[j-nsp] IPSEC VPN

[Mohammad Khalil]

Hi all

I have configured an IPSEC between my SRX210 and a provider who will
provide monitoring services
The IPSEC is up and running and I can reach from my internal servers (LAN)
to their monitoring servers (remote LAN) via ICMP , but they cannot pull
any data through my SNMP
I have configured the needed (I guess!) and do not know what is blocking
data polling



*set snmp community bbc2k4 clients 65.198.233.4/32
set security zones security-zone untrust interfaces
st0.1 host-inbound-traffic system-services snmpset security zones
security-zone untrust interfaces st0.1 host-inbound-traffic system-services
snmp-trap*

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