Re: [j-nsp] EX4550 and MX104

[Jimmy]

We encountered this on T1600 chassis.
After months troubleshooting, i discovered myself it is due to some
monitoring system were still polling using snmp v1. After all changed to
v2c. Problem resolved.
As usual JTAC would suspect here and there, and luckyly i have another
chassis with identical software / config but not affected as comparison.

On Wed, 18 Jul 2018 at 14:37, Gert Doering  wrote:

> Hi,
>
> On Wed, Jul 18, 2018 at 02:50:13AM +, Richard McGovern wrote:
> > As well the really important stuff comes after the sale, not before.
>
> Yeah.  JTAC really excels on this.
>
> (We have an open case where SNMP on *some* EX4600 is abysmally slow while
> the same queries on other EX4600 with the same software / SNMP config
> behave quite normally.  Not proceeding in meaningful ways since half
> a year...)
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never
> doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> ___
> 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 about T640

[Jimmy]

resend

I'm sorry,
For T640, How about this announcement ?
https://gallery.mailchimp.com/1466897c24c515e6739f14c9e/files/TSB16819.pdf

On Mon, Apr 11, 2016 at 2:55 PM, Alireza Soltanian 
wrote:

> No T640 and T4000 are still manufactured. Anyway is there anybody who can
> provide answer?
> On Apr 11, 2016 11:24 AM, "Fredrik Korsbäck"  wrote:
>
> > You do realize that most of T-series is EOL?
> >
> > Hugge@ as2603
> >
> > > 11 Apr 2016 kl. 07:02 skrev Alireza Soltanian :
> > >
> > > Hi
> > >
> > > Yes the price of MX Series is much higher.
> > >
> > >
> > >
> > > From: Josh Reynolds [mailto:j...@kyneticwifi.com]
> > > Sent: Monday, April 11, 2016 9:27 AM
> > > To: Alireza Soltanian 
> > > Cc: Juniper List 
> > > Subject: Re: [j-nsp] Questions about T640
> > >
> > >
> > >
> > > Any reason to not go with the MX line here?
> > >
> > > On Apr 10, 2016 11:55 PM, "Alireza Soltanian"  >  > wrote:
> > >
> > > Hi everybody
> > >
> > > We are going to change our M320 router with T640. There are some
> concerns
> > > about supported features on T640. We need to have following features on
> > this
> > > router:
> > >
> > >
> > >
> > > 1-  GRE Tunnels
> > >
> > > 2-  GRE Keepalive (OAM)
> > >
> > > 3-  802.1q over 802.1ad
> > >
> > > 4-  MPLS TE
> > >
> > > 5-  ATOM VLAN re-write
> > >
> > >
> > >
> > > We need to handle up to 80Gbps of traffic. Here is the setup:
> > >
> > > For Module setup we are going to use following FPC:
> > >
> > > -  T640-FPC3-ES
> > >
> > > For Physical connections we are going to use following PICs:
> > >
> > > 1-  PC-1XGE-TYPE3-XFP-IQ2
> > >
> > > 2-  PC-1XGE-XENPAK
> > >
> > > For GRE tunnels we are going to use following PICs:
> > >
> > > PC-Tunnel
> > >
> > > For Routing Engine following item is considered:
> > >
> > > -  RE- A-2000-4096-BB
> > >
> > > For SIB:
> > >
> > > -  SIB-I-T640-B
> > >
> > > For Control Board:
> > >
> > > -  CB-L-T
> > >
> > > And for Connector interface panel:
> > >
> > > -  CIP-L-T640-S
> > >
> > > Is there anybody here who can guide me is this setup good or not and
> can
> > I
> > > have the mentioned feature with T640? Also is there any note about
> > required
> > > JunOS version of this setup?
> > >
> > >
> > >
> > > Thank you
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > juniper-nsp mailing list 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
> > > 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] SSG Dialup VPN stability problems

[Jimmy Stewpot]

Hello,

I am currently investigating some on-going stability problems with 
client-to-site vpn connections on a SSG140. Unfortunately I've been unable to 
find any detailed diagnostics steps to take when troubleshooting this type of 
issue. The site previously used a Cisco ASA and have since moved to Juniper's 
we are running 6.2.0r2 as the software version with client to site using a 
tunnel interface. 

The config as stated :
===SNIP===
set ike gateway Remote_Dialup_VPN dialup Dialup_VPN_Group Aggr 
outgoing-interface ethernet0/3 preshare KEY HERE proposal 
pre-g2-3des-md5 pre-g2-3des-sha pre-g2-aes128-md5 pre-g2-aes128-sha
set ike gateway Remote_Dialup_VPN dpd-liveness interval 20
set ike gateway Remote_Dialup_VPN dpd-liveness always-send
unset ike gateway Remote_Dialup_VPN nat-traversal udp-checksum
set ike gateway Remote_Dialup_VPN nat-traversal keepalive-frequency 20
set ike gateway Remote_Dialup_VPN xauth server AD_Radius user-group 
VPN.Users
unset ike gateway Remote_Dialup_VPN xauth do-edipi-auth
set vpn Remote_Dialup_VPN gateway Remote_Dialup_VPN replay tunnel idletime 
0 proposal nopfs-esp-3des-sha  nopfs-esp-3des-md5  nopfs-esp-des-sha  
nopfs-esp-des-md5 
set vpn Remote_Dialup_VPN id 0x6 bind interface tunnel.3
set vpn Remote_Dialup_VPN dscp-mark 0
set vpn Remote_Dialup_VPN proxy-id local-ip 192.168.0.0/16 remote-ip 
255.255.255.255/32 ANY 
set address VPN Dialup_IPPool 10.10.40.0 255.255.255.0
set ippool IPPool 10.10.40.2 10.10.40.254




set interface tunnel.3 zone VPN
set interface tunnel.3 ip unnumbered interface ethernet0/3
set vpn Remote_Dialup_VPN id 0x6 bind interface tunnel.3
set vpn Remote_VPN_to_DMZ id 0x9 bind interface tunnel.3
set route 10.10.40.0/24 interface tunnel.3 permanent




set auth-server AD_Radius account-type l2tp xauth 
set user-group VPN.Users type l2tp xauth 
set ike gateway Remote_Dialup_VPN xauth server AD_Radius user-group 
VPN.Users
unset ike gateway Remote_Dialup_VPN xauth do-edipi-auth
set xauth lifetime 30
set xauth default ippool IPPool
set xauth default dns1 192.168.10.1
set xauth default dns2 192.168.10.2
set xauth default wins1 192.168.10.1
set xauth default wins2 192.168.10.2
set xauth default auth server AD_Radius
set xauth default accounting server AD_Radius

===SNIP===

Now the problem we have is that very often systems can't remain connected for 
more than a few seconds while other users can be stable as a rock. This is 
despite both systems having identical configurations with either the Shrew 
client or the Juniper VPN client. One thing that I do see is a huge number of 
replay packets detected in the error logs, Does that have something to do with 
it? Moving forward has anyone experienced similar problems in the past and what 
did they do to resolve them? I have been unable to identify any single problem 
as every time I connect I am able to stay online for days without being 
disconnected?.

Any feedback would be really appreciated.

Regards,

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

