Re: [j-nsp] RAM Type for SRX240

[Ben Dale]

On 25/03/2013, at 12:33 PM, Skeeve Stevens 
 wrote:

> Hey all,
> 
> I've heard quite a few people have self-upgraded their SRX240's from v1 to
> v2's simply by upgrading the RAM from 1Gb to 2Gb.
> 
> Couple of questions.
> 
> 1. Any one got a photo of the inside of the SRX240 (can't find any on
> Google)

Yes - I'll send directly

> 2. What 'exact' kind of RAM is in the SRX240... slots, sizes, speed, ecc?,
> etc

Stock module in the v1s is:

1GB 1RX8 PC2-5300U-555-13-ZZ

There is only a single slot, but basically any old bit of 2G PC5300 will do the 
trick.  My normal supplier has them in stock in QLD for $30

> 3. Is there anything else that makes the B2/H2 from a hardware perspective
> other than the RAM? i.e. CPU, etc?

Flash and possibly CPU.  Still, for $30 I think the RAM upgrade is worth it - 
especially if you're doing any sort of BGP.  I haven't done any hard 
comparisons on whether it improves IDP operation any - most processes in 
branch-SRX Junos seem to have hard-coded memory limits.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RAM Type for SRX240

[Julien Goodwin]

No idea what the actual form factor is, as I never got around to opening
the case of the one I had at $JOB[-1], but from the CPU's spec page:

DDR2 up to 800 MHz
1x 72-bit wide


On 25/03/13 13:33, Skeeve Stevens wrote:
> Hey all,
> 
> I've heard quite a few people have self-upgraded their SRX240's from v1 to
> v2's simply by upgrading the RAM from 1Gb to 2Gb.
> 
> Couple of questions.
> 
> 1. Any one got a photo of the inside of the SRX240 (can't find any on
> Google)
> 
> 2. What 'exact' kind of RAM is in the SRX240... slots, sizes, speed, ecc?,
> etc
> 
> 3. Is there anything else that makes the B2/H2 from a hardware perspective
> other than the RAM? i.e. CPU, etc?
> 
> Can anyone point to a link online where I can get some details of people
> selling the specific kind of RAM... be nice if it was in .au, but happy to
> search myself once I know what it is.
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
> 
> twitter.com/networkceoau ; blog: www.network-ceo.net
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


-- 
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

Re: [j-nsp] RAM Type for SRX240

[Michael Dale]

Hi Skeeve,

3)
a) The v2 model also has 2GB of internal flash, where as the v1 only 
has 1GB. I believe that the flash is soldered on the motherboard.
b) The data sheet now lists 1.8gbit/sec throughput where as the older 
datasheet has 1.5gbit/sec. Not sure if this is because of an updated CPU or 
not. I suspect that the CPU would have had an upgrade as they upgraded the 
SRX210 recently too.

At this stage I don't believe there is much point in upgrading the ram on the 
SRX (unless there is a specific memory limitation that you're hitting). I also 
suspect that this will void the warranty (if it doesn't I might to it myself in 
future when needed).

It is a shame that juniper didn't build these devices to be better future 
proofed.

Thanks,
Michael.





Direct: +61 2 9043 5780
Mobile: +61 422 770 473
Web site: www.dalegroup.net
Support Portal: support.dalegroup.net
CodeCanyon Support Portal: portal.dalegroup.net

On 25/03/2013, at 1:33 PM, Skeeve Stevens 
 wrote:

> Hey all,
> 
> I've heard quite a few people have self-upgraded their SRX240's from v1 to
> v2's simply by upgrading the RAM from 1Gb to 2Gb.
> 
> Couple of questions.
> 
> 1. Any one got a photo of the inside of the SRX240 (can't find any on
> Google)
> 
> 2. What 'exact' kind of RAM is in the SRX240... slots, sizes, speed, ecc?,
> etc
> 
> 3. Is there anything else that makes the B2/H2 from a hardware perspective
> other than the RAM? i.e. CPU, etc?
> 
> Can anyone point to a link online where I can get some details of people
> selling the specific kind of RAM... be nice if it was in .au, but happy to
> search myself once I know what it is.
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
> 
> twitter.com/networkceoau ; blog: www.network-ceo.net
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud
> ___
> 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] LLDP on LAG behaviour

[Steve Rossen]

What version Junos? I ran into some LLDP bugs on early 11.4 versions.


On Wed, Mar 13, 2013 at 5:45 AM, Riccardo S  wrote:

>
>
>
> I’ve a couple of EX in VC configuration
> mode (same Junos) connected with two links in LAG mode and LLDP
> switched-on on the
> aggregate interface.
>
> The problem is that on one VC I see
> lldp neighborship with the other, on the other nothing…
>
> Any idea ?
>
>
>
> 4200A# run show lldp neighbors
>
> Local InterfaceParent InterfaceChassis Id  Port info
>System Name
>
> ge-1/0/1.0 ae0.0   54:e0:31:32:bd:c0   ge-1/0/1.0
> 4200B
>
> {master:0}[edit protocols]
>
>
>
> 4200B# run show lldp neighbors
>
> {master:0}[edit protocols]
> Tks
>
>
>
> ___
> 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] RAM Type for SRX240

[Skeeve Stevens]

Hey all,

I've heard quite a few people have self-upgraded their SRX240's from v1 to
v2's simply by upgrading the RAM from 1Gb to 2Gb.

