date:20101109

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Brett O'Hara

Makes sure you test them in a lab before commiting to a deployment.  They don't 
always perform as expected and there are unusual limitations compared to the 
SSGs.

Regards,
Brett

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Maqbool Hashim
Sent: Tuesday, 9 November 2010 8:02 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Using SRX's for BGP and Firewalling

Hmmm, that's interesting.  There were two reasons why I was considering the 
SRX's over the SSG's for this setup.

1) I had thought that the routing functionality in JunOS would be more mature 
than in the SSGs.

2) Getting more experience with JUNOS and the SRX's as JUNOS might be the one 
platform for Juniper going forwards.

I think we will still go for the SRX's in this case especially as they seem to 
offer better value for money in features and performance.

Maq

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Michel de Nostredame
Sent: 08 November 2010 22:30
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Using SRX's for BGP and Firewalling

On Mon, Nov 8, 2010 at 10:54 AM, Keegan Holley  
wrote:
> One of the things that turned us off to the SRX series was the fact 
> that code upgrades have to be done on both firewalls if you run them in HA 
> mode.
>  That's kind of a big deal if you want hitless upgrades or there are 
> issues with the upgrade itself.  BGP is one of the main reasons to use 
> a juniper fw over a cisco in some designs, but I find myself liking 
> the SSG/Netscreen code better for now, even though Juniper has stated 
> that they plan to move everything to JunOS.

This is the reason we still stay in ScreenOS on all of our SSG and continue to 
buy SSG boxes. From our experience that ScreenOS on SSG is much stable and 
mature compares to JUNOS on SRX, if we don't take hardware performance into 
consideration.

Don't know why Juniper is so keen on adapting everything to JUNOS. It only 
break stable things, from a small customer point of view.
If the JUNOS CLI is that good and important (be honest, it is very good from 
our point of view) why not just add a shell in ScreenOS that accepts JUNOS CLI 
style statements?

--
Michel~

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

--
This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not an intended recipient, please delete this e-mail immediately and 
notify NTS(UK) Ltd on 0844 815 5925
This e-mail does not necessarily reflect the Company's opinion and should not 
be interpreted as such.
This message was scanned by Proofpoint Protection Server - please contact NTS 
for further information.

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

Primus Telecom
MIS Strategic 100

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

[j-nsp] (no subject)

2010-11-09 Thread Jared Gull

http://eastcoastgreenenergy.com.au/to.html


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

Re: [j-nsp] JunOS 10.0R3 MX960 (DPC's only)

2010-11-09 Thread Ger, Javier

Thanks all for your help.

Javier Ger
Hornos 690 - Buenos Aires - Argentina 
Tel +54.11.5530.4531 
Cel +54.9.11.3926.5017 
j...@cablevision.com.ar 
www.cablevision.com.ar

-Mensaje original-
De: Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Enviado el: Martes, 02 de Noviembre de 2010 02:12 a.m.
Para: Paul Stewart
CC: Ger, Javier; juniper-nsp@puck.nether.net
Asunto: Re: [j-nsp] JunOS 10.0R3 MX960 (DPC's only)

On Mon, Nov 01, 2010 at 08:13:41PM -0400, Paul Stewart wrote:
> And it sounds like you do a mighty fine job finding them ;)
> 
> Those items you list wouldn't be effecting us today - no ISIS and no
MPLS
> enabled (yet, coming shortly)...
> 
> What do you run on your MX boxes today for reference?

At this exact moment (well, the last time we did a new deployment or 
upgrade and had to make the decision at any rate), we're running 10.1S6 
on DPC-only MX's, and 10.2R3 for MX's with Trio cards.

Neither is perfect. 10.2R3 still has some very serious issues w/SNMP 
counters not working correctly (that don't seem to be entirely Trio 
specific), which fortunately is only a problem if you'd like to, you 
know, bill your customers. :) 10.1S6 hsd actually had a pretty 
reasonable run for a few months now, until a few days ago, when one box 
decided that it was going to stop passing traffic correctly over DPC 
non-E cards with the old rev of EZchip, and also startedly randomly 
corrupting the firewall filters.

Honestly I can't remember the last time I had my number of simultaneous 
open JTAC cases below 30, so no matter where you go there is going to be

