Re: [j-nsp] SRX performance

[harbor235]

Great information, thanks for all the input.



Mike



On Tue, Dec 22, 2015 at 12:10 PM, Payam Chychi  wrote:

> Hi Mike,
>
> Here is what i got so far, from the testing i had done in the past using
> the SRX240H, no issues with 800Mbps and 90K pps... also, no issues with 300
> Mbps and 150K pps.
> I am Not running it in Packet mode since i have no need to do so.
>
> I am not doing nay IDS/Anti-Virus/IPSEC.
>
> As of last year, the 240H was updated with better hardware and more RAM,
> really notice the difference.
>
> Hope this helps.
> -Payam
>
>
>
>
> On 2015-12-22, 8:14 AM, Stepan Kucherenko wrote:
>
>> Can anyone share real world SRX performance? ?I am looking at the SRX220
>>> or SRX240 for a small website ~150-200Mbps in a co-location environment.
>>> The performance charts state the SRX220 can do 300Mbps with a mix of
>>> traffic and  up to 900Mbps with mostly large packet sizes.
>>>
>>
>> SRX240 can give required bandwidth but it has no redundant power. Anyway,
>> I don't think it's a good idea, see below.
>>
>> > If you go down the path of an SRX240 I’d suggest using the
>> > screen features and tuning it for your needs. It can really
>> > save the device from dealing with junk / attack traffic at
>> > higher levels. Can’t help you with a 100Gbps DDoS but can
>> > help deal with SYN floods and other junk.
>>
>> Um. No. It'll die under SYN flood even faster than a server would. I've
>> tested its screen options against SYN floods and it's pathetic, epsecially
>> compared to what a Linux box with synproxy can do. Not surprising, SRX CPU
>> is very slow compared to Xeons and it can't offload everything.
>>
>> That "other junk" will probably kill it as well.
>>
>> Even 550/650 or "datacenter" models are not robust enough because state
>> exhaustion attacks are easy and cheap. Magic "screen" is far from a
>> panacea. Any stateful firewall in datacenter is just a fragile SPOF that
>> will eventually keep over, taking your whole setup with it.
>>
>> With that said, SRX is a very nice box when it's used correctly. I have
>> lots of them in branch offices and some in datacenter, but I wouldn't put
>> it before servers expecting them to hold their ground under attack.  And
>> I'm not bashing SRXes specifically, I'm talking about any stateful firewall
>> from any vendor, they all suck.
>>
>>
>> Don't use stateful firewalls before servers. Ever. Grab an l3 switch and
>> do stateless filtering at ingress and filter everything else on servers.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] bootp and dhcp-relay

[Antoine]

Hi,

I'm wondering if anyone can advise me on my issue getting dhcp-relay to work. 
Currently I am using bootp which is working fine:

