Re: [j-nsp] Limitations of MPLS support on EX4200

[Gordon Smith]

Label depth - EX4200 only supports a single MPLS label on a packet.

See 
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/mpls-label-operations-ex-series.html




On Thu, 1 May 2014 14:15:36 +0700, Victor Sudakov wrote:

Colleagues,

Is MPLS support on EX4200 not complete? It is not a router after all,
it is an L3 switch, so I expect there to be limitations.
Where can I read more about EX4200 MPLS limitations and supported 
features?


E.g. I cannot find "ldp" under "edit protocols".

I have an Advanced license installed with says:

admin@sw-us-parabel> show system license
License usage:
 Licenses LicensesLicenses
Expiry

  Feature name   usedinstalled  needed
  bgp   01   0
permanent
  isis  01   0
permanent
  mpls  01   0
permanent


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

Re: [j-nsp] MX960 ARP issues

[Gordon Smith]

On Tue, 28 Jan 2014 08:27:13 -0700, John Neiberger wrote:

I'll preface this question by saying that I don't think this is a
problem on the router, but I'm stumped and I'm curious if anyone else
has run into this. We have a Cisco 4948 with two uplinks to different
MX960s we'll call RouterA and Router B. There are a few linux servers
connected to the switch. We have good layer two connectivity between
the routers through this vlan, evidenced by good ARP tables,
responsive pings, and since VRRP is working correctly.

The problem is that the linux servers only respond to ARP requests
from RouterA. When RouterB sends an ARP request, the servers never 
see

it. Packet captures done on the servers don't even show the packets
arriving. I know they are because ARP is working between the routers
and we also have an SVI on the switch in the same VLAN. We have no
problems with ARP and those other devices. It is only these linux
servers that don't see these particular requests.

I've used "monitor traffic" to verify that the ARP requests are
leaving the router. I also tried setting a static ARP for one of the
servers and I was able to ping it, so we know the path is good. I
don't know much about linux system administration, but I did ask them
to check if iptables or arptables were running and they said no.

The reason I'm nearly certain this has to be their problem is this: 
if

they reboot their servers, they will respond to ARP requests for a
short time and then they stop. That tells me that something running 
on

the server must be blocking ARP requests, but why only from one
router? It's very unusual. We've been working on this off and on for 
a

few weeks and haven't been able to nail down the root cause.

Any ideas? Have any of you seen anything like this before?
___



I'd suggest looking at a couple of things...

First, the arp cache cache timers on both the switch & routers.
From memory, Cisco & juniper differed in when the arp cache was 
expired.


On the router side, it'd be worth checking if accept-data is enabled at 
the interface level.

Turning on passive learning may also be worth considering
http://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/arp-learning-aging-options-configuring.html

Cheers,
Gordon

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

Re: [j-nsp] Power issues on 10Gig link

[Gordon Smith]

That's a fault.

Grab an OTDR and test from each end to determine where it is (and test 
the optics, of course)


Could be dirty optics, dirty / damaged connector, damaged fibre



On Fri, 24 Jan 2014 00:14:19 +1100, Ali Sumsam wrote:

Hi All,

I am using a SFP-10GBase-ER for my Cisco3750X for a 10gig link going 
to a

Juniper MX5-T router (10GE XFP)


I am receiving following logs on my Cisco3750X.

 %SFF8472-5-THRESHOLD_VIOLATION: Te1/1/2: Rx power low alarm; 
Operating

value: -21.3 dBm, Threshold value: -20.0 dBm.

No logs on Juniper.

Does this mean I have to increase the power on the interface?
Or is there anything else I need to look at?

Following are the readings from my Juniper router.

 Laser rx power high alarm threshold   :  1.2589 mW / 1.00 dBm
Laser rx power low alarm threshold:  0.0158 mW / -18.01 
dBm

Laser rx power high warning threshold :  1. mW / 0.00 dBm
Laser rx power low warning threshold  :  0.0199 mW / -17.01 
dBm



Regards,

*Ali Sumsam  - *eintellego Networks Pty Ltd
Senior Network Engineer
a...@eintellegonetworks.com ; www.eintellegonetworks.com