[j-nsp] SSG 140 WebVPN

[Jimmy Stewpot]

Hello,

I have attempted to setup a WebVPN (SSL VPN) on the SSG that we have. 
Unfortunately it appears as though we can only set it up on an external VIP? Is 
that correct?

We only get assigned a single external address so we can't use a different IP. 
Is there a way to allow us to have WebVPN on the standard external Public IP?

Regards,

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

[j-nsp] Windows XP L2TP/IPSEC vpn without certificates

[Jimmy Stewpot]

Hello,

I am looking around at getting the native client within XP, Vista and Windows 7 
to work when connecting to a Juniper SSG 140. Currently all the documentation 
and examples that I have found on the Internet seem to suggest that it only 
works with certificates. Is there a good how to guide which tells me how to 
configure L2TP without certificates specifically I would love to be able to use 
Radius/user password authentication for the vpn.

Regards,

Jimmy Stewpot.

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

[j-nsp] SSG 140 Software

[Jimmy Stewpot]

Hi All,

I am interested to know if anyone can provide me with what the latest version 
of software is for the SSG140?

Regards,

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

[j-nsp] Diagnosing Policy Discards

[Jimmy Stewpot]

Hello,

I am working on an issue where we have some Policy Discards on an interface. I 
understand that Policy Discards are essentially anything that the Juniper does 
not understand. I guess this means things like HSRP etc. What I am interested 
to know is there a method to break down what those policy discards are? For 
example see a log of the packet type/protocol type etc?

Here is the output of the JunOS commands with a 1 second interval


show interfaces ge-3/3/0 extensive | match Policed
Errors: 21, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 
73485969, L3 incompletes: 21, L2 channel errors: 0,

show interfaces ge-3/3/0 extensive | match Policed
Errors: 21, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 
73485982, L3 incompletes: 21, L2 channel errors: 0,

show interfaces ge-3/3/0 extensive | match Policed
Errors: 21, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 
73485998, L3 incompletes: 21, L2 channel errors: 0,

I understand that its not fatal however its causing some monitoring 
abnormalities which we would like to get to the bottom of to clarify that there 
is nothing misconfigured etc on the network.

Any additional feedback would be much appreciated.

Regards,

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