suffering. At the time we went with 10.1S6 instead of 10.0R4 because 
10.0R4 had some unresolved issues that 10.1 didn't, and we needed a fix 
for a specific and very obvnoxious MPLS LSP double-counting bug in a 
hurry. We'll be looking into 10.1S8, but I have no feedback on it at the

moment.

That's my MPLS/BGP/ISIS/v4+v6/carrier feature set take at any rate, I'm 
sure there is a completely different set of voodoo potions that goes 
into finding a working version for IRB/etc. :)

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)

Visite http://www.cablevision.com.ar

Visite http://www.fibertel.com.ar

___

Este mensaje es confidencial. Puede contener informacion amparada por el 
secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas 
gracias.

This message is confidential. It may also contain information that is 
privileged or not
authorized to be disclosed. If you have received it by mistake, delete it from 
your system.
You should not copy the messsage nor disclose its contents to anyone. Many 
thanks.
___

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

Re: [j-nsp] Graphing VCP Backplane

2010-11-09 Thread Phill Jolliffe

If you can find a counter for the vcp throughput then you can populate
the "utility mib" with the value and snmp poll and graph it.

http://www.juniper.net/techpubs/en_US/junos10.3/topics/task/operational/snmp-best-practices-utility-mib-using.html

That said for all I know there might be a enterprise mib you can poll
with VCP already. This would be easier than commit script / utility
mib hackery
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Alexander Shikoff

Thanks a lot to all who replied!

On Tue, Nov 09, 2010 at 01:57:00PM +0300, Alexandre Snarskii wrote:
> On Tue, Nov 09, 2010 at 12:18:37PM +0200, Alexander Shikoff wrote:
> > 
> > Filtering of outgoing prefixes is performed via to-MHost policy:
> > minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
> > term Default {
> > from {
> > route-filter 0.0.0.0/0 exact;
> > }
> > then reject;
> > }
> > term Itself {
> > from {
> > protocol static;
> > route-filter 178.214.192.0/19 exact;
> > }
> > then accept;
> > }
> > then accept;
> > 
> > 
> > As you can see only route 178.214.192.0/19 from static routes should be 
> > redistributed into BGP, but I see another routes (direct, static, OSPF) 
> > also being redistributed:
> 
> Because other direct/static/ospf routes match final 'then accept' statement.
> You may either just change 'then accept' to 'then reject', or, if
> you need to provide full-view to your customer, rewrite final term as
> 
>  term transit { 
>   from protocol bgp;
> then accept;
>  }
>  then reject;
> 
> -- 
> In theory, there is no difference between theory and practice. 
> But, in practice, there is. 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Tomas Caslavsky



you have  "then accept" on the of policy  to-MHost so all other routes 
will be accepted

( the reject will announce only  178.214.192.0/19 from static )

Tomas

 Dne 09/11/2010 11:18, Alexander Shikoff napsal(a):

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group 
Downstreams
neighbor 178.214.196.6
description "MHost: World";
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost
term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
}
term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be
redistributed into BGP, but I see another routes (direct, static, OSPF)
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol bgp
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10 holddown, 
3675
hidden)
   Prefix  Nexthop  MED LclprefAS path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.



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

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Christian


I guess you want a  reject instead of the last accept,
rgds,

Christian


Le 09/11/2010 11:18, Alexander Shikoff a écrit :

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group 
Downstreams
neighbor 178.214.196.6
description "MHost: World";
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost
term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
}
term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be
redistributed into BGP, but I see another routes (direct, static, OSPF)
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol bgp
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10 holddown, 
3675
hidden)
   Prefix  Nexthop  MED LclprefAS path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.



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

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Alexandre Snarskii

On Tue, Nov 09, 2010 at 12:18:37PM +0200, Alexander Shikoff wrote:
> 
> Filtering of outgoing prefixes is performed via to-MHost policy:
> minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
> term Default {
> from {
> route-filter 0.0.0.0/0 exact;
> }
> then reject;
> }
> term Itself {
> from {
> protocol static;
> route-filter 178.214.192.0/19 exact;
> }
> then accept;
> }
> then accept;
> 
> 
> As you can see only route 178.214.192.0/19 from static routes should be 
> redistributed into BGP, but I see another routes (direct, static, OSPF) 
> also being redistributed:

Because other direct/static/ospf routes match final 'then accept' statement.
You may either just change 'then accept' to 'then reject', or, if
you need to provide full-view to your customer, rewrite final term as

 term transit { 
from protocol bgp;
then accept;
 }
 then reject;

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

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

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Tore Anderson

Hi Alexander,

* Alexander Shikoff

> Filtering of outgoing prefixes is performed via to-MHost policy:
> minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
> term Default {
> from {
> route-filter 0.0.0.0/0 exact;
> }
> then reject;
> }
> term Itself {
> from {
> protocol static;
> route-filter 178.214.192.0/19 exact;
> }
> then accept;
> }
> then accept;
   - this makes the policy-statement accept all prefixes.
 (except for 0.0.0.0/0)

> As you can see only route 178.214.192.0/19 from static routes should be 
> redistributed into BGP, but I see another routes (direct, static, OSPF) 
> also being redistributed:
>
> [...]
> 
> Why does policy accepts another direct/static/OSPF routes?

Remove the out-of-term «then accept» and I think it'll behave the way
you want, provided that the «Deny-Rest» statement does what its name
suggests.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Alexey Tolstenok

Hi Alexander,
Cause any other routes are matched against the last unnamed term within the
policy to-MHost (the only statement "then accept" without from means that
all routes match)

2010/11/9 Alexander Shikoff 

> Hello,
>
> On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream
> configured as follows:
>
> minot...@br1-gdr.ki# show routing-instances World protocols bgp group
> Downstreams
> neighbor 178.214.196.6
> description "MHost: World";
> import [ Local-Pref-400 from-MHost Deny-Rest ];
> export to-MHost;
> peer-as 21098;
>
>
> Filtering of outgoing prefixes is performed via to-MHost policy:
> minot...@br1-gdr.ki# show policy-options policy-statement to-MHost
> term Default {
>from {
>route-filter 0.0.0.0/0 exact;
>}
>then reject;
> }
> term Itself {
>from {
>protocol static;
>route-filter 178.214.192.0/19 exact;
>}
>then accept;
> }
> then accept;
>
>
> As you can see only route 178.214.192.0/19 from static routes should be
> redistributed into BGP, but I see another routes (direct, static, OSPF)
> also being redistributed:
> minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol
> bgp
> 178.214.196.6
>
> World.inet.0: 337026 destinations, 668447 routes (60 active, 10
> holddown, 3675
> hidden)
>  Prefix  Nexthop  MED LclprefAS path
> * 178.214.192.0/19SelfI
> * 178.214.192.0/27Self 2  I
> * 178.214.192.64/32   SelfI
> * 178.214.192.65/32   Self 2  I
> * 178.214.192.68/32   Self 2  I
> * 178.214.192.69/32   SelfI
> * 178.214.192.96/28   SelfI
> * 178.214.192.128/29  SelfI
> * 178.214.192.136/30  SelfI
> * 178.214.192.140/30  Self 2  I
> * 178.214.192.144/30  SelfI
> * 178.214.193.0/30Self 2  I
> * 178.214.193.4/30Self 2  I
> * 178.214.194.0/30Self 2  I
> * 178.214.194.4/30Self 2  I
> * 178.214.195.0/24Self 2  I
> * 178.214.196.4/30SelfI
>
> Why does policy accepts another direct/static/OSPF routes?
>
> Thanks.
>
> --
> MINO-RIPE
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Alexey Tolstenok
CCIEx3 (R&S, SP, Sec) #17405, JNCIE-M #313
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Tim Vollebregt


Hi Alexander,

When using this policy you are doing the following:

-Reject sending default route
-Sending prefix 178.214.192.0/19
-Accepting all other advertisements by BGP it's default behaviour.

I think this would be fine:

show policy-options policy-statement to-MHost
term Itself {
from {
protocol static;
route-filter 178.214.192.0/19 exact;
}
then next policy;
}
term reject {
then reject;
}

Regards,

Tim

policy-options policy-statement to-MHost
term Itself {
from {
protocol static;
route-filter 178.214.192.0/19 exact;
}
then accept;
  then
next policy;

}

term reject {

then reject;

}


