Re: [j-nsp] MX960 PEMs and 3 phase power

[Tom Storey via juniper-nsp]

We have A+B power delivered 3 phase to the racks, broken out on PDUs, but I
think I must have been thinking about another platform in regards to not
splitting PSUs across phases.

Thanks!

On Thu, 23 Mar 2023, 09:15 Mark Tinka via juniper-nsp, <
juniper-nsp@puck.nether.net> wrote:

>
>
> On 3/23/23 10:29, Gert Doering wrote:
>
> > "typical" data centres over here have 2 primary feeds, either one
> > with UPS and one with generator, or both with (different) UPSes - but
> > depending on the load drawn by a rack, might be presented as multiple
> > circuits with 16A each, and individual circuit breakers.
>
> Same here, and also what we have seen at most of the larger data centres
> we work with.
>
>
> > Now, if another device next to your MX960 has a PSU failure and kicks
> > one of the circuit breakers, what do you want your MX960 to do...  as
> > well, what do you want to happen if the UPS fails, and one of the primary
> > feeds goes down.
>
> We typically deploy a full power complement in all our routers to
> protect against issues such as these, even when we may not necessarily
> need all that power Day 1.
>
>
> > We do not have MX960s, but we did have other devices with 3 PSUs that
> > needed 2 to fully power all line cards, and this was quite a bit annoying
> > - "it says redundant PSUs, but no full feed A / feed B resiliency"...
>
> Even with the 2nd generation high-capacity AC power supplies, the MX960
> requires at least 2 power supplies at a minimum, to power the 2 zones in
> the system.
>
> These power supplies have 2 receptacles per unit, to allow you to drive
> a full chassis running at speed with just 2 of them in the box.
> Otherwise, with just a single receptacle per power supply, you only get
> about half of the energy out of the power supply.
>
> Mark.
> ___
> 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] MX960 PEMs and 3 phase power

[Tom Storey via juniper-nsp]

Hi all.

I had this idea in my head that MX960 power supplies should not be split
across phases, but I cant find anything in any documentation that says that.

Can anyone comment on whether multiple phases per PEM are supported, or
whether its even a reasonable idea to put into practice?

My thought is one PEM on one phase, such that if that phase drops, you drop
that PEM entirely. Or is it worthwhile spreading across phases to keep even
half of a PEM alive and supplying the chassis?

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

Re: [j-nsp] Apply-group brain fart

[Tom Storey]

Hi Balasankar,

I dont have the same issue when I configure in the foreground.

I am running software version 15.1X49-D120.3 if that helps.

Ive been informed that we have support on this gear, so I will raise a case
via JTAC too.

Thanks!
Tom

On Mon, 27 Aug 2018 at 08:28, Balasankar Rajaguru 
wrote:

> Hi Tom,
>
> > Ive tried defining the st0 interface and unit 1 within the interfaces
> stanza, but
> > that didnt help. What am I missing? What can I look at? Am I trying to do
> > something that simply cant be done?
>
> Does the issue happens when the same config is configured in foreground
> under
> Interface stanza without the apply-groups config.
>
> Regards,
> Balasankar
>
> > -Original Message-
> > From: juniper-nsp  On Behalf Of Tom
> > Storey
> > Sent: Friday, August 24, 2018 3:35 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Apply-group brain fart
> >
> > Hi everyone. I am trying to build some configuration groups with the
> intention of
> > keeping related configuration for some IPSEC VPNs etc nicely contained
> in one
> > spot - define all relevant configuration in a group and apply it in one
> go, and also
> > remove it *all* when you delete and remove the configuration group. This
> way,
> > hopefully, little bits and pieces dont get left behind as VPNs are set
> up and torn
> > down, ideally maintaining a cleaner configuration.
> >
> > But I have an odd situation. I am working with a cluster of SRX345, and
> it seems
> > that when ever I apply a config group with an st interface defined, my
> default
> > route disappears and some connected routes seem to disappear or change
> from
> > local to reject, and I lose the ability to manage the cluster via SSH
> and have to
> > use the console. The same does not happen on a standalone SRX110.
> >
> > For example, prior to applying the configuration, my routing table looks
> > like:
> >
> > 0.0.0.0/0  *[Static/5] 16:51:49
> > > to 10.32.31.1 via reth2.0
> > 10.32.31.0/24  *[Direct/0] 16:51:49
> > > via reth2.0
> > 10.32.31.230/32*[Local/0] 16w6d 23:56:30
> >   Local via reth2.0
> > 10.32.31.231/32*[Static/1] 6d 22:02:40
> >   Receive
> > 100.64.0.0/24  *[Direct/0] 16:51:49
> > > via reth3.0
> > 100.64.0.1/32  *[Local/0] 1w0d 19:43:19
> >   Local via reth3.0
> >
> > And after applying the apply group:
> >
> > 10.32.31.230/32*[Local/0] 16w6d 23:58:13
> >   Reject
> > 10.32.31.231/32*[Static/1] 6d 22:04:23
> >   Receive
> > 100.64.0.1/32  *[Local/0] 1w0d 19:45:02
> >   Reject
> > 100.64.255.0/30*[Direct/0] 00:00:04
> > > via st0.1
> > 100.64.255.1/32*[Local/0] 00:00:04
> >   Local via st0.1
> >
> > The very simple configuration group that I have defined is (I removed a
> lot of it
> > during debugging, and this is all that is left):
> >
> > groups {
> > EXAMPLE-VPN {
> > interfaces {
> > st0 {
> > unit 1 {
> > description "DCN VPN to srx110:st0.0";
> > family inet {
> > address 100.64.255.1/30;
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > I set this with:
> >
> > {primary:node0}[edit]
> > root@node0-srx345# set apply-groups EXAMPLE-VPN
> >
> > Pretty straight forward I thought...
> >
> > In the configuration, after the commit has completed (no complaints) I
> do see
> > my st0 configuration inherited, and all of the configuration for my reth
> > interfaces is also inherited, and show int terse shows them all there
> with their IP
> > addresses.
> >
> > # show interfaces | display inheritance
> > ...
> > reth2 {
> > description UNTRUST;
> > ##
> > ## 'redundant-ether-options' was inherited from group
> 'SRX34X-CLUSTER'
> > ##
> > redundant-ether-options {
> > ##
> > ## '1' was inherited from group 'SRX34X-CLUSTER'
> > ##
> > redundancy-group 1;
> > }
> > unit 0 {
> > family inet {
> > address 10.32.31.230/24;
> > }
> > }
> > }
>

[j-nsp] Apply-group brain fart

[Tom Storey]

Hi everyone. I am trying to build some configuration groups with the
intention of keeping related configuration for some IPSEC VPNs etc nicely
contained in one spot - define all relevant configuration in a group and
apply it in one go, and also remove it *all* when you delete and remove the
configuration group. This way, hopefully, little bits and pieces dont get
left behind as VPNs are set up and torn down, ideally maintaining a cleaner
configuration.

But I have an odd situation. I am working with a cluster of SRX345, and it
seems that when ever I apply a config group with an st interface defined,
my default route disappears and some connected routes seem to disappear or
change from local to reject, and I lose the ability to manage the cluster
via SSH and have to use the console. The same does not happen on a
standalone SRX110.

For example, prior to applying the configuration, my routing table looks
like:

0.0.0.0/0  *[Static/5] 16:51:49
> to 10.32.31.1 via reth2.0
10.32.31.0/24  *[Direct/0] 16:51:49
> via reth2.0
10.32.31.230/32*[Local/0] 16w6d 23:56:30
  Local via reth2.0
10.32.31.231/32*[Static/1] 6d 22:02:40
  Receive
100.64.0.0/24  *[Direct/0] 16:51:49
> via reth3.0
100.64.0.1/32  *[Local/0] 1w0d 19:43:19
  Local via reth3.0

And after applying the apply group:

10.32.31.230/32*[Local/0] 16w6d 23:58:13
  Reject
10.32.31.231/32*[Static/1] 6d 22:04:23
  Receive
100.64.0.1/32  *[Local/0] 1w0d 19:45:02
  Reject
100.64.255.0/30*[Direct/0] 00:00:04
> via st0.1
100.64.255.1/32*[Local/0] 00:00:04
  Local via st0.1

The very simple configuration group that I have defined is (I removed a lot
of it during debugging, and this is all that is left):

groups {
EXAMPLE-VPN {
interfaces {
st0 {
unit 1 {
description "DCN VPN to srx110:st0.0";
family inet {
address 100.64.255.1/30;
}
}
}
}
}
}

I set this with:

{primary:node0}[edit]
root@node0-srx345# set apply-groups EXAMPLE-VPN

Pretty straight forward I thought...

In the configuration, after the commit has completed (no complaints) I do
see my st0 configuration inherited, and all of the configuration for my
reth interfaces is also inherited, and show int terse shows them all there
with their IP addresses.

# show interfaces | display inheritance
...
reth2 {
description UNTRUST;
##
## 'redundant-ether-options' was inherited from group 'SRX34X-CLUSTER'
##
redundant-ether-options {
##
## '1' was inherited from group 'SRX34X-CLUSTER'
##
redundancy-group 1;
}
unit 0 {
family inet {
address 10.32.31.230/24;
}
}
}
reth3 {
description "AVAILABLE - Parent for ge-[05]/0/3";
##
## 'redundant-ether-options' was inherited from group 'SRX34X-CLUSTER'
##
redundant-ether-options {
##
## '1' was inherited from group 'SRX34X-CLUSTER'
##
redundancy-group 1;
}
unit 0 {
family inet {
address 100.64.0.1/24;
}
}
}
...
##
## 'st0' was inherited from group 'EXAMPLE-VPN'
##
st0 {
##
## '1' was inherited from group 'EXAMPLE-VPN'
##
unit 1 {
##
## 'DCN VPN to srx110:st0.0' was inherited from group 'EXAMPLE-VPN'
##
description "DCN VPN to srx110:st0.0";
##
## 'inet' was inherited from group 'EXAMPLE-VPN'
##
family inet {
##
## '100.64.255.1/30' was inherited from group 'EXAMPLE-VPN'
##
address 100.64.255.1/30;
}
}
}

So Im a bit struck as to what is going wrong here. The only smoking gun I
see is that my reth subinterfaces appear to be "hardware down" with the
parents claiming "physical link down" when the config group is applied.
Remove it and everything returns to normal.

Ive tried defining the st0 interface and unit 1 within the interfaces
stanza, but that didnt help. What am I missing? What can I look at? Am I
trying to do something that simply cant be done?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Tom Storey]

Thinking out loud.

Wouldnt that assume that you always access your REs inband, therefore
only ever connecting to the master? What if you access them out of
band via their ethernet ports. Each RE then needs its own unique key?

I mean, in theory they probably dont (is there anything to stop
multiple machines sharing the same key?), but it would make sense that
each RE has its own unique "identity"?

Or maybe that becomes a knob, shared identity with key in config or
unique stored on disk?

Or perhaps you store master and slave RE keys in config so they switch
during failover, at least then you have a maximum of two keys to
expect for any given box, which is better than n keys depending on how
many REs you go through? Or some combination of both of these?


On 5 April 2016 at 17:34, Saku Ytti  wrote:
> On 5 April 2016 at 19:18, Tore Anderson  wrote:
>
> Hey,
>
>> Speaking only for myself, I'd accept server key change only if it's a
>> device that is known to have been recently replaced/zeroized/etc. I'd
>> *never* accept a key changing without that being expected for some
>> reason known in advance.
>
> Depending on scale of network and position in the organisation this
> may work. But if network has 100 tacacs account, thousands or tens of
> thousands of devices, it may not be realistic to expect everyone of
> the 100 user has good grasp when device is being replaced. Maybe 5 of
> those even understand what SSH keys mean.
> I think secret-in-config is fast remedy to hard problem. People who
> are able to do something smart should be able to disable it, but it
> seems safest default way to work. But it might be too late now for
> that, as everyone has learned to ignore keys and many people have
> toolised the key verification out.
>
>> That's not really true even if you blindly accept any changed/unknown
>> SSH key, because telnet will leak information like login credentials in
>> cleartext to any passive listener while mounting a successful attack on
>> SSH requires MitM capability. That's more difficult to pull off. Also,
>> if you're using SSH keys your login credentials won't leak even if you
>> are successfully MitMed.
>
> I don't really have statistics on how often you are able to passively
> listen but not inject, but logically it does make sense that passive
> listen is more common, but by which margin, I don't know. From
> security point of view I consider SSH Telnet equal when SSH keys are
> not verified. But I still prefer SSH in this scenario, because it's
> easier to mechanise with SSH via exec() channels etc.
>
> --
>   ++ytti
> ___
> 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] MX960 with 3 RE's?

[Tom Storey]

On 13 January 2016 at 22:32, Mark Tinka  wrote:
> A more current RE means you can run more recent Junos releases. I
> haven't run the RE-S-2000 in a while, so not sure how well it's
> supported by current Junos releases (someone else who has the older RE's
> might want to chime in).

Guess it depends how old an RE you are talking about, and how recent JunOS?

Have seen RE-S-2000's running 13.3.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX VPLS learning domains

[Tom Storey]

Ive been through this myself. The short of it is that you will need a
VPLS instance for each VLAN you wish to carry on SRX.

I dont remember the exact details, but the MX do some "magic" to
automatically carry multiple VLANs through a single VPLS instance,
whereas the SRX do not.

Try as you might, you probably wont get it to work and will waste
countless hours on it (unless theyve changed something in more recent
JunOS versions...) :-)

On 24 December 2015 at 23:26, Dan Rimal  wrote:
> Hi,
>
> I am trying to pass multiple VLAN via single VPLS routing instance and
> assume separate learning domain for every single VLAN. I tried knob
> "vlan-id all" under routing instance without success. O MX series it
> works, it create multiple learning domain, on SRX 240 (second site) nope
> and same MAC from different VLANs collide. Is it some SRX limitation or
> something like this?
>
> Junos 12.1X46-D35 on SRX240B
>
> My config:
>
> ge-0/0/3 {
> vlan-tagging;
> mtu 1590;
> encapsulation flexible-ethernet-services;
> unit 512 {
> description CE-facing-1;
> encapsulation vlan-vpls;
> vlan-id 512;
> family vpls {
> policer {
> input vpls-10m;
> output vpls-10m;
> }
> }
> }
>
>unit 513 {
> description CE-facing-1;
> encapsulation vlan-vpls;
> vlan-id 513;
> family vpls {
> policer {
> input vpls-10m;
> output vpls-10m;
> }
> }
> }
>
>
>VPLS-ALGO-V512 {
> instance-type vpls;
> interface lt-0/0/0.0;
> interface ge-0/0/3.512;
> interface ge-0/0/3.513;
> vlan-id all;
> route-distinguisher 31.41.176.64:512;
> vrf-target target:36736:512;
> protocols {
> vpls {
> site-range 4;
> mac-table-size {
> 128;
> packet-action drop;
> }
> no-tunnel-services;
> site j3r-512 {
> site-identifier 2;
> interface ge-0/0/3.512;
> interface ge-0/0/3.513;
> interface lt-0/0/0.0;
> }
> connectivity-type ce;
> }
> }
> }
>
>
> Thanks,
>
> Dan
>
> ___
> 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] understand "version" and "ns"(namespace) statements in SLAX scripts

[Tom Storey]

According to libslax documentation, which is also the base of Junipers
implementation, the version statement indicates the minimum SLAX
language version required to run your script.

You can find libslax documentation here:
http://www.libslax.org/the-slax-language

On 22 December 2015 at 20:50, Martin T  wrote:
> Hi,
>
> if I look the SLAX script examples in Juniper web-site, then almost
> all of those examples have "version" and multiple "ns" statements. For
> example:
>
> version 1.0;
> ns junos = "http://xml.juniper.net/junos/*/junos;;
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
> ns ext = "http://xmlsoft.org/XSLT/namespace;;
>
>
> While I understand the idea of namespace in XML, then what is the
> point of those statements in SLAX scripts? In addition, how does the
> "version" statement work? Looks like this is (for some reason)
> mandatory as let's say that I have a following very simple script:
>
> $ cat hello_world.slax
> version 1.0;
>
> match / {
>{
>  "Hello World!";
>   }
> }
> $
>
> ..and I remove the "version 1.0;" line, then the script does not operate:
>
>> op hello_world
> error: /var/db/scripts/op/hello_world.slax:1: missing 'version'
> statement; 'match' is not legal
> error: /var/db/scripts/op/hello_world.slax: 1 error detected during parsing
> error: error reading stylesheet: hello_world.slax
>
>>
>
>
>
> thanks,
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MTU on switch interfaces

[Tom Storey]

But would that be +14 assuming no VLAN headers, +18 assuming 1 VLAN
header, +22 assuming q-in-q ?

Was always my understanding that JunOS MTU figures were on-the-wire
frame sizes, whereas Cisco was always payload sizes, with requisite
headers accounted for automagically.

On 19 December 2015 at 16:23, Mark Tinka  wrote:
>
>
> On 19/Dec/15 05:23, Victor Sudakov wrote:
>
>> Dear Colleagues,
>>
>> The MTU on EX4200 ports in port-mode access is 1514 bytes. Shouldn't
>> it become 1518 bytes when the port is reconfigured in port-mode trunk ?
>
> You can set the interface MTU on the EX4200 to whatever you want; up to
> 9,192 bytes.
>
>>
>> And if I want to configure the MTU on an EX4200 to match MTU=2000 on a
>> Cisco Catalyst, what would be the correct value? 2014? 2018?
>
> +14 bytes on the Juniper for whatever you have running on IOS and IOS XE.
>
> Mark.
> ___
> 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] DHCP SERVER in m7i

[Tom Storey]

Use DHCP helper to point to an existing DHCP server where you can
serve leases from would be my thinking.

On 10 November 2015 at 01:15, Sebastian Bermeo
 wrote:
> If this device not support this service, what kind of configuration may I
> use to run this function?  I need a example, I'm learning over junos.
>
>
> On Monday, 9 November 2015, Chad Myers  wrote:
>
>> There was a version of Junos where the dhcp server simply wouldn't work on
>> a M7i.  Digging into traceoptions found that it was because it was trying
>> to synchronize with the dhcp process on the backup routing engine to
>> determine who should be active.  Minor detail that the M7i can't have a
>> second RE was overlooked so the dhcp server never went active.
>>
>> I don't remember the specific code version I was running at the time, but
>> I think it was something in 11.4 or 12.1.
>>
>> -Chad
>>
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net
>> ] On Behalf Of Sebastian Bermeo
>> Sent: Monday, November 09, 2015 3:48 PM
>> To: juniper-nsp@puck.nether.net 
>> Subject: [j-nsp] DHCP SERVER in m7i
>>
>> Hi
>>
>> I was trying  to configure a dhcp server in a m7i, something like this:
>>
>> set interfaces ge-0/0/0 unit 7 description visits
>> set interfaces ge-0/0/0 unit 7 vlan-id 7
>> set interfaces ge-0/0/0 unit 7 family inet address 192.168.7.1/24
>> set interfaces ge-0/0/0 unit 7 family iso
>>
>> set system services dhcp-local-server group dhcp-visitas interface
>> ge-0/0/0.7
>> set access address-assignment pool pool-visitas family inet
>> set access address-assignment pool pool-visitas family inet network
>> 192.168.7.0/24
>> set access address-assignment pool pool-visitas family inet dhcp-attributes
>> name-server 192.168.1.3
>>
>> Its correct this configuration?
>>
>> In addicion in this range of address, I need to start the first
>> dhcp-address in 192.168.7.64 and end in 192.168.7.254, exists a sentence
>> may I use to configure this?
>>
>> I use JUNOS OS 11.4R7.5.
>>
>> Thanks for any answer.
>>
>> Regards.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> 
>>
>> This message may contain confidential information and is intended for
>> specific recipients unless explicitly noted otherwise. If you have reason
>> to believe you are not an intended recipient of this message, please delete
>> it and notify the sender. This message may not represent the opinion of
>> Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and
>> does not constitute a contract or guarantee. Unencrypted electronic mail is
>> not secure and the recipient of this message is expected to provide
>> safeguards from viruses and pursue alternate means of communication where
>> privacy or a binding message is desired.
>>
> ___
> 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] purpose of "commit check"?