[j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

[Jimmy Halim]

Hi guys,
 
I have a situation where the PE (router A) is not advertising the routes
that they got from direct peering (for example under CT vrf) to other PE
(router B) under different vrf (for example premium vrf).
 
I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table.
It means the import policy is working.
 
The strange thing, thouse routes are not being advertised to premium vrf in
router B. I have confirmed there is no problem with export policy in router
A and import policy in router B.
 
In router A, under route table bgp.l3vpn.0, I am seeing the route that is
learned via direct peering interface. This shouldn't be the case right?
 
==
route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250, from
122.5.5.1
  AS path: 1334 I
  to 122.5.5.2 via so-1/2/0.0 - Direct peering
interface
 to 122.5.5.3 via so-1/3/0.0 - Direct peering
interface
==
 
I can confirm that direct connected, static, and customer's BGP routes that
are provisioned in router A under premium vrf are being seen under router B
under premium vrf. So the issue is only on those routes that are learned via
direct peering under CT vrf. Those routes are not advertised to router B
premium vrf.
 
Any clue?
 
Cheers,
Jimmy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

[Jimmy Halim]

Hi Tarique,

Yes, I am leaking CT crf routes into premium vrf on router A using the
community.

policy-options policy-statement csr-rib-policy-from-CT-vrf-peer
term aloha {
from {
community csr-CT-vrf;
}
to rib vrf_premium.inet.0;
then {
accept;
}
}

==
Export policy on router A:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 1.1.1.1:9005;
vrf-export premium-export;
vrf-table-label;


policy-options policy-statement premium-export:
term add-premium {
from protocol [ direct static bgp ];
then {
community add rt-premium;
accept;
}
}
then reject;


community rt-premium:
members target:10026:9005;

===
Import policy on router B:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 2:2:2:2:9005;
vrf-import premium-import;
vrf-table-label;


policy-options policy-statement premium-import
term add-premium {
from community rt-premium;
then accept;
}
then reject;


community rt-premium:
members target:10026:9005


By the way, what do you think of the route table bgp.l3vpn.0?
Is it correct to say that it shouldn't show the direct peering routes that
is provisioned on the same PE?

route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250, from
122.5.5.1
  AS path: 1334 I
  to 122.5.5.2 via so-1/2/0.0 - Direct peering
interface
 to 122.5.5.3 via so-1/3/0.0 - Direct peering
interface
==

Cheers,
Jimmy


-Original Message-
From: Nalkhande Tarique Abbas [mailto:ntari...@juniper.net] 
Sent: Monday, October 05, 2009 4:55 PM
To: Jimmy Halim; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue


You said

--I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table. 

--I can confirm that direct connected, static, and customer's BGP routes
that are provisioned in router A under premium vrf are being seen under
router B under premium vrf. So the issue is only on those routes that are
learned via direct peering under CT vrf. Those routes are not advertised to
router B premium vrf. Any clue?



Tarique
So how do you leak CT vrf routes into premium vrf on router A, by means of
community? These routes certainly won't fall under static, direct or
customers bgp (of premium).

With the available information, I would still doubt the export policy on
router A  import on router B of premium vrf. Though having a look at
outputs/config on both sides would help.


 
Thanks  Regards,
Tarique A. Nalkhande


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jimmy Halim
Sent: Monday, October 05, 2009 2:03 PM
To: juniper-nsp@puck.nether.net
Cc: ji...@pacnet.net
Subject: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

Hi guys,
 
I have a situation where the PE (router A) is not advertising the routes
that they got from direct peering (for example under CT vrf) to other PE
(router B) under different vrf (for example premium vrf).
 
I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table.
It means the import policy is working.
 
The strange thing, thouse routes are not being advertised to premium vrf in
router B. I have confirmed there is no problem with export policy in router
A and import policy in router B.
 
In router A, under route table bgp.l3vpn.0, I am seeing the route that is
learned via direct peering interface. This shouldn't be the case right?
 
==
route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250, from
122.5.5.1
  AS path: 1334 I
  to 122.5.5.2 via so-1/2/0.0 - Direct peering
interface
 to 122.5.5.3 via so-1/3/0.0 - Direct peering
interface ==
 
I can confirm that direct connected, static, and customer's BGP routes that
are provisioned in router A under premium vrf are being seen under router B
under premium vrf. So the issue is only on those routes that are learned via
direct peering under CT vrf. Those routes are not advertised to router B
premium vrf.
 
Any clue?
 
Cheers,
Jimmy
___
juniper-nsp mailing list juniper-nsp

Re: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

[Jimmy Halim]

Hi Tarique,

I have tried it. But it is still not being advertised :(

Regarding my query, for strange reason bgp.l3vpn table in router A is
storing the routes that learned via direct BGP peering that being
provisioned in router A. I believe this shouldn't be the case. bgp.l3vpn
table only should store routes that are learned via other PEs.


show route table bgp.l3vpn.0 20.139.160.0/20

bgp.l3vpn.0: 316660 destinations, 316660 routes (316660 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1:9001:20.20.0.0/16 - 1.1.1.1:9001 is RT of CT vrf
   *[BGP/170] 5d 23:44:00, MED 100, localpref 250
  AS path: 123 321 I
 to 20.20.20.1 via ge-0/2/0.0


So, router A is advertising those routes learned via direct BGP peering
under bgp.l3vpn table. There are no routes being advertised out to other PEs
under CT vrf table or premium vrf table.

Thanks  Regards,
Jimmy

-Original Message-
From: Nalkhande Tarique Abbas [mailto:ntari...@juniper.net] 
Sent: Monday, October 05, 2009 6:11 PM
To: Jimmy Halim; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue


Hi Jimmy,

How about adding another term in your premium-export policy ..

term export-CT {
from community csr-CT-vrf;
then accept;
}

... before reject on both the sides. 


Coming to your query on direct route in bgp.l3vpn table, do you mean this is
a direct route from inet.0? Is this BGP peer not under any VRF  at a global
level?

 

Thanks  Regards,
Tarique A. Nalkhande

-Original Message-
From: Jimmy Halim [mailto:ji...@pacnet.net]
Sent: Monday, October 05, 2009 2:52 PM
To: Nalkhande Tarique Abbas; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

Hi Tarique,

Yes, I am leaking CT crf routes into premium vrf on router A using the
community.

policy-options policy-statement csr-rib-policy-from-CT-vrf-peer term aloha {
from {
community csr-CT-vrf;
}
to rib vrf_premium.inet.0;
then {
accept;
}
}

==
Export policy on router A:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 1.1.1.1:9005;
vrf-export premium-export;
vrf-table-label;


policy-options policy-statement premium-export:
term add-premium {
from protocol [ direct static bgp ];
then {
community add rt-premium;
accept;
}
}
then reject;


community rt-premium:
members target:10026:9005;

===
Import policy on router B:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 2:2:2:2:9005;
vrf-import premium-import;
vrf-table-label;


policy-options policy-statement premium-import term add-premium {
from community rt-premium;
then accept;
}
then reject;


community rt-premium:
members target:10026:9005


By the way, what do you think of the route table bgp.l3vpn.0?
Is it correct to say that it shouldn't show the direct peering routes that
is provisioned on the same PE?

route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250, from
122.5.5.1
  AS path: 1334 I
  to 122.5.5.2 via so-1/2/0.0 - Direct peering
interface
 to 122.5.5.3 via so-1/3/0.0 - Direct peering
interface ==

Cheers,
Jimmy


-Original Message-
From: Nalkhande Tarique Abbas [mailto:ntari...@juniper.net]
Sent: Monday, October 05, 2009 4:55 PM
To: Jimmy Halim; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue


You said

--I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table. 

--I can confirm that direct connected, static, and customer's BGP routes
that are provisioned in router A under premium vrf are being seen under
router B under premium vrf. So the issue is only on those routes that
are
learned via direct peering under CT vrf. Those routes are not advertised
to
router B premium vrf. Any clue?



Tarique
So how do you leak CT vrf routes into premium vrf on router A, by means
of
community? These routes certainly won't fall under static, direct or
customers bgp (of premium).

With the available information, I would still doubt the export policy on
router A  import on router B of premium vrf. Though having a look at
outputs/config on both sides would help.


 
Thanks  Regards,
Tarique A. Nalkhande


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jimmy Halim
Sent: Monday, October

[j-nsp] CoS clarification on MPLS interface

[Andrew Jimmy]

Which policy will took place, if you apply a CoS DSCP/EXP classification and
DSCP/EXP rewrite policy on an MPLS switching interface (keeping in mind
packet is being switched using MPLS shim header), I know MPLS EXP
classification and rewriting will defiantly be used but what about DSCP
classification and rewriting. The confusing is packet is being switched on
MPLS header without touching regular IP header while DSCP value set in IP
header. I just wana know how Juniper router (J Series and M Series) treats a
packet in MPLS core facing interface while both DCSP/MPLS EXP classifier and
rewriting are configured.

 

OR in simple words . Is it possible to use DSCP classification/rewriting on
MPLS core interface (while packet is being switched using MPLS shim header).

 

Regards,

Andrew 

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

Re: [j-nsp] CoS clarification on MPLS interface

[Andrew Jimmy]

The question is not what to use (I do know we use EXP because packet is not
being processed on IP layer). The question was, what if you have configured
both DSCP/EXP classifier and rewriting rules on an MPLS switching interface
for the MPLS switching traffic (not regular IP traffic), what behavior would
you expect  from a Juniper J-Series or M-Series router. Will it use DSCP
classification or not? Will it rewrite DSCP value or not?

Regards,
Andrew

-Original Message-
From: Fahad Ali Khan [mailto:faha...@cyber.net.pk] 
Sent: Sunday, May 24, 2009 9:03 PM
To: Andrew Jimmy
Subject: Re: [j-nsp] CoS clarification on MPLS interface

In my opinion n experience, on mpls core interface only EXP bits r used 4
classification n rewriting. DSCP based classification n rewriting b used
only when IP traffic (non switched) passed the interface.

Now ur question may b that in what scenario mpls interface b used 4 both
routing n mpls swutching. Consider if my policy is to carry only VPN traffic
over mpls lsp n won't used IGP forwarding to use LSP. In normal
circumstances only Mpls vpn (whose next-hop) is available via BGP in Inet3
table will use lsp...all other will follow IGP forwarding rules. Where this
behaviour can b changed.

Regards

Fahad
--Original Message--
From: Andrew Jimmy
Sender: juniper-nsp-boun...@puck.nether.net
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] CoS clarification on MPLS interface
Sent: May 25, 2009 1:51 AM

Which policy will took place, if you apply a CoS DSCP/EXP classification and
DSCP/EXP rewrite policy on an MPLS switching interface (keeping in mind
packet is being switched using MPLS shim header), I know MPLS EXP
classification and rewriting will defiantly be used but what about DSCP
classification and rewriting. The confusing is packet is being switched on
MPLS header without touching regular IP header while DSCP value set in IP
header. I just wana know how Juniper router (J Series and M Series) treats a
packet in MPLS core facing interface while both DCSP/MPLS EXP classifier and
rewriting are configured.

 

OR in simple words . Is it possible to use DSCP classification/rewriting on
MPLS core interface (while packet is being switched using MPLS shim header).

 

Regards,

Andrew 

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


*** This Message Has Been Sent Using BlackBerry Internet Service ***

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

Re: [j-nsp] Rate limit ARP per interface (or JUNOS bug)?

[Andrew Jimmy]

This policer thing seems fine. Can you please write what to police under arp
FOO firewall. It would be great if you can write the complete firewall.

Regards,
AW

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Pekka Savola
Sent: Friday, May 15, 2009 7:36 AM
To: Chris Adams
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Rate limit ARP per interface (or JUNOS bug)?

On Thu, 14 May 2009, Chris Adams wrote:
 Is this behavior a JUNOS bug or am I supposed to be rate-limiting ARP
 requests (on a per-VLAN basis) somehow?

I've seen LAN loops etc cause junos problems.  That's why you need to 
add 'policer arp FOO' under interfaces,unit,family inet.  I'd have 
hoped Juniper would have sane defaults but 

-- 
Pekka Savola You each name yourselves king, yet the
Netcore Oykingdom bleeds.
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
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] bursit size for OC-192

[Andrew Jimmy]

Calculating burst size for low interfaces is very simple which is ten times
the interface's MTU. For a high-speed interface, such as an OC-192, the
recommended burst size is the transmit rate of the interface times 3-5
milliseconds (AS per JNCIE book). Can someone write a real-time and
practical example that how you calculate this 3-5 milliseconds thing
exactly!

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

Re: [j-nsp] forwarding class nd loss priority

[Andrew Jimmy]

Hi Patrik,
Many thanks for the reply. It really helps a lot. Can you please put some
comments on the following configuration. Just to avoid jitter, I'm keeping
the voice queue small.
 voice-profile
 fill-level 0 drop-probability 0;
 fill-level 25 drop-probability 100;

transmit-rate percent 20 exact;
buffer-size percent 20;
priority high;
drop-profile-map loss-priority any protocol any drop-profile voice-profile;

Is this good on Gig interface for Voice. What is exactly this file-level
with drop-probability.

-Original Message-
From: Patrik Olsson [mailto:d...@webkom.se] 
Sent: Friday, May 01, 2009 10:26 AM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] forwarding class nd loss priority