Couple of questions.

1. Any one got a photo of the inside of the SRX240 (can't find any on
Google)

2. What 'exact' kind of RAM is in the SRX240... slots, sizes, speed, ecc?,
etc

3. Is there anything else that makes the B2/H2 from a hardware perspective
other than the RAM? i.e. CPU, etc?

Can anyone point to a link online where I can get some details of people
selling the specific kind of RAM... be nice if it was in .au, but happy to
search myself once I know what it is.

...Skeeve

*Skeeve Stevens - *eintellego Networks Pty Ltd
ske...@eintellegonetworks.com ; www.eintellegonetworks.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellegonetworks ;  
linkedin.com/in/skeeve

twitter.com/networkceoau ; blog: www.network-ceo.net


The Experts Who The Experts Call
Juniper - Cisco - Cloud
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX series junos 12.x version

[Nitzan Tzelniker]

We had case with vc on 12.2R3
The vc cable didnt forwared traffic in one of the directions
I think it is PSN 2013-03-868

Nitzan


On Sun, Mar 24, 2013 at 12:32 PM, Tore Anderson  wrote:

> * Timh Bergström
>
> > That's interesting, have you seen any other 'gotchas' with 12.2R3? I'm
> > running a 11.3 version and desperately want NSSU (among other things)
> > and have a similar setup, lag/lacp/vlan termination/routing/ospf(v3).
> > Does 3rd party transceivers work? How is missing licenses handled
> > (enforced/warnings)?
>
> I've seen one gotcha - uplinks to a couple of Cisco 6120s went down
> after a short period of uptime. Error seen on the Cisco side was "DCX-No
> ACK in 100 PDUs". No idea if the Cisco or the Juniper was to blame - I
> never investigated the issue, as deleting the "protocols dcbx"
> configuration hierarchy on the EX made the links stay up. I'm not using
> DCBX for anything anyway, so I'm fine with that.
>
> Other than that: So far, so good. YMMV, of course.
>
> I'm using 3rd party optics with no issues, although most of them are
> coded specifically for Juniper. We also use some Cisco-coded DAC cables
> without any problems.
>
> I have no idea on how missing licences are handled, as I have all the
> licences I need.
>
> --
> Tore Anderson
> ___
> 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] Am I carrying this route or not ?

[joel jaeggli]

On 3/24/13 1:24 PM, Zehef Poto wrote:

Thank you Payam. I think I got what you mean.

In this particular case however, the X/22 route is not a customer or
anything. It is the IXP's peering LAN !

So... It means that the person requested all the IXP's members to
null-route the whole peering LAN ? How can you possibly ask for this ?

I peer with several members within this LAN. If I null-route the X/22 LAN,
we agree that my peering sessions will go down, right ?
What they're asking is for you to not carry the prefix in your 
network... The devices directly attached have that route at a lower 
admin distance (e.g. direct) your peering routers will therefore no have 
their sessions go down. However any bgp routes you learn over the 
peering fabric need to have a nexthop that is in your routing table, 
that could be the peering router (nexthop self)  a more specific route 
for the peer router or something else.



Thanks again,

2013/3/24 Payam Chychi 


  Carry a route is the same as accepting a route and having it become
active, allowing traffic to traverse your network to the destination. In
this case the user is asking you to drop the route (attack traffic) at your
edge if possible and not to carry it through your network and deliver it to
the end destination(his network) because its probably saturating or causing
him performance issues.

Normally networks well have a global community string that they can tag a
route with and it will send it to null0, dropping that traffic at the edge
v.s the user withdrawing its -/24 route from the advertise table. You can
also go on the peering router and set the next hop route for the attacked
destination ip to null0 (discard) and only traffic traversing that one
router well drop the traffic (global community well handle this if you
  have a multi homed network)

Local nullroute example:
"Set routing-options static route x.x.x.x/32 discard" ... Something like
this

All your doing is dropping traffic for x.x.x.x/x at your edge, most cases
its a /32 nullroute.

Google is your friend :)
Cheers,
--
Payam Chychi
Network Engineer / Security Specialist

On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:

Hey guys,

Thank you all for the very valuable input. Actually yes, Tobias is right,
I'm having this question because of the (quoted by Tobias) e-mail we got
yesterday across several IXPs.

I just don't understand what is to "carry a route in my backbone". Am I not
supposed to know all of (or most of) the Internet routes, since I work with
tier-1 upstream providers ? As a consequence, it means I'm carrying all
these routes right ?

A "show route X/22" tells that it was advertised by an eBGP peer on one of
my edge routers, and the three other ones learnt this same route via OSPF.

This is where I'm completely confused. What am I supposed to do to "carry"
a route or not ?

Thanks again,

2013/3/24 Tobias Heister 

Hi All,

Am 24.03.2013 00:26, schrieb Jeff Wheeler:

Whoever that person is that said something about "use next-hop-self"
in this context, either you misunderstood them, or you shouldn't
listen to them anymore. That has nothing to do with looking to see if
your router knows about a route.


This sounds like the OP wants to help the cloudfare guys who send the
following mail to DECIX/AMSIX (and probably other IX) yesterday.

We're currently seeing a very large attack directed to our IP on AMS-IX

(X).


We request that all peers:

1) Don't carry this route (X/22) in your backbone. (you can set