[edit interfaces xe-1/0/0 unit 186]
description To-DHCP-Server;
vlan-id 186;
family inet {
address 172.16.3.45/28;
}
[edit forwarding-options]
helpers {
bootp {
server 172.16.3.34;
interface {
xe-1/0/0.186;
}

However, to support IPv6 DHCP I need to use dhcp-relay as it can't work 
concurrently with bootp. So when I disable bootp and configure dhcp-relay, my 
DHCP server doesn't receive any DHCP Discovery/Requests anymore:

dhcp-relay {
server-group {
dhcp-relay {
172.16.3.34;
}
}
active-server-group dhcp-relay;
group dhcp1 {
interface xe-1/0/0.186;
}
}

Regards,
Antoine

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

Re: [j-nsp] NETCONF in Junos

[Stepan Kucherenko]

Sometimes it does strange stuff with SSH internally though. Example:

Let's say I do " show route table ?" at a router.

Logs show:

mgd[62935]: UI_CHILD_START: Starting child '/bin/sh'
mgd[68498]: UI_AUTH_EVENT: Authenticated user 'root' at permission level 
'super-user'
mgd[68498]: UI_LOGIN_EVENT: User 'root' login, class 'super-user' [68498], 
ssh-connection ' 60259  22', client-mode 'cli'
mgd[68498]: UI_CMDLINE_READ_LINE: User 'root', command 'show route summary | 
display xml | grep table-name '
mgd[68498]: UI_LOGOUT_EVENT: User 'root' logout
mgd[62935]: UI_CHILD_STATUS: Cleanup child '/bin/sh', PID 68494, status 0

Obviously I don't login under root, but somehow my CLI spawns a shell, then 
sshes to itself under root (?) using my credentials (?) to do a single command. 
Then it logs out. Every time I request something about route tables.


I'm still puzzled why it can't do that in my CLI session. 


On 21.12.2015 12:04, Matt Bernstein via juniper-nsp wrote:
> On 21/12/2015 08:57, Martin T wrote:
>> Thanks! So as I understand, the general idea is that it doesn't matter
>> much for Junos if the command is executed in the CLI or from the
>> remote(management server) NETCONF manager, i.e. Junos is basically
>> built around the NETCONF? However, local calls(for example if one
>> executes "show version" in Junos CLI) do not travel internally over
>> SSH as remote calls would, do they?
> Yes. the Junos CLI can itself be considered a (really nice) NETCONF 
> wrapper. It makes me idly wish other vendors' NETCONF implementations 
> were good enough that the Junos CLI could be used on them!
> 
> I doubt the CLI uses SSH internally, but I suppose it wouldn't really 
> matter if it did.
> 
> Matt
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] understand "version" and "ns"(namespace) statements in SLAX scripts

[Martin T]

Hi,

if I look the SLAX script examples in Juniper web-site, then almost
all of those examples have "version" and multiple "ns" statements. For
example:

version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos;;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
ns ext = "http://xmlsoft.org/XSLT/namespace;;


While I understand the idea of namespace in XML, then what is the
point of those statements in SLAX scripts? In addition, how does the
"version" statement work? Looks like this is (for some reason)
mandatory as let's say that I have a following very simple script:

$ cat hello_world.slax
version 1.0;

match / {
   {
 "Hello World!";
  }
}
$

..and I remove the "version 1.0;" line, then the script does not operate:

> op hello_world
error: /var/db/scripts/op/hello_world.slax:1: missing 'version'
statement; 'match' is not legal
error: /var/db/scripts/op/hello_world.slax: 1 error detected during parsing
error: error reading stylesheet: hello_world.slax

>



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

Re: [j-nsp] SRX performance

[Stepan Kucherenko]

Can anyone share real world SRX performance? ?I am looking at the SRX220
or SRX240 for a small website ~150-200Mbps in a co-location environment.
The performance charts state the SRX220 can do 300Mbps with a mix of
traffic and  up to 900Mbps with mostly large packet sizes.


SRX240 can give required bandwidth but it has no redundant power. 
Anyway, I don't think it's a good idea, see below.


> If you go down the path of an SRX240 I’d suggest using the
> screen features and tuning it for your needs. It can really
> save the device from dealing with junk / attack traffic at
> higher levels. Can’t help you with a 100Gbps DDoS but can
> help deal with SYN floods and other junk.

Um. No. It'll die under SYN flood even faster than a server would. I've 
tested its screen options against SYN floods and it's pathetic, 
epsecially compared to what a Linux box with synproxy can do. Not 
surprising, SRX CPU is very slow compared to Xeons and it can't offload 
everything.


That "other junk" will probably kill it as well.

Even 550/650 or "datacenter" models are not robust enough because state 
exhaustion attacks are easy and cheap. Magic "screen" is far from a 
panacea. Any stateful firewall in datacenter is just a fragile SPOF that 
will eventually keep over, taking your whole setup with it.


With that said, SRX is a very nice box when it's used correctly. I have 
lots of them in branch offices and some in datacenter, but I wouldn't 
put it before servers expecting them to hold their ground under attack. 
 And I'm not bashing SRXes specifically, I'm talking about any stateful 
firewall from any vendor, they all suck.



Don't use stateful firewalls before servers. Ever. Grab an l3 switch and 
do stateless filtering at ingress and filter everything else on servers.

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

Re: [j-nsp] SRX performance

[Payam Chychi]

Hi Mike,

Here is what i got so far, from the testing i had done in the past using 
the SRX240H, no issues with 800Mbps and 90K pps... also, no issues with 
300 Mbps and 150K pps.

I am Not running it in Packet mode since i have no need to do so.

I am not doing nay IDS/Anti-Virus/IPSEC.

As of last year, the 240H was updated with better hardware and more RAM, 
really notice the difference.


Hope this helps.
-Payam



On 2015-12-22, 8:14 AM, Stepan Kucherenko wrote:

Can anyone share real world SRX performance? ?I am looking at the SRX220
or SRX240 for a small website ~150-200Mbps in a co-location environment.
The performance charts state the SRX220 can do 300Mbps with a mix of
traffic and  up to 900Mbps with mostly large packet sizes.


SRX240 can give required bandwidth but it has no redundant power. 
Anyway, I don't think it's a good idea, see below.


> If you go down the path of an SRX240 I’d suggest using the
> screen features and tuning it for your needs. It can really
> save the device from dealing with junk / attack traffic at
> higher levels. Can’t help you with a 100Gbps DDoS but can
> help deal with SYN floods and other junk.

Um. No. It'll die under SYN flood even faster than a server would. 
I've tested its screen options against SYN floods and it's pathetic, 
epsecially compared to what a Linux box with synproxy can do. Not 
surprising, SRX CPU is very slow compared to Xeons and it can't 
offload everything.


That "other junk" will probably kill it as well.

Even 550/650 or "datacenter" models are not robust enough because 
state exhaustion attacks are easy and cheap. Magic "screen" is far 
from a panacea. Any stateful firewall in datacenter is just a fragile 
SPOF that will eventually keep over, taking your whole setup with it.


With that said, SRX is a very nice box when it's used correctly. I 
have lots of them in branch offices and some in datacenter, but I 
wouldn't put it before servers expecting them to hold their ground 
under attack.  And I'm not bashing SRXes specifically, I'm talking 
about any stateful firewall from any vendor, they all suck.



Don't use stateful firewalls before servers. Ever. Grab an l3 switch 
and do stateless filtering at ingress and filter everything else on 
servers.

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


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