Phone: 1300 239 038; Cell +61 (0)450 609 592 ; skype://sumsam.ali80

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


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


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

Re: [j-nsp] BOOTP helper on MX vrf

[Gordon Smith]

It's the same on the MX series

I ended up with an open JTAC case because I'd configured bootp under 
vrf's, but it wasn't working.
It needed to be configured under the base instance, as you've shown 
here.


Perhaps something that Juniper should look at clarifying or expanding 
on in the docs.


Cheers,
Gordon


On Thu, 13 Jun 2013 12:22:17 +0100, Phil Mayers wrote:


It's a J-series, not MX, but should be the same:

forwarding-options {
helpers {
bootp {
interface {
ge-0/0/2.2021 {
server x.x.x.x routing-instance BLAH;

...and


routing-instances {
BLAH {
instance-type vrf;
interface ge-0/0/2.2021;

Basically, you have to put the routing-instance on the server option,
matching the routing instance of the interface.
___
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] SSH - Firewall Filter - MX80

[Gordon Smith]

If you want to only block specific ports, rather than all traffic to 
the RE, something like this may suit you:


term permit-ssh-ssl {
from {
source-address {
0.0.0.0/0;
E.F.G.H/20 except;
}
protocol tcp;
destination-port [ ssh telnet ftp http https ];
}
then {
log;
discard;
}
}
term default_access {
then accept;
}
}


If you don't want to see what you're dropping, omit the log statement


Cheers,
Gordon


On Wed, 5 Jun 2013 09:49:56 +0700, Samol wrote:

Dear All,

We are having problems with filtering ssh access to out MX80 box. 
Many

thanks in advance for your assistance.

The problem is kind of weird. There are a few random IP addresses, 
which
should be blocked by firewall filter, have established ssh 
connections to
our MX80 while most of other IPs (our tested IP) from the Internet 
trying
to ssh are silently dropped (no log) by this firewall filter on 
loopback 0

interface.


show configuration firewall family inet filter limit-mgmt-access
term permit-ssh-ssl {
from {
source-address {
E.F.G.H/20;
}
protocol tcp;
destination-port [ ssh http https telnet ];
}
then accept;
}
term deny-all-other-ssl-ssh {
from {
protocol tcp;
destination-port [ ssh http https telnet ];
}
then {
discard;
}
}
term default {
then accept;
}

---

show configuration interfaces lo0
unit 0 {
family inet {
filter {
input limit-mgmt-access;
}
address W.X.Y.Z/32 {
primary;
preferred;
}
}
}

--

Jun  4 14:48:53 R1 sshd: SSHD_LOGIN_FAILED: Login failed for user 
'nagios'

from host 'A.B.C.D'
Jun  4 14:48:53  R1 sshd[77836]: Failed password for nagios from 
A.B.C.D

port 37231 ssh2
Jun  4 14:48:54  R1 sshd[77837]: Received disconnect from A.B.C.D: 
11: Bye

Bye
Jun  4 14:48:54  R1 inetd[1224]: /usr/sbin/sshd[77836]: exited, 
status 255

Jun  4 14:48:57  R1 sshd: SSHD_LOGIN_FAILED: Login failed for user
'student' from host 'A.B.C.D'
Jun  4 14:49:06  R1 sshd: SSHD_LOGIN_FAILED: Login failed for user 
'tom'

from host 'A.B.C.D'
Jun  4 14:49:06  R1 sshd[77844]: Failed password for tom from A.B.C.D 
port

38247 ssh2
Jun  4 14:49:07  R1 sshd[77845]: Received disconnect from A.B.C.D: 
11: Bye

Bye
Jun  4 14:49:07  R1 inetd[1224]: /usr/sbin/sshd[77844]: exited, 
status 255
Jun  4 14:49:10  R1 sshd: SSHD_LOGIN_FAILED: Login failed for user 
'public'

from host 'A.B.C.D'
Jun  4 14:49:10  R1 sshd[77846]: Failed password for public from 
A.B.C.D

port 38511 ssh2
Jun  4 14:49:10  R1 sshd[77847]: Received disconnect from A.B.C.D: 
11: Bye

Bye
Jun  4 14:49:10  R1 inetd[1224]: /usr/sbin/sshd[77846]: exited, 
status 255


Regards,
Samol
___
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 Remote log denied traffic

[Gordon Smith]

This (remote syslog) works for me on SRX550's running 12.1R1.9
This will apply a default deny & log to the end of your security 
policies, so you don't need to reorder policies after adding a new one.


I have had issues logging locally where the box will stop logging after 
a while. Not a big issue, since it all gets piped off to a syslog 
server, but still annoying.

Syntax for that was:
file traffic-log {
any any;
match RT_FLOW_SESSION;
structured-data;
}



groups {
global-policy {
security {
policies {
from-zone <*> to-zone <*> {
policy default-logdrop {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}
}
system {
syslog {
host x.x.x.x {
any any;
}
}
}
security {
apply-groups global-policy;
}



On Mon, 25 Feb 2013 16:10:49 -0500, Mike Devlin wrote:

nope, that didnt work either :(

meeks@MeeksNet-SRX210# run show log TEST-DENY

[edit]

meeks@MeeksNet-SRX210# show system syslog file TEST-DENY
any any;
match RT_FLOW;

[edit]

On Sat, Feb 23, 2013 at 2:35 AM, Farrukh Haroon
wrote:


Hello Mike

Was wondering if you can get the deny logs  while doing local 
logging?


set system syslog file TEST-DENY any any
set system syslog file TEST-DENY match RT_FLOW

Regards
Farrukh


On Fri, Feb 22, 2013 at 4:39 AM, Mike Devlin  
wrote:



So fingers crossed that this is an easy one for you guys,

Device is an SRX210BE running 11.4R5.5 code.

ive added the syslog host to the config

meeks@MeeksNet-SRX210> show configuration system syslog
archive size 100k files 3;
user * {
any emergency;
}
host 192.168.1.12 {
any any;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file security {
security any;
}
file default-log-messages {
any any;
match "(requested 'commit' operation)|(copying configuration to
juniper.save)|(commit complete)|ifAdminStatus|(FRU power)|(FRU
removal)|(FRU insertion)|(link UP)|(vc add)|(vc


delete)|transitioned|Transferred|transfer-file|QFABRIC_NETWORK_NODE_GROUP|QFABRIC_SERVER_NODE_GROUP|QFABRIC_NODE|(license
add)|(license delete)|(package -X update)|(package -X

delete)|GRES|CFMD_CCM_DEFECT|LFMD_3AH|MEDIA_FLOW_ERROR|RPD_MPLS_PATH_BFD";
structured-data;
}



and implemented the default deny template i found here:


http://kb.juniper.net/InfoCenter/index?page=content&id=KB20778&actp=RSS


meeks@MeeksNet-SRX210> show configuration groups
default-deny-template {
security {
policies {
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}

meeks@MeeksNet-SRX210> show configuration apply-groups
## Last commit: 2013-02-21 16:05:36 EST by meeks
apply-groups default-deny-template;

however, when i log on to the syslog host, and tail the syslog file 
i do

not see denies being logged remotely.

if i apply the session-init and session-close options to permitted
traffic,
it does get logged remotely.

Alternatively,

creating a new policy has the same result, regardless if i use 
reject or

deny

meeks@MeeksNet-SRX210# show security policies from-zone untrust 
to-zone

trust policy deny-all
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}

my google-foo is failing, so i hope you guys can help.

Looking forward to hearing back from you,

Mike
___
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] Framing Errors

[Gordon Smith]

Hi Paul,

First, I'd fix up the MTU on those interfaces.
If the base mtu is 1500, you won't fit a full frame in a dot1q 
interface under it.
To fix it, set the base interface mtu high & specify the mtu you want 
at the subinterface level. e.g.


interfaces {
ge-1/0/0 {
vlan-tagging;
mtu 9192;
unit 507 {
vlan-id 507;
family inet {
mtu 1500;
address x.x.x.x/29;
}
family inet6 {
address ::0:4::2/64;
}
}
}


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

Re: [j-nsp] MX5 with bras?

[Gordon Smith]

I guess it's a feature subset that they've decided to add.
The architecture between the two is very different, so development of 
the features would no doubt take some time.
They could have been waiting for sufficient demand first, since there 
was already a product range that fulfilled the BRAS requirements.
Or maybe they've identified a subset of customers that don't need all 
the features that the E-series provide...


http://www.juniper.net/us/en/products-services/routing/e-series/



On Sat, 8 Dec 2012 20:53:58 +, Gavin Henry wrote:

How come its so new in the mx range?

--
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghe...@suretec.co.uk

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. 
Registered

number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
Inverurie,
Aberdeenshire, AB51 8GL.

Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

Do you know we have our own VoIP provider called SureVoIP? See
http://www.surevoip.co.uk

On 8 Dec 2012, at 13:07, Gordon Smith  wrote:



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

Re: [j-nsp] MX5 with bras?

[Gordon Smith]

> 
> This all doesn't sounds very encouraging to use Juniper for this.
> Others have recommended the Cisco ASR1kx for this instead and keed
> Juniper in the core :-(
> 
> --
> Kind Regards,
> 
> Gavin Henry.
> Managing Director.
> 
> T +44 (0) 1224 279484
> M +44 (0) 7930 323266
> F +44 (0) 1224 824887
> E ghe...@suretec.co.uk
> 
> Open Source. Open Solutions(tm).
> 
> http://www.suretecsystems.com/
> 
> Suretec Systems is a limited company registered in Scotland. Registered
> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
> Inverurie,
> Aberdeenshire, AB51 

Could always use an ERX - they're a good BRAS box, and Juniper have been 
selling them for a long time now. I've used both Cisco & Juniper BRAS's, and I 
do prefer the flexibility of the Junipers... The ERX's do not run junos, which 
some may find a bit confusing at first
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Nextgen Multicast on MX boxes

[Gordon Smith]

Hi all,

I'm after some advice on setting up nextgen multicast on an RSVP based 
MPLS network.


The network is quite simple - MX5's with static lsp's, rsvp signalling 
& fast reroute.


But setting up multicast over this is not something I'm very familiar 
with.
I've looked at the Juniper extranet doc, but it's not exactly clear 
with explanations of why the configs are done that way.
e.g. if I want to pass a stream from one vrf to another vrf on the same 
router, I need to configure a vt- interface. That's fine, but what (if 
any) additional steps

are required to actually establish a stream between the 2 vrf's?

The routers are set up as redundant pairs (vrrp between interfaces) - 
is PIM sparse my best option, or should I be looking to anycast for 
redundancy, or something else?
Can I dictate the group membership at the router, or do the endpoints 
need to be statically configured for the correct group membership?
The docs show both ldp & rsvp configured together - is the mLDP 
functionality a requirement to get mvpn to work correctly?


Sorry for all the questions. Trying to get a better understanding on 
what the best solution is and what the box limitations are



Cheers,
Gordon

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

[j-nsp] DHCP relay between VRF's on an MX5?

[Gordon Smith]

Hi all,

I'm not too sure what I'm doing wrong here

I have several VRF's, and want to pass dhcp requests to another vrf...

VRF config:

instance-type vrf;
interface ge-1/1/0.512;
interface ge-1/1/0.602;
interface ge-1/1/0.2064;
interface ge-1/1/0.2068;
interface ge-1/1/0.2072;
interface ge-1/1/0.2076;
interface ge-1/1/0.2080;
interface vt-1/2/10.1 {
multicast;
}
interface lo0.107;
route-distinguisher 56263:107;
provider-tunnel {
rsvp-te {
label-switched-path-template {
default-template;
}
}
}
vrf-import import-c1-ivpn;
vrf-export export-c1-ivpn;
vrf-target target:56263:107;
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 {
next-hop 10.102.0.14;
no-readvertise;
}
}
multicast {
ssm-groups 239.27.0.0/16;
}
auto-export;
}
forwarding-options {
helpers {
bootp {
relay-agent-option;
server 10.27.1.16 routing-instance corp;
interface {
ge-1/1/0.2072 {
broadcast;
}
}
}
}
}

From what I can tell from the docs, this should be all I need to pass 
the request to the correct vrf.
Or I can use dhcp-relay, and build a firewall filter and rib groups, 
since I believe that dhcp-relay is passed to the RE for processing...


A tcpdump on the interface confirms that the router is receiving 
discover packets, but they aren't reaching their destination.


I'd appreciate any suggestions on this one... router is running 
11.2R7.4



Cheers,
Gordon

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

Re: [j-nsp] encrypted-password /* SECRET-DATA */;

[Gordon Smith]

As Jonathan says, the output you posted appears to come from a config 
collection program like RANCID.


I'd suggest logging on to the M10i directly and grabbing the config 
that way.


By default, when RANCID collects a config, it won't collect passwords 
or SNMP community strings.

To enable these, edit rancid.conf and set the following:

FILTER_PWDS=NO; export FILTER_PWDS
NOCOMMSTR=NO; export NOCOMMSTR

Cheers,
Gordon



On Mon, 6 Aug 2012 03:17:49 +, ibariouen khalid wrote:

Hi  Jonathan

 the hash do not appear on the configuration i have ;

the example bellow
("$1$sbvf432k$qYoeoRs9/t2kywPztwxl01")

is from another router , with an old Junos version.
Regards



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

Re: [j-nsp] Logical Systems Interconnection by Physical Interface

[Gordon Smith]

Pays to set the mtu of the interface as well... e.g.

R1)
fe-0/0/0 {
   vlan-tagging;
   mtu 9192;
   unit 1 {
   vlan-id 111;
   family inet {
  mtu 1500;
  address 10.0.5.1/24;
   }
   }
   }


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Abdul 2012
Sent: Friday, 27 July 2012 11:14 PM
To: Per Westerlund
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Logical Systems Interconnection by Physical Interface

Many thanks to you all, Now is working after adding "VLAN tagging" in main
interface.

Regards,
Abdullah

On Fri, Jul 27, 2012 at 4:07 PM, Per Westerlund  wrote:

> Didn't you just forget to add VLAN tagging to the main interface?
>
> /Per Westerlund
>
> 27 jul 2012 kl. 14:17 skrev Abdul 2012:
>
> > Hello,
> >
> >
> >
> > I have two logical systems configured on m7i router, I want to 
> > connect both LSs through two physical interfaces on the same router 
> > (fe-0/0/0 and fe0/1/0): My configs on both interfaces like:
> >
> >
> >
> > R1)
> >
> >
> >
> > root@JNCIE-SP# run show configuration logical-systems R1 interfaces 
> > {
> >fe-0/0/0 {
> >unit 1 {
> >vlan-id 111;
> >family inet {
> >address 10.0.5.1/24;
> >}
> >}
> >}
> >
> > }
> >
> >
> >
> > P1)
> >
> >
> >
> > root@JNCIE-SP# run show configuration logical-systems P1 interfaces 
> > {
> >fe-0/1/0 {
> >unit 1 {
> >vlan-id 111;
> >family inet {
> >address 10.0.5.254/24;
> >}
> >}
> >}
> >
> > }
> >
> >
> >
> >
> >
> > However, when I ping from R1 to P1 I got the following message "ping:
> > sendto: Can't assign requested address"
> >
> >
> >
> > What's the reason for that?
> > ___
> > 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] Quick Question About HA Setup

[Gordon Smith]

Commit confirmed does not work in 12.1 (SRX550 cluster), and is a known
issue.
Apparently it will be fixed, but no timeframe has been given  :-(

It will accept a commit confirmed, but when you decide to keep the changes
made and do a commit, you'll get a "file not found" error, and the config
will be rolled back regardless.


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clay Haynes
Sent: Tuesday, 17 July 2012 10:08 PM
To: Pavel Lunin
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Quick Question About HA Setup

I believe the command was "configure exclusive" in order to perform a commit
confirmed on a cluster prior to 11.4; however this did have the side effect
of only allowing one user to configure the SRX cluster at a time. Also there
are no guarantees that the rollback would actually work (hence why it was
unsupported).

- Clay






On 7/17/12 6:43 AM, "Pavel Lunin"  wrote:

>
>HmŠ didn't know that, thanks.
>
>And how about to share the unsupported way? (could not realize it 
>myself)
>
>> Commit confirmed came into clusters in 11.4 ...
>>
>> Could always do it is unsupported ways before ... But now you can do 
>> it supported in 11.4rx ...
>>
>
>___
>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] IPv6 static default route in routing instance?

[Gordon Smith]

A downgrade from 11.4R2.14 to 11.2R7.4 fixed the problem.
I now see a v6 default route in the vrf...

G... Thats a pretty big bug to be in the second code revision of 
that train



On Wed, 13 Jun 2012 08:33:26 -0600, Stacy W. Smith wrote:

Please provide the output of

show route table dmz.inet6.0 :a500:0:2::1

Thanks,
--Stacy

On Jun 12, 2012, at 11:48 PM, Gordon Smith wrote:

Hi,

Just wondering if anybody's come across this before - default IPv6 
static not appearing in the routing instance inet6 table...


Instance is a VRF:

instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
   graceful-restart;
   rib dmz.inet6.0 {
   static {
   route ::/0 next-hop :a500:0:2::1;
   }
   }
   static {
   route 0.0.0.0/0 {
   next-hop xxx.x.216.54;
   no-readvertise;
   }
   }
}


Looking at the dmz.inet6.0 table shows directly connected routes, 
but not the default.

In contrast, dmz.inet.0 has a v4 default as expected.

I must be doing something wrong here

___
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] IPv6 static default route in routing instance?

[Gordon Smith]

Hi,

Just wondering if anybody's come across this before - default IPv6 
static not appearing in the routing instance inet6 table...


Instance is a VRF:

instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
}


Looking at the dmz.inet6.0 table shows directly connected routes, but 
not the default.

In contrast, dmz.inet.0 has a v4 default as expected.

I must be doing something wrong here

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

Re: [j-nsp] Regular maintenance advice

[Gordon Smith]

Most of this you can automate on your monitoring boxes.
e.g. use rancid to generate an email on config changes, interfaces 
flapping & chassis alarms will generate SNMP alerts.


You only need to snapshot when upgrading code. Definitely make that 
part of the upgrade procedure, and let rancid keep track of the config.


Another thing to look at would be BGP peers - number of routes, 
uptimes, etc. Low uptimes on a peer can indicate a problem at the far 
end that the cust isn't aware of.


Cheers,
Gordon


On Wed, 4 Apr 2012 00:28:09 +1000, Skeeve Stevens wrote:

Hey all,

I am designing a document for low level technicians to regularly
(depending on sensitivity of the device) login to the Juniper
router/or switch to look around and make sure that things are 'ok'.

I am seeking comments of anything else that would be useful for an
technician to look at that would catch their eye that something is
potentially wrong.

So far I have:

---

RJ01 – Router

Description: Standard Juniper Router or Switch

1. Show log messages

 a. Look at last few days for anything suspicious

  i. Interfaces flapping

2. Show interfaces terse

 a. Anything down that shouldn’t be?


3. Show chassis alarm

 a. Look for any alarm information

4. Show system snapshot

 a. If older than 1 week then – ‘Request system snapshot’

5. Show system uptime

 a. As expected?

6. Show system storage

 a. Confirm / (root) disk space is not getting full.





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

Re: [j-nsp] proxy arp C vs J

[Gordon Smith]

Proxy ARP can be useful while sorting out a broken (misconfigured) network,
but can also cause you a lot of grief.
If the network is configured correctly, it's just a hindrance. Most
definitely turn it off, then fix any routing issues it was masking.

I see someone mentioned turning off gratuitous arps, but I'd only do that if
really necessary, as its very useful for forcing a refresh of an entry e.g.
E-Series cable customers


Cheers,
Gordon


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of biwa net
Sent: Tuesday, 7 February 2012 5:57 a.m.
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] proxy arp C vs J

Hi Guys
We are experiencing some issues in one of our client sites,

Basically we migrate from a Cisco to a Juniper MX80, and since there has
been some issues,  mainly we are seeing IP addresses being shared by 2-3 mac
address, to be precise , mac address being rewritten , ie: one IP is being
seen on the Juniper owned by 3 different mac address within one hour (  the
1st mac address is being re-writen by the 2nd one and then 2nd by the 3rd
mac).

This is causing a lot of users not having any kind of internet
connectivity.When we rollback to the Cisco device , this issue does not
occur.

After investigation we can safely eliminates the DHCP server being the cause
of issue (, also proved when Cisco is roll back in the topology),

The config of the Cisco is fairly simple and is almost 99.99% than the one
being copied over to the Juniper.

One thing we notice is that both Cisco and Juniper has proxy-arp configured
on some of the interface, and we are planning in our next maintenance to
disable it.

my question is: is the proxy-arp behavior in Juniper slightly different than
the Cisco ?

thanks for your inputs
___
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] Rate limiting v4 and v6 together