Hello,


schedulers and schedulers-map is to schdule traffic egress.
The scheduler decides how much bandwidth a forwarding class gets.

Ingress forwarding class is decided and also a drop priority ion case
the traffic needs to be dropped.

In the scheduler within a forwarding class different drop-priorities can
be treated different through applying different drop profiles.

When it comes to voice, it should have it's own forwarding class of a
high priority. It should not be using different drop priorities and
different drop profiles. It should have one that says: drop everything
if you need to queue. Because voice traffic dont like to be queued and
sent later. It will mess the sound up. In return voice traffic should
have the highest priority and whatever bandwidth it need to push any
other traffic away.


Cheers
Patrik

 Forwarding class and loss priority is some of the confusing stuff in JUNOS
 world. Can someone write about loss priority/scheduler maps in detail
along
 with a example. Like what if you are running MPLS VPN and you want to keep
 priorities voice traffic (if you want to avoid jitter for the sip call)
 weather the congestion is happening or not. How do you do it practically.
 
  
 
 voice-profile 
 
 fill-level 0 drop-probability 0;
 
 fill-level 25 drop-probability 100;
 
  
 
 Is this good to have on Gig interface for Voice traffic.
 
  
 
 transmit-rate percent 20 exact;
 
 buffer-size percent 20;
 
 priority high;
 
 drop-profile-map loss-priority any protocol any drop-profile
voice-profile;
 
  
 
 I will highly appreciate if someone can dig into this along with
 configuration/comments.
 
  
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


-- 

//Patrik

Webkom
http://www.webkom.se

+46 (0)709 35 22 99
+46 (0)8 559 26 488



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

[j-nsp] snmp-trap community

[Andrew Jimmy]

You can set the snmp community in JUNOS using.. 'set snmp community public
authorization read-only'.. But it's for pooling OK

You know when you configure snmp traps you define a community for trap
manager..I have configure my trap settings like show be

low.

Set trap-group auth-traps targets 5.6.7.8

Set trap-group auth-traps categories authentication 

 

Now where do you define community for trap manager so that you can get
authenticated when you send traps to trap manager from router.

 

 

 

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

Re: [j-nsp] snmp-trap community

[Andrew Jimmy]

Thanks for the reply. So WEBKOM is community the one you send along with
traps to snmp manager for authentication. Correct!

-Original Message-
From: Patrik Olsson [mailto:d...@webkom.se] 
Sent: Thursday, April 30, 2009 11:45 AM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] snmp-trap community

The definition of the traps community is the name of the trap-group you
are configuring...

For example, this is my trap group WEBKOM:

trap-group WEBKOM {
version all;
categories {
authentication;
chassis;
link;
remote-operations;
routing;
startup;
rmon-alarm;
vrrp-events;
configuration;
services;
sonet-alarms;
}
targets {
192.168.142.150;
}
}

Best
Patrik

Andrew Jimmy wrote:
 You can set the snmp community in JUNOS using.. 'set snmp community public
 authorization read-only'.. But it's for pooling OK
 
 You know when you configure snmp traps you define a community for trap
 manager..I have configure my trap settings like show be
 
 low.
 
 Set trap-group auth-traps targets 5.6.7.8
 
 Set trap-group auth-traps categories authentication 
 
  
 
 Now where do you define community for trap manager so that you can get
 authenticated when you send traps to trap manager from router.
 
  
 
  
 
  
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


-- 

//Patrik

Webkom
http://www.webkom.se

+46 (0)709 35 22 99
+46 (0)8 559 26 488



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

[j-nsp] forwarding class nd loss priority

[Andrew Jimmy]

Forwarding class and loss priority is some of the confusing stuff in JUNOS
world. Can someone write about loss priority/scheduler maps in detail along
with a example. Like what if you are running MPLS VPN and you want to keep
priorities voice traffic (if you want to avoid jitter for the sip call)
weather the congestion is happening or not. How do you do it practically.

 

voice-profile 

fill-level 0 drop-probability 0;

fill-level 25 drop-probability 100;

 

Is this good to have on Gig interface for Voice traffic.

 

transmit-rate percent 20 exact;

buffer-size percent 20;

priority high;

drop-profile-map loss-priority any protocol any drop-profile voice-profile;

 

I will highly appreciate if someone can dig into this along with
configuration/comments.

 

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

[j-nsp] display mpls table

[Andrew Jimmy]

When you run the following command, why you can't see the 679 active routes.


 

junos show route protocol mpls table mpls.0   

 

mpls.0: 679 destinations, 679 routes (679 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

0  *[MPLS/0] 4w5d 13:23:40, metric 1

  Receive

1  *[MPLS/0] 4w5d 13:23:40, metric 1

  Receive

2  *[MPLS/0] 4w5d 13:23:40, metric 1

  Receive

 

{master}

junos

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

Re: [j-nsp] display mpls table

[Andrew Jimmy]

Yup, this is an ingress PE

-Original Message-
From: Nilesh Khambal [mailto:nkham...@juniper.net] 
Sent: Tuesday, April 28, 2009 9:30 PM
To: Andrew Jimmy
Cc: 'Stefan Fouant'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] display mpls table

Is this an ingress PE?

Nilesh

Andrew Jimmy wrote:
 I know one can displays the route for the LDP FECs, stored in inet.3 using
 'show route ldp table inet.3'. What if you want to see the label-switching
 state stored in mpls.0
 
 For this you use 'show route table mpls.0'; now I don't know why this
 juniper router is not displaying the label-switching state stored in