[Tom Storey]

On 29 September 2015 at 15:39, Phil Shafer  wrote:
> "show | compare"

o/t but is there any difference between "show | compare" and "show | diff" ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Reboot: right or wrong ?

[Tom Storey]

Normal shutdown.

This is the reason recorded at the end of the shutdown process. Any action
that causes the re to reboot at this stage is equal.
On 14 Aug 2015 7:37 am, james list jameslis...@gmail.com wrote:

 Hi
 In the second case if instead of hitting enter after the normal shutdown
 you power off and then power on, which is the reason you get?

 Greetings
 Il 14/Ago/2015 07:30, MSusiva ssiva1...@gmail.com ha scritto:

  1)  Last reboot reason 0x1:power cycle/failure
 
  [Answer] This could be due to unexpected power failure or power loss to
 RE.
 
  2)  Last reboot reason Router rebooted after a normal
  shutdown.
 
  [Answer] This reason is shown when a reboot is requested using a cli
  command.
 
 
  When command request system halt is executed, the RE is halted and
  reboot reason is recorded as normal shutdown as you see below:
 
  Mar 16 04:27:48 Waiting (max 60 seconds) for system process `vnlru_mem'
  to stop...done
  Waiting (max 60 seconds) for system process `vnlru' to stop...done
  Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
  Waiting (max 60 seconds) for system process `syncer' to stop...
  Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 done
 
  syncing disks... All buffers synced.
  Uptime: 18m37s
  recorded reboot as normal shutdown
 
  The operating system has halted.
  Please press any key to reboot.
 
 
  After this event, if you hit enter the RE is rebooted and reboot reason
 is
  shown as normal shutdown.
 
 
 ___
 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] Replacement HD/SSD for RE-850

[Tom Storey]

I wonder if some double sided tape would suffice to hold it in place
until it needed to be replaced?

On 25 July 2015 at 00:13, Markus unive...@truemetal.org wrote:
 Am 23.07.2015 um 15:26 schrieb Colin Baker:

 Recently had a hard drive fail on one of our RE-850 in an M7i.  Does
 anyone have a known working (preferably SSD) replacement they can
 recommend?  I seem to remember something on juniper.cluepon.net that
 certain models don't fit on the RE board all that well, but the site has
 been down for awhile now.


 A few weeks ago I used Transcend TS32GPSD330 but these newer Transcend
 thingies still cannot get mounted properly and the result looks like this:

 http://truemetal.org/universe/blog/2013/03/upgrading-juniper-re-5-0-re-400-to-ssd/

 Oh well, it was just a backup.

 I've also used KingSpec KSD-PA25.1-032MJ 32 GB in 2013 and KingSpec
 KSD-PA25.6-032SS 32 GB (MLC) in 2014 and these work fine. E.g.
 http://www.amazon.de/dp/B0047U977G - but it's MLC.

 With the KingSpecs you need to set the jumper to cable select or there'll be
 problems.

 Good luck.

 PS: Sad to see cluepon is down. Why?


 ___
 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] M7i stuck in PXE boot loop

[Tom Storey]

Fixed.

Maybe the battery is dieing on the RE and some settings reset, but it
seems the boot list in the BIOS was set to LAN only.

Set it back to PMC,CF,HD,LAN and its back up and running.

Thanks for listening!

Tom

On 17 June 2015 at 16:25, Tom Storey t...@snnap.net wrote:
 Hi everyone. I powered off an M7i yesterday to relocate it to a new
 rack, and after powering back on it seems to have forgotten it has a
 CF and HDD or even a PCMCIA slot, and is only attempting to boot from
 ethernet.

 e.g.

 Will try to boot from :
 Ethernet
 Boot Sequence is reseted due to a PowerUp

 Trying to Boot from Ethernet

 Intel UNDI, PXE-2.0 (build 078)
 Copyright (C) 1997,1998,1999  Intel Corporation
 PXE-E61: Media test failure, check cable
 PXE-M0F: Exiting Intel PXE ROM.

 Trying to Boot from Ethernet

 Intel UNDI, PXE-2.0 (build 078)
 Copyright (C) 1997,1998,1999  Intel Corporation
 PXE-E61: Media test failure, check cable
 PXE-M0F: Exiting Intel PXE ROM.

 Trying to Boot from Ethernet

 

 and so on.

 Tried a reseat of the RE, reseated the CF, reset, power on/off the
 whole chassis. Nothing seems to be working.

 Has anyone come across this before and knows how to fix it, other than
 replacing the RE?

 I had a similar issue with it once before, but at that stage it
 actually booted to a version-ish of JunOS where I was able to
 re-configure the bootlist to include the HDD and CF, this time its not
 even getting that far. :-(

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

[j-nsp] M7i stuck in PXE boot loop

[Tom Storey]

Hi everyone. I powered off an M7i yesterday to relocate it to a new
rack, and after powering back on it seems to have forgotten it has a
CF and HDD or even a PCMCIA slot, and is only attempting to boot from
ethernet.

e.g.

Will try to boot from :
Ethernet
Boot Sequence is reseted due to a PowerUp

Trying to Boot from Ethernet

Intel UNDI, PXE-2.0 (build 078)
Copyright (C) 1997,1998,1999  Intel Corporation
PXE-E61: Media test failure, check cable
PXE-M0F: Exiting Intel PXE ROM.

Trying to Boot from Ethernet

Intel UNDI, PXE-2.0 (build 078)
Copyright (C) 1997,1998,1999  Intel Corporation
PXE-E61: Media test failure, check cable
PXE-M0F: Exiting Intel PXE ROM.

Trying to Boot from Ethernet



and so on.

Tried a reseat of the RE, reseated the CF, reset, power on/off the
whole chassis. Nothing seems to be working.

Has anyone come across this before and knows how to fix it, other than
replacing the RE?

I had a similar issue with it once before, but at that stage it
actually booted to a version-ish of JunOS where I was able to
re-configure the bootlist to include the HDD and CF, this time its not
even getting that far. :-(

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

Re: [j-nsp] [c-nsp] Help with an IPSec scenario

[Tom Storey]

For anyone else that wants to do something like this, I whipped up a EEM applet:

event manager applet update_tunnel0_dest authorization bypass
 event none
 event timer watchdog time 60
 action 1.0 set ifname Tunnel0
 action 1.1 set tundest dyndns.hostname
 action 2.0 cli command show interface $ifname
 action 2.1 regexp (up|down), line protocol $_cli_result result ifadminstatus
 action 2.2 if $_regexp_result eq 1
 action 2.2.0 if $ifadminstatus eq up
 action 2.2.0.0 regexp line protocol is (up|down) $_cli_result
result ifoperstatus
 action 2.2.0.1 if $ifoperstatus eq down
 action 2.2.0.1.0 syslog msg Set new destination for $ifname
 action 2.2.0.1.1 cli command enable
 action 2.2.0.1.2 cli command configure terminal
 action 2.2.0.1.3 cli command interface $ifname
 action 2.2.0.1.4 cli command tunnel destination $tundest
 action 2.2.0.1.5 cli command end
 action 2.2.0.2 end
 action 2.2.1 end
 action 2.3 end

Just re-name it to something more useful, adjust the ifname and
tundest variables, and perhaps the timer interval if you want it to
run more frequently than 60 seconds.

The odd thing is that I have a Cisco behind NAT firing up an IPSec
tunnel to a Juniper, and that works just fine. Strange that it wouldnt
work the other way around...

On 13 March 2015 at 17:06, Tom Storey t...@snnap.net wrote:
 Hi Nick,

 Yeah, I dont believe Juniper support NHRP, thats a Cisco thing.

 I just tried replacing my Tunnel config with a Virtual-Template
 config, I now get an IPSec SA, and a Virtual-Access interface is
 created and seems to be receiving packets if I run a ping from the
 Juniper...!

 How to get an IP from my ptp subnet on to it to permit routing back in
 the other direction is the next question...

 I may yet have to surrender and do something similar to what youve
 done. A little less elegant, but it will work at the least.

 Thanks!

 On 13 March 2015 at 16:48, Nick Cutting ncutt...@edgetg.co.uk wrote:
 Further to this, I don't think it is possible without a hardcoded 
 destination on the VTI tunnel interface.  The reason it works with dynamic 
 spoke public addresses with DMVPN is the dynamic spoke does a NHRP 
 registration, and the tunnel endpoint is built using this information.

 There is no such process with static VTI.

 Phase1 is fine, then Phase2 fails with debug messages that don't necessary 
 explain why this won't work.

 I don't think Junos supports NHRP, but I could be wrong.


 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
 Cutting
 Sent: 13 March 2015 16:25
 To: Tom Storey; cisco-nsp; juniper-nsp@puck.nether.net
 Subject: Re: [c-nsp] Help with an IPSec scenario

 I tried to get this to work for weeks, in the end, I used dyn-dns on the 
 Juniper side, and ran an EMM script on the cisco router (2911 - 15.3) that 
 looked up the dyn-dys juniper name, then rewrote the tunnel destination, 
 every 5 minutes.

 I can't see your config, as it is blocked at my work - I was using 0.0.0.0/0 
 as the proxy id on the juniper side, and a normal static VTI tunnel on the 
 Juniper side.

 This works, as it is my home setup back to the office.

 I did not try DVTI, And I'm not sure if it uses NHRP in the same way as 
 DMVPN would (with no gre) - which wouldn't probably work with a juniper 
 routed tunnel anyway.



 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom 
 Storey
 Sent: 13 March 2015 15:35
 To: cisco-nsp; juniper-nsp@puck.nether.net
 Subject: [c-nsp] Help with an IPSec scenario

 Hi everyone,

 Trying to establish an IPSec tunnel (route based) between a Juniper SRX and 
 a Cisco IOS router.

 The topology is two routers with DSL services, the SRX is on a dynamic IP, 
 the Cisco on a static. No NAT is involved in the path between the two 
 routers.

 Heres the configs Im working on: http://pastebin.com/gUEFVTau

 Basically what Im getting is this...

 In main mode, phase 1 is OK, and I get probably 99% of the way in phase 2, 
 but it doesnt quite complete, with errors like proxy identities not 
 supported.

 I can fix this by configuring Tunnel0's destination as the IP of the SRX /at 
 the time/ and can then ping across the tunnel. But this obviously isnt a 
 long term solution because if the IP of the SRX changes (and it does, 
 frequently, because the DSL is notoriously
 unstable) then the VPN stops working.

 So I try to go aggressive mode, but this is even worse, with phase 1 not 
 completing with errors like IKE packet from x.x.x.x was not encrypted and 
 it should've been, and never really making it past AG_INIT_EXCH.

 This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE

 Based on my supplied configs, can anyone help me come up with a solution 
 that allows the SRX to initiate a connection from any random IP, and the 
 Cisco accepts it but I dont have to configure the IP of the SRX on the Cisco 
 in order for it to work? I feel like Im tantalisingly close

Re: [j-nsp] [c-nsp] Help with an IPSec scenario

[Tom Storey]

Excuse the long post, but I just want all this out in the open in case
someone else finds it useful. :-)

Here are my Cisco and Juniper configs for the IPSec portion. Add in
the EEM script to help with updating the tunnel destination IP on the
Cisco, and you'll need some kind of event script for the Juniper to
update a dynamic DNS hostname somewhere to complete the solution. I
think I found one on Junipers website, or maybe it was made by someone
else (apologies if I got the credits for that mixed up!)

interfaces {
st0 {
unit 3 {
description IPv4 tunnel to c2821;
family inet {
mtu 1420;
address 172.25.144.243/31;
}
}
}
}
event-options {
policy dyn-dns-updater {
events SYSTEM;
attributes-match {
SYSTEM.message matches EVENT Add at-1/0/0.0;
}
then {
event-script dyn-dns-update.xslt;
}
}
event-script {
file dyn-dns-update.xslt;
}
}
security {
ike {
proposal ike-proposal-j2c-1 {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
lifetime-seconds 28800;
}
policy ike-policy-j2c-1 {
mode main;
proposals ike-proposal-j2c-1;
pre-shared-key ascii-text SECRET-DATA; ## SECRET-DATA
}
gateway ike-gateway-j2c-1 {
ike-policy ike-policy-j2c-1;
address 1.2.3.4;
local-identity hostname srx110c2821;
external-interface at-1/0/0.0;
}
}
ipsec {
proposal ipsec-proposal-j2c-1 {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
lifetime-kilobytes 4608000;
}
policy ipsec-policy-j2c-1 {
proposals ipsec-proposal-j2c-1;
}
vpn ipsec-vpn-j2c-1 {
bind-interface st0.3;
ike {
gateway ike-gateway-j2c-1;
ipsec-policy ipsec-policy-j2c-1;
}
establish-tunnels immediately;
}
}
}



crypto keyring j2c-keyring
  pre-shared-key address 0.0.0.0 0.0.0.0 key SECRET-DATA
!
crypto isakmp policy 1
 encr aes 256
 hash sha256
 authentication pre-share
 group 5
crypto isakmp profile j2c-1
   keyring j2c-keyring
   match identity user-fqdn srx110c2821
!
crypto ipsec transform-set ESP_AES256 esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile j2c-1
 set transform-set ESP_AES256
 set isakmp-profile j2c-1
!
interface Tunnel0
 description IPv4 tunnel to srx110
 ip address 172.25.144.242 255.255.255.254
 ip mtu 1420
 tunnel source Dialer0
 tunnel mode ipsec ipv4
 ! tunnel destination set by EEM script
 tunnel protection ipsec profile j2c-1
!

Pastebin version (friendlier formatting etc): http://pastebin.com/nPXTcdvj

On 13 March 2015 at 19:08, Nick Cutting ncutt...@edgetg.co.uk wrote:
 Very nice, your EMM is much better than mine !

 -Original Message-
 From: Tom Storey [mailto:t...@snnap.net]
 Sent: 13 March 2015 18:09
 To: Nick Cutting
 Cc: cisco-nsp; juniper-nsp@puck.nether.net
 Subject: Re: [c-nsp] Help with an IPSec scenario

 For anyone else that wants to do something like this, I whipped up a EEM 
 applet:

 event manager applet update_tunnel0_dest authorization bypass  event none  
 event timer watchdog time 60  action 1.0 set ifname Tunnel0
  action 1.1 set tundest dyndns.hostname
  action 2.0 cli command show interface $ifname
  action 2.1 regexp (up|down), line protocol $_cli_result result 
 ifadminstatus  action 2.2 if $_regexp_result eq 1  action 2.2.0 if 
 $ifadminstatus eq up
  action 2.2.0.0 regexp line protocol is (up|down) $_cli_result result 
 ifoperstatus  action 2.2.0.1 if $ifoperstatus eq down
  action 2.2.0.1.0 syslog msg Set new destination for $ifname
  action 2.2.0.1.1 cli command enable
  action 2.2.0.1.2 cli command configure terminal
  action 2.2.0.1.3 cli command interface $ifname
  action 2.2.0.1.4 cli command tunnel destination $tundest
  action 2.2.0.1.5 cli command end
  action 2.2.0.2 end
  action 2.2.1 end
  action 2.3 end

 Just re-name it to something more useful, adjust the ifname and tundest 
 variables, and perhaps the timer interval if you want it to run more 
 frequently than 60 seconds.

 The odd thing is that I have a Cisco behind NAT firing up an IPSec tunnel to 
 a Juniper, and that works just fine. Strange that it wouldnt work the other 
 way around...

 On 13 March 2015 at 17:06, Tom Storey t...@snnap.net wrote:
 Hi Nick,

 Yeah, I dont believe Juniper support NHRP, thats a Cisco thing.

 I just tried replacing my Tunnel config with a Virtual-Template
 config, I now get an IPSec SA, and a Virtual-Access interface is
 created and seems to be receiving packets if I run a ping from the
 Juniper

[j-nsp] Help with an IPSec scenario

[Tom Storey]

Hi everyone,

Trying to establish an IPSec tunnel (route based) between a Juniper
SRX and a Cisco IOS router.

The topology is two routers with DSL services, the SRX is on a dynamic
IP, the Cisco on a static. No NAT is involved in the path between the
two routers.

Heres the configs Im working on: http://pastebin.com/gUEFVTau

Basically what Im getting is this...

In main mode, phase 1 is OK, and I get probably 99% of the way in
phase 2, but it doesnt quite complete, with errors like proxy
identities not supported.

I can fix this by configuring Tunnel0's destination as the IP of the
SRX /at the time/ and can then ping across the tunnel. But this
obviously isnt a long term solution because if the IP of the SRX
changes (and it does, frequently, because the DSL is notoriously
unstable) then the VPN stops working.

So I try to go aggressive mode, but this is even worse, with phase 1
not completing with errors like IKE packet from x.x.x.x was not
encrypted and it should've been, and never really making it past
AG_INIT_EXCH.

This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE

Based on my supplied configs, can anyone help me come up with a
solution that allows the SRX to initiate a connection from any random
IP, and the Cisco accepts it but I dont have to configure the IP of
the SRX on the Cisco in order for it to work? I feel like Im
tantalisingly close, but after several hours at it so far and copious
amounts of googling, I just cant see the solution...

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

Re: [j-nsp] [c-nsp] Help with an IPSec scenario

[Tom Storey]

Hi Nick,

Yeah, I dont believe Juniper support NHRP, thats a Cisco thing.

I just tried replacing my Tunnel config with a Virtual-Template
config, I now get an IPSec SA, and a Virtual-Access interface is
created and seems to be receiving packets if I run a ping from the
Juniper...!

How to get an IP from my ptp subnet on to it to permit routing back in
the other direction is the next question...

I may yet have to surrender and do something similar to what youve
done. A little less elegant, but it will work at the least.

Thanks!

On 13 March 2015 at 16:48, Nick Cutting ncutt...@edgetg.co.uk wrote:
 Further to this, I don't think it is possible without a hardcoded destination 
 on the VTI tunnel interface.  The reason it works with dynamic spoke public 
 addresses with DMVPN is the dynamic spoke does a NHRP registration, and the 
 tunnel endpoint is built using this information.

 There is no such process with static VTI.

 Phase1 is fine, then Phase2 fails with debug messages that don't necessary 
 explain why this won't work.

 I don't think Junos supports NHRP, but I could be wrong.


 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
 Cutting
 Sent: 13 March 2015 16:25
 To: Tom Storey; cisco-nsp; juniper-nsp@puck.nether.net
 Subject: Re: [c-nsp] Help with an IPSec scenario

 I tried to get this to work for weeks, in the end, I used dyn-dns on the 
 Juniper side, and ran an EMM script on the cisco router (2911 - 15.3) that 
 looked up the dyn-dys juniper name, then rewrote the tunnel destination, 
 every 5 minutes.

 I can't see your config, as it is blocked at my work - I was using 0.0.0.0/0 
 as the proxy id on the juniper side, and a normal static VTI tunnel on the 
 Juniper side.

 This works, as it is my home setup back to the office.

 I did not try DVTI, And I'm not sure if it uses NHRP in the same way as DMVPN 
 would (with no gre) - which wouldn't probably work with a juniper routed 
 tunnel anyway.



 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom 
 Storey
 Sent: 13 March 2015 15:35
 To: cisco-nsp; juniper-nsp@puck.nether.net
 Subject: [c-nsp] Help with an IPSec scenario

 Hi everyone,

 Trying to establish an IPSec tunnel (route based) between a Juniper SRX and a 
 Cisco IOS router.

 The topology is two routers with DSL services, the SRX is on a dynamic IP, 
 the Cisco on a static. No NAT is involved in the path between the two routers.

 Heres the configs Im working on: http://pastebin.com/gUEFVTau

 Basically what Im getting is this...

 In main mode, phase 1 is OK, and I get probably 99% of the way in phase 2, 
 but it doesnt quite complete, with errors like proxy identities not 
 supported.

 I can fix this by configuring Tunnel0's destination as the IP of the SRX /at 
 the time/ and can then ping across the tunnel. But this obviously isnt a long 
 term solution because if the IP of the SRX changes (and it does, frequently, 
 because the DSL is notoriously
 unstable) then the VPN stops working.

 So I try to go aggressive mode, but this is even worse, with phase 1 not 
 completing with errors like IKE packet from x.x.x.x was not encrypted and it 
 should've been, and never really making it past AG_INIT_EXCH.

 This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE

 Based on my supplied configs, can anyone help me come up with a solution that 
 allows the SRX to initiate a connection from any random IP, and the Cisco 
 accepts it but I dont have to configure the IP of the SRX on the Cisco in 
 order for it to work? I feel like Im tantalisingly close, but after several 
 hours at it so far and copious amounts of googling, I just cant see the 
 solution...

 Thanks.
 ___
 cisco-nsp mailing list  cisco-...@puck.nether.net 
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

 ___
 cisco-nsp mailing list  cisco-...@puck.nether.net 
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [j-nsp] Activating FPC's on an EX8208

[Tom Storey]

Interesting, Ive got a couple of MX960's with high line AC PEMs in front of
me, and if I only turn one of them on, I only get half a router powered up.
As far as I know, there is still zoning with high line AC PEMs.

PEM0 and PEM2 supply one half of the router (slots 0-5 and RE0 and one fan
tray), and PEM1 and PEM3 the other half (RE1 and slots 6-11 and the other
fan tray) - as I understand it.

So we do PEM0 and PEM1 as A feeds and PEM2 and PEM3 as B feeds, therefore
if you lose A or B the router keeps running with all slots.

So 2 may be mandatory, but you have to do one for each zone.

Smaller boxes like MX240 we can power entirely with a single PEM.

On 5 March 2015 at 13:01, Kevin Wormington kw...@sofnet.com wrote:

 That's right the power zones are only for DC power.  AC has only one zone,
 but according to the link below 2 high line AC supplies are mandatory and 3
 low-line.  I guess it might come up on a single high line depending on what
 line cards you have.

 http://www.juniper.net/documentation/en_US/release-
 independent/junos/topics/reference/specifications/calculating-power-
 requirements-mx480.html


 On 03/05/2015 12:48 AM, Mark Tinka wrote:



 On 4/Mar/15 18:21, Kevin Wormington wrote:

 I don't have any experience the the large EXs, but is there a chance
 you don't have enough power to the chassis to bring the line cards
 online? I know the larger MXs require a certain number of supplies and
 IIRC certain supplies power certain slots.  So if you just have one
 supply plugged into 120VAC it may not bring the line cards online.


 For the MX routers, I think this is only if you run DC or the AC low
 power units (i.e., 120VAC).

 IIRC, a single 240VAC PSU on an MX should be able to drive an entire MX
 chassis, non?

 Mark.
 ___
 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] MPC3E oversubscribe rate with two 10x10GE MICs

[Tom Storey]

As I understand it, it is still split 50/50% wise. Two active MIC slots
arbitrate equally for packet processing resources, regardless of how much
bandwidth they could potentially (or not) use. A 20x1G MIC will essentially
waste 40G of throughput. Yeah. :-/

On 5 December 2014 at 19:10, Olivier Benghozi olivier.bengh...@wifirst.fr
wrote:

 If you use one 10x10GE MIC and one 20x1GE, on the paper 120 Gb/s would
 mean no oversubscribing, but how the capacity will be really divided?

  Tom Storey t...@snnap.net wrote :
 
  As was explained to me a while back, the MPC3E has ~120gbit of capacity.
 
  But the devil was in how that capcity is shared between the two MIC
 slots.
 
  When you have two active MICs that capacity is divided equally between
 the
  two MICs: 50/50% or ~60/60gbps. It is NOT a case of operate one card at
  full whack and only use a couple of ports on the other.
 
  If you plan to put in a second 10x10 MIC then you'll have to shuffle your
  circuits around to balance them across the two MICs too.
 
  And if you need all wire speed ports then you need the 16x10G MPC3, and
  only use 3 ports of each PIC.
 
  On 30 November 2014 at 23:22, Robert Hass robh...@gmail.com wrote:
 
  Hi
  I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960
  routers.
 
  I need to add 10GE ports, if I will put second 10x10GE MIC in existing
  MPC3E what will be oversubscribe rate ? I'm not sure but docs says about
  200Gbps for MPC3E then It should be wire-speed if docs claims
 full-duplex
  or 1:2 if docs claims half-duplex.
 
  What is best solution (from price point of view) to have 16 x 10GE in 1
  slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ?


 ___
 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] MPC3E oversubscribe rate with two 10x10GE MICs

[Tom Storey]

As was explained to me a while back, the MPC3E has ~120gbit of capacity.

But the devil was in how that capcity is shared between the two MIC slots.

When you have two active MICs that capacity is divided equally between the
two MICs: 50/50% or ~60/60gbps. It is NOT a case of operate one card at
full whack and only use a couple of ports on the other.

If you plan to put in a second 10x10 MIC then you'll have to shuffle your
circuits around to balance them across the two MICs too.

And if you need all wire speed ports then you need the 16x10G MPC3, and
only use 3 ports of each PIC.

On 30 November 2014 at 23:22, Robert Hass robh...@gmail.com wrote:

 Hi
 I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960
 routers.

 I need to add 10GE ports, if I will put second 10x10GE MIC in existing
 MPC3E what will be oversubscribe rate ? I'm not sure but docs says about
 200Gbps for MPC3E then It should be wire-speed if docs claims full-duplex
 or 1:2 if docs claims half-duplex.

 What is best solution (from price point of view) to have 16 x 10GE in 1
 slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ?

 Rob
 ___
 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] Cisco to Juniper, route based IPSec VPN

[Tom Storey]

Hi everyone.

Im trying to set up a route based VPN between a Cisco IOS router (1841) and
a Juniper SRX, where the Cisco is sitting behind NAT and the Juniper is out
on the public Internet.

My tunnel interfaces arent coming up at either end, but I feel like Im
teetering on the edge of success.

Phase 1 seems to be ok (up in agressive mode), but phase 2 is a little
dubious. debug crypto ipsec on the Cisco isnt really giving up much in
the way of error messages. The Juniper reports SA not initialised and the
Cisco seems to be sending SA requests...

I feel like Im making a really noobie mistake but I cant figure out what.
Ive trawled the Internet for sample configs and from what I can see my only
difference is the specifics for my particular setup (IPs, leys,
proposals/transforms.)

Does anyone have a sample config I can review, or would you be willing to
review my current configs?

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

Re: [j-nsp] Cisco to Juniper, route based IPSec VPN

[Tom Storey]

 proxy-identity remote 10.250.1.1/32
 set security ipsec vpn COMPANY ike ipsec-policy IPSEC-POLICY
 set security ipsec vpn COMPANY establish-tunnels immediately
 set security policies from-zone INSIDE to-zone INSIDE policy
 default-permit match source-address any
 set security policies from-zone INSIDE to-zone INSIDE policy
 default-permit match destination-address any
 set security policies from-zone INSIDE to-zone INSIDE policy
 default-permit match application any
 set security policies from-zone INSIDE to-zone INSIDE policy
 default-permit then permit
 set security policies from-zone INSIDE to-zone OUTSIDE policy
 default-permit match source-address any
 set security policies from-zone INSIDE to-zone OUTSIDE policy
 default-permit match destination-address any
 set security policies from-zone INSIDE to-zone OUTSIDE policy
 default-permit match application any
 set security policies from-zone INSIDE to-zone OUTSIDE policy
 default-permit then permit
 set security zones security-zone OUTSIDE interfaces fe-0/0/7.0
 host-inbound-traffic system-services dhcp
 set security zones security-zone OUTSIDE interfaces fe-0/0/7.0
 host-inbound-traffic system-services ping
 set security zones security-zone OUTSIDE interfaces fe-0/0/7.0
 host-inbound-traffic system-services ike
 set security zones security-zone OUTSIDE interfaces fe-0/0/7.0
 host-inbound-traffic system-services ssh
 set security zones security-zone INSIDE host-inbound-traffic
 system-services all
 set security zones security-zone INSIDE host-inbound-traffic protocols all
 set security zones security-zone INSIDE interfaces ge-0/0/0.0
 set security zones security-zone INSIDE interfaces lo0.0
 set security zones security-zone INSIDE interfaces st0.0
 set security zones security-zone INSIDE interfaces gr-0/0/0.0



 -







 -Original Message-
 From: Tom Storey [mailto:t...@snnap.net]
 Sent: Friday, November 21, 2014 9:00 AM
 To: cisco-nsp; juniper-nsp@puck.nether.net
 Subject: [j-nsp] Cisco to Juniper, route based IPSec VPN

 Hi everyone.

 Im trying to set up a route based VPN between a Cisco IOS router (1841)
 and a Juniper SRX, where the Cisco is sitting behind NAT and the Juniper is
 out on the public Internet.

 My tunnel interfaces arent coming up at either end, but I feel like Im
 teetering on the edge of success.

 Phase 1 seems to be ok (up in agressive mode), but phase 2 is a little
 dubious. debug crypto ipsec on the Cisco isnt really giving up much in
 the way of error messages. The Juniper reports SA not initialised and the
 Cisco seems to be sending SA requests...

 I feel like Im making a really noobie mistake but I cant figure out what.
 Ive trawled the Internet for sample configs and from what I can see my
 only difference is the specifics for my particular setup (IPs, leys,
 proposals/transforms.)

 Does anyone have a sample config I can review, or would you be willing to
 review my current configs?

 Thanks in advance.
 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] T4000 power architecture

[Tom Storey]

Found an ebay listing with some pictures of a T1600 power supply
(T640/T1600/T4000, its all the same chassis so the pinout should be
the same) that also includes a description of each pin on the power
supply...

http://www.potomacescrap.com/ebay/images/STORE-5409-0005.JPG
http://www.potomacescrap.com/ebay/images/STORE-5409-0003.JPG

Seems there are some pins on one connector that relate to each FPC
(enable pins, perhaps detects when an FPC is inserted?) and there are
-48 outputs from 0 to 8 (FPC 0-7 + 1 more for ?)

Perhaps the power supply detects when an FPC is inserted and enables
the related output, or all of the outputs are enabled regardless but
individually traced to each FPC slot rather than sharing a common
trace on the backplane. It is possible to configure on or off the
power supply to individual FPC slots, so it seems plausible that each
power supply has individually switchable power outlets?

Though TBH after nearly 3 weeks I'd just do the maintenance and see if
swapping the power supply is simple enough to fix the problem. If you
havent got an answer from Juniper by now, how many more weeks are you
potentially going to wait before you either cant turn up more
capacity, or a power feed failure takes down your FPC and the capacity
on it? :-)

On 25 September 2014 00:21, Sam Silvester sam.silves...@gmail.com wrote:
 Hi Fred,

 Thanks for the reply. Your suggestions from step 1 - 3.2 makes sense.

 Having said that, rather than swapping the PEMs in step 4, I can just swap
 PEM1 with a replacement (we have support on the chassis). The difficulty
 for me is we have to get electricians onsite out of hours to do this -
 which I'm trying to avoid if it's unlikely the PEM is actually at fault.
 This would be the case if the PEM output is carried to the FPCs via a
 common bus arrangement, at which point I would suggest there is no way the
 PEM can be at fault considering all the other FPCs DO show power being
 received from PEM1. If I can confirm (via JTAC or otherwise) what the power
 architecture is, then we can save this step, bite the bullet and move on
 with getting the chassis replaced without wasting time on replacing the
 PEM, then having to get a second window booked with electricians etc to
 swap out the whole chassis.

 I suppose ultimately part of the problem here has been that my coworkers
 and myself would have assumed back in July when we first lodged this issue
 to JTAC that asking a relatively straightforward question (how is the
 power distributed from the PEMs to the FPCs in a T4000?) that we would
 have actually had a fairly clear answer without too much fuss.

 To date, that hasn't happened - we can't work out why this is; is it that
 nobody runs T4000s? Is it that nobody in Juniper has this information? Is
 it 'commercially sensitive' enough that nobody wants to tell us?

 The response from JTAC so far has basically been hand-waving and avoiding
 the question. That doesn't give me much confidence in either the platform
 or JTAC.

 Cheers,

 Sam



 On Thu, Sep 25, 2014 at 2:33 AM, Fred Quan fq...@juniper.net wrote:

 Hi Sam,

 Maybe you can try the below steps to isolate the problem.

 1.  run show chassis environment pem to check which FPC has 0 Voltage
 and Current on PEM.
 ( Here, I assume that,  FPC 0 has 0 Voltage and Current on PEM 1 )
 2. check FPC 0 is Online state with Dual PEM power on.
 3. power off PEM #0 in slot 0, then check FPC 0 state.
 3.1 if FPC 0 is still Online state with single PEM #1 power on, then PEM
 #1 in slot 1 can provide power to FPC 0, it is a display problem in STEP 1.
 3.2 if FPC 0 is Offline state with single PEM #1 power on, then PEM #1 in
 slot 1 cannot provide power to FPC 0, then continue STEP 4.
 4. power off both PEMs and swap PEM #0 and PEM #1, so PEM #0 in slot 1 and
 PEM #1 in slot 0.
 5. power on PEM #1 in slot 0 only. It looks like the PEM #1 problem if FPC
 0 is Offline state.
 6. power on PEM #0 in slot 1 only. It looks like the Mid plane problem if
 FPC 0 is Offline state.


 Regards,

 -Fred


 
 From: juniper-nsp juniper-nsp-boun...@puck.nether.net on behalf of Sam
 Silvester sam.silves...@gmail.com
 Sent: Tuesday, September 23, 2014 9:40 PM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] T4000 power architecture

 Bumping for good measure...

 So JTAC are suggesting it's either the PEM or the midplane, but I was
 hoping to get some more information so I can validate what I'm being told -
 which, currently, is very little. Basically the suggestion is replace the
 PEM, if that doesn't work replace the chassis. I'd like to avoid
 whack-a-mole if possible; for example, if I knew that all of the FPCs were
 fed via the PEM via a central bus on the midplane, then we don't have to
 worry about replacing the PEM and can go straight ahead with organising a
 chassis swap.

 I don't suppose somebody happens to have a spare T4000 chassis or PEM lying
 around and could take a photo of 

[j-nsp] SRX550 as MPLS/VPLS platform

[Tom Storey]

Hi everyone.

The SRX240 works pretty well as an MPLS/VPLS platform when stuck in packet mode.

I am wondering if the SRX550 operates in a similar way?

Has anyone out there used an SRX550 as a slightly more high powered
xPLS platform? Of particular interest it has 10GE modules available
that the SRX240 doesnt have.

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

Re: [j-nsp] SRX550 as MPLS/VPLS platform

[Tom Storey]

Cost, essentially.

I have recommended the MX5-MX80 series instead, being a proper routing
platform,  but was asked to find other options too.
On 16 Apr 2014 20:07, Chris Jones ipv6fre...@gmail.com wrote:

 Why not an MX instead?


 On Wed, Apr 16, 2014 at 11:41 AM, Tom Storey t...@snnap.net wrote:

 Hi everyone.

 The SRX240 works pretty well as an MPLS/VPLS platform when stuck in
 packet mode.

 I am wondering if the SRX550 operates in a similar way?

 Has anyone out there used an SRX550 as a slightly more high powered
 xPLS platform? Of particular interest it has 10GE modules available
 that the SRX240 doesnt have.

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




 --
 Chris Jones
 JNCIE-ENT #272
 CCIE# 25655 (RS)

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

Re: [j-nsp] J2300/J4300 FPCs cannot go online

[Tom Storey]

Juniper's solution is perhaps a little more elegant.

They suggest:

1. Deactivate existing NTP configuration
2. Set date back ~10 years

root set date 20040325.00

3. Disable sw - hw time sync (incl. at boot time via rc script)

root% sysctl -w machdep.disable_rtc_set=1
root% touch /cf/etc/rc.custom
root% chmod +x /cf/etc/rc.custom
root% echo sysctl -w machdep.disable_rtc_set=1  /cf/etc/rc.custom
root% cat /cf/etc/rc.custom

4. Re-activate NTP configuration
5. Reboot (doesnt seem strictly necessary, but maybe worthwhile as a test)

So basically youre setting the hw clock back ~10 years which allows
the FPC to come online. You disable sw - hw time sync so even when
running NTP, if the device reboots the hw clock is still in the past,
the FPC will come online because the certificate is still valid, and
then NTP will update the time on the box to the present.

Genius even if still a little hacky. :-)

On 31 March 2014 09:38, Per Granath per.gran...@gcc.com.cy wrote:
 Change the date to 2004, and do not use NTP.

 set date 200403311010.10


 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
 Mircho Mirchev
 Sent: Saturday, March 29, 2014 11:32 PM
 To: Tom Storey
 Cc: Juniper Maillist
 Subject: Re: [j-nsp] J2300/J4300 FPCs cannot go online

 Hi,
 Same here
 Seems there are more expired certificates.
 We'll have to try JTAC - however, I'm not sure if they can help - these boxes 
 are long out of support.
 Any other ideas?

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

Re: [j-nsp] Do the old M-series fixed optic SONET/SDH PICs wear out?

[Tom Storey]

show int diag optic interface

Some interfaces don't support it as mentioned, e.g. the fixed optic
STM-64/OC-192 PICs in my experience. Otherwise I haven't come across a PIC
that takes pluggable optics that this didn't work on, as long as the optic
supports DOM I guess.

On Friday, 21 March 2014, Keegan Holley no.s...@comcast.net wrote:


 On Mar 14, 2014, at 5:06 PM, Will Orton w...@loopfree.net javascript:;
 wrote:

  I have a couple P(E)-4OC3-SON-SMIR that I purchased used and
 successfully ran in a
  production network in the 2007-2009 timeframe. Then, about 5 years ago
 the OC3
  links were taken out of service and the PICs sat in their routers (an
 M10 and an
  M20) for 4-5 more years doing nothing.
 
  The ports were set disable but the PIC was online, so I believe the
 optical
  transmitters were still active.

 Could just be dust/debris even if someone put the boots back on, which
 sometimes doesn’t happen.  SMIR is very sensitive dirt.
 
  Now I'm trying to reussurect them for lab use and I cannot for the life
 of me get
  them to link up back-to-back. Only one port out of eight will even go
 green when
  looped to itself with a 1m patch cable. None will link port-to-port.
 
  LOL clears and I get PLL lock, but then either LOS or LOF, AIS, BERR,
 etc on
  both sides.
 
  I've tried:
  -multiple patch cables (yes they're SMF)
  -cleaning the cables' SC connector with tissue/alcohol

 This is a bad idea.  You could replace tiny dust particles with giant
 tissue fibers twice as big but still too small to see.  A proper fiber
 cleaner is about $100.  If you don’t have access to one you should just
 replace cables.

  -blowing canned air into the ports on the PIC

 Bad idea as well. You’re actually more likely to blow things into the
 connectors than away from them.

  -5  10db optical attenuators in case it was rx overload even though that
  shouldn't matter

 I’ve never had to attenuate in a lab even with SMIR optics and 1-2m
 cables, but YMMV.  To quote my old SE, “Juniper likes it hot!”.

  -verifying tx/rx strands and swapping just in case
  -every combination of clocking,enable/disable scrambling, crc16/32, etc
  -JUNOS 10, 11, and 12 in both M10 and M20 with FPC-E
 are you sure the new code is compatible with those cards?

 Are the optics swappable? I can’t remember for that card.  I’d try new
 ones or at least try known good ones in all the non-working ports.

 
 
  Unfortunately I don't have a light meter. But I'm starting to think the
  transmitters might just be toast and not pushing enough light to present
 a
  usable signal to the other end even with only a 1m patch.

 You do actually have a moderately accurate light meter.  There’s a command
 that will show you light levels from the perspective of the PIC IIRC.  I
 can’t guarantee that it is supported on hardware this old though so YMMV.
  I believe it’s under the show interfaces physical hierarchy.  It should
 tell you what it’s transmitting, what it’s receiving and the minimum light
 level to establish a link.

 Over the years, I’ve also taken to simply taking the known good port and
 cable and plugging it into all the stuff that didn’t work.  I would
 sometimes end up with cables pulled through racks and other dodgy places
 temporarily, but I always ended up invalidating some of my deductions.

 
 
 http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-network-interfaces/id-12763130.html
 
  says:
 
  To extend the life of the laser, when a SONET/SDH PIC is not being
 actively used
  with any valid links, take the PIC offline until you are ready to
 establish a link
  to another device. To do this, issue the request chassis pic offline
 fpc-slot
  slot-number pic-slot slot-number operational mode command
 
  Is this a real thing? Is 10-15 years in the expected usable lifetime of a
  circa-2001 1310nm laser?

 Yes. no. maybe. probably. definitely.  sometimes…   I’ve seen gear used
 well beyond it’s expected lifetime and I’ve seen things come out of the
 depot completely unusable.  Everything breaks.  Stuff is either broken or
 not broken yet.  That’s why hardware lifecycle’s were invented.  If there’s
 no current in the components they will last longer at least according to
 the laws of physics.  That doesn’t mean that leaving one on for 5 years
 will definitely fry it.

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


 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
 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] Another SRX240 VPLS question - trunking multiple VLANs through single VPLS

[Tom Storey]

Hi all. Sorry for the noise on this topic, but Im getting my feet very
wet right now. :-)

Im passing on the access port idea from my previous email at the moment.

Right now Im trying to get a different configuration working, whereby
I assign multiple units of one interface in to a VPLS routing instance
and allow them to be trunked to other VPLS sites.

I had a previous configuration working fine whereby the whole
interface itself was assigned to the VPLS. Trunking worked great in
that instance, I could pass as many VLANs through as I wanted
seemingly.

Heres what I was doing:

interfaces {
   ge-0/0/12 {
   description L2VPN test interface;
   encapsulation ethernet-vpls;
   unit 0 {
   family vpls;
   }
   }
}
routing-instances {
   VPLS-1 {
   instance-type vpls;
   interface ge-0/0/12.0;
   route-distinguisher 12345:2;
   vrf-target {
   import target:12345:2;
   export target:12345:2;
   }
   protocols {
   vpls {
   no-tunnel-services;
   site CORE {
   site-identifier 1;
   }
   vpls-id 1;
   }
   }
   }
}

This config works fine.

Now what Im trying to do is, in order to allow VLANs to be aggregated
via one interface of the SRX and assign them at will to various L3VPN
and VPLS instances, as follows:

interfaces {
ge-0/0/5 {
description Aggregation interface;
vlan-tagging;
mtu 1618;
encapsulation flexible-ethernet-services;
unit 10 {
encapsulation vlan-vpls;
vlan-id 10;
}
unit 30 {
encapsulation vlan-vpls;
vlan-id 30;
}
unit 40 {
encapsulation vlan-vpls;
vlan-id 40;
}
unit 50 {
encapsulation vlan-vpls;
vlan-id 50;
}
unit 60 {
encapsulation vlan-vpls;
vlan-id 60;
}
}
}
routing-instances {
VPLS-1 {
instance-type vpls;
vlan-id all;
interface ge-0/0/5.50;
interface ge-0/0/5.60;
route-distinguisher 12345:1;
vrf-target {
import target:12345:1;
export target:12345:1;
}
protocols {
vpls {
no-tunnel-services;
site CORE {
site-identifier 1;
}
vpls-id 1;
}
}
}
}

Ive also tried removing vlan-id all, and also replacing it with
something like vlan-id 4000 for what I believe is referred to as
normalisation.

The problem is that, when I only have one logical interface assigned
to the VPLS, it works great. As soon as I add a second or more, it
just seems to flop.

With a single logical interface, if I run the command show route
forwarding-table family vpls I see a nice big list of MAC addresses
as I would expect. When I add the second+ logical ints, after a few
minutes (probably mac table aging) they all seem to disappear.

Everything Ive tried configuring to date is based on what examples I
can find online. Now, a lot of that is geared towards the bigger boys
toys routers like the M/MX series. Am I trying to do something that
the SRX series simply cant do?

Im trying my hardest to work this out on my own, but I would again be
greatly appreciative if anyone has any tips or pointers. I think Ive
been through just about every forum post, blog, and random note I can
find on this topic, I just cant seem to get it working.

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

Re: [j-nsp] VLAN sub-ints and VPLS

[Tom Storey]

Thanks for the responses so far, heres a few more details about what
Im experiencing at the moment.

So I start with something like this:

# show interfaces ge-0/0/12
description VPLS test interface;
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}

And I want to pop the VLAN header on output and push it on input:

# show interfaces ge-0/0/12
description VPLS test interface;
encapsulation ethernet-vpls;
unit 0 {
##
## Warning: Only compatible with vpls vlan encapsulations
##
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
##
## Warning: Only compatible with vpls vlan encapsulations
##
output-vlan-map pop;
family vpls;
}

Ok, apply a unit wise encap:

# show interfaces ge-0/0/12
description VPLS test interface;
encapsulation ethernet-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}

No errors, try to commit:

# commit
error: VLAN Encapsulation: Not allowed on untagged interfaces
[edit interfaces ge-0/0/12]
  'unit 0'
 invalid encapsulation
error: configuration check-out failed

Ok, lets add some VLAN tagging (I did also try regular vlan-tagging):

# set interfaces ge-0/0/12 flexible-vlan-tagging

[edit]
# show interfaces ge-0/0/12
description VPLS test interface;
##
## Warning: Only compatible with vpls vlan encapsulations
##
flexible-vlan-tagging;
encapsulation ethernet-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}

Alright we'll change the encap:

# show interfaces ge-0/0/12
description VPLS test interface;
vlan-tagging;
encapsulation vlan-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}

Great, no more errors, try to commit again:

# commit
[edit interfaces ge-0/0/12]
  'unit 0'
vlan map ge-0/0/12: input-vlan-map and output-vlan-map are valid
on untagged interfaces only for ethernet-ccc and ethernet-vpls
encapsulations
error: configuration check-out failed

But you just told me I need to use  tagging? And there is no
ethernet-vpls encapsulation for units. wtf?

Maybe its just not possible on an SRX, perhaps it doesnt have the
smarts, or maybe Im just missing something really obvious.

Any help appreciated. Cheers!

On 20 January 2014 04:01, Will Orton w...@loopfree.net wrote:
 ge-0/0/12 {
 encapsulation ethernet-vpls;
 unit 0 {
 encapsulation vlan-vpls;
 input-vlan-map {
 push;
 tag-protocol-id 0x8100;
 vlan-id 123;
 }
 output-vlan-map pop;
 family vpls;
 }
 }

 but I dont seem to be able to get the right combination of
 encapsulations and other settings to be able to commit.

 Q2. Does anyone have a working example I could look at?


 This works for me on MX to swap .1q 2700 to 603 in the VPLS.

 ge-1/0/4 {
 flexible-vlan-tagging; // plain vlan-tagging would be ok too
 encapsulation flexible-ethernet-services;
 unit 2700 {
 encapsulation vlan-vpls;
 vlan-tags outer 2700;
 input-vlan-map {
 swap;
 vlan-id 603;
 }
 output-vlan-map swap;
 family vpls;
 }

 So your example looks okay except the encaps on the phys interface.
 I haven't tried on SRX (yet); not sure what is correct if you don't
 want or can't do flexible-ethernet-services.


 Also, are VPLS and L2VPN the same thing or different? Once source I
 read said L2VPN is ptp while VPLS is ptmp.

 That's basically it. VPLS being multi-point means your PE routers are
 mac-learning, snd you can of course have a full range of issue like
 layer-2 loops (hence STP coming into play sometimes too). l2vpn is
 simpler.

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

[j-nsp] VLAN sub-ints and VPLS

[Tom Storey]

Hi everyone.

Im playing around with VPLS between 3x SRX240's and looking for a little info.

Ive got an interface configured as such:

ge-0/0/12 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-vpls;
vlan-id 123;
}
}

And between two sites in my VPLS this is working just fine, I can ping
across between two devices configured with sub-ints in VLAN 123. Happy
days.

Q1. With this configuration am I right in thinking that the VLAN ID is
maintained within the frame as it is transported across the VPLS? Or
does it get popped on input at the source site, transported as a
regular ethernet frame, and then the VLAN ID is pushed on output at
the destination site?

The reason I ask is what I'd like to do is take an interface at a 3rd
site, and push/pop on in/ouput to produce effectively an access
port.

Ive been toying with a configuration like this for the 3rd site based
on examples Ive found:

ge-0/0/12 {
encapsulation ethernet-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}
}

but I dont seem to be able to get the right combination of
encapsulations and other settings to be able to commit.

Q2. Does anyone have a working example I could look at?

Or have I complicated this and I only need to set the native VLAN ID
and let the SRX take care of the push/pop automagically? I havent
actually tried that yet as I litterally just thought about it, but Im
about to crash in bed.

Also, are VPLS and L2VPN the same thing or different? Once source I
read said L2VPN is ptp while VPLS is ptmp.

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

Re: [j-nsp] VPLS: site-range

[Tom Storey]

Ok, so then you could in theory just leave the site-range command out
of a VPLS config in order to go by default values, unless you needed
to enforce a maximum site count?

On 8 January 2014 11:56, Saku Ytti s...@ytti.fi wrote:
 On (2014-01-08 00:21 +), Tom Storey wrote:

 Hi Tom,

 From the reading around I have done, the site-range basically
 indicates how many sites maximum can/should exist for a given VPLS.

 Yes.

 This tells the routers how many labels should be reserved for
 conveying data between each PE that has a site that is part of a given
 VPLS.

 No. Site range can be 64k, and not single label is assigned. Labels are
 assigned on-demand, in label-block-size, to cover all seen sites, not all
 possible sites.

 If I say site-range 10 then I shouldnt/cant provision more than 10
 sites for that VPLS, because insufficient labels will have been
 reserved for conveying data between any PE routers beyond the first
 10, and thus those sites will be unreachable.

 It won't allocate labels for higher sites, correct.

 Suppose I configure all of my VPLS instances with site-range 10
 initially, if I need to add more sites later, I just need to go back
 and re-configure each VPLS instance to increase the number
 appropriately?

 Yes.

 The default site-range value seems to be somewhere up in the 65,000's
 which from my reading is bad, because 65k labels will be reserved for
 that instance, which could be pretty wasteful if the VPLS only has 3-4
 sites.

 It's sane, I don't think it should be even configurable. But maybe there is
 some obscure CsC like situation where there is partial trust between two
 parties and you want to ensure no one is stealing VPLS sites without paying,
 only thing I can come up with.
 I would keep it at maximum value.

 --
   ++ytti
 ___
 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] VPLS: site-range

[Tom Storey]

Hi all,

Could someone validate my understanding (or lack of) about the purpose
of the site-range command...

From the reading around I have done, the site-range basically
indicates how many sites maximum can/should exist for a given VPLS.
This tells the routers how many labels should be reserved for
conveying data between each PE that has a site that is part of a given
VPLS.

If I say site-range 10 then I shouldnt/cant provision more than 10
sites for that VPLS, because insufficient labels will have been
reserved for conveying data between any PE routers beyond the first
10, and thus those sites will be unreachable.

Suppose I configure all of my VPLS instances with site-range 10
initially, if I need to add more sites later, I just need to go back
and re-configure each VPLS instance to increase the number
appropriately?

I hope that makes sense...

The default site-range value seems to be somewhere up in the 65,000's
which from my reading is bad, because 65k labels will be reserved for
that instance, which could be pretty wasteful if the VPLS only has 3-4
sites.

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

[j-nsp] J series packet mode

[Tom Storey]

Hi everyone.

Whats the general consensus about using a J series entirely in packet mode?

Are there any gotchyas to be wary of, like missing features,
performance hit? It looks like you can configure 3 address families
for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
reading, enabling MPLS packet mode forces the whole box in to packet
mode, including inet4.

Source: http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf page 6

Quote: When MPLS is configured, there is no way of knowing if an IP
packet entering the services gateway will require MPLS encapsulation
until the packet is processed, so enabling MPLS can be used to force
an SrX Series or J Series device to forward all IPv4 traffic in packet
mode.

FWIW the situation I am picturing would not require NAT or IPSEC or
other services like that, just packet shifting with ACLs, some routing
protocols (IS-IS/BGP), and something like VRRP for gateway redundancy.

Im interested in using it more like a router than a firewall, just
good old fashion packets and ACLs!

As I understand it the J series were originally a packet mode box
until Juniper switched the default behaviour to flow based. Has there
been any major architecture changes that would rule out packet mode
operation?

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

Re: [j-nsp] J series packet mode

[Tom Storey]

On 19 December 2013 14:39, Phil Mayers p.may...@imperial.ac.uk wrote:

 performance hit? It looks like you can configure 3 address families
 for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
 reading, enabling MPLS packet mode forces the whole box in to packet
 mode, including inet4.


 Yes.

Just want to clarify, are you saying there is a performance hit? Or
just that enabling MPLS packet mode forces the entire box in to packet
mode?

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

Re: [j-nsp] J series packet mode

[Tom Storey]

Excellent. Seems the prospects are good then. :-)

No new purchases.

On 19 December 2013 14:25, Tom Storey t...@snnap.net wrote:
 Hi everyone.

 Whats the general consensus about using a J series entirely in packet mode?

 Are there any gotchyas to be wary of, like missing features,
 performance hit? It looks like you can configure 3 address families
 for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
 reading, enabling MPLS packet mode forces the whole box in to packet
 mode, including inet4.

 Source: http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf page 6

 Quote: When MPLS is configured, there is no way of knowing if an IP
 packet entering the services gateway will require MPLS encapsulation
 until the packet is processed, so enabling MPLS can be used to force
 an SrX Series or J Series device to forward all IPv4 traffic in packet
 mode.

 FWIW the situation I am picturing would not require NAT or IPSEC or
 other services like that, just packet shifting with ACLs, some routing
 protocols (IS-IS/BGP), and something like VRRP for gateway redundancy.

 Im interested in using it more like a router than a firewall, just
 good old fashion packets and ACLs!

 As I understand it the J series were originally a packet mode box
 until Juniper switched the default behaviour to flow based. Has there
 been any major architecture changes that would rule out packet mode
 operation?

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

Re: [j-nsp] J series packet mode

[Tom Storey]

Awesome. Thanks everyone. :-)

On Thursday, December 19, 2013, abdullahbaheer wrote:

 Also Jseries is end of sale and will be end of support soon after, so an
 SRX would be a better option for a new deployment.
 Thanks
 Abdullah Baheer


 Sent from Samsung Mobile



  Original message 
 From: Phil Mayers p.may...@imperial.ac.uk javascript:_e({}, 'cvml',
 'p.may...@imperial.ac.uk');
 Date: 19/12/2013 6:09 PM (GMT+03:00)
 To: Tom Storey t...@snnap.net javascript:_e({}, 'cvml',
 't...@snnap.net');
 Cc: juniper-nsp@puck.nether.net javascript:_e({}, 'cvml',
 'juniper-nsp@puck.nether.net');
 Subject: Re: [j-nsp] J series packet mode


 On 19/12/13 15:06, Tom Storey wrote:
  On 19 December 2013 14:39, Phil Mayers 
  p.may...@imperial.ac.ukjavascript:_e({}, 'cvml', 
  'p.may...@imperial.ac.uk');
 wrote:
 
  performance hit? It looks like you can configure 3 address families
  for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
  reading, enabling MPLS packet mode forces the whole box in to packet
  mode, including inet4.
 
 
  Yes.
 
  Just want to clarify, are you saying there is a performance hit? Or
  just that enabling MPLS packet mode forces the entire box in to packet
  mode?

 The latter.

 We've not seen any unexpected performance issues from being in packet mode.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:_e({},
 'cvml', '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] J series packet mode

[Tom Storey]

Yeah I did see this, but Im looking to avoid flow mode on the whole.

On Thursday, December 19, 2013, 雨飞 叶 wrote:

 You can also use selective packet mode: To get best of both worlds, see

 http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf

 On Thu Dec 19 2013 at 8:38:14 AM, Tom Storey 
 t...@snnap.netjavascript:_e({}, 'cvml', 't...@snnap.net');
 wrote:

 Awesome. Thanks everyone. :-)

 On Thursday, December 19, 2013, abdullahbaheer wrote:

  Also Jseries is end of sale and will be end of support soon after, so an
  SRX would be a better option for a new deployment.
  Thanks
  Abdullah Baheer
 
 
  Sent from Samsung Mobile
 
 
 
   Original message 
  From: Phil Mayers p.may...@imperial.ac.uk javascript:_e({}, 'cvml',
 'p.may...@imperial.ac.uk'); javascript:_e({}, 'cvml',
  'p.may...@imperial.ac.uk javascript:_e({}, 'cvml',
 'p.may...@imperial.ac.uk');');
  Date: 19/12/2013 6:09 PM (GMT+03:00)
  To: Tom Storey t...@snnap.net javascript:_e({}, 'cvml',
 't...@snnap.net'); javascript:_e({}, 'cvml',
  't...@snnap.net javascript:_e({}, 'cvml', 't...@snnap.net');');
  Cc: juniper-nsp@puck.nether.net javascript:_e({}, 'cvml',
 'juniper-nsp@puck.nether.net'); javascript:_e({}, 'cvml',
  'juniper-nsp@puck.nether.net javascript:_e({}, 'cvml',
 'juniper-nsp@puck.nether.net');');
  Subject: Re: [j-nsp] J series packet mode
 
 
  On 19/12/13 15:06, Tom Storey wrote:
   On 19 December 2013 14:39, Phil Mayers 
   p.may...@imperial.ac.ukjavascript:_e({}, 'cvml', 
   'p.may...@imperial.ac.uk');
 javascript:_e({}, 'cvml', 'p.may...@imperial.ac.uk javascript:_e({},
 'cvml', 'p.may...@imperial.ac.uk');');
  wrote:
  
   performance hit? It looks like you can configure 3 address families
   for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
   reading, enabling MPLS packet mode forces the whole box in to packet
   mode, including inet4.
  
  
   Yes.
  
   Just want to clarify, are you saying there is a performance hit? Or
   just that enabling MPLS packet mode forces the entire box in to packet
   mode?
 
  The latter.
 
  We've not seen any unexpected performance issues from being in packet
 mode.
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.netjavascript:_e({}, 
  'cvml', 'juniper-nsp@puck.nether.net');javascript:_e({},
  'cvml', 'juniper-nsp@puck.nether.net javascript:_e({}, 'cvml',
 'juniper-nsp@puck.nether.net');');
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:_e({},
 'cvml', '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] BGP/L3 routing support on EX2200 EX2200-C

[Tom Storey]

Interesting. Has anyone tried this with protocols like IS-IS and with IPv6?
I'd love to add an EX3200 to my lab, but shelling out for a license would
make it a bit too expensive.
On 27 Nov 2013 00:25, Paul S. cont...@winterei.se wrote:

 From what I've seen, the license is mainly a 'nag license,' at least for
 BGP.

 I've got quite a few customers doing BGP on the aforementioned products
 without the AFL, all it appears to affect is that it whines every single
 time a commit is performed -- yet continues to function fine.

 This doesn't mean you shouldn't buy it, but it does offer /some/ leeway.

 -- Paul

 On 11/27/2013 午前 07:47, Yucong Sun wrote:

 nvm , looks like it still does:, quoting the software license bit.

 Sigh!

 To use the following features on EX3200, EX4200, EX4500, EX4550, EX8200,
 and EX9200 switches, you must install an advanced feature license (AFL):

 - Border Gateway Protocol (BGP) and multiprotocol BGP (MBGP)
 - Intermediate System-to-Intermediate System (IS-IS)
 - IPv6 routing protocols: IS-IS for IPv6, IPv6 BGP, IPv6 for MBGP
 - Logical systems (available only on EX9200 switches)
 - MPLS with RSVP-based label-switched paths (LSPs) and MPLS-based
 circuit cross-connects (CCCs) (Not supported on EX9200 switches)




 On Tue, Nov 26, 2013 at 2:44 PM, Yucong Sun sunyuc...@gmail.com wrote:

  specifically,  for BGP and wire-speed ip routing, at least that's how i
 intereprt the datasheet.


 On Tue, Nov 26, 2013 at 2:43 PM, Yucong Sun sunyuc...@gmail.com wrote:

  Thanks for the link, what about EX3200 ? EX3200 doesn't need AFL for l3
 features?


 On Tue, Nov 26, 2013 at 1:52 PM, Skeeve Stevens 
 skeeve+juniper...@eintellegonetworks.com wrote:

  To quote:
 http://www.juniper.net/techpubs/en_US/junos/topics/
 concept/ex-series-software-licenses-overview.html#jd0e63

 Yes, I agree it is vague.   I'd like more information about the amount
 if Layer 3 interfaces (RVI/SVI), Static routing, etc... which, the
 theory
 if it can do OSFP, then should be able to do some of that.  Even VRRP
 means
 layer 3 interfaces should be functional in some way.

 ---
 Features Requiring a License on EX2200 Switches

 For EX2200 switches, the following features can be added to basic Junos
 OS by installing an enhanced feature license (EFL):

 - Bidirectional Forwarding Detection (BFD)
 - Connectivity fault management (IEEE 802.1ag)
 - IGMP (Internet Group Management Protocol) version 1 (IGMPv1),
 IGMPv2, and IGMPv3
 - OSPFv1/v2 (with four active interfaces)
 - Protocol Independent Multicast (PIM) dense mode, PIM
 source-specific mode, PIM sparse mode
 - Q-in-Q tunneling (IEEE 802.1ad)
 - Real-time performance monitoring (RPM)
 - Virtual Router
 - Virtual Router Redundancy Protocol (VRRP)
 -

 ---


 ...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 ;  http://twitter.com/networkceoau
 linkedin.com/in/skeeve

 twitter.com/theispguy ; blog: www.theispguy.com


 The Experts Who The Experts Call
 Juniper - Cisco - Cloud


 On Wed, Nov 27, 2013 at 8:19 AM, Yucong Sun sunyuc...@gmail.com
 wrote:

  The datasheet is conveniently vague here,  Do any know whether these
 two
 support BGP? and how much instances/peers can they support? Also, do
 they
 have wire routing capability (suspiciously missing from data sheet
 too)

 BTW: Why is it so hard to get a cheap  decent l3 switch? EX2200-C
 looks
 perfect fit for a few uplinks, too bad if it doesn't support BGP!
  it's
 not
 like it is complex software feature or anything. EX3200 on the other
 hand,
 does everything, but with way too many ports necessary.
 ___
 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX104

[Tom Storey]

Why so much just to enable some ports? How do they come up with that
kind of price? Pluck it out of thin air?

The hardware has been paid for, and I know thats only list pricing,
but it still seems ridiculous.

On 8 November 2013 16:46, Paul Nazario naza...@doit.wisc.edu wrote:
 That is what we've heard and they have the following two items in their $USD 
 list pricing:


 S-MX104-UPG-2X10GE  Upgrade License to activate 2 x 10GE fixed ports on 
 MX104   MX104   $10,000
 S-MX104-UPG-4X10GE  Upgrade License to activate 4 x 10GE fixed ports on 
 MX104   MX104   $18,000



 On Nov 5, 2013, at 1:16 PM, Nicolaj Kamensek n...@accelerated.de wrote:

 Hi everybody,

 anybody had a chance yet to put their hands on the new MX104? According to 
 Juniper the 4 10G ports on-board are software locked this time but I'd like 
 to have a confirmation for that from an actual experience.


 Thanks!
 ___
 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] Heterogeneous LACP link

[Tom Storey]

Isnt that the whole point of the OSI model? To separate different layers
and make them independent of each other so that one layer doesnt need to
care about ones above or below it as such?

With that in mind, different optics shouldnt have any kind of bearing on
LACP, which should only need a bunch of like links to bundle together.

And having said that, I have seen LACP bundles formed over two different
submarine systems of different lengths. While it might not be ideal, it did
seem to work just fine.


On 16 September 2013 11:52, Laurent CARON lca...@unix-scripts.info wrote:

 Hi,


 Current setup: 2 VCs (one on each site) each composed of 2xEX4200-24T

 I have the possibility of having a redundant connection between 2
 buildings distant of ~10/15 km.

 The main link is a pair of dark fibers on which I'll use 40 km XFP modules.

 The second link is a WDM transport on which I plan to use 2 short reach
 monomode SFP's (one on each side).

 2 questions:
 - Is it wise to mix SFP and XFP on the same LACP aggregate ?
 - Is it wise to mix 2 different technologies on a LACP aggregate
 (shuoldn't matter much, but I'd prefer hearing experiences ;)) ?

 Thanks

 Laurent
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Vlan question MX

[Tom Storey]

The thing thats confusing me is, who on earth presents a service to a
customer as a tagged service? Ive never come across such a thing.

If you're plugged in to a router interface on the providers side, why is
there a need to add VLAN tagging on top? Similarly, if you're plugged in to
a switch, normally the switch port is just an access port, not a trunk.

Someone help me out here... :-)


On 8 July 2013 22:47, Michael Loftis mlof...@wgops.com wrote:

 vlan-tagging tells JunOS to treat the interface as multiple separate
 L3 interfaces, identified by VLAN ID.  Their end is almost certainly
 similarly configured (maybe as a MPLS PE)

 On Mon, Jul 8, 2013 at 10:26 AM, Keith kwo...@citywest.ca wrote:
  Have this setup in the lab on some srx's but want to get some info
  on this.
 
  We have an upstream provider that we use a config:
 
  set interfaces ge-0/1/0 vlan-tagging
  set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
  set interfaces ge-0/1/0 unit 1500 vlan-id 1500
  set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30
 
 
  We are turning up a second connection to them that will be terminated on
 a
  10G
  link and want us to use the same thing, vlan 1500, just a different IP
  address.
 
  Will this cause a problem by having the same vlan id on both links to the
  same provider? (I am guessing we are being terminated on different
 routers
  on their side).
 
  My lab router didn't complain so I'm guessing its probably ok.
 
  Thanks,
  Keith
 
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp



 --

 Genius might be described as a supreme capacity for getting its possessors
 into trouble of all kinds.
 -- Samuel Butler
 ___
 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] SLAX script, redefining variables

[Tom Storey]

Hi all.

It seems that older SLAX implementations dont have the ability to redefine
variable (Juniper is calling them immutable variables). This is apparently
fixed in 1.1 on JunOS12+ boxes with something called a mutable variable
(defined with mvar instead of var) but all of the boxes I am using are not
on JunOS12+ yet.

Has anyone found a way to collect a whole bunch of information, and then
display it at the end of the script, rather than duplicating their output
code 50 times to handle the various exceptions?

e.g. a script I am writing grabs the tx/rx figures for optics and lists
them, along with the description of the interface, so I can run my op
script and get a list of power levels, grep for destination devices etc and
see whats happening with my circuits.

But there are a couple of exceptions that I hit along the way:

1) Descriptions arent always on the physical interface, so if theres no
description there I need to look at a logical interface, which is usually
unit 0 in my case
2) SONET interfaces dont use the same variable to store the rx power
figure as ethernet interfaces, so depending on the interface type I need to
look at a different variable for the rx power figure

To handle these exceptions would be quite easy if I could simply use a
bunch of IF blocks to test for the various locations of the information I
want, set them in to variables, and then at the end dump it out to the
screen.

But without being able to redefine a variable, and with variables defined
inside an IF block not being accessible outside of that IF block, I will
need to reproduce my output code numerous times.

Anyone know of a solution?

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

Re: [j-nsp] SLAX script, redefining variables

[Tom Storey]

Duh. Thats what happens when you spend all night coding, you forget silly
little things. :-P

Theres still some duplication of the function call, but I guess thats
better than nothing.

Would much prefer to do a bulk collection and then a dump at the end.

I'll take this route for the time being.


On 7 June 2013 11:43, Phil Mayers p.may...@imperial.ac.uk wrote:

 On 07/06/13 09:54, Tom Storey wrote:

  But without being able to redefine a variable, and with variables defined
 inside an IF block not being accessible outside of that IF block, I will
 need to reproduce my output code numerous times.


 Move the output code to a function?
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Juniper MX480 BNG Feature ?

[Tom Storey]

f two or more people are trying to share the same IP on an on-demand type
basis, then the router needs to keep some kind of session table to be able
to return traffic to the correct end user should something come by at a
random interval.

And this is essentially what NAT is doing anyway, so wouldn't you be better
off just implementing that?


On 4 June 2013 11:51, Thong Hawk Yen hawk.yen.th...@time.com.my wrote:

 Hi J-NSP Members,

 We are using MX480 with Junos [11.4X27.44] as BRAS and with Juniper policy
 manager SRC with Software version SRC-PE Release 4.2 [V4.2.0.R-16] to
 provide Broadband services over PPPoE.
 The BRAS is the element  that is leasing out IP addresses to the
 subscribers on the ppo interfaces. We notice that there is a high
 percentage of users are actually idling, not sending/receiving any traffic
 but the sessions are taking up ip addresses.

 It is not very efficient to time-out their session because customer end
 routers will re-dial. Is there a way to leave the PPPoE session on while
 the BRAS relinquish idling sessions ip address and re-assign when the
 customer traffic is back ?

 Please advise. Any feedback from any deployment of other BRAS would be
 helpful. Thanks.

 Regards
 thong

 

 CONFIDENTIALITY
 -
 The contents of and any attachments to this email are private and
 confidential. If you are not the intended recipient or addressee indicated
 in this message, please notify the sender of the error and destroy the
 email and any attachments. Please do not reproduce the contents of the
 email or its attachments as such reproduction is a breach of
 confidentiality and for which legal action including injunctive relief may
 be sought against you. If it is your company policy that official
 communications are not by email, please advise immediately. Any opinions,
 conclusions and other information in this message that do not relate to the
 official business of TIME dotCom shall be understood as neither given nor
 endorsed by TIME dotCom, nor shall TIME dotCom shall be liable (directly or
 vicariously) for such opinions, statements or communications.
 ___
 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] Inserting security policies on SRX

[Tom Storey]

There was some discussion on it just recently. Apparently a bunch of
messages got held up, and while playing around with mailman Jared managed
to free them up.

In response to the question, you could also do a load replace terminal
and paste in the formatted config for the entire stanza. Might be helpful
if you need to re-order a lot of things or make other complex changes.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Stackable switches, looping stacking ports

[Tom Storey]

So I imagine that might help with latency, but is it going to have any
affect on bit rate throughput?


On 9 April 2013 21:05, Chuck Anderson c...@wpi.edu wrote:

 On Tue, Apr 09, 2013 at 11:48:36AM -0700, joel jaeggli wrote:
  On 4/9/13 11:15 AM, Tom Storey wrote:
  Hey all.
  
  A colleague of mine tells me that, if you have a single stackable switch
  (not in a stack obviously) and do not loop the two stacking ports on the
  back using the stacking cable that comes in the box, then you reduce the
  effective throughput of the switch.
 
  The ex4200's asic has a capacity of 136Gb/s from the front panel
  ports which is 100% of line rate across all ports. I don't imagine
  connecting the asic back to itself is that useful or usable
  topology.

 It does make a positive difference to loop back the stack cable on a
 standalone unit.  See this diagram:

 http://blog.cochard.me/2010/08/juniper-ex-4200-internal-pfe-routing-in.html

 Connecting from ports 0-23 to 24-47 has to normally cross 3 internal
 PFEs.  If you connect VCP-0 to VCP-1, then it only has to cross 2
 PFEs.

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

[j-nsp] Stackable switches, looping stacking ports

[Tom Storey]

Hey all.

A colleague of mine tells me that, if you have a single stackable switch
(not in a stack obviously) and do not loop the two stacking ports on the
back using the stacking cable that comes in the box, then you reduce the
effective throughput of the switch.

Specifically I am talking about an EX4200.

To me this sounds a bit odd, and is not in line with my perhaps rudimentary
understanding of stackable switches, so hoping someone here can clarify
whether looping the stacking ports is good/bad/necessary/unnecessary?

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

Re: [j-nsp] AC-DC

[Tom Storey]

Tyco/Lineage Power make a couple of products that I have used personally
for powering Juniper routers and other telco equipment.

There are two 1RU shelves that can take 4 rectifier bricks each, one made
to take 2kW rectifiers with 10A inputs, the other 2.7kW with 16A inputs.

The 10.8kW shelves I have used have a small slot for a monitoring card,
while the 8kW shelves dont. This could just be a simple matter of not
ordering an 8kW shelf with a monitoring card slot though...

We tend to add in a mini BDFB (also by Tyco/Lineage) to provide more output
terminals, and importantly individual fuses.

I could get part numbers if required. Unsure of pricing, usually the parts
are just shipped as part of a BOM to the site where I am working.


On 26 February 2013 17:45, Rutger Bevaart rut...@netnova.nl wrote:

 Hello list,

 Anybody have some good advice on AC to DC converters to power a Juniper
 T640 with dual input DC power supplies? I found a few vendors that do 4x50A
 in 1U (TDK for example) and was wondering if anybody was using these in
 real life to power T's.

 Regards
 Rutger
 ___
 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] Quick way to delete multiple licenses on SRX

[Tom Storey]

Is it feasible to make multiple copies of the CF card for each router (dd
style), customise each copy with the licenses required for a given class,
then swap CFs depending on the class?

Whats more expensive or valuable, your time, or a bunch of CF cards? :-)


On 1 February 2013 13:03, Mark Menzies m...@deimark.net wrote:

 If we park the fact that this is for training courses here, I still need an
 answer to how I would do this on an SRX.  :)  So the problem exists and am
 just looking to see if we can find an answer.


 On 1 February 2013 11:31, Eugeniu Patrascu eu...@imacandi.net wrote:

  On Thu, Jan 31, 2013 at 9:00 PM, Mark Menzies m...@deimark.net wrote:
   If I enforced that, I would be training an empty room.  :)
 
  I wouldn't bet on it and you might go ahead and try it.
  I also do training and have licenses for every feature (not on
  Juniper, by the way) on the equipment and if the students ask, I tell
  them that since it is training equipment they have all the licenses
  and that's that. No confusion, no nothing.
 
  I might be wrong, but I think you're trying to solve a non-existing
  problem :)
 
  Cheers,
  Eugeniu
 
 ___
 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] BGP filter

[Tom Storey]

You could simplify it a little with an as-path-group and only need a single
term to match both.

You could also combine them in to a single regex like so:

(65204|65205) .*

Here is some information about as-path regexs from Juniper that also
confirms that () is null, i.e. originated in your AS.

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/defining-as-path-regular-expressions.html
http://www.juniper.net/techpubs/software/junos/junos74/swconfig74-policy/html/policy-extend-match-config3.html


On 1 February 2013 08:28, Riccardo S dim0...@hotmail.com wrote:


 Or the reg-ex has to be written in this way ?

 set as-path from-AS-65204 .*65204;
 set as-path from-AS-65205 .*65205;

 Is the follwoing correct for the local bgp announcement ?

 set as-path from-local-router ();

 Tks

 From: dim0...@hotmail.com
 To: juniper-nsp@puck.nether.net
 Subject: BGP filter
 Date: Thu, 31 Jan 2013 08:51:49 +





 I'd like to filter BGP announcement based on the generating AS-path.
 In the example below I'd like to permit outbound announcement only if the
 generating AS is 65204 or 65025:

 [edit policy-options]
 # set as-path from-AS-65204 65204.*
 # set as-path from-AS-65205 65205.*

 [edit policy-options policy-statement BGP-filter-out ]
 # set term 1 from as-path from-AS-65204
 # set term 1 then accept
 # set term 2 from as-path from-AS-65205
 # set term 1 then accept
 # set term accept-others then reject

 [edit protocols bgp]
 # set group EBGP export BGP-filter-out

 Is there a better method to do it ?

 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

Re: [j-nsp] Tacacs on Junos

[Tom Storey]

When you set the password on the Juniper, did you by any chance
enclose the password text in , e.g. password ?

If you did, the  is encoded as part of the password, rather than
suggesting everything inside quotes is the password like it does
with other things (like interface descriptions.)

I hit that little doozy when I was configuring TACACs for the first
time, so thought I'd throw it out there.

Tom


On 16 September 2012 14:49, Mohammad Khalil eng.m...@gmail.com wrote:
 Hi all
 I have mx240 , i want to configure tacacs authentication
 set system authentication-order tacplus
 set system tacplus-server x.x.x.x port 49 single-connection secret juniper
 source-address y.y.y.y

 Of course the server is reachable from the device
 I see in the log messages
 Failed password for mkhalil from 109.107.128.104 port 43262 ssh2

 Is there anything missing ?

 BR,
 Mohammad
 ___
 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] SNMP interface counters ... not counting

[Tom Storey]

Hi all.

I upgraded my SRX100 to 12.1 (specifically R2.9) about a month and a
half ago. On Sunday I went to look at my mrtg graphs and noticed that
for about the past 5 weeks or so no traffic has been recorded.

I looked into my mrtg config to make sure it was ok (Im using
interface name instead of ifIndex to reference my interfaces), and
tried a couple of snmpwalk's from the CLI, and all seems ok, and I can
return data.

Then I noticed something odd. Although the interface counters have
values, indicating they must have been counting at some stage, the
values are basically stuck in time.

Running successive snmpget's for one particular interface just returns
the same values over and over, despite the fact it is carrying data
for the snmp query.

I tried to restart the snmp daemon, but no change. So I rebooted the
device and it started working again.

Now, exactly 3 days later, it has stopped again.

Has anyone else experienced this and know of a fix besides reboot or
perhaps a downgrade? Theres nothing in particular that I need from
this release, but it would still be annoying.

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

[j-nsp] Asymmetric flow, session reset, breaking SSH

[Tom Storey]

Hi all, hoping there is someone familiar with J Series flow handling
that can help me out with this.

I have a network situation (deliberate by design, not accidental in
any sense) that results in asymmetric data flow. There are 3 devices
involved, a PC, J2320, and a Cisco 1811. The PC is plugged into a
switch port on the 1811 configured as an access port in VLAN10. This
VLAN is trunked via a second switch port on the 1811 to ge-0/0/2
(configured for VLAN tagging) on the J2320 where the default gateway
for the PC lives. The J2320 is also connected via ge-0/0/1 to Fa0 on
the 1811, and this is used for pure routing.

Initiating an SSH session from the PC results in IP packets being
switched through the 1811 and into the J2320 where they then exit via
ge-0/0/1 and into port Fa0 on the 1811. There is an SVI configured on
the 1811 in the same subnet that the PC lives in (along with
ge-0/0/2.10), so when the 1811 sends packets back to the PC they go
straight out and into the PC rather than back through the J2320.

This results in a session on the J2320 which has data flow in one
direction, but not the other. After about 10 or so seconds, the J2320
clears this session and sends an RST back to the PC, dropping the SSH
session, but not the 1811 it seems (which ties up VTY lines - but this
is ok, they clear themselves up after exec-timeout is reached.)

If I set security flow tcp-session no-syn-check on the J2320 the
problem seems to disappear, and it no longer seems to care about one
way data flow. But the session doesnt clear away after I end the SSH
session (via ~. or exit), not at least for 40 minutes or so anyway.

Does anyone know how to properly handle situations like this? At the
moment the configuration is just in a lab, pre-deployment. Otherwise
the only practical way I can see to get around this is to remove the
SVI from the 1811 so that it doesnt have a direct route back to the
PC. This will just require a slight modification to the design, and
I'll need to acquire additional IPs to assign to the 1811 (e.g. a /32
assigned to a loopback interface) in place of sitting it in what will
be a DMZ subnet via the SVI.

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

Re: [j-nsp] Asymmetric flow, session reset, breaking SSH

[Tom Storey]

NAT is evil. :-)

Removing the SVI from the Cisco seems the cleanest solution to me,
allowing packets to just route naturally.

Thanks.

On 8 August 2012 15:08, Mark Menzies m...@deimark.net wrote:
 We can go about this in one of 2 ways here.

 1.  Remove the cisco SVI and force all the traffic to be passed through the
 J series

 2.  Add interface NAT to the initial SSH session when passing the SYN
 through to ge-0/0/2.10.  This achieves the same aim as 1 by forcing the
 reply traffic back through the J series as the source address of the SSH
 connection seems to be the J series.

 If we do the no-syn-check, we are basically negating any benefit we get from
 the J series as a firewall and I would not normally recommend that.

 The nat solution in 2 is common place for traffic that the firewall needs to
 see for some local network traffic (ie switched rather than routed)

 HTH




 On 8 August 2012 15:00, Tom Storey t...@snnap.net wrote:

 Hi all, hoping there is someone familiar with J Series flow handling
 that can help me out with this.

 I have a network situation (deliberate by design, not accidental in
 any sense) that results in asymmetric data flow. There are 3 devices
 involved, a PC, J2320, and a Cisco 1811. The PC is plugged into a
 switch port on the 1811 configured as an access port in VLAN10. This
 VLAN is trunked via a second switch port on the 1811 to ge-0/0/2
 (configured for VLAN tagging) on the J2320 where the default gateway
 for the PC lives. The J2320 is also connected via ge-0/0/1 to Fa0 on
 the 1811, and this is used for pure routing.

 Initiating an SSH session from the PC results in IP packets being
 switched through the 1811 and into the J2320 where they then exit via
 ge-0/0/1 and into port Fa0 on the 1811. There is an SVI configured on
 the 1811 in the same subnet that the PC lives in (along with
 ge-0/0/2.10), so when the 1811 sends packets back to the PC they go
 straight out and into the PC rather than back through the J2320.

 This results in a session on the J2320 which has data flow in one
 direction, but not the other. After about 10 or so seconds, the J2320
 clears this session and sends an RST back to the PC, dropping the SSH
 session, but not the 1811 it seems (which ties up VTY lines - but this
 is ok, they clear themselves up after exec-timeout is reached.)

 If I set security flow tcp-session no-syn-check on the J2320 the
 problem seems to disappear, and it no longer seems to care about one
 way data flow. But the session doesnt clear away after I end the SSH
 session (via ~. or exit), not at least for 40 minutes or so anyway.

 Does anyone know how to properly handle situations like this? At the
 moment the configuration is just in a lab, pre-deployment. Otherwise
 the only practical way I can see to get around this is to remove the
 SVI from the 1811 so that it doesnt have a direct route back to the
 PC. This will just require a slight modification to the design, and
 I'll need to acquire additional IPs to assign to the 1811 (e.g. a /32
 assigned to a loopback interface) in place of sitting it in what will
 be a DMZ subnet via the SVI.

 Thanks.
 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] Commit status in SNMP

[Tom Storey]

What about forcing the use of configure exclusive and configure
private as opposed to plain configure? This way you're either
locking configuration of the box to yourself for a good reason, or
multiple people/systems can work on configuration simultaneously?

Its a tiny pain to get used to in the beginning, but not so bad.


On 2 August 2012 09:35, Benny Amorsen benny+use...@amorsen.dk wrote:
 Is it possible via SNMP to see if the configuration is locked or whether
 there are uncommitted changes?

 If I forget to commit my changes, our automated configuration systems
 cannot do their job. I'm wondering if I could make OpenNMS poke me
 when that happens -- before the automated scripts start failing.


 /Benny


 ___
 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] cable modem/dsl/ftth bandwidth limiting

[Tom Storey]

An ISP I used to work for shaped/policed every single session at the
LNS, downstream towards the customer, to the maximum service speed of
their purchased plan.

If a customer suddenly becomes the target of a DoS attack, you dont
want hundreds or thousands of megabits flooding onto your expensive
and/or limited uplinks to your wholesale broadband suppliers and
potentially affecting all of your customers instead of just 1.

Also if a customer is provisioned for say 2mbit, and the provider
stuffs up and accidentally allows 20mbit, the customer still only gets
what they paid for, though I think that was very rare, and it was
mostly to protect from the above.

They used a number of different platforms (all Cisco) from 7200, to
1, and now ASR1k.

Tom


On 19 June 2012 21:41, Chris Kawchuk juniperd...@gmail.com wrote:
 Not costly at all; when you think about scaling it to 20,000/30,000 
 subscribers per box.

 BRAS's (xDSL, PPPoE, PPPoA) have massive numbers of hardware queues, and 
 shape/queue per individual subscriber. These boxes are designed to do this.

 Examples: Juniper E-series, Cisco ASR-Series, Juniper MX-series w/the Q 
 cards, Redback SmartEdge 400/800, etc...

 You still need something in the central network anyways to aggregate all 
 these individual connections from every scubscriber. It's a natural to 
 perform this function there; and not at the CPE. Usually it's the link 
 between the DSLAM/CMTS/GPON to the Customer that's congested anyways - As 
 Jerry mentioned, why transport it just to drop it? May as well rate-limit it 
 upstream before it hits the narrow-bandwidth portion of the link to the 
 customer.

 - CK.

 On 2012-06-20, at 3:19 AM, Chris Evans wrote:

  performing bandwidth limits on a central network device
 would be too costly to do.


 ___
 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] J2320 power consumption

[Tom Storey]

Has anyone measured the actual power consumption of a J2320 with a
watt meter and have the results handy?

Im looking at sticking one into co-lo, and Junipers documentation
says, from the way Im reading it, 1.3 amps at 240v. But in my
experience gear tends to use a lot less than the manufacturer quotes.

If anyone has a J2320 and a watt meter handy I would greatly
appreciate if you would be able to take a reading for me (powered up
and sitting idle after full boot.)

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

[j-nsp] J2320 power consumption

[Tom Storey]

Thanks!

So that would be about 500mA at 240v for the pair by my reckoning, or about
250mA each? And if thats for a 2350, one would imagine a 2320 would be the
same or less.

I also would have no modules, just using base ports.

On Monday, June 18, 2012, Yucong Sun (叶雨飞) wrote:

 I have a pair of J2350 running about 200mbits through traffic each and
 they together use about 1A under 120v (juding from my power strip) . Hope
 it will helps your decision.

 Cheers.

 On Mon, Jun 18, 2012 at 2:42 PM, Tom Storey t...@snnap.net wrote:

 Has anyone measured the actual power consumption of a J2320 with a
 watt meter and have the results handy?

 Im looking at sticking one into co-lo, and Junipers documentation
 says, from the way Im reading it, 1.3 amps at 240v. But in my
 experience gear tends to use a lot less than the manufacturer quotes.

 If anyone has a J2320 and a watt meter handy I would greatly
 appreciate if you would be able to take a reading for me (powered up
 and sitting idle after full boot.)

 Thanks,
 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] what would you put in this PoP

[Tom Storey]

Assuming space were not an issue, is there a reason why you might
avoid something like an M320, or maybe a T320, being the traditional
multi-protocol boxes?

Im just a curious bystander, trying to learn. :-)


On 23 May 2012 10:33, Per Granath per.gran...@gcc.com.cy wrote:
 MX240, with redundant REs, with two MPC1, two 2XE MIC, one ATM MIC, one 20GE 
 MIC.
 For the Business connections, do a VC of two EX4200, uplinks to the available 
 XE ports.

 If you have space, go for the MX480 which does not really cost much more.

 You need to figure out if you can use MPC1E (reduce scale L3) or MPC1-3D-R-B 
 (full scale L3), depending on your services (L3VPN?).

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of MKS
 Sent: Wednesday, May 23, 2012 1:32 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] what would you put in this PoP

 Hi

 Imagine a town of 15.000-20.000 people. What type of device/devices and
 size would you put into this town, given the following requirements

 Residential triple play (HSI, VoD, Multicast)
    8 IP dslams (GigE)
    Vod servers (4 GigE pors)

 Business connections (L3VPN)
    10 Business connections on GigE
    30-40 Business connections 10-100 mb

 AToM
 ATMoMPLS port mode, 4 STM1 ports needed.

 Uplinks on 10GbE in a ring based structure, current traffic levels 2-3 gigs 
 total
 BNG termination (pppoe) is not a requirement

 Spare parts are located 4-5 hours away.

 1) If you where given a clean slate, what would you put in?
 2) What do you put normally, given your normal capex level.

 Regards
 MKS
 ___
 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

[j-nsp] Capturing/displaying contents of incoming packets

[Tom Storey]

Hi all,

I am trying to debug some stubborn circuits that just dont seem to
want to work. I can see incoming packets being recorded on both
interfaces (10GE, both on the same router), but I cannot ping across
either link. Ive verified with the owner of the router at the other
end and we are using the correct subnets, and the same interface
configuration, but neither of us can ping the other.

I am interested to try and work out what is in the packets that are
coming in to work out if they belong to the routers they are supposed
to at the opposite end of each link, or where they are from.

Im wondering if there is some way to output the details like a TCP
dump, or capture to a pcap file which can be read by Wireshark et al?
The later seems possible on certain models, but not the gear in
question here, an MX960 with DPCEs.

The rate of packets is extremely low, as in 1 or 2 packets a minute,
but would potentially reveal a lot to me at this stage. Unfortunately
theres a bit of an air (and sea) gap between me and the router in
question, so any form of local troubleshooting is out of the question
at the moment.

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

Re: [j-nsp] Layer 2 feature on srx

[Tom Storey]

What software are you running on your SRX's?

The only reason I ask is that I am running 10.4R4.5 on an SRX100, and
this is how I do my VLANs (SRX is in flow mode, but does that really
matter to L2??):

interfaces {
fe-0/0/1 {
description ** Trunk to esxi1;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
native-vlan-id 1;
}
}
}
fe-0/0/4 {
description ** Console server;
unit 0 {
family ethernet-switching {
vlan {
members VLAN11-MGMT;
}
}
}
}
vlan {
unit 10 {
family inet {
address 172.25.144.65/26;
}
family inet6 {
address 2001:::1::/64 {
eui-64;
}
}
}
unit 11 {
family inet {
address 172.25.144.17/28;
}
}
}
}
vlans {
VLAN10-LAN {
vlan-id 10;
l3-interface vlan.10;
}
VLAN11-MGMT {
vlan-id 11;
l3-interface vlan.11;
}
}

The primary difference seems to be that I use vlans instead of
bridge-domains at the bottom, and the vlan interface instead of
irb.

Ive also successfully trunked VLANs to/from a HP switch using this
configuration.

Tom


On 9 April 2012 10:05, bruno bruno.juni...@gmail.com wrote:
 hello expert,
 i use two srx210h to test some Layer 2 networking features on MX Series 
 routers. the topo is very simple
 PC1---SRX1SRX2PC2.  the link in srx1---srx2 is set to trunk mode. PC1 
 and PC2 is belong to vlan 100.  PC1 can't ping PC2.


 interfaces {
    ge-0/0/1 {
        description TO-SRX2;
        vlan-tagging;
        unit 0 {
            family bridge {
                interface-mode trunk;
                vlan-id-list [ 100 200 ];
            }
        }
    }
    fe-0/0/4 {
        unit 0 {
            family bridge {
                interface-mode access;
                vlan-id 100;
            }
        }
    }
    irb {
        unit 100 {
            description GW For VLAN 100;
            family inet {
                address 100.1.1.254/24;
            }
        }
        unit 200 {
            description GW For VLAN 200;
            family inet {
                address 200.1.1.254/24;
            }
        }
    }
 }
 security {
    forwarding-options {
        family {
            mpls {
                mode packet-based;
            }
        }
    }
 }
 bridge-domains {
    vlan_100 {
        vlan-id 100;
        routing-interface irb.100;
    }
    vlan_200 {
        vlan-id 200;
        routing-interface irb.200;
    }
 }



 --
 Best Regards,
 Bruno
 ___
 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] Regular maintenance advice

[Tom Storey]

On 3 April 2012 15:41, Julien Goodwin jgood...@studio442.com.au wrote:
 If you can be strict about it you can say anything but up/up and
 down/down are problems.

What about SONET/SDH interfaces that display down/up?

The interface can be admin down, but if its still receiving a
SONET/SDH signal from the other side then line proto will be up -
nothing necessarily wrong with that. :-)

In reply to Skeeves original email, is there any reason you couldn't
script something like this? At least give a device a once over and
produce a summary report of problems for this device after which the
tech can then target only devices that have issues that need
attention. Otherwise you find yourself wasting time looking at a bunch
of boxes that dont need to be looked at when you could be doing
something more productive.

Or better yet, syslog and SNMP traps collectors and some scripts that
produce a dashboard highlighting any issues detected. :-)

Scripts, scripts, scripts everywhere. :-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Logical systems on an M7i

[Tom Storey]

Hi Doug,

Thanks for the reply. You are correct, each logical system gets its
own rpd process.

I managed to get access to an M7i and indeed you can do 15 LS's on
them. Each rpd process only takes a couple of MB RAM, and seem to be
quite light on CPU (barely even registers) so it looks promising for
an RE-400 with only a couple of hundred MB of RAM even.

Still need to test with a few more features, so this might impact on
RAM and CPU. We'll see over the next couple of days as I play around
some more.

Hopefully this information is helpful for someone else. :-)

Tom

On 1 March 2012 05:37, Doug Hanks dha...@juniper.net wrote:
 15.  Should be fine for personal use.  It really just spawns another
 instance of rpd.

 Thank you,

 --
 Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
 Sr. Systems Engineer
 Juniper Networks



 On 2/29/12 9:51 AM, Tom Storey t...@snnap.net wrote:

Hi everyone.

Can anyone provide any pointers for the maximum number of logical
systems one could expect to run on an M7i?

As I understand it, each logical system has its own batch of processes
running on the RE, so I am assuming the number is going to be some
function of how much RAM you have on it.

I am looking at using an M7i or two in a lab, with not very large
tables (basically just the topology of the lab itself), but want to
maximise the number of logical routers I can run to allow for
vast/complex topologies. Ideally I would be able to run 20 logical
systems.

There are quite a few M7i's floating around on ebay with RE-400-768's,
or even RE-400-256's (though RAM should be quite easy to upgrade.) The
maximum number of logical systems per box is supposed to be 15, but
with a RE-400-768, that gives roughly 50mb of RAM to each one,
excluding the overhead for the system itself. How much RAM is required
to run one? Can an RE-400 expand past 768mb?

RE-850-1536 would give about double the RAM for each logical system
and Im sure a decent boost in responsiveness due to faster CPU, but
are about as rare as hens teeth with a price to match.

Price is a big constraint since this will be for personal use, so
while I know the MX80 is a nice box, it is out of my reach
financially. :-)

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

[j-nsp] Logical systems on an M7i

[Tom Storey]

Hi everyone.

Can anyone provide any pointers for the maximum number of logical
systems one could expect to run on an M7i?

As I understand it, each logical system has its own batch of processes
running on the RE, so I am assuming the number is going to be some
function of how much RAM you have on it.

I am looking at using an M7i or two in a lab, with not very large
tables (basically just the topology of the lab itself), but want to
maximise the number of logical routers I can run to allow for
vast/complex topologies. Ideally I would be able to run 20 logical
systems.

There are quite a few M7i's floating around on ebay with RE-400-768's,
or even RE-400-256's (though RAM should be quite easy to upgrade.) The
maximum number of logical systems per box is supposed to be 15, but
with a RE-400-768, that gives roughly 50mb of RAM to each one,
excluding the overhead for the system itself. How much RAM is required
to run one? Can an RE-400 expand past 768mb?

RE-850-1536 would give about double the RAM for each logical system
and Im sure a decent boost in responsiveness due to faster CPU, but
are about as rare as hens teeth with a price to match.

Price is a big constraint since this will be for personal use, so
while I know the MX80 is a nice box, it is out of my reach
financially. :-)

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

Re: [j-nsp] Unit ID's and q-in-q

[Tom Storey]

Dotted unit numbers is an interesting concept. Why not both? :-)

On 27 December 2011 22:28, Benny Amorsen benny+use...@amorsen.dk wrote:

 Saku Ytti s...@ytti.fi writes:

  What ever you do, also open enhancement request. This is extremely
 annoying
  and trivial to fix.
  (While at it JNPR, give us tags/colours to direct routes, kthx).

 Certainly. What would be your preferred enhancement, just larger unit
 numbers or the ability to have unit ID's with dots in?

 If the commit check error message is to be believed, larger unit ID's
 are already available for certain interface types (demux0 and pp0).


 /Benny

 ___
 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] Unit ID's and q-in-q

[Tom Storey]

You could stick something in the description of the interface, like some
sort of tag, and then just do a show int desc | match tag.

Something along the lines of

description Customer X [qq=1010.7];

or some such. No scripts or databases to maintain either, infact a script
could automatically maintain a DB for you based on this kind of setup. :-)

On 22 December 2011 23:26, Derick Winkworth dwinkwo...@att.net wrote:

 Just do it sequentially and then write an op script that takes the vlan(s)
 as an argument to show you the interface info you are looking for...


 Sent from Yahoo! Mail on Android

 ___
 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] questions regarding submarine cables

[Tom Storey]

The Pipe International blog is excellent, I followed it from start to
finish while it was happening. It gives a real insight that has probably
never been given before about the construction of a submarine cable, and
some of the operational aspects (at least not on a free for all public
blog).

Dont forget to read the comments section of each article, as additional
questions and answers can be found there!

Tom

On 12 December 2011 03:02, Mark Tinka mti...@globaltransit.net wrote:

 On Monday, December 12, 2011 06:54:14 AM Martin T wrote:

  This isn't directly related with Juniper, but hopefully
  not totally off-topic as well :) At least here might be
  some industry insiders, who have some experience with
  submarine cables.

 It's operational in a way that affects the Internet, so I'm
 happy :-).

  1) According to engineer in this video:
  http://vimeo.com/29975179 ..modern submarine cables are
  often built as self-healing rings. For example FLAG
  Atlantic (FA-1) between USA and Europe seen here:
  http://www.cablemap.info/ is a good example. How does
  such self-healing ring works?

 In essence, it's not that different from SDH or SONET rings
 built on land.

 See here:

http://en.wikipedia.org/wiki/EAC-C2C


 However, it is also feasible that some cable operators
 consider options for building 2x or more linear paths, as
 opposed to ring topologies (ring topologies do have their
 own sets of challenges, e.g., choosing the best route,
 guarantees on latency, management, e.t.c.; which is not to
 say that linear topologies do not bring with them their own
 unique set of constraints - it's a balancing act).

  Am I correct, that in case
  both cables are healthy, only one of two is utilized
  with traffic?

 Cable operators are unlike IP operators. They don't normally
 load balance traffic across all available physical media.

 They could use the other part of the cable as a Protect
 circuit, i.e., if you buy a service from the cable operator
 and request for protection, the protection will be enabled
 on the other part of the ring.

 Some operators run as many as 3x rings and designate that as
 primary, secondary and tertiary.

  Who provides equipment for such setups(I
  guess Alcate-Lucent is one of the vendors)?

 Key submarine equipment (SLTE) vendors are:

o ALU.
o Fujistu.
o NEC
o Tyco.


 Some of the terrestrial players are now looking to enter
 this space, e.g., Huawei, Infinera, Nortel, e.t.c.

  In addition,
  how long it will take such switch-over to occur? Are we
  talking about couple of milliseconds or few seconds?

 Cable operators offer 50ms failover for pre-provisioned
 protect circuits. Typical electrical hand-offs to customers
 are SDH or SONET, although Ethernet is now commonplace. I've
 dealt with SDH and Ethernet only.

 However, I know some cable operators are considering
 GMPLS/ASON which does provide protection, but may not be as
 quick as 50ms. GMPLS, for example, uses an IP control
 comprising:

o OSPF-TE or ISIS-TE for routing.
o RSVP-TE or CR-LDP for signaling.
o LMP for link management.

 Of course, what we normally do is rather than buy a service
 + protect circuit from the same cable operator, we buy 2x
 service circuits from different operators so we can:

a) Have both circuits active at the same time.
b) Reduce risk by using different providers.

  2) In case cable has multipoint landings(for example
  GLO1, which has 15 landings in west coast of Africa
  and Europe) then submarine branching units should be in
  use. How this branching works? Are some waves(CWDM)
  inside the cables switched towards the landing and other
  continue via submarine cable? Because as I understand,
  on a wave level, we are still talking about point to
  point connections(?). In addition, are those branching
  units under the water or are they on small islands, oil
  platforms etc if possible?

 That is what is called an OADM-BU. You may take a look here:

 http://www.nec.co.jp/techrep/en/journal/g10/n01/100104-71.html

 http://blog.pipeinternational.com/index.php?option=com_myblogshow=The-
 OADM-BU.htmlItemid=53

 Hope this helps.

 Cheers,

 Mark.

 ___
 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] DHCP IPv6

[Tom Storey]

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 {
tunnel {
source me.me.me.me;
destination 216.66.80.26;
}
family inet6 {
address 2001:470:1f08:me::2/64;
}
}
}
pp0 {
unit 0 {
family inet {
filter {
input FIX-V6V4-TUNNEL;
}
}
}
}
vlan {
unit 10 {
family inet {
address 172.25.144.65/26;
}
family inet6 {
address 2001:470:me:1::/64 {
eui-64;
}
}
}
}
}
routing-options {
rib inet6.0 {
static {
route ::/0 next-hop 2001:470:1f08:me::1;
}
}
}
protocols {
router-advertisement {
interface vlan.10 {
prefix 2001:470:me:1::/64 {
on-link;
autonomous;
}
}
}
}
firewall {
family inet {
filter FIX-V6V4-TUNNEL {
term OUTPUT {
from {
destination-address {
216.66.80.26/32;
}
protocol 41;
}
then packet-mode;
}
term INPUT {
from {
source-address {
216.66.80.26/32;
}
protocol 41;
}
then packet-mode;
}
term OTHERWISE {
then accept;
}
}
}
}

IPv6 has some issues on the SRX series still, meant to be fixed in 11.4
IIRC, so theres a simple fix required to make it work in the mean time with
the firewall rule.

Someone may find this useful. :-)


On 10 October 2011 16:26, Mark Tinka mti...@globaltransit.net wrote:

 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 setups where v6 is
 involved.

 Common cases have been Windows Vista hosts making themselves
 routers and spewing 6-to-4 on the network. Suffice it to
 say, DRP implementation in routers (sort of meant to thwart
 this) on the subnet is pretty useless.

 As you likely know, Rogue RA support is lacking today
 (although specs. are already out), as is DHCPv6 Snooping.
 Our only solution was to filter at the MAC layer. Hectic,
 but luckily, we used few switches and were able to deploy
 filters quite rapidly.

 Mark.

 ___
 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] ex4200 vlan problem

[Tom Storey]

Is that device running any kind of firewall? Seems likely if you can ping
from it.

On 26 August 2011 16:26, Pappas, AJ apap...@ottawaregional.org wrote:

 I am have a ex4200 that is configured for a particular vlan vlan 244.
 This vlan is configured on 2 ports.  I can reach one device fine, the
 other I am unable to ping the second device ge-4/0/16.



 I can ping from it but not to it.



 AJ Pappas   |   Network Administrator

 www.ottawaregional.org http://www.ottawaregional.org/   |
 apap...@ottawaregional.org mailto:apap...@ottawaregional.org
 phone: 815.431.5180 | mobile line: 815.993.8522
 1100 East Norris Drive, Ottawa, IL 61350 USA





 ___
 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] traffic load balancing between Juniper and Cisco equipment

[Tom Storey]

Or where MLPPP is not possible (since some ISPs dont allow it for various
reason), some sort of E/IGP and an appropriate multipath/equal cost routing
config?

Perhaps not as seamless as MLPPP as you'll need to wait for the protocol to
realise the other end is no longer there, but on the way down I think even
MLPPP wont be entirely seamless either (it also needs to work out that the
other end isnt there), causing perhaps minimal p/l, but I think everything
will be like that anyway.

Theres is also this thing called qualified-next-hop in JunOS which you
might be able to use in conjunction with object tracking on the Cisco side
to create static routes that load balance across available links using equal
cost routing. Not 100% sure if it will allow multiple routes/paths to exist
though, have not looked at it in that way yet...

I used qualified-next-hop to configure a failover solution for a friends
business. User LAN traffic was policy routed out of a cheapie ADSL
connection while servers take a default route via an SHDSL circuit. But
should ADSL fail, user LAN traffic would roll over to the SHDSL circuit. It
works pretty well, but getting a bit O/T.

Tom

On 22 August 2011 14:36, Gabriel Blanchard g...@teksavvy.ca wrote:

 mlppp


 On 08/21/2011 08:11 PM, Martin T wrote:

 Is it possible to load-balance traffic between a Juniper M10i and
 Cisco 1812 using two different last-mile(ADSL2+) providers? Topology
 should be like this:

 http://img803.imageshack.us/**img803/8766/loadb.pnghttp://img803.imageshack.us/img803/8766/loadb.png

 Idea is to use both ADSL2+ links simultaneously in order to achieve
 better speed. In case on of the link fails, the traffic should use the
 available ADSL2+ path. Is such load-balancing doable using the Juniper
 PE router and Cisco CPE? If yes, what are the optimal/easiest
 technologies to achieve the goals I described?


 regards,
 martin
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp

 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Help with NAT configuration

[Tom Storey]

Im sure this question has been asked before, but googling and reading  
examples and the JUNOS documentation has not yeilded an answer yet.


I have a classic network example whereby my WAN IP address is  
dynamically assigned, but every configuration example I have seen  
specifically states the WAN IP address [range] to use for NAT.


Is there anyway I can simply say I dont know what address to use, use  
whatever is assigned to interface x? Specifically I would like to  
tell it to use which ever address is assigned to pp0.0.


Below is the config I wish to apply, but Ive yet to solve the above  
before I can commit it (complains about the lack of address in the  
pool). Ive been playing around, so please correct me on any mistakes  
Ive made.


Any help greatly appreciated! :-)

  services {
  service-set wan-service-set {
  nat-rules nat-egress;
  nat-rules nat-ingress;
  interface-service {
  service-interface sp-0/0/0;
  }
  }
  nat {
  pool nat-pool {
  port automatic;
  }
  rule nat-egress {
  match-direction output;
  term 1 {
  then {
  translated {
  source-pool nat-pool;
  translation-type {
  source dynamic;
  }
  }
  }
  }
  }
  rule nat-ingress {
  match-direction input;
  term other {
  from {
  destination-address {
  any-unicast;
  }
  }
  then {
  no-translation;
  }
  }
  }
  }
  }

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

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tom Storey]

On 13/02/2009, at 6:21 PM, Tore Anderson wrote:


Hey, Juniper, if you're reading this:  Do you think that I ENJOY  
wasting

hours of my to clear up the mess this «feature» has caused,


If using MRTG, and particularly if you use cfgmaker, you could always  
specify the -ifref=descr option.


This will cause interface names rather than interface indexes to be  
placed in the generated config. This way if the ifIndex changes your  
graphs dont break.


However, this would require at least one more SNMP operation each time  
MRTG runs to associate ifNames with ifIndexes (I am unsure if MRTG  
will do one walk to get a list of all ifNames and associated  
ifIndexes, or if it does it per interface).


But at least you wont have to suffer the agony of updating all of your  
MRTG configs to accomodate changed ifIndexes. I too got over doing  
this, and now dont generate any MRTG configs using cfgmaker without  
the above option.


Example from one of my MRTG configs, though its from a Cisco:

Target[myrouter_FastEthernet0_0.2]: \FastEthernet0/0.2:pub...@myrouter:

Give it a try.

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

Re: [j-nsp] Rate limiting

[Tom Storey]

 Hello,

 I have configured following policer

 policer bw-1500k.5ms {
 if-exceeding {
 bandwidth-limit 150;
 burst-size-limit 1500;
 }
 then discard;
 }

 believing it will rate limit traffic to 1500 Kbps. But it starts to drop
 packets at much less than configured bandwidth-limit rates. When
 burst-size-limit was strongly increased (150K) everything went well.

 I read that JTAC suggests setting the burst-size-limit equal to the
 amount of traffic forwarded by the interface in 5 milliseconds but I
 can't figure out fundamentals for that suggestion. The appropriate
 policer didn't work as I expected. Can anybody give some references
 about setting allowable time for burst traffic?

 Thanks

A burst size of 1.5kbps as you have configured in your example only allows
traffic to increase at 1.5 kilobits each second, not a hell of a lot. At
that rate it would take upto 1000 seconds, i.e. 16 minutes to reach the
full 1.5 megabits you are wanting to supply...

That is going to cause considerable packet loss as the permittable traffic
level is gradually increased.

Im no expert on the subject, particularly when it comes to Juniper, but I
have found on my Ciscos that a burst size of 5-10% of the CIR works pretty
well for TCP traffic on multi megabit policers. For sub megabit policers a
minimum of 64kbit works pretty well. Though having said that Ive never
really looked into the loss figures for any of these policers, so I dont
know how well they perform.

Tom

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

Re: [j-nsp] RAM for J2300

[Tom Storey]

 On 16 Dec 2008 at 12:24, Tom Storey wrote:
 [...]
 Can anyone confirm if DDR400 will work with a J2300? I understand this
 is
 able to fall back to DDR266.

   Yep, that's just the spec.  The clock is supplied by the chipset.
 If I'd planned ahead I would have used the memory I pulled from my
 SSG 550 in my J2300, but I'd already purchased more (identical sticks
 from Crucial).  It's DDR (i.e. DDR1), non-ECC.  If you use a memory
 selector, just choose an Intel 845G motherboard.  I prefer Crucial as
 Juniper uses Micron sticks, but that's just paranoia.
   Theoretically the chipset will support 1GB, but I haven't tried
 more in the J2300.  While the forwarding process sucks up a
 tremendous amount or RAM, I doubt 1GB (to achieve 512MB free when
 idle/unconfigured) would buy you much.

 [...]

 Peter E. Fry


Thanks to all who responded. Seems Ive got everything sorted out now. :-)

Cheers,
Tom

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

[j-nsp] RAM for J2300

[Tom Storey]

Hi all,

Can anyone confirm if DDR400 will work with a J2300? I understand this is
able to fall back to DDR266.

If DDR400 wont work, is anyone able to confirm if any old DDR266 stick
will work, or does it have to be a specific brand or have specific
features?

Thanks.
Tom

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

[j-nsp] Getting started with Juniper

[Tom Storey]

Hi all, hopefully not too off topic.

Im looking for some advice on getting started with Juniper.

A J2300 (with 2xE1 and 2xFE) has come up that might be in my price range,
and if it is Id be very interested in buying it.

At present Im very much a Cisco person, but Ive always been interested in
wetting my hands with Juniper aswell. Cant hurt to be vendor diverse, can
it? :-)

I guess the most important piece of information Im looking for is: what is
the most cost effective way to get my hands on a more recent JUNOS image?
The box currently appears to have 7.0R1.5 on it which is from around 2004,
which sounds a bit old.

The types of features I'd be looking for are:

* PPPoE
* Routing protocols (OSPF, BGP)
* IPSEC
* MPLS
* IPv6 is a must, but seems to be covered already anyway
* LAC and LNS functionality (L2TP)
* Definitely want dot1q for the FE ports, but I believe this is also covered

What sort of image would I be looking at to support these features? Can
anyone point me in the right direction to some web pages that have the
info on them?

Im continuing my own searches to delve more into this particular subject,
but any advice would be greatly appreciated for this fledgling Juniper
tech. :-)

Cheers,
Tom

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

Re: [j-nsp] The Switch is ON !!!

[Tom Storey]

 This makes it more useful than the Nexus.  MPLS = good.

If youre looking at using it in an SP environment, yes.

But the Nexus isnt targeted at SP environments...

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