[Gordon Smith]

Under your interface, apply a policer:

interfaces {
fe-1/0/1 {
unit 148 {
description "Some Customer";
bandwidth 10m;
vlan-id 148;
family inet {
policer {
input 10meg;
output 10meg;
}
address x.x.x.x/x;
}
}
}
}


and for the policer:

firewall {
policer 10meg {
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 125;
}
then discard;
}



to police total bandwidth per interface




On Wed, 1 Jun 2011 20:07:48 -0500, Chris Adams wrote:
I'm currently using interface, policer, and filter config like this 
to

rate-limit ethernet interfaces to paid bandwidth on an M10i:

interfaces {
fe-1/0/1 {
unit 148 {
description "Some Customer";
bandwidth 10m;
vlan-id 148;
family inet {
filter {
input 10meg;
output 10meg;
}
address x.x.x.x/x;
}
}
}
}
firewall {
policer 10meg {
filter-specific;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 125;
}
then discard;
}
filter 10meg {
interface-specific;
term other {
then {
policer 10meg;
count rate;
accept;
}
}
}
}

This gives me SNMP-graphable in/out counters for each interface that
show after-rate-limiting bits.

Now, I want to add IPv6, but I want to limit (and hopefully graph) 
the

total bandwidth, not the bandwidth per address family.  If I create a
"10megv6" filter under firewall family inet6, the policer is filter
specific, so I would expect the interface to allow 10meg of IPv4 plus
10meg of IPv6.