On 09-11-10 11:18, Alexander Shikoff wrote:

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group 
Downstreams
neighbor 178.214.196.6
description "MHost: World";
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost
term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
}
term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be
redistributed into BGP, but I see another routes (direct, static, OSPF)
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol bgp
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10 holddown, 
3675
hidden)
   Prefix  Nexthop  MED LclprefAS path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.


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

Re: [j-nsp] Strange behavior of BGP policy

2010-11-09 Thread William Jackson

My punt would be to get rid of the last accept statement.

Without it your processing should fall through to the default BGP export
policy.

At the moment I guess you are accepting everything.

Best Regards
 
William Jackson
Technical Department
Sapphire Networks



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alexander
Shikoff
Sent: 09 November 2010 11:19
To: juniper-nsp
Subject: [j-nsp] Strange behavior of BGP policy

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream 
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group
Downstreams 
neighbor 178.214.196.6 
description "MHost: World";
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
term Default {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
term Itself {
from {
protocol static;
route-filter 178.214.192.0/19 exact;
}
then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be 
redistributed into BGP, but I see another routes (direct, static, OSPF) 
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19
advertising-protocol bgp 
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10
holddown, 3675 
hidden)
  Prefix  Nexthop  MED LclprefAS
path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.

-- 
MINO-RIPE
___
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

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Julien Goodwin

On 09/11/10 20:12, Keegan Holley wrote:
> 
> On Mon, Nov 8, 2010 at 10:26 PM, Julien Goodwin
> mailto:jgood...@studio442.com.au>> wrote:
> 
> On 09/11/10 14:17, Keegan Holley wrote:
> > BGP full feed on an SRX650 is fine, if you disable flow mode
> (as much as
> > you can, don't forget the ALG's).
> >
> >
> > What's the point of doing BGP on a firewall with firewallling
> turned off?
> 
> Because they're cheaper then the J-series.
> 
> 
> Why bother with either if you're all ethernet? 
> 

Because an SRX650, after discounts, is cheaper, and more robust then a
PC based (ie, standard rack pc, not a special one) router.

Especially once you add support, and don't forget that many carriers
want a DC PSU option, even if they don't use it.

-- 
Julien Goodwin
Studio442
"Blue Sky Solutioneering"



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

[j-nsp] Strange behavior of BGP policy

2010-11-09 Thread Alexander Shikoff

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream 
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group 
Downstreams 
neighbor 178.214.196.6 
description "MHost: World";
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
term Default {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
term Itself {
from {
protocol static;
route-filter 178.214.192.0/19 exact;
}
then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be 
redistributed into BGP, but I see another routes (direct, static, OSPF) 
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol bgp 
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10 holddown, 
3675 
hidden)
  Prefix  Nexthop  MED LclprefAS path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.

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

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Keegan Holley

On Tue, Nov 9, 2010 at 4:01 AM, Maqbool Hashim  wrote:

> Hmmm, that’s interesting.  There were two reasons why I was considering the
> SRX's over the SSG's for this setup.
>
> 1) I had thought that the routing functionality in JunOS would be more
> mature than in the SSGs.
>

I think it depends on what mode you put the device in.  If you want stateful
firewall my guess would be that the SSG code is more stable.  If you put it
in packet mode you essentially have a glorified EX switch which can't really
be compared to the SSG in terms of maturity/stability.

>
> 2) Getting more experience with JUNOS and the SRX's as JUNOS might be the
> one platform for Juniper going forwards.
>

It depends on your needs. There definitely are some places I would use them
and places I wouldn't.

>
> I think we will still go for the SRX's in this case especially as they seem
> to offer better value for money in features and performance.
>

The performance is actually pretty good as well as the number of features it
can support.  It just depends on your design criteria.


-Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:
> juniper-nsp-boun...@puck.nether.net] On Behalf Of Michel de Nostredame
> Sent: 08 November 2010 22:30
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Using SRX's for BGP and Firewalling
>
> On Mon, Nov 8, 2010 at 10:54 AM, Keegan Holley 
> wrote:
> > One of the things that turned us off to the SRX series was the fact
> > that code upgrades have to be done on both firewalls if you run them in
> HA mode.
> >  That's kind of a big deal if you want hitless upgrades or there are
> > issues with the upgrade itself.  BGP is one of the main reasons to use
> > a juniper fw over a cisco in some designs, but I find myself liking
> > the SSG/Netscreen code better for now, even though Juniper has stated
> > that they plan to move everything to JunOS.
>
> This is the reason we still stay in ScreenOS on all of our SSG and continue
> to buy SSG boxes. From our experience that ScreenOS on SSG is much stable
> and mature compares to JUNOS on SRX, if we don't take hardware performance
> into consideration.
>
> Don't know why Juniper is so keen on adapting everything to JUNOS. It only
> break stable things, from a small customer point of view.
> If the JUNOS CLI is that good and important (be honest, it is very good
> from our point of view) why not just add a shell in ScreenOS that accepts
> JUNOS CLI style statements?
>
>
> --
> Michel~
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you are not an intended recipient, please delete this e-mail immediately
> and notify NTS(UK) Ltd on 0844 815 5925
> This e-mail does not necessarily reflect the Company's opinion and should
> not be interpreted as such.
> This message was scanned by Proofpoint Protection Server - please contact
> NTS for further information.
>
> ___
> 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

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Maqbool Hashim

Thanks, taking the responses on board:

I think 2 x SRX210s in HA Active Passive mode connected into 2 x EX2200-24T  
should work for us.  I want to take a default and partial routing table from 
the ISPs.  Partial as in just the routes for that ISP.  I think that should be 
well within the capabilities of the SRX210s.  In addition to that firewalling 
and maybe some VPNs in the future.

Shame about not being able to do hitless upgrades due to having to do upgrades 
on the HA pair at the same time as Keegan Holley said.  However we will just 
have to bear this in mind and plan upgrades accordingly.

From: Keegan Holley [mailto:keegan.hol...@sungard.com]
Sent: 09 November 2010 03:18
To: Julien Goodwin
Cc: Maqbool Hashim; juniper-nsp
Subject: Re: [j-nsp] Using SRX's for BGP and Firewalling

On Mon, Nov 8, 2010 at 7:47 PM, Julien Goodwin 
mailto:jgood...@studio442.com.au>> wrote:
On 09/11/10 02:38, Maqbool Hashim wrote:
> Hi,
>
> I'm looking at doing a multihomed BGP setup using two upstream Internet 
> providers.  We are obtaining PI space and would like to announce our PI space 
> via BGP to our upstreams.I'm looking at using one of the SRX range from 
> Juniper to handle the BGP and firewalling requirement for us.  We don't need 
> a full routing table.  Is it a realistic proposal to do the BGP and 
> firewalling on one device (an SRX) ?  Or am I creating a rod for my own back 
> by not using separate BGP routers and using separate devices to do the 
> firewalling for me.  I'd be interested in hearing if other people are using 
> the SRX's in a similar way.
Thunderbird just ate my response, grr.

BGP full feed on an SRX650 is fine, if you disable flow mode (as much as
you can, don't forget the ALG's).

What's the point of doing BGP on a firewall with firewallling turned off?

BGP with a default inbound and advertising a few routes is fine with
firewalling.
You could probably do this with openwrt if you found the right platform.

Combining a full feed with firewalling is a bad idea, at least on the
branch kit, and probably the SRK1k and 3k.

--
Julien Goodwin
Studio442
"Blue Sky Solutioneering"

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

--
This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not an intended recipient, please delete this e-mail immediately and 
notify NTS(UK) Ltd on 0844 815 5925
This e-mail does not necessarily reflect the Company's opinion and should not 
be interpreted as such.
This message was scanned by Proofpoint Protection Server - please contact NTS 
for further information.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Keegan Holley

On Mon, Nov 8, 2010 at 10:26 PM, Julien Goodwin
wrote:

> On 09/11/10 14:17, Keegan Holley wrote:
> > BGP full feed on an SRX650 is fine, if you disable flow mode (as much
> as
> > you can, don't forget the ALG's).
> >
> >
> > What's the point of doing BGP on a firewall with firewallling turned off?
>
> Because they're cheaper then the J-series.
>

Why bother with either if you're all ethernet?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Using SRX's for BGP and Firewalling

2010-11-09 Thread Maqbool Hashim

Hmmm, that’s interesting.  There were two reasons why I was considering the 
SRX's over the SSG's for this setup.

1) I had thought that the routing functionality in JunOS would be more mature 
than in the SSGs.

