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

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  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...
>
&g

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

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

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

Re: [j-nsp] SRX Layer 2 Bridge

[Tom Storey]

If you can handle burning 2 more ports on your SRX you could also do the
following:

The existing interface which the VLANs come in on is "interface A".

Take two more interfaces, B and C and hook them up back to back and
configure interfaces A and B as switched trunk interfaces.

On interface C you can terminate VLANs using routed sub interfaces by
allowing them to trunk between A and B, while other VLANs that come in
through interface A can be terminated on vlan.x interfaces, trunked off to
another device, or you can just use that to allow you to add in more ports
to that VLAN. What ever really.

Not entirely elegant, but it should work.

On 21 November 2014 at 16:59, Levi Pederson <
levipeder...@mankatonetworks.net> wrote:

> All,
>
> I'm in a bit of a quandry.  I need to land a vlan on a Tagged interface and
> then have it processed by the l3 vlan interface.
>
> I currently have 5 different tags landing on that interface and would like
> to add another.
>
> Has anyone accomplished this.  All the internet has given me is the use of
> the "family bridge" and that is being rejected as there is an "inet"
> statement (on another Logical interface) in existence.
>
> Thank you,
>
> *Levi Pederson*
> Mankato Networks LLC
> cell | 612.481.0769
> work | 612.787.7392
> levipeder...@mankatonetworks.net
> ___
> 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] Cisco to Juniper, route based IPSec VPN

[Tom Storey]

NY bind-interface st0.0
> set security ipsec vpn COMPANY ike gateway GATEWAY
> set security ipsec vpn COMPANY ike proxy-identity local 10.250.1.2/32
> set security ipsec vpn COMPANY ike 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

[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] 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  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  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  on behalf of Sam
>> Silvester 
>> 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

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"  wrote:

> Why not an MX instead?
>
>
> On Wed, Apr 16, 2014 at 11:41 AM, Tom Storey  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 (R&S)
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[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] 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  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] J2300/J4300 FPCs cannot go online

[Tom Storey]

Ive just tried this on my J2300 running 9.3r4.4.

The certificate now appears, unlike before when nothing appeared:

root> show system certificate
Certificate identifier: FeatureLicense-v4

However my FPC is still seemingly refusing to come online:

root> show chassis fpc detail
Slot 0 information:
  State   Offline
  Reason  Chassis connection dropped

root> request chassis fpc slot 0 online
FPC 0 is in transition, try again

The instructions dont seem to indicate whether anything further from
adding the new certificate needs to be done. I tried a couple of
reboots, and that didnt seem to help. Any clues?

On 28 March 2014 20:15, Mircho Mirchev  wrote:
> Tomorrow I test this with 9.3 and keep the list posted about the result.
> In 9.3 there's no specific license to enable all the ports. Seems it's
> embedded.
>
> Sent from my mobile.
> On 28 Mar 2014 21:41, "Damon Vaughn"  wrote:
>
>> Please refer to Juniper technical service bulletin TSB16366 that documents
>> the fix for the certificate issue.
>>
>> -
>> Confidentiality Notice:
>> This email and any of its attachments may be legally privileged
>> and/or confidential. If you are not an intended recipient, you
>> should not retain, disseminate, distribute, or copy this e-mail and
>> may be violating law if you do so. If you have received this e-mail
>> in error, please notify the sender and permanently delete this
>> e-mail and any attachments immediately.
>>
>>
>> ___
>> 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] Do the old M-series fixed optic SONET/SDH PICs wear out?

[Tom Storey]

show int diag optic 

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

>
> On Mar 14, 2014, at 5:06 PM, Will Orton >
> 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 
> > 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] TACACS in Junos

[Tom Storey]

For everyones reference, this is the config I have been using, and
seems to work as you'd expect on a Cisco. Using this config I have run
Junipers against the same TACACS server used by Cisco devices without
any issues.

system {
authentication-order [ tacplus password ];
root-authentication {
encrypted-password ""; ## SECRET-DATA
}
tacplus-server {
172.25.150.26 {
secret ""; ## SECRET-DATA
timeout 5;
source-address 172.25.150.26;
}
}
accounting {
events [ login change-log interactive-commands ];
destination {
tacplus;
}
}
login {
class rescue {
idle-timeout 30;
permissions all;
}
user remote {
full-name "Remote user template";
uid 2002;
class rescue;
}
user rescue {
full-name "Rescue account";
uid 2000;
class rescue;
authentication {
encrypted-password ""; ## SECRET-DATA
}
}
}
}

The key is in the "remote" user, which is basically a template from
which various properties get assigned to each user that logs in. It
needs to exist and needs to be called "remote", but commands executed
by users are recorded against their own username, as expected.

The "rescue" account is what you use to log in if TACACS becomes
unavailable for some reason (e.g. network outage) but can be called
anything you want, same goes for the "rescue" class.

On 20 March 2014 22:16, Skeeve Stevens
 wrote:
> Hey all,
>
> We've been implementing Tacacs on our networks and have this issue where we
> can't seem to get Tacacs working unless we declare the username and Tacacs
> is used just for the authentication.
>
> Does anyone know how to get Tacacs working like Cisco where you just set it
> up and once you add users to the Tacacs back-end, they can login?
>
> ...Skeeve
>
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> 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] 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  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  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

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 
> >
> 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');> > > 'p.may...@imperial.ac.uk > 'p.may...@imperial.ac.uk');>');>>
>> > Date: 19/12/2013 6:09 PM (GMT+03:00)
>> > To: Tom Storey > 't...@snnap.net');> > > 't...@snnap.net ');>>
>> > Cc: juniper-nsp@puck.nether.net > 'juniper-nsp@puck.nether.net');> > > 'juniper-nsp@puck.nether.net > '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.uk');>
>> > '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> > 'cvml', 'juniper-nsp@puck.nether.net');>> > 'cvml', 'juniper-nsp@puck.nether.net > 'juniper-nsp@puck.nether.net');>');>
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net > '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]

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');>>
> Date: 19/12/2013 6:09 PM (GMT+03:00)
> To: Tom Storey  't...@snnap.net');>>
> Cc: juniper-nsp@puck.nether.net  '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.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  '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]

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

No new purchases.

On 19 December 2013 14:25, Tom Storey  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]

On 19 December 2013 14:39, Phil Mayers  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

[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] 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."  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  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  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 ;  
> 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 
> 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  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  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  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-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  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  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

Re: [j-nsp] monitor start messages

[Tom Storey]

Just a thought, but have you tried doing a "chmod 664 /var/log/messages"?

That should make it world readable, so should not matter what your user
level/permissions are.

I would also compare the user/group ownership against a working box to make
sure its all the same.


On 13 June 2013 16:06, Vincent De Keyzer  wrote:

> Hello,
>
> I hope this is a simple one.
>
> I have trouble with "monitor start messages":
>
> dude@LON2-R96-01-re0> monitor start messages
>
> {master}
> dude@LON2-R96-01-re0>
> *** error - couldn't open 'messages' (Permission denied) - removed ***
>
>
> {master}
> dude@LON2-R96-01-re0>
>
> It is unclear to me whether this is a file permission issue, or a system
> login configuration issue.
>
> These are the rights I have:
>
> dude@LON2-R96-01-re0> show configuration system login class noc-team-user
> permissions
> permissions [ access access-control admin configure firewall flow-tap
> interface-control network routing security snmp-control system
> trace-control view view-configuration ];
>
> {master}
> dude@LON2-R96-01-re0>
>
> Logging on with higher priviledges, I can start a shell and see that:
>
> % ls -al /var/log/messages
> -rw-rw  1 root  wheel  316194 Jun 13 14:57 /var/log/messages
> %
>
> Strangely, a similar configuration works ok on an EX4200 (it is on a MX960
> that it does not work).
>
> Any idea?
>
> Thanks,
>
> Vincent
> ___
> 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] 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  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-nsp<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] SLAX script, redefining variables

[Tom Storey]

I do have a for-each loop with a big block of nested IFs. Was hoping to
minimise the depth and size of that nesting though.

One IF block tests for the interface description on the physical interface,
and if that fails it goes to look on a logical interface.

Then within each of those I need to look for the two variations of the
variable that stores the rx power figure.

In addition to Phils suggestion above, I suppose I could break this up in
to even more functions, one to "getDescription" and one to "getRxPower".

That should just about cover it I think.

Sometimes your mind needs a little jiggling till the ideas fall through the
sieve and on to the plate. :-)

Thanks all. :-)


On 7 June 2013 13:34, Alex Arseniev  wrote:

> The checks can be embedded into "if"/"for-each" constructs, see example
> here
> https://code.google.com/p/**junoscriptorium/source/browse/**
> trunk/library/public/op/**display/op-show-lsp-interface/**
> op-show-lsp-interface.slax<https://code.google.com/p/junoscriptorium/source/browse/trunk/library/public/op/display/op-show-lsp-interface/op-show-lsp-interface.slax>
>
>   if ($ifdescrdb/logical-interface[**name ==
> $if]/description) {
>
>
> The above means that only IFLs whose  XML tag matches a string
> stored in variable $if will be processed.
> HTH
> Thanks
> Alex
>
> - Original Message - From: "Tom Storey" 
> To: 
> Sent: Friday, June 07, 2013 9:54 AM
> Subject: [j-nsp] SLAX script, redefining variables
>
>
>  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<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<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] 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  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  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  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] 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  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] 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  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  wrote:
>
> > On Thu, Jan 31, 2013 at 9:00 PM, Mark Menzies  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] 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  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

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

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

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

[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

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  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  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  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  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"  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  wrote:

> Saku Ytti  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 ".

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  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  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_myblog&show=The-
> OADM-BU.html&Itemid=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  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  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    |
> 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  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.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-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] 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