mpls.0
 for 679 active labels.
 
 
 
 -Original Message-
 From: Stefan Fouant [mailto:sfou...@gmail.com] 
 Sent: Tuesday, April 28, 2009 8:57 PM
 To: Andrew Jimmy
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] display mpls table
 
 On Tue, Apr 28, 2009 at 3:49 PM, Andrew Jimmy go...@live.com wrote:
 When you run the following command, why you can't see the 679 active
 routes.
 junos show route protocol mpls table mpls.0

 mpls.0: 679 destinations, 679 routes (679 active, 0 holddown, 0 hidden)

 + = Active Route, - = Last Active, * = Both

 0  *[MPLS/0] 4w5d 13:23:40, metric 1
  Receive
 1  *[MPLS/0] 4w5d 13:23:40, metric 1
  Receive
 2  *[MPLS/0] 4w5d 13:23:40, metric 1
  Receive
 
 mpls.0 is the label table.  Try a 'show route table inet.3' to see the
 routes.
 

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

[j-nsp] PIM join Upstream Unknown

[Andrew Jimmy]

When will you get Upstream interface: uknown? PIM-dense-sparse  mode has
already been enabled on all interfaces. All the IPs are accessible from each
router and end clients. There is no connectivity or route reach-ability
issues between routers or multicast source/receiver. 

 

Multicast source is: 192.168.0.1

 

I don't know why the heck I'm getting Upstream interface Unknown on PIM
join..

 

Here is show multicast rpf on receiver end router:

 

1.1.1.1/32

Protocol: OSPF

Interface: lsq-1/3/0.1

Neighbor: (null)

 

192.168.0.1/24

Protocol: OSPF

Interface: lsq-1/3/0.1

Neighbor: (null)

 

Here is show pim join:

 

Group: 227.12.22.33

Source: *

RP: 1.1.1.1

Flags: sparse,rptree,wildcard

Upstream interface: unknown (no nexthop)

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

Re: [j-nsp] j series query not answered on the KB

[Andrew Jimmy]

Hi do you have any real time example for Junos scripting. Run ping checks
and change static route based on result. If yea, can you please share the
code and the way it works.


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Patrik Olsson
Sent: Tuesday, April 07, 2009 7:47 PM
To: Nick Ryce
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] j series query not answered on the KB

Hello!

1. There is a standard which even Cisco supports called BFD. That tracks
routes from all protcols including static routes. So if the other end
supports BFD, that settles it.

2. Dynamic routing using OSPF/ISIS/BGP?

3. Junos scripting. Run ping checks and change static route based on result.


Cheers
Patrik

 Hi there,
 
 I have predominantly used cisco and have recently forayed into the land of
juniper and have the following question regarding a J2320 with junos 9.
 
 I have a j2320 with a 100meg metro ethernet connected on interface 0 with
a /30 link subnet (for example 10.0.0.0./30) this is also the default
gateway.
 Interface 1 is connected to a 10meg metro Ethernet with a /30 link subnet
(10.0.1.0/30).
 
 What I am looking to do is have everything go across the 100meg link and
if that goes down then route through the 10 meg.  The only problem is that
on interface 0 the link may not show as down as the provider connection is
through a switch and the fibre behind that may break.
 
 In cisco land I would use object tracking and set up a rule to ping the
default gateway on interface 0 and when that became unreachable then it
would automagically failover.
 
 The juniper kb gives reference to track-ip but it doesn't seem to be avail
on j series routers.
 
 Any help appreciated.
 
 Nick
 
 
 
 --
 
 This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed.
 If you have received this email in error please notify the sender. Any
 offers or quotation of service are subject to formal specification.
 Errors and omissions excepted. Please note that any views or opinions
 presented in this email are solely those of the author and do not
 necessarily represent those of Lumison and nPlusOne.
 Finally, the recipient should check this email and any attachments for the
 presence of viruses. Lumison and nPlusOne accept no liability for any
 damage caused by any virus transmitted by this email.
 ___
 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] FEB/FPC Complexity

[Andrew Jimmy]

I come to know that M120 can provide N:1 FEB redundancy. 

 

As per juniper DOCS, A FEB redundancy group is a named collection of two or
more Forwarding Engine Boards (FEBs) that can improve interface
availability. You can design your redundant FEB configuration to provide
backup on a one-to-one basis, or you can provide one backup for multiple
FEBs. Each FEB redundancy group can contain only one primary FEB. 

 

Can someone write some text about primary FEB and secondary FEBs, what is
the difference? What if you have two  FEBs type 1 along with two FPCs type
1, Is it possible to use both FEBs for each FPC 1+1 while both FEBs are
acting active/standby to each other so if one FEB goes offline the other can
serve both FPCs. If yes, can some help in configuring this.

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

Re: [j-nsp] FEB/FPC Complexity

[Andrew Jimmy]

Thanks for the email, the question is: Is it possible to use two FEBs for
two FPC (type 1) while both FEBs are acting active/standby to each other so
if one FEB goes offline the other can serve both FPCs. If yes, can some help
in configuring this.

-Original Message-
From: raymondh (NSP) [mailto:raymondh@gmail.com] 
Sent: Monday, April 06, 2009 9:17 PM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] FEB/FPC Complexity

A maximum of two Type 1 FPCs and one Type 2 or Type 3 compact FPC can  
be mapped per FEB.
Do the math. Each FEB can hold up to 20G.

To achieve to the N+1 concept, you'll need to do some basic math and  
FPC selection / PIC (Good to have or need to have / alternative  
solution).

A general concept of the math (related to some other questions).
https://puck.nether.net/pipermail/juniper-nsp/2009-February/012466.html


--raymondh

On Apr 6, 2009, at 10:53 PM, Andrew Jimmy wrote:

 I come to know that M120 can provide N:1 FEB redundancy.



 As per juniper DOCS, A FEB redundancy group is a named collection of  
 two or
 more Forwarding Engine Boards (FEBs) that can improve interface
 availability. You can design your redundant FEB configuration to  
 provide
 backup on a one-to-one basis, or you can provide one backup for  
 multiple
 FEBs. Each FEB redundancy group can contain only one primary FEB.



 Can someone write some text about primary FEB and secondary FEBs,  
 what is
 the difference? What if you have two  FEBs type 1 along with two  
 FPCs type
 1, Is it possible to use both FEBs for each FPC 1+1 while both FEBs  
 are
 acting active/standby to each other so if one FEB goes offline the  
 other can
 serve both FPCs. If yes, can some help in configuring this.

 ___
 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] LDP FEC Default Behavior

[Andrew Jimmy]

What if you want to configure JUNOS to advertise MPLS labels for all Static,
Connected and IGP routes. 



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka
Sent: Tuesday, March 24, 2009 8:52 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LDP FEC Default Behavior

On Tuesday 24 March 2009 07:42:16 pm William Jackson wrote:

 What happens with an IOS box? Does it have the same behavior or does 
 it create an FEC for every entry in the routing table?

IOS setups FEC's for all Static, Connected and IGP routes. 
It will also advertise those by default, which is why I normally would
suggest that you setup filters on LDP so you control what is advertised -
both in IOS and JunOS.

Label distribution mode in IOS is downstream unsolicited, and this can't be
changed.

Cheers,

Mark.

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

[j-nsp] ispf support on Juniper routers

[Andrew Jimmy]

Does Juniper router support ispf feature so that router only recalculate a
portion of the Shortest Path Tree when receive local link state
advertisements

 

Cisco

router ospf 1

ispf

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

Re: [j-nsp] IOS to JUNOS QoS

[Andrew Jimmy]

Thanks for your reply. Can you let me know the way to use 8 supported Queues
instead of 4 usable queues.