2) Getting more experience with JUNOS and the SRX's as JUNOS might be the one 
platform for Juniper going forwards.

I think we will still go for the SRX's in this case especially as they seem to 
offer better value for money in features and performance.

Maq

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Michel de Nostredame
Sent: 08 November 2010 22:30
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Using SRX's for BGP and Firewalling

On Mon, Nov 8, 2010 at 10:54 AM, Keegan Holley  
wrote:
> One of the things that turned us off to the SRX series was the fact 
> that code upgrades have to be done on both firewalls if you run them in HA 
> mode.
>  That's kind of a big deal if you want hitless upgrades or there are 
> issues with the upgrade itself.  BGP is one of the main reasons to use 
> a juniper fw over a cisco in some designs, but I find myself liking 
> the SSG/Netscreen code better for now, even though Juniper has stated 
> that they plan to move everything to JunOS.

This is the reason we still stay in ScreenOS on all of our SSG and continue to 
buy SSG boxes. From our experience that ScreenOS on SSG is much stable and 
mature compares to JUNOS on SRX, if we don't take hardware performance into 
consideration.

Don't know why Juniper is so keen on adapting everything to JUNOS. It only 
break stable things, from a small customer point of view.
If the JUNOS CLI is that good and important (be honest, it is very good from 
our point of view) why not just add a shell in ScreenOS that accepts JUNOS CLI 
style statements?

--
Michel~

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

--
This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not an intended recipient, please delete this e-mail immediately and 
notify NTS(UK) Ltd on 0844 815 5925
This e-mail does not necessarily reflect the Company's opinion and should not 
be interpreted as such.
This message was scanned by Proofpoint Protection Server - please contact NTS 
for further information.

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

Re: [j-nsp] ERX route distribution via RIP

2010-11-09 Thread Tom Teeuwen

Found a solution:
On my loopback interface i used for the pppoe i had to enter the following 
command:
ip rip copy-to-dynamic

Kind regards,
Tom




Van: Tom Teeuwen
Verzonden: zaterdag 6 november 2010 17:03
Aan: juniper-nsp-boun...@puck.nether.net
Onderwerp: RE: ERX route distribution via RIP

My logging shows the following:

DEBUG 11/06/2010 11:01:38 ripRoute (myvirtualrouter): can't receive, circuit not
found

Someone an idee what it is ?

Van: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
namens Tom Teeuwen [...@tomteeuwen.eu]
Verzonden: vrijdag 5 november 2010 9:18
Aan: juniper-nsp@puck.nether.net
Onderwerp: [j-nsp] ERX route distribution via RIP

Hello,

I would like to distribute routes from my CPE (Cisco 877) to my ERX. CPE's are 
connectec via PPP.
On the CPE i configured:
router rip
 version 2
  network 10.0.0.0
  no auto-summary
Config says network 10.0.0.0 but because I used no auto-summary it sends 
10.64.63.0

On my ERX I configured:
router rip
 version 2
 address 10.32.3.254
The address is the adress from the loopback interface used for the ppp

10.32.3.254, Rip is up, loopback209
  Send version = 2
  Receive version = 2
  Authentication mode = none
  Default metric = 1
  Passive Interface = No
  Access-list applied to outgoing route = none
  Access-list applied to incoming route = none
  Route-map applied to outgoing route = none
  Received bad packet = 0
  Received bad routes = 0
  Triggered updates sent = 0
  Received updates = 0

I'm not receiving the routes, also tried with neighborh statement.


Kind regards,
Tom
___
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

Re: [j-nsp] Using SRX's for BGP and Firewalling

[j-nsp] (no subject)

Re: [j-nsp] JunOS 10.0R3 MX960 (DPC's only)

Re: [j-nsp] Graphing VCP Backplane

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Using SRX's for BGP and Firewalling

[j-nsp] Strange behavior of BGP policy

Re: [j-nsp] Using SRX's for BGP and Firewalling

Re: [j-nsp] Using SRX's for BGP and Firewalling

Re: [j-nsp] Using SRX's for BGP and Firewalling

Re: [j-nsp] Using SRX's for BGP and Firewalling

Re: [j-nsp] ERX route distribution via RIP

19 matches

Site Navigation

Mail list logo

Footer information