next-hop-self, etc). It'll save other security concerns and possible free
transit you're giving away to others.

2) Filter any traffic within to the AMS-IX exchange fabric (again,

X/22), except for your point to [multi]point BGP communications.

--
Kind Regards
Tobias Heister

___
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



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

Re: [j-nsp] Am I carrying this route or not ?

[Payam Tarverdyan Chychi]

Hey,

I'm not sure what the actual exact request from the user was since i 
don't really participate much in the AMS-IX anymore ...


maybe the attack was destined towards their actual nei ip on the 
exchange (initially i assumed /22 was their network, sounds like maybe 
they meant the /22 that is shared for connectivity by the exchange 
members) and they wanted to drop traffic destined to them? You have to 
remember that traffic routed via a router is not the same as traffic 
destined for a router and if I recall the email paste by Tobias, it 
sounded like the use on AMS-IX was getting attacked on their bgp ip and 
asked everyone to either stop carrying traffic from their networks to 
the x.x.x.x/22 or setup a filtering so only BGP protocol is allowed and 
everything else is dropped (someone correct me here if im wrong)


Yes, If you nullroute /22 that belongs to the peering session you are 
going to kill your nei adj with the exchange.
Since only valid traffic is identified to be BGP, i would simply setup 
an ACL and discard anything being sent to the x.x.x.x/22 exchange subnet 
except BGP packets, applied on the "output" (which carry the routing 
table/updates...) and perhaps add your own network mgmt interface ips 
for ICMP ping to help for troubleshooting down the line.


On a side note ...the X0Changes really need to some up with process and 
procedures to help people deal with issues like this, leaving it open in 
this day and age is ... (stupid?) Not all network admins are the same 
nor share the same knowledge and leaving it up to the network admins to 
figure things out sometimes just means bad news for everyone.


Simple link to look at for constructing an ACL on a Juniper (im sure 
google has more!) heh

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16685

cheers,
-Payam

On 13-03-24 1:24 PM, Zehef Poto wrote:

Thank you Payam. I think I got what you mean.

In this particular case however, the X/22 route is not a customer or 
anything. It is the IXP's peering LAN !


So... It means that the person requested all the IXP's members to 
null-route the whole peering LAN ? How can you possibly ask for this ?


I peer with several members within this LAN. If I null-route the X/22 
LAN, we agree that my peering sessions will go down, right ?


Thanks again,

2013/3/24 Payam Chychi mailto:pchy...@gmail.com>>

Carry a route is the same as accepting a route and having it
become active, allowing traffic to traverse your network to the
destination. In this case the user is asking you to drop the route
(attack traffic) at your edge if possible and not to carry it
through your network and deliver it to the end destination(his
network) because its probably saturating or causing him
performance issues.

Normally networks well have a global community string that they
can tag a route with and it will send it to null0, dropping that
traffic at the edge v.s the user withdrawing its -/24 route from
the advertise table. You can also go on the peering router and set
the next hop route for the attacked destination ip to null0
(discard) and only traffic traversing that one router well drop
the traffic (global community well handle this if you  have a
multi homed network)

Local nullroute example:
"Set routing-options static route x.x.x.x/32 discard" ...
Something like this

All your doing is dropping traffic for x.x.x.x/x at your edge,
most cases its a /32 nullroute.

Google is your friend :)
Cheers,
-- 
Payam Chychi

Network Engineer / Security Specialist

On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:


Hey guys,

Thank you all for the very valuable input. Actually yes, Tobias
is right,
I'm having this question because of the (quoted by Tobias) e-mail
we got
yesterday across several IXPs.

I just don't understand what is to "carry a route in my
backbone". Am I not
supposed to know all of (or most of) the Internet routes, since I
work with
tier-1 upstream providers ? As a consequence, it means I'm
carrying all
these routes right ?

A "show route X/22" tells that it was advertised by an eBGP peer
on one of
my edge routers, and the three other ones learnt this same route
via OSPF.

This is where I'm completely confused. What am I supposed to do
to "carry"
a route or not ?

Thanks again,

2013/3/24 Tobias Heister mailto:li...@tobias-heister.de>>


Hi All,

Am 24.03.2013 00 :26, schrieb Jeff Wheeler:

Whoever that person is that said something about "use
next-hop-self"
in this context, either you misunderstood them, or you shouldn't
listen to them anymore. That has nothing to do with looking to
see if
your router knows about a route.


This sounds like the OP wants to help the cloudfare guys who
send the
following mail to DECIX/AMSIX (and probably other IX) yesterday.

Re: [j-nsp] Am I carrying this route or not ?

[Payam Tarverdyan Chychi]

On 13-03-24 2:08 PM, Payam Tarverdyan Chychi wrote:

Hey,

I'm not sure what the actual exact request from the user was since i 
don't really participate much in the AMS-IX anymore ...


maybe the attack was destined towards their actual nei ip on the 
exchange (initially i assumed /22 was their network, sounds like maybe 
they meant the /22 that is shared for connectivity by the exchange 
members) and they wanted to drop traffic destined to them? You have to 
remember that traffic routed via a router is not the same as traffic 
destined for a router and if I recall the email paste by Tobias, it 
sounded like the use on AMS-IX was getting attacked on their bgp ip 
and asked everyone to either stop carrying traffic from their networks 
to the x.x.x.x/22 or setup a filtering so only BGP protocol is allowed 
and everything else is dropped (someone correct me here if im wrong)