CoS queues : 8 supported, 4 maximum usable queues




-Original Message-
From: Patrik Olsson [mailto:d...@webkom.se] 
Sent: Monday, February 16, 2009 3:16 PM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] IOS to JUNOS QoS

class-of-service {
schedulers {
FTP {
transmit-rate percent 20;
}
HTTP {
transmit-rate percent 20;
}
}

scheduler-map test-policy {
forwarding-class FTP-class scheduler FTP;
forwarding-class HTTP-class scheduler HTTP;
}

forwarding-classes {
queue 0 best-effort;
queue 1 FTP-class;
queue 2 HTTP-class;
queue 3 network-control;
}

interface se-0/0/0 {
unit 0{
scheduler-map test-policy;
}
}

 }


Of course you need to classify the traffic to FTP-class and HTTP-class
either via class-of-service and classifier stanza, or via firewall
filter on ingress/egress.

Cheers
Patrik

Andrew Jimmy wrote:
 What is the equivalent  to this in JUNOS, keeping in mind that I'm not
 pasting classes intentionally. 
 
  
 
 Policy-map test-policy
 Class FTP
 Bandwidth percent 10
 Class HTTP
 Bandwidth percent 20
 !
 Interface Serial 0/0/0
 Bandwidth 1536
 service-policy output test-policy
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


-- 

//Patrik

Webkom
http://www.webkom.se

+46 (0)709 35 22 99
+46 (0)8 559 26 488



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

Re: [j-nsp] IOS to JUNOS QoS

[Andrew Jimmy]

Is there any default priority of these numbered queues like if link is
congested and packets are queuing in 0-8 different queues which one gonna be
served first.   Let's say, 3 packets are in queue 0 and 4 in queue 1 and 7
in queue 5, which one will be serialized first. 

 

From: Sean Clarke [mailto:s...@clarke-3.demon.nl] 
Sent: Monday, February 16, 2009 10:49 PM
To: Andrew Jimmy
Cc: 'Patrik Olsson'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] IOS to JUNOS QoS

 


You have to enable it ... by default the PIC only has 4 queues available.

i.e.
set chassis fpc 1 pic 0 max-queues-per-interface 8  

cheers




On 2/16/09 6:33 PM, Andrew Jimmy wrote: 

Thanks for your reply. Can you let me know the way to use 8 supported Queues
instead of 4 usable queues.
 
CoS queues : 8 supported, 4 maximum usable queues
 
 
 
 
-Original Message-
From: Patrik Olsson [mailto:d...@webkom.se] 
Sent: Monday, February 16, 2009 3:16 PM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] IOS to JUNOS QoS
 
class-of-service {
schedulers {
   FTP {
   transmit-rate percent 20;
   }
   HTTP {
   transmit-rate percent 20;
   }
   }
 
scheduler-map test-policy {
   forwarding-class FTP-class scheduler FTP;
   forwarding-class HTTP-class scheduler HTTP;
   }
 
forwarding-classes {
   queue 0 best-effort;
   queue 1 FTP-class;
   queue 2 HTTP-class;
   queue 3 network-control;
   }
 
interface se-0/0/0 {
   unit 0{
   scheduler-map test-policy;
   }
   }
 
 }
 
 
Of course you need to classify the traffic to FTP-class and HTTP-class
either via class-of-service and classifier stanza, or via firewall
filter on ingress/egress.
 
Cheers
Patrik
 
Andrew Jimmy wrote:
  

What is the equivalent  to this in JUNOS, keeping in mind that I'm not
pasting classes intentionally. 
 
 
 
Policy-map test-policy
Class FTP
Bandwidth percent 10
Class HTTP
Bandwidth percent 20
!
Interface Serial 0/0/0
Bandwidth 1536
service-policy output test-policy
 
___
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] Juniper SONET OC48/192

[Andrew Jimmy]

I'm just looking information about juniper 'PC-1OC192-SON-XFP,
XFP-10G-L-OC192-SR1'. For this we need to have SDH or we can directly
terminate into DWDM network. What will be the coloring scheme? How do you
consider dB losses when interconnecting router optical interface to SDH
which contains two to three ODFs on the path? What if I'm expecting -5 dBm
-6 dBm losses, the above card will work or not. I'm looking the same thing
for 'PC-4OC48-SON-SFP'.?  

 

Is there any document contacting deep details of such parameters for these
modules.  

 

 

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

Re: [j-nsp] Juniper SONET OC48/192

[Andrew Jimmy]

Hi many thanks for your email. Yea we are looking for OTN type equipment
that insets colored laser directly into the DWDM system. Can you please give
us some insights in detail on it.

Second how much dB losses from transponder to PC-1OC192-SON-XFP PIC are
supported. It will work with -6 or -7 dBm or not. It would be nice if you
can describe this.

Once again thanks for your quick response.



-Original Message-
From: Patrik Olsson [mailto:pols...@juniper.net] 
Sent: Friday, February 13, 2009 6:38 PM
To: Andrew Jimmy
Subject: RE: [j-nsp] Juniper SONET OC48/192

Hello!

I'm just looking information about juniper 'PC-1OC192-SON-XFP, 
XFP-10G-L-OC192-SR1'. For this we need to have SDH or we can directly 
terminate into DWDM network. What will be the coloring scheme? How do
you
consider dB losses when interconnecting router optical interface to SDH 
which contains two to three ODFs on the path? What if I'm expecting -5
dBm
-6 dBm losses, the above card will work or not. I'm looking the same
thing
for 'PC-4OC48-SON-SFP'.?  

If you use PC-1OC192-SON-XFP with XFP-10G-L-OC192-SR1, you need a
transponder in the DWDM system, you can not insert the signal directly since
this type of XFP sends normal light. Same goes for PC-4OC48-SON-SFP with
the SFP-1OC48-SR.

The loss discussion is then not upto the XFP/SFP, since you need to use a
transponder in the system, and the DWDM system will be the source of the
colored light.

Are you indeed looking for OTN type of equipment that inserts colored laser
directly into the DWDM system?

Cheers
Patrik


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

[j-nsp] IOS to JUNOS QoS

[Andrew Jimmy]

What is the equivalent  to this in JUNOS, keeping in mind that I'm not
pasting classes intentionally. 

 

Policy-map test-policy
Class FTP
Bandwidth percent 10
Class HTTP
Bandwidth percent 20
!
Interface Serial 0/0/0
Bandwidth 1536
service-policy output test-policy

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

[j-nsp] mpls l3vpn

[Andrew Jimmy]

Why you get * on destination PE and one extra hop when you do traceroute. 

 

juni...@re traceroute 192.1.1.5 routing-instance l3vpn

traceroute to 192.1.1.5 (192.1.1.5), 30 hops max, 40 byte packets

 1  1.1.0.1 (1.1.0.1)  157.301 ms  207.940 ms  157.392 ms

 MPLS Label=299840 CoS=0 TTL=1 S=0

 MPLS Label=17 CoS=0 TTL=1 S=1

 2  10.1.1.2 (10.1.1.2)  183.165 ms  123.536 ms  185.375 ms

 MPLS Label=300704 CoS=0 TTL=1 S=0

 MPLS Label=17 CoS=0 TTL=2 S=1

 3  * * *

 4  192.1.1.5 (192.1.1.5)  134.623 ms  181.346 ms  183.886 ms

 