I used to put a policer directly on the unit under "family inet" (no
counters for SNMP though), but I would also assume doing that under
"family inet" and "family inet6" would also result in separate 
bandwidth

for IPv4 and IPv6, not shared.

I looked at "family any" filters, but they don't have the same 
options

(no "interface-specific").

Any suggestions?


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

Re: [j-nsp] Odd issue with ARP in different subnet

[Gordon Smith]

Put the /32 on a loopback instead of a secondary address.

See 
http://www.netlinxinc.com/netlinx-blog/45-dns/119-anycast-dns-part-2-using-static-routes-.html


You could always fire up WireShark and watch exactly what's going on on 
the wire




On Wed, 9 Mar 2011 18:56:44 -0600, Chris Adams wrote:

Once upon a time, Gordon Smith  said:

Check the default router config.

When the server sends the arp request, the router should reply with
it's own MAC address
Does it not have a route back to the switch?


No, the router isn't proxy ARPing.  Let me put some IPs to the 
problem:


EX switch: 10.1.1.5/27
Linux server eth0: 10.1.1.10/27
router (M10i): 10.1.1.30/27
DNS IP: 10.2.2.2/32 (secondary IP on Linux server eth0)

EX wants to reach 10.2.2.2, so it sends the packet to the M10i at
10.1.1.30.  Router has route for 10.2.2.2/32 pointing to 10.1.1.10, 
so

it sends the packet to the Linux server.  Linux server realizes it
doesn't need to route back to EX in the same subnet and is going to 
send
a packet directly from 10.2.2.2 to 10.1.1.5.  Linux server doesn't 
have
an ARP entry for 10.1.1.5, so it sends an ARP request, using a source 
IP

of 10.2.2.2 (since that's the source of the desired packet).

At this point the EX sees the ARP request for its IP, but doesn't
respond to it.  I'm guessing it is ignoring the ARP request because 
the

source IP is in a different subnet (but that's just a guess).

There's also an old Cisco switch on the same segment, and it replies 
to
out-of-subnet ARP requests just fine.  I also tried a FreeBSD host in 
a
similar setup with a different Linux server, and it also works okay.  
I

don't have any other OSes handy to try.

Per another email, I tried setting the Linux server to put the DNS IP 
on
a loopback interface instead of the ethernet, but it still sent the 
ARP

request with the DNS IP as the source.


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

Re: [j-nsp] Odd issue with ARP in different subnet

[Gordon Smith]

Check the default router config.

When the server sends the arp request, the router should reply with 
it's own MAC address

Does it not have a route back to the switch?


On Wed, 9 Mar 2011 09:43:43 -0600, Chris Adams wrote:
I have run into an odd issue with ARP on an EX switch that I think is 
a

bug in JUNOS, but I wanted to see what others thought before I tried
JTAC (maybe I'm missing something).

I have an EX2200 switch that cannot talk to one of my recursive DNS
servers.  The switch is in subnet a.b.c.0/27, while the DNS IP is in
x.y.z.0/29.  The DNS IP is anycasted, and the primary server serving 
it

is in the same a.c.b.0/27 subnet as the switch (the DNS IP is a
secondary IP on the same interface).

When the switch tries to reach the DNS IP, it sends the packet to the
default router.  The router sends it to the server, and the server 
sends
an ARP request for the switch's IP.  The sending IP address in the 
ARP

request is the DNS IP.  As far as I can tell, JUNOS doesn't send a
response to the ARP request.

I'm guessing that it isn't sending a response because the sending IP 
is
in a different subnet, but as far as I can tell from reading the ARP 
RFC

(826), that is not supposed to figure into an ARP response.

The DNS server is Linux, and I can see Linux will respond to
out-of-subnet ARP requests.  I also have an old Cisco switch in the 
same

subnet, and it also responds to out-of-subnet ARP requests.

If I ping the switch from the Linux server, the ARP request goes out
with the IP in the same subnet, the switch responds, the Linux server
gets an ARP cache entry, and communication works both ways for all 
IPs

until the ARP cache entry expires on the Linux side.


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

Re: [j-nsp] JUNOS POLICER

[Gordon Smith]

The "accept" is what is allowing full bandwidth - you never hit the
policer.


firewall {
   family inet {
 filter policer {
 term 10 {
 from {
 source-address {
 192.168.10.35/32;
 }
 then {
policer teste;
 }
  }
   }
 }
}

 

On Thu, 02 Sep 2010 13:07:08 -0300, Giuliano Cardozo Medalha
 wrote:
> People,
> 
> We are trying to configure policers to logical interfaces created
> under IQ2E PIC.
> 
> All policers are using firewall filters.
> 
> One of them is a different situation ... we cannot rate all interface
> but only 3 IPs that pass thought the interface.
> 
> But the policer is not worlink correctly:
> 
> 
> set firewall policer teste if-exceeding bandwidth limit 10m burst size 1000
> set firewall policer teste then discar
> 
> set firewall family inet filter policer term 10 from source-address
> 192.168.10.35/32
> set firewall family inet filter policer term 10 then accept
> set firewall family inet filter policer term 10 then policer teste
> set firewall family inet filter policer term 20 from source-address
> 192.168.10.36/32
> set firewall family inet filter policer term 20 then accept
> set firewall family inet filter policer term 20 then policer teste
> set firewall family inet filter policer term 30 from source-address
> 192.168.10.37/32
> set firewall family inet filter policer term 30 then accept
> set firewall family inet filter policer term 30 then policer teste
> set firewall family inet filter policer term 40 then accept
> 
> set interface ge-0/0/0 unit 100 vlan-id 100 family inet filter input policer
> 
> 
> The problem is ... the 3 chosen IPs are exceeding 10m.  Sometimes 12,
> sometimes 18 Mbps.
> 
> We need to use some special command for it ?  Like - logical
> interface under policer ?
> 
> What is the correct manner to use it ?
> 
> Or we need to put it all in the same term ?
> 
> Thanks a lot,
> 
> Giuliano
> ___
> 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