--> Sorry, this below was in response to your previous statement of 
being multi-homed (if you null route on not directly connected 
routers). The directly connected router will not drop the bgp sesions 
as its 'directly connected'
Yes, If you nullroute /22 that belongs to the peering session you are 
going to kill your nei adj with the exchange.
Since only valid traffic is identified to be BGP, i would simply setup 
an ACL and discard anything being sent to the x.x.x.x/22 exchange 
subnet except BGP packets, applied on the "output" (which carry the 
routing table/updates...) and perhaps add your own network mgmt 
interface ips for ICMP ping to help for troubleshooting down the line.


On a side note ...the X0Changes really need to some up with process 
and procedures to help people deal with issues like this, leaving it 
open in this day and age is ... (stupid?) Not all network admins are 
the same nor share the same knowledge and leaving it up to the network 
admins to figure things out sometimes just means bad news for everyone.


Simple link to look at for constructing an ACL on a Juniper (im sure 
google has more!) heh

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16685

cheers,
-Payam

On 13-03-24 1:24 PM, Zehef Poto wrote:

Thank you Payam. I think I got what you mean.

In this particular case however, the X/22 route is not a customer or 
anything. It is the IXP's peering LAN !


So... It means that the person requested all the IXP's members to 
null-route the whole peering LAN ? How can you possibly ask for this ?


I peer with several members within this LAN. If I null-route the X/22 
LAN, we agree that my peering sessions will go down, right ?


Thanks again,

2013/3/24 Payam Chychi mailto:pchy...@gmail.com>>

Carry a route is the same as accepting a route and having it
become active, allowing traffic to traverse your network to the
destination. In this case the user is asking you to drop the
route (attack traffic) at your edge if possible and not to carry
it through your network and deliver it to the end destination(his
network) because its probably saturating or causing him
performance issues.

Normally networks well have a global community string that they
can tag a route with and it will send it to null0, dropping that
traffic at the edge v.s the user withdrawing its -/24 route from
the advertise table. You can also go on the peering router and
set the next hop route for the attacked destination ip to null0
(discard) and only traffic traversing that one router well drop
the traffic (global community well handle this if you  have a
multi homed network)

Local nullroute example:
"Set routing-options static route x.x.x.x/32 discard" ...
Something like this

All your doing is dropping traffic for x.x.x.x/x at your edge,
most cases its a /32 nullroute.

Google is your friend :)
Cheers,
-- 
Payam Chychi

Network Engineer / Security Specialist

On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:


Hey guys,

Thank you all for the very valuable input. Actually yes, Tobias
is right,
I'm having this question because of the (quoted by Tobias)
e-mail we got
yesterday across several IXPs.

I just don't understand what is to "carry a route in my
backbone". Am I not
supposed to know all of (or most of) the Internet routes, since
I work with
tier-1 upstream providers ? As a consequence, it means I'm
carrying all
these routes right ?

A "show route X/22" tells that it was advertised by an eBGP peer
on one of
my edge routers, and the three other ones learnt this same route
via OSPF.

This is where I'm completely confused. What am I supposed to do
to "carry"
a route or not ?

Thanks again,

2013/3/24 Tobias Heister mailto:li...@tobias-heister.de>>


Hi All,

Am 24.03.2013 00 :26, schrieb Jeff Wheeler:

Whoever that person is that said something about "use
next-hop-self"
in this context, either you misunderstood th

Re: [j-nsp] Am I carrying this route or not ?

[Zehef Poto]

Thank you Payam. I think I got what you mean.

In this particular case however, the X/22 route is not a customer or
anything. It is the IXP's peering LAN !

So... It means that the person requested all the IXP's members to
null-route the whole peering LAN ? How can you possibly ask for this ?

I peer with several members within this LAN. If I null-route the X/22 LAN,
we agree that my peering sessions will go down, right ?

Thanks again,

2013/3/24 Payam Chychi 

>  Carry a route is the same as accepting a route and having it become
> active, allowing traffic to traverse your network to the destination. In
> this case the user is asking you to drop the route (attack traffic) at your
> edge if possible and not to carry it through your network and deliver it to
> the end destination(his network) because its probably saturating or causing
> him performance issues.
>
> Normally networks well have a global community string that they can tag a
> route with and it will send it to null0, dropping that traffic at the edge
> v.s the user withdrawing its -/24 route from the advertise table. You can
> also go on the peering router and set the next hop route for the attacked
> destination ip to null0 (discard) and only traffic traversing that one
> router well drop the traffic (global community well handle this if you
>  have a multi homed network)
>
> Local nullroute example:
> "Set routing-options static route x.x.x.x/32 discard" ... Something like
> this
>
> All your doing is dropping traffic for x.x.x.x/x at your edge, most cases
> its a /32 nullroute.
>
> Google is your friend :)
> Cheers,
> --
> Payam Chychi
> Network Engineer / Security Specialist
>
> On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:
>
> Hey guys,
>
> Thank you all for the very valuable input. Actually yes, Tobias is right,
> I'm having this question because of the (quoted by Tobias) e-mail we got
> yesterday across several IXPs.
>
> I just don't understand what is to "carry a route in my backbone". Am I not
> supposed to know all of (or most of) the Internet routes, since I work with
> tier-1 upstream providers ? As a consequence, it means I'm carrying all
> these routes right ?
>
> A "show route X/22" tells that it was advertised by an eBGP peer on one of
> my edge routers, and the three other ones learnt this same route via OSPF.
>
> This is where I'm completely confused. What am I supposed to do to "carry"
> a route or not ?
>
> Thanks again,
>
> 2013/3/24 Tobias Heister 
>
> Hi All,
>
> Am 24.03.2013 00:26, schrieb Jeff Wheeler:
>
> Whoever that person is that said something about "use next-hop-self"
> in this context, either you misunderstood them, or you shouldn't
> listen to them anymore. That has nothing to do with looking to see if
> your router knows about a route.
>
>
> This sounds like the OP wants to help the cloudfare guys who send the
> following mail to DECIX/AMSIX (and probably other IX) yesterday.
>
> We're currently seeing a very large attack directed to our IP on AMS-IX
>
> (X).
>
>
> We request that all peers:
>
> 1) Don't carry this route (X/22) in your backbone. (you can set
>
> next-hop-self, etc). It'll save other security concerns and possible free
> transit you're giving away to others.
>
> 2) Filter any traffic within to the AMS-IX exchange fabric (again,
>
> X/22), except for your point to [multi]point BGP communications.
>
> --
> Kind Regards
> Tobias Heister
>
> ___
> 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] Am I carrying this route or not ?

[Payam Chychi]

Carry a route is the same as accepting a route and having it become active, 
allowing traffic to traverse your network to the destination. In this case the 
user is asking you to drop the route (attack traffic) at your edge if possible 
and not to carry it through your network and deliver it to the end 
destination(his network) because its probably saturating or causing him 
performance issues. 

Normally networks well have a global community string that they can tag a route 
with and it will send it to null0, dropping that traffic at the edge v.s the 
user withdrawing its -/24 route from the advertise table. You can also go on 
the peering router and set the next hop route for the attacked destination ip 
to null0 (discard) and only traffic traversing that one router well drop the 
traffic (global community well handle this if you  have a multi homed network)

Local nullroute example:
"Set routing-options static route x.x.x.x/32 discard" ... Something like this

All your doing is dropping traffic for x.x.x.x/x at your edge, most cases its a 
/32 nullroute. 

Google is your friend :)
Cheers,
-- 
Payam Chychi
Network Engineer / Security Specialist


On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:

> Hey guys,
> 
> Thank you all for the very valuable input. Actually yes, Tobias is right,
> I'm having this question because of the (quoted by Tobias) e-mail we got
> yesterday across several IXPs.
> 
> I just don't understand what is to "carry a route in my backbone". Am I not
> supposed to know all of (or most of) the Internet routes, since I work with
> tier-1 upstream providers ? As a consequence, it means I'm carrying all
> these routes right ?
> 
> A "show route X/22" tells that it was advertised by an eBGP peer on one of
> my edge routers, and the three other ones learnt this same route via OSPF.
> 
> This is where I'm completely confused. What am I supposed to do to "carry"
> a route or not ?
> 
> Thanks again,
> 
> 2013/3/24 Tobias Heister 
> 
> > Hi All,
> > 
> > Am 24.03.2013 00:26, schrieb Jeff Wheeler:
> > > Whoever that person is that said something about "use next-hop-self"
> > > in this context, either you misunderstood them, or you shouldn't
> > > listen to them anymore. That has nothing to do with looking to see if
> > > your router knows about a route.
> > > 
> > 
> > 
> > This sounds like the OP wants to help the cloudfare guys who send the
> > following mail to DECIX/AMSIX (and probably other IX) yesterday.
> > 
> > > We're currently seeing a very large attack directed to our IP on AMS-IX
> > (X).
> > > 
> > > We request that all peers:
> > > 
> > > 1) Don't carry this route (X/22) in your backbone. (you can set
> > next-hop-self, etc). It'll save other security concerns and possible free
> > transit you're giving away to others.
> > > 2) Filter any traffic within to the AMS-IX exchange fabric (again,
> > 
> > X/22), except for your point to [multi]point BGP communications.
> > 
> > --
> > Kind Regards
> > Tobias Heister
> > 
> 
> ___
> 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] Am I carrying this route or not ?

[Zehef Poto]

Hey guys,

Thank you all for the very valuable input. Actually yes, Tobias is right,
I'm having this question because of the (quoted by Tobias) e-mail we got
yesterday across several IXPs.

I just don't understand what is to "carry a route in my backbone". Am I not
supposed to know all of (or most of) the Internet routes, since I work with
tier-1 upstream providers ? As a consequence, it means I'm carrying all
these routes right ?

A "show route X/22" tells that it was advertised by an eBGP peer on one of
my edge routers, and the three other ones learnt this same route via OSPF.

This is where I'm completely confused. What am I supposed to do to "carry"
a route or not ?

Thanks again,

2013/3/24 Tobias Heister 

> Hi All,
>
> Am 24.03.2013 00:26, schrieb Jeff Wheeler:
> > Whoever that person is that said something about "use next-hop-self"
> > in this context, either you misunderstood them, or you shouldn't
> > listen to them anymore.  That has nothing to do with looking to see if
> > your router knows about a route.
>
> This sounds like the OP wants to help the cloudfare guys who send the
> following mail to DECIX/AMSIX (and probably other IX) yesterday.
>
> > We're currently seeing a very large attack directed to our IP on AMS-IX
> (X).
> >
> > We request that all peers:
> >
> > 1) Don't carry this route (X/22) in your backbone. (you can set
> next-hop-self, etc). It'll save other security concerns and possible free
> transit you're giving away to others.
> > 2) Filter any traffic within to the AMS-IX exchange fabric (again,
> X/22), except for your point to [multi]point BGP communications.
>
> --
> Kind Regards
> Tobias Heister
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 generates power supply and fan alarms when environment is good

[JP Velders]

> Date: Sun, 24 Mar 2013 11:48:32 +
> From: Peter Tavenier 
> Subject: Re: [j-nsp] EX4200 generates power supply and fan alarms when
> environment is good

> Which other problems do 12.3 have with the chassisd process? 

I've seen the health-monitoring stuff ignore it's timelimit for traps 
(not fully reproducable) on EX. 12.3 has LLDP fixes/features that make 
it a choice hard to ignore in a mixed environment, both EX and MX.

Not doing any exciting stuff with 12.3 on EX yet though.

Now 12.3 on MX VC with L2CPd thrashing seems to be something else... :(

Kind regards,
JP Velders

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

Re: [j-nsp] EX series junos 12.x version

[Timh Bergström]

Sorry for hijacking!

On Sat, Mar 23, 2013 at 11:05 AM, Tore Anderson  wrote:
> * Marco Nesler
>
>> I need to deploy a small VC with EX4200 switches. For the junos version,
>> usually i just stick with the JTAC recommended one. In this case NSSU and
>> non stop bridging are a requirement, so i need to put a 12.something
>> version on the vc. Any suggestion on a good 12.x release, stable and
>> suitable for a small production environment ?
>> The machines will be used basically as a small L2/L3 core, vlan switching,
>> lacp, inter vlan routing, ospfv2/ospfv3 with single area with around 500
>> routes.
>
> Running 12.2R3 on an EX4500-VC here, having pretty much the same tasks
> as you mention above. So far so good. Didn't actually try NSSU yet, but
> having it available for future upgrades was my primary motivation for
> going above 11.4 too.

That's interesting, have you seen any other 'gotchas' with 12.2R3? I'm
running a 11.3 version and desperately want NSSU (among other things)
and have a similar setup, lag/lacp/vlan termination/routing/ospf(v3).
Does 3rd party transceivers work? How is missing licenses handled
(enforced/warnings)?

Thanks!

-- 
Timh Bergström
Head of System Operations
+46 727 406 845

Videoplaza AB
S:t Eriksgatan 46A
Stockholm
www.videoplaza.com

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

Re: [j-nsp] EX4200 generates power supply and fan alarms when environment is good

[Peter Tavenier]

I got the two PR numbers (PR842933, PR858565) for this issues which will be 
fixed in 12.3R2. 

Which other problems do 12.3 have with the chassisd process? 

Kind regards, 
Peter Tavenier

Op 22 mrt. 2013, om 22:09 heeft Giuliano  het volgende 
geschreven:

> Never mind about 12.3 
> 
> It has big trouble with chassid daemon
> 
> Sent from my iPhone
> 
> On 22/03/2013, at 17:12, JP Velders  wrote:
> 
>> 
>>> Date: Thu, 21 Mar 2013 09:04:49 +
>>> From: Peter Tavenier 
>>> Subject: [j-nsp] EX4200 generates power supply and fan alarms when 
>>> environment
>>>is good
>> 
>>> On my EX4200 running version 12.3R1.7 is see the following alarms in the 
>>> logging:
>> 
>>> Mar 21 08:46:46   chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: 
>>> SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, 
>>> jnxContentsL1Index 1, jnxContentsL2Index 3, jnxContentsL3Index 0, 
>>> jnxContentsDescr Power Supply: Power Supply 2 @ 0/2/*, 
>>> jnxOperatingState/Temp 1)
>>> ... 41 more times same type of alarms ...
>>> Mar 21 08:46:46   chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: 
>>> SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, 
>>> jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 1, 
>>> jnxContentsDescr FAN: Fan 1 @ 1/0/0, jnxOperatingState/Temp 1)
>>> Mar 21 08:46:46   chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: 
>>> SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, 
>>> jnxContentsL1Index 8, jnxContentsL2Index 1, jnxContentsL3Index 0, 
>>> jnxContentsDescr Power Supply: Power Supply 0 @ 7/0/*, 
>>> jnxOperatingState/Temp 1)
>>> Mar 21 08:46:46   chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: 
>>> SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, 
>>> jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 2, 
>>> jnxContentsDescr FAN: Fan 2 @ 1/0/1, jnxOperatingState/Temp 1)
>>> Mar 21 08:46:46   chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: 
>>> SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, 
>>> jnxContentsL1Index 8, jnxContentsL2Index 3, jnxContentsL3Index 0, 
>>> jnxContentsDescr Power Supply: Power Supply 2 @ 7/2/*, 
>>> jnxOperatingState/Temp 1)
>>> ... 32 more times same type of alarms ...
>> 
>> Seen here on EX2200C's, EX4200's and EX4500's as well, even funnier, 
>> take a look at what items it is actually complaining about: 
>> non-existing components, basically all other _possible_ VC members.
>> 
>> Was busy with other things, so didn't bother to contact JTAC yet, 
>> think I should have a good laugh this weekend with them on this. :)
>> 
>> Mind you, identical configs do not exhibit this on 11.4 or 12.1. Would 
>> guess this is either a 12.2 or (more likely) a 12.3 oddity.
>> 
>> Kind regards,
>> JP Velders
>> ___
>> 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] Am I carrying this route or not ?

[Tobias Heister]

Hi All,

Am 24.03.2013 00:26, schrieb Jeff Wheeler:
> Whoever that person is that said something about "use next-hop-self"
> in this context, either you misunderstood them, or you shouldn't
> listen to them anymore.  That has nothing to do with looking to see if
> your router knows about a route.

This sounds like the OP wants to help the cloudfare guys who send the following 
mail to DECIX/AMSIX (and probably other IX) yesterday.

> We're currently seeing a very large attack directed to our IP on AMS-IX (X). 
> 
> We request that all peers:
> 
> 1) Don't carry this route (X/22) in your backbone. (you can set 
> next-hop-self, etc). It'll save other security concerns and possible free 
> transit you're giving away to others.
> 2) Filter any traffic within to the AMS-IX exchange fabric (again, X/22), 
> except for your point to [multi]point BGP communications.

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

Re: [j-nsp] internal BGP necessary ?

[Piotr]

There is some problem with upload diagram, even small, here is link:

http://pokazywarka.pl/mg6gtf/

[url=http://pokazywarka.pl/mg6gtf/]diagram[/url]

W dniu 2013-03-24 11:36, Piotr pisze:

Hi

I attached diagram. I have to connect together two different companies.
They have ethernet leased lines, so i can use bgp on private AS numbers.
Each have own OSPF. There is max 1k routes in igp. In this moment i use
only ebgp, i removed ibgp. I made redistrubutions ospf-(e)bgp and
(e)bgp-ospf on A1 A2 B1 B2,  i have also tags against mutual
redistributions. Ebgp has 200 ad on cisco, For now all works, but first
time without ibgp. I'm affraid about some problems like loops..

thanks for any advice or notice
regards,
Piotr


W dniu 2013-03-23 22:29, Patrick Okui pisze:

Hi Piotr,

On  23-Mar-2013 16:13:18 (+0200), Piotr wrote:

I have to connect two networks via bgp, both have own ospf area0, there
are 2 points od redistribution between BGP and OSPF. We use med to have
symmetry, because Junipers must work in flow based (ipsec).


Probably a small ascii diagram would help in this case. If you're using
MED then these two networks are two separate ASes correct? Juniper in
one, Cisco in another?


When we set on cisco  default AD, on juniper we change bgp ad to 20 (


The default AD of eBGP in Cisco is 20, but of iBGP is 200. However,
Cisco by default will wait to see a route in the IGP before installing
it into BGP. I usually set both to 200 (and turn off synchronisation)
thusly:

router bgp NN
   distance bgp 200 200 200
   no synchronisation

You may also want to set bgp deterministic-med on the cisco side to
match how most other vendors treat MED.


like in Cisco) juniper prefer routes from ibgp and there is a problem
with redistribution between ospf and ebgp because there is no prefix
from ospf in rib.


one of BGP's first rules is reachability to the next hop. If BGP can't
reach the next hop it will drop the prefix advertisment. Your IGP has to
guarantee this.



I think that when i remove internal bgp session there should be ok, in
rib there will be prefixes only from ospf so there will be no problem
wirh redistribution? There are some disadvantages when there is no
ibgp ?


I think my first question is ... why are you redistributing in the first
place? iBGP will handle more prefixes than any IGP - so usually you just
want to carry your infrastructure/interface/link prefixes in the IGP and
everything else in BGP. If you go down this route, then a full iBGP
mesh[*] between BGP speakers is required to avoid loops.

Again, it's not easy to guess what you're trying to achieve without a
diagram.

Will OBrien's comments above give hints on getting redistribution
working but then again, we're all shooting in the dark.

--
patrick

[*] or a route reflector or ...





___
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] internal BGP necessary ?

[Piotr]

Hi

I attached diagram. I have to connect together two different companies. 
They have ethernet leased lines, so i can use bgp on private AS numbers. 
Each have own OSPF. There is max 1k routes in igp. In this moment i use 
only ebgp, i removed ibgp. I made redistrubutions ospf-(e)bgp and 
(e)bgp-ospf on A1 A2 B1 B2,  i have also tags against mutual 
redistributions. Ebgp has 200 ad on cisco, For now all works, but first 
time without ibgp. I'm affraid about some problems like loops..


thanks for any advice or notice
regards,
Piotr


W dniu 2013-03-23 22:29, Patrick Okui pisze:

Hi Piotr,

On  23-Mar-2013 16:13:18 (+0200), Piotr wrote:

I have to connect two networks via bgp, both have own ospf area0, there
are 2 points od redistribution between BGP and OSPF. We use med to have
symmetry, because Junipers must work in flow based (ipsec).


Probably a small ascii diagram would help in this case. If you're using
MED then these two networks are two separate ASes correct? Juniper in
one, Cisco in another?


When we set on cisco  default AD, on juniper we change bgp ad to 20 (


The default AD of eBGP in Cisco is 20, but of iBGP is 200. However,
Cisco by default will wait to see a route in the IGP before installing
it into BGP. I usually set both to 200 (and turn off synchronisation)
thusly:

router bgp NN
   distance bgp 200 200 200
   no synchronisation

You may also want to set bgp deterministic-med on the cisco side to
match how most other vendors treat MED.


like in Cisco) juniper prefer routes from ibgp and there is a problem
with redistribution between ospf and ebgp because there is no prefix
from ospf in rib.


one of BGP's first rules is reachability to the next hop. If BGP can't
reach the next hop it will drop the prefix advertisment. Your IGP has to
guarantee this.



I think that when i remove internal bgp session there should be ok, in
rib there will be prefixes only from ospf so there will be no problem
wirh redistribution? There are some disadvantages when there is no ibgp ?


I think my first question is ... why are you redistributing in the first
place? iBGP will handle more prefixes than any IGP - so usually you just
want to carry your infrastructure/interface/link prefixes in the IGP and
everything else in BGP. If you go down this route, then a full iBGP
mesh[*] between BGP speakers is required to avoid loops.

Again, it's not easy to guess what you're trying to achieve without a
diagram.

Will OBrien's comments above give hints on getting redistribution
working but then again, we're all shooting in the dark.

--
patrick

[*] or a route reflector or ...



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

Re: [j-nsp] EX series junos 12.x version

[Tore Anderson]

* Timh Bergström

> That's interesting, have you seen any other 'gotchas' with 12.2R3? I'm
> running a 11.3 version and desperately want NSSU (among other things)
> and have a similar setup, lag/lacp/vlan termination/routing/ospf(v3).
> Does 3rd party transceivers work? How is missing licenses handled
> (enforced/warnings)?

I've seen one gotcha - uplinks to a couple of Cisco 6120s went down
after a short period of uptime. Error seen on the Cisco side was "DCX-No
ACK in 100 PDUs". No idea if the Cisco or the Juniper was to blame - I
never investigated the issue, as deleting the "protocols dcbx"
configuration hierarchy on the EX made the links stay up. I'm not using
DCBX for anything anyway, so I'm fine with that.

Other than that: So far, so good. YMMV, of course.

I'm using 3rd party optics with no issues, although most of them are
coded specifically for Juniper. We also use some Cisco-coded DAC cables
without any problems.

I have no idea on how missing licences are handled, as I have all the
licences I need.

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

Re: [j-nsp] Am I carrying this route or not ?

[Andrew Miehs]

On Sun, Mar 24, 2013 at 8:21 AM, Zehef Poto  wrote:

> I just inherited our backbone. We're a small LIR, we have an AS. The
> backbone consists of four MX80 routers, all acting as eBGP edge ones (there
> are various IP transit links up and running on all of them). I also use
> OSPF adjacencies, and iBGP. Again, all of this is very new to me, so I'm
> learning little by little. Sorry about possible mistakes/errors.
>

Please look at doing some of the Juniper certifications. Especially as an
LIR - you can break things not only for yourself, but all your customers,
and potentially, some of your upstreams if they don't filter you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Am I carrying this route or not ?

[Payam Chychi]

Hey, 

I suggest grabbing a book on routing and ip fundamentals but here is a basic 
overview

You get routs, you install routes, you pass routes... So what does this mean?

Every protocol exchanges routes but before it makes them "active" it must run 
its specific algorithm to ensure best path is selected (most cases this is a 
single path however larger or more advance networks might have eclb or even 
un-eclb"). When the best path is selected its then installed in your routing 
table and becomes active. 

Be careful to not mistake a passed route with an installed route 
(inactive/active). Ex. if you look at a nei bgp table for received routes, you 
are seeing what they are advertising to you, some or all may be active if they 
are best paths.

Number of reasons why a route may not activate: invalid/unreachable next hop 
(including down vlans and interfaces) better AD, better metrics... 

Normally if you have a simple network then you can look at the output of your 
routing table and any valid route well be marked by a "*" beside it, along side 
bunch of other information about the origin of the route

Hope this helps. Make sure to google before making changes... Or at lease do 
"commit confirm 60" which will revert your changes after 60 seconds in case you 
blow up your network and lose access. 

Cheers, 

-- 
Payam Chychi
Network Engineer / Security Specialist


On Saturday, 23 March, 2013 at 4:26 PM, Jeff Wheeler wrote:

> On Sat, Mar 23, 2013 at 5:21 PM, Zehef Poto  wrote:
> > I just inherited our backbone. We're a small LIR, we have an AS. The
> > backbone consists of four MX80 routers, all acting as eBGP edge ones (there
> > are various IP transit links up and running on all of them). I also use
> > OSPF adjacencies, and iBGP. Again, all of this is very new to me, so I'm
> > learning little by little. Sorry about possible mistakes/errors.
> > 
> 
> 
> I think you had better get some help before you break your network!
> 
> > The question is : how can I check if a particular route is being carried in
> > my backbone ? How can I make sure that's not the case ? I'm being suggested
> > to "use next-hop-self", but for some reason I can't fully understand what's
> > involved here...
> > 
> 
> 
> In the CLI, use the command:
> show route 192.0.2.0/24
> Hit ? for options such as exact, detail, etc.
> 
> Whoever that person is that said something about "use next-hop-self"
> in this context, either you misunderstood them, or you shouldn't
> listen to them anymore. That has nothing to do with looking to see if
> your router knows about a route.
> 
> -- 
> Jeff S Wheeler 
> Sr Network Operator / Innovative Network Concepts
> ___
> 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