juni...@re

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

[j-nsp] Control Plane Protection

[Andrew Jimmy]

 

You are concerned about DoS attacks against a key perimeter router in your
company. Configure router so that it limits the aggregate rate of ARP
traffic toward the route processor to 75 packets per second. Routing control
traffic marked with an IP Precedence value of 6 should be limited to 100
packets per second. How do you do this in JUNOS?

 

Here is the way you do on Cisco router:

 

class-map match-all RP
match ip precedence 6
class-map match-all ARP
match protocol arp
!
!
policy-map CoPP
class ARP
police rate 75 pps
class RP
police rate 100 pps
!
control-plane
!
service-policy input CoPP

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

[j-nsp] RSVP LSP Bandwidth

[Andrew Jimmy]

What does meant by reserved and highwater bandwidth reservation exactly. Is
this something similar to police rate-limit or traffic shaping? Why do you
need to reserve bandwidth and in what circumstances ; what are the impacts?

 

I will appreciate if someone can explain all of this in very simple words.

 

juni...@nasa show rsvp interface

RSVP interface: 2 active

  Active Subscr- Static   Available
Reserved Highwater

Interface  State  resv iption BW  BW BW
mark

so-0/0/0.0 Up 0  100% 155.52Mbps  155.52Mbps 0bps
0bps

so-0/0/2.0 Up 1  100% 155.52Mbps  105.52Mbps 50Mbps
50Mbps.

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

[j-nsp] l2circuit OL

[Andrew Jimmy]

encapsulation vlan-ccc;

fastether-options {

loopback;

}

unit 101 {

encapsulation vlan-ccc;

vlan-id 512;

family ccc;

}

 

neighbor 10.1.1.3 {

interface fe-0/0/2.101 {

virtual-circuit-id 512;

}

}

 

 

Neighbor: 10.1.1.3 

Interface Type  St Time last up  # Up trans

fe-0/0/2.101(vc 512)  rmt   OL   

 

I'm trying to configure l2ciruict between 2 PEz. I don't have any problem
running MPLS L3VPN. Label binding is working quite fine on both end. Can
someone please point out when would you get OL (no outing label).

 

 

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

[j-nsp] VRF router reflector support

[Andrew Jimmy]

BGP route reflection is not supported for VPN routing and forwarding (VRF)
routing instances. Is there any hope we will get route-reflection for VRF
(L3VPNs or VPLS)? 

 

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

Re: [j-nsp] l2circuit or l2vpn

[Andrew Jimmy]

Well, this means that you need to have MPLS switching in both case either
l2ciruict or l2vpn. What if you want to use pseudo-wire services (like
L2TPv3 (Cisco)) when you don't have MPLS environment.

Second if l2vpn is multipoint than what's the usage of VPLS. Is there any
significant difference between l2vpn and VPLS. 

 

Can't you have pseudo-wire circuit on traditional IP network ( just like
cisco L2TPVv3).

 

 

 

 

From: keegan.hol...@sungard.com [mailto:keegan.hol...@sungard.com] 
Sent: Thursday, January 08, 2009 11:08 PM
To: Andrew Jimmy
Cc: juniper-nsp@puck.nether.net; juniper-nsp-boun...@puck.nether.net
Subject: Re: [j-nsp] l2circuit or l2vpn

 


The main differences are related to the Martini and Kompella method of
implementing the technology. For example l2vpn is based on MBGP with RSVP
doing the LSP signaling and advertising the labels.  This means that the
path of the circuit is handled as if it were a virtual circuit because RSVP
signals and reserves the bandwidth before traffic is passed.  l2circuit is
based on LDP which sends hellos end to end but depends on the IGP for
resource reservations.  The data forwarding is technically the same and you
can achieve the same results with either though.  Personally, I'm a fan of
l2vpn the use of RSVP allows for more tidy configuration and bandwidth
reservations.  I think l2vpn is a little easier to troubleshoot as well,
however YMMV. 

Keegan 





From: 

Andrew Jimmy go...@live.com 


To: 

juniper-nsp@puck.nether.net 


Date: 

01/08/2009 12:54 PM 


Subject: 

[j-nsp] l2circuit or l2vpn 


Sent by: 

juniper-nsp-boun...@puck.nether.net

 

  _  




What are the major differences between l2cirucit and l2vpn in terms of
Juniper JUNOS. Which is best in replacing Cisco L2TPv3 pseudo-wr.

___
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] Queue PQ CQ WFQ CBWFQ

[Andrew Jimmy]

Does Juniper boxes and JUNOS support queue mechanism of PQ CQ WFQ or CBWFQ.
If yes; Is there any hardware limitations? Can anyone guide me to the right
Document?

 

 

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

Re: [j-nsp] VPLS support on Fast Ethernet

[Andrew Jimmy]

Thanks for the update on this. How about running MPLS label switching (P) on
E3 IQ PICS and using PB-4FE-TX/PE-4FE-TX as PE customer edge. 

The question is what MPLS applications (VPLS, L3VPN RFC 2527bis, Multicast
over MPLS L3VPN/VPLS are supported in such infrastructure. 



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of sth...@nethelp.no
Sent: Thursday, December 25, 2008 3:31 AM
To: go...@live.com
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VPLS support on Fast Ethernet

  Does VPLS supported on Juniper Fast Ethernet PB-4FE-TX/PE-4FE-TX?
 
 No.

I stand corrected here. VPLS is possible on FE ports using LSI
interfaces (no-tunnel-services configured under the VPLS instance).
This carries some restrictions compared to using IQ interfaces and
tunnel PICs.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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 support on Fast Ethernet

[Andrew Jimmy]

 

Does VPLS supported on Juniper Fast Ethernet PB-4FE-TX/PE-4FE-TX?

 

If above Fast-Ethernet doest support VPLS; Can someone recommend any of
Fast-Ethernet module which support VPLS. 

 

What's the difference between PB or PE cards?

 

 

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

Re: [j-nsp] JR Global static route configuration

[Andrew Jimmy]

Two minor points you can have multiple static routes for the same
destination address with the same preference (juniper) admin distance
(Cisco) and difference interfaces for load balancing. The exception is the
default gateway 0.0.0.0 which can only occur once per admin distance but you
can use the interface method with difference admin distance described above
to provide resilience for 0.0.0.0. These methods are used when you do not
want to use a routing protocol.

You can have multiple static routes for the same destination address with
different preference (Juniper) admin distance (Cisco). In Juniper world
Qualified Next Hops is the way to go. For example, 

routing-options {
static {
route 1.1.1.1/32 {
next-hop 2.2.2.2;
qualified-next-hop 3.3.3.3 {
preference 5;
}
}
}
}

Regards,
Masood

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jose Madrid
Sent: Friday, November 21, 2008 7:07 PM
To: harish 
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JR Global static route configuration

Yes, someone on here will correct me if im wrong, but I believe
qualified-next-hop is what you want.

http://www.juniper.net/techpubs/software/junos/junos73/swconfig73-routing/ht
ml/routing-summary51.html

On Fri, Nov 21, 2008 at 1:58 AM, harish T [EMAIL PROTECTED] wrote:
 Hi,

 Can we configure more than one instance of Global static route for a
 perticular Destination address ?

 Static route 1:
 destination mask:255.255.255.252
 destination prefix:10.12.32.0
 next hop:156.65.21.2


 Static route 2:
 destination mask:255.255.255.252
 destination prefix:10.12.32.0
 next hop:100.200.333.1

 Is it possible to have more than one entry of static route for a
particular
 network like above?


 --
 --
 To accomplish great things, we must not only act, but also dream; not only
 plan, but also believe.



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




-- 
It has to start somewhere, it has to start sometime.  What better
place than here? What better time than now?
___
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] 4:1 oversubscription

[Andrew Jimmy]

Can someone please explain what does mean by 4:1 or 2:1 oversubscription?

 

A 4-port Gigabit Ethernet PIC supporting up to 4:1 oversubscription 

A 8-port Gigabit Ethernet PIC supporting up to 2:1 oversubscription

 

 

 

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

Re: [j-nsp] 4:1 oversubscription

[Andrew Jimmy]

Many thanks for the reply. What are the key difference between simple IQ2
PIC and Enhanced IQ2 PIC. 

For what one would need Enhanced IQ2 PIC instead of simple IQ2 PIC.





-Original Message-
From: Paul Goyette [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 20, 2008 6:50 PM
To: Andrew Jimmy; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] 4:1 oversubscription

It means you can assign bandwidths to individual units
where the sum of the assigned bandwidths are two (or
four) times the bandwidth of the physical interface.

Paul Goyette
Juniper Networks Customer Service
JTAC Senior Escalation Engineer
Juniper Security Incident Response Team
PGP Key ID 0x53BA7731 Fingerprint:
  FA29 0E3B 35AF E8AE 6651
  0786 F758 55DE 53BA 7731 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Jimmy
 Sent: Thursday, November 20, 2008 5:42 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] 4:1 oversubscription
 Importance: High
 
 Can someone please explain what does mean by 4:1 or 2:1 
 oversubscription?
 
  
 
 A 4-port Gigabit Ethernet PIC supporting up to 4:1 oversubscription 
 
 A 8-port Gigabit Ethernet PIC supporting up to 2:1 oversubscription
 
  
 
  
 
  
 
 ___
 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] junos policy

[Andrew Jimmy]

How do you guys do else in JUNOS policy.. like what if I want 116.203.0/16
orlonger damping high and rest normal. How you are going to use it.

 

Damping: high

Damping: normal

 

policy-statement damp {

term 1 {

from {

route-filter 116.203.0.0/16 orlonger damping high;

}

}

Else normal

}

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

Re: [j-nsp] VRRP trap

[Andrew Jimmy]

snmp {
trap-group vrrp {
categories {
vrrp-events;
}
targets {
1.1.1.1;
}
}
}

You can change snmp trap target as well as trap events verion. ? mark is
always your friend ...:)

HTH

Regards,
Masood 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bit Gossip
Sent: Sunday, November 02, 2008 1:10 PM
To: juniper-nsp
Subject: [j-nsp] VRRP trap

Experts,
I would  like my Junos 8.5 and 9.2 routers to send traps when there is a
change in the VRRP status but I can not find any reference in the
documentation. Anyone has experience and can give me an hint..
Thanks,
Bit

___
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] ospf import policy

[Andrew Jimmy]

 

To keep consistency of ospf database; we don't use import policy. If we
don't need import policy for ospf protocol why the heck juniper developers
are giving us an option to configure it. Can someone please write the usage
of import policy for OSPF protocol.

 

top set protocols ospf import

 

 

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

Re: [j-nsp] routing optimal path or suboptimal path

[Andrew Jimmy]

It would be nice if you can explain the following questions..

-Original Message-
From: Mark Tinka [mailto:[EMAIL PROTECTED] 
Sent: Saturday, October 25, 2008 7:13 PM
To: juniper-nsp@puck.nether.net
Cc: Andrew Jimmy
Subject: Re: [j-nsp] routing optimal path or suboptimal path

On Saturday 25 October 2008 21:53:55 Andrew Jimmy wrote:

 How do you guys practically define/consider that this is optimal path 
 and this is suboptimal path.

This may differ from network to network.

In our case: 

For the IGP; the optimal path is the shortest one to the Loopback address of
the end router. Default routing is sub-optimal and unsupported.

How do you guys practically configure this. What do you mean by this that
default routing is sub-optimal and unsupported? So what you have to do make
it optimal.

For BGP; the optimal path is generally the one with the shortest vector to
the end AS. The routing/forwarding table would typically be default-free.
However, other factors may cause this strategy to evolve, e.g.,
$ettlement-$tatu$ of circuits, circuit congestion, management decisions,
e.t.c.

It would be nice if you can further explain this.

How this is actually technically implemented is in the details. What the
above tries to show, for us, is a high-level strategy on how we consider
path optimity.

Cheers,

Mark.

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

[j-nsp] aggregate and generated routes

[Andrew Jimmy]

What is the practical usage of aggregate and generated routes. Aggregate
routes does make sense to me but what is the usage of generated routes in
network.

 

Can someone please explain with example and conf.

 

Thanks in advance..

 

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

[j-nsp] alias command in JUNOS

[Andrew Jimmy]

What is the equivalent to Cisco alias command like alias exec sr show
running-config in JUNOS.

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

[j-nsp] bgp-l3vpn table is confusing

[Andrew Jimmy]

While executing command below; I'm getting confuse with this prefix
2.2.2.2:3:192.168.6.0/24

 

Can someone please explain what the hell is :3: between 2.2.2.2 and
192.168.6.0.

 

[EMAIL PROTECTED] run show route receive-protocol bgp 2.2.2.2 

 

inet.0: 2233 destinations, 2233 routes (2233 active, 0 holddown, 0 hidden)

 

inet.3: 1739 destinations, 1739 routes (1739 active, 0 holddown, 0 hidden)

 

__juniper_private1__.inet.0: 5 destinations, 6 routes (5 active, 0 holddown,
0 hidden)

 

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown,
1 hidden)

 

QNET.inet.0: 384 destinations, 412 routes (384 active, 0 holddown, 0 hidden)

  Prefix  Nexthop  MED LclprefAS path

* 10.10.100.56/31 2.2.2.2  100I

* 192.168.1.0/24  2.2.2.2  505 100I

* 192.168.2.0/24  2.2.2.2  505 100I

* 192.168.8.0/24  2.2.2.2  505 100I

 

mpls.0: 1728 destinations, 1728 routes (1728 active, 0 holddown, 0 hidden)

 

bgp.l3vpn.0: 311 destinations, 317 routes (311 active, 0 holddown, 0 hidden)

  Prefix  Nexthop  MED LclprefAS path

  2.2.2.2:3:10.10.100.56/31

* 2.2.2.2  100I

  2.2.2.2:3:192.168.6.0/24

* 2.2.2.2  505 100I

  2.2.2.2:3:192.168.2.0/24

* 2.2.2.2  505 100I

  2.2.2.2:3:192.168.8.0/24

* 2.2.2.2  505 100I

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