On Tuesday, October 11, 2011 03:49:33 AM Paul Stewart wrote:
> As the private intercommunication within a Juniper box is
> in a private table, I don't believe it should be viewed
> as "public vs private" as that IP addressing can never
> been reached publicly anyways
That's where I don't hav
On Tuesday, October 11, 2011 04:59:54 AM Vladimir Blazhkun
wrote:
> +1. I guess nobody cares about intersecting address
> spaces in typical BGP L3VPNs, why to discuss router's
> internals then?
See my previous post.
That's why even with l3vpn's in our environment, we still
stick to private add
On Tue, Mar 22, 2011 at 14:03:03, Michael Lee wrote:
> I am trying to eval netflow collector for multi-vendor hardwares,
> anyone could suggest any good commercial netflow collector running on
> Linux?
>
I have been very pleased with netflow auditor
http://www.netflowauditor.com/
Abel.
___
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> boun...@puck.nether.net] On Behalf Of Phil Mayers
> Sent: Monday, November 15, 2010 7:46 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] SRX100/2x0 as small MPLS CPE?
>
> In the recent thread
Its not DHCPv6, as last time I looked (which admittedly was a while ago)
there were still a lot of OS's/devices lacking (decent) DHCPv6 support, but
heres a working SLAAC config that I use on my SRX100 at home (10.4R4.5)
hanging off a HE.net tunnel:
interfaces {
ip-0/0/0 {
unit 0 {
If they all go at the same time it may indicate that the chassis connections
to it is bad. Can you try the same fans in a different chassis?
2011/10/10 Jon Helman
> Graham,
>
>
>
> Previously, I was only receiving a syslog report that the upper fan tray
> had
> failed.
>
>
>
> I went to the ro
Graham,
Previously, I was only receiving a syslog report that the upper fan tray had
failed.
I went to the router site and replaced the upper left fan assembly. After
that they all reported failure.
I placed my hand over the side of the JM20 and I feel no air being pushed
out from the
+1. I guess nobody cares about intersecting address spaces in typical
BGP L3VPNs, why to discuss router's internals then?
Just my .02$.
With best regards,
Vladimir Blazhkun.
On Mon, Oct 10, 2011 at 23:59, Tima Maryin wrote:
> I don't see any problem with it since it's different routing table.
On 10.10.2011 22:43, Jonas Frey (Probe Networks) wrote:
To whomever opened a PR about this:
It has been posted on the amsix mailing list that juniper also needs to
change internal addressing because of the issue with 128.0.0.0/16 as
addresses of this space are used internally within JunOS (see b
hey,
> It has been posted on the amsix mailing list that juniper also needs to
> change internal addressing because of the issue with 128.0.0.0/16 as
> addresses of this space are used internally within JunOS (see below).
It's worse. Example from SRX cluster:
show interfaces terse | match "^(fab
I'm not disagreeing with that at all ... just seemed implied somewhere that
this could have operational impact and I was questioning why/how?
As the private intercommunication within a Juniper box is in a private
table, I don't believe it should be viewed as "public vs private" as that IP
addressi
Keeping away technical constrains (needs to be evaluated, if any); in a simple
way, why would one want to use Public IP range for its Internal addressing ??
Thanks & Regards
Tarique Abbas Nalkhande
-Original Message-
From: Paul Stewart [mailto:p...@paulstewart.org]
Sent: 10 October,
Pardon me for asking this...
But those routes are in "private tables"... does this really mean that
Juniper is going to block the traffic when it doesn't seen it in inet.0 ?
If it does actually block it (meaning someone has proven this out) then
that's kinda scary...
Apologies if I missed somethi
So with 128/16 going live, Juniper may also additionally need to change their
internal addressing!
re0> show interfaces em1 terse
Interface Admin Link ProtoLocal Remote
em1 upup
em1.0 upup inet
To whomever opened a PR about this:
It has been posted on the amsix mailing list that juniper also needs to
change internal addressing because of the issue with 128.0.0.0/16 as
addresses of this space are used internally within JunOS (see below).
Please add this to the PR so it gets fixed.
re0>
Most customers are from layer 2 MSANs in several COs. A few are from legacy
ATM based DSLAM. We need to support both Internet and MPLS-VPN customers.
Ideally we can use E-series to build a full blown BRAS network. However
since all customers use static IP address only, we don't need the standard
BR
On Saturday, October 08, 2011 02:54:40 AM Paul Stewart
wrote:
> Thank you Amos, Robert, Jared, and Scott for the on-list
> and off-list replies.
> Got it up and running – appreciate the responses…
You also want to look out for rogue RA's on the network,
typical of conference or enterprise setu
On Mon, Oct 10, 2011 at 03:23:48PM +0200, Sebastian Wiesinger wrote:
> > Recently RIPE NCC started to allocate addresses from 128/8 to end
> > users, example:
> >
> > https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html
> >
> > Junos software (upto and including 11.1) blo
* Tima Maryin [2011-10-10 14:41]:
> Hello!
>
>
> Recently RIPE NCC started to allocate addresses from 128/8 to end
> users, example:
>
> https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html
>
>
> Junos software (upto and including 11.1) blocks those address by default
On 10/10/11 23:39, Tima Maryin wrote:
> Hello!
>
>
> Recently RIPE NCC started to allocate addresses from 128/8 to end users,
> example:
>
> https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html
> inet.0:
> 128.0.0.0/16 orlonger -- disallowed
It's only the
Hello Tima,
Thank you for making me aware of this and raising this with JTAC, I am sure
that this would be deemed as critical and an easy fix. If you get allocated
a PR, could you please share this with the group so we can monitor the
progress and get a heads up on what releases contain the fix. I
Haha looks like Robert already responded to you... At least it's nice to know
I'm not crazy and someone else would give you similar advice... :-b
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
Follow us on Twitter @JuniperEducate
Sent from my iPad
On Oct
If you are using EX Series, take a look at PVLANs -
http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/private-vlans-ex-series.html
This allows you to split broadcast domains into separate isolated broadcast
subdomains to constrain connectivity while at the same time keeping devices
You should take a look at Private VLANs. Here is a link for EX series but the
concept is the same.
http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/private-vlans-ex-series.html
Robert Juric
On Oct 10, 2011, at 3:59 AM, Richard Zheng wrote:
> Hi,
>
> Here is our setup. Customer
Hello!
Recently RIPE NCC started to allocate addresses from 128/8 to end users,
example:
https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html
Junos software (upto and including 11.1) blocks those address by default:
> show route martians
inet.0:
0.0.0
Hi,
Here is our setup. Customer A comes in on vlan 2001, customer B on vlan 2002
and etc. We may uses separate subnets for each vlan. However it wastes lots
of IPs. Is there a way to use the same subnet, e.g. vlan 2001 uses IP
10.0.0.10, and vlan 2002 uses IP 10.0.0.11 and 10.0.0.12. How about use
26 matches
Mail list logo
