Re: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
Thank-you very much.
Dan
From: Adam Vitkovsky <adam.vitkov...@gamma.co.uk>
Sent: Monday, October 26, 2015 6:06 PM
To: Dan Farrell; Nitzan Tzelniker
Cc: juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
Hi Dan,
I found this:
"BGP is the only protocol to which you can apply routing policies that
reference policies and policy objects configured in the dynamic database"
http://www.juniper.net/documentation/en_US/junos12.3/topics/usage-guidelines/policy-configuring-dynamic-routing-policies.html
adam
>
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: adam.vitkov...@gamma.co.uk
W: www.gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of
this email are confidential to the ordinary user of the email address to which
it was addressed. This email is not intended to create any legal relationship.
No one else may place any reliance upon it, or copy or forward all or any of it
in any form (unless otherwise notified). If you receive this email in error,
please accept our apologies, we would be obliged if you would telephone our
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with
limited liability, with registered number 04340834, and whose registered office
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
-Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Dan Farrell
> Sent: Monday, October 26, 2015 6:34 PM
> To: Nitzan Tzelniker
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
>
> Hi Nitzan,
>
> Thanks for your reply- I think you're right. To further add info and split the
> documentation and feature-set hairs-
>
>
>
> - At least from 9.5 this is stated to be usable by EX series.
>
> - BUT! All docs that reference dynamic-db do so with routing
> policies,
> and show support for only M, MX, and T.
>
> - JUNOS-on-EX does not error out on the configuration (as it would,
> for
> example, when configuring BGP on an EX2200-C).
>
> The use-case is loading large numbers of prefixes for filtering purposes
> without having to churn the unit with a typical commit operation and it's
> associated churn. I'd hate to have to migrate to MX because EX can't/won't
> do it.
>
> Cheers!
>
> Dan
>
> From: Nitzan Tzelniker [mailto:nitzan.tzelni...@gmail.com]
> Sent: Monday, October 26, 2015 2:19 PM
> To: Dan Farrell <da...@appliedi.net>
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
>
> Dan,
>
> AFAIK dynamic-db is for routing policy only it dose not work for firewall
> filters
>
> Nitzan
>
>
> On Mon, Oct 26, 2015 at 7:29 PM, Dan Farrell
> <da...@appliedi.net<mailto:da...@appliedi.net>> wrote:
> Howdy List,
>
> I can't seem to get a dynamic-db prefix-list to work correctly on either an
> ex3200 or ex2200 on JUNOS 12.3 and 12.10.
> I'm starting to suspect it simply won't work on these models (or maybe on
> EX-series at all, or maybe only on routing policies).
>
> Using a dynamic-db prefix-list in a filter leads to NO packets passing on the
> interface it is instantiated on. (tested on l2 and l3 interface filtering).
>
> It seems to be a simple implementation (create the same prefix-list name in
> the normal configuration as the dynamic-db prefix list and tag it
> 'dynamic-db',
> then use in a filter), so I'm currently not suspecting myself as the culprit.
>
>
> Combining manual prefixes with the dynamic-db in one prefix-list results in
> only the manual prefixes being honored, while the dynamic-db ones are still
> ignored (same as above).
>
>
> Thanks list!
>
>
> Also, here's my configuration's relevant parts:
>
> DYNAMIC CONFIGURATION:
>
> policy-options {
> prefix-list badips {
>
> 192.168.75.35/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDM
> PbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-
> mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.75.35%2F
> 32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
>
> 192.168.75.100/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dD
> MPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-
> mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.75.100%2
> F32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
>
> 192.168.100.251/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dD
>
[j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
Howdy List,
I can't seem to get a dynamic-db prefix-list to work correctly on either an
ex3200 or ex2200 on JUNOS 12.3 and 12.10.
I'm starting to suspect it simply won't work on these models (or maybe on
EX-series at all, or maybe only on routing policies).
Using a dynamic-db prefix-list in a filter leads to NO packets passing on the
interface it is instantiated on. (tested on l2 and l3 interface filtering).
It seems to be a simple implementation (create the same prefix-list name in the
normal configuration as the dynamic-db prefix list and tag it 'dynamic-db',
then use in a filter), so I'm currently not suspecting myself as the culprit.
Combining manual prefixes with the dynamic-db in one prefix-list results in
only the manual prefixes being honored, while the dynamic-db ones are still
ignored (same as above).
Thanks list!
Also, here's my configuration's relevant parts:
DYNAMIC CONFIGURATION:
policy-options {
prefix-list badips {
192.168.75.35/32;
192.168.75.100/32;
192.168.100.251/32;
}
}
STATIC CONFIGURATION:
==
policy-options {
prefix-list badips {
dynamic-db;
1.1.1.1/32;
}
}
firewall {
family inet {
filter blocktest {
term block-dy {
from {
destination-prefix-list {
badips;
}
}
then {
discard;
}
}
term allow-all-else {
then accept;
}
}
}
}
interfaces {
vlan {
unit 33 {
family inet {
filter {
input blocktest;
}
address 192.168.78.1/24;
}
}
}
}
vlans {
noc24-test {
vlan-id 33;
interface {
ge-0/0/3.0;
}
l3-interface vlan.33;
}
}
Dan Farrell
Applied Innovations Corp.
d...@appliedi.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
Hi Nitzan,
Thanks for your reply- I think you're right. To further add info and split the
documentation and feature-set hairs-
- At least from 9.5 this is stated to be usable by EX series.
- BUT! All docs that reference dynamic-db do so with routing policies,
and show support for only M, MX, and T.
- JUNOS-on-EX does not error out on the configuration (as it would,
for example, when configuring BGP on an EX2200-C).
The use-case is loading large numbers of prefixes for filtering purposes
without having to churn the unit with a typical commit operation and it's
associated churn. I'd hate to have to migrate to MX because EX can't/won't do
it.
Cheers!
Dan
From: Nitzan Tzelniker [mailto:nitzan.tzelni...@gmail.com]
Sent: Monday, October 26, 2015 2:19 PM
To: Dan Farrell <da...@appliedi.net>
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] dynamic-db for prefix-list filter on ex3200, ex2200
Dan,
AFAIK dynamic-db is for routing policy only
it dose not work for firewall filters
Nitzan
On Mon, Oct 26, 2015 at 7:29 PM, Dan Farrell
<da...@appliedi.net<mailto:da...@appliedi.net>> wrote:
Howdy List,
I can't seem to get a dynamic-db prefix-list to work correctly on either an
ex3200 or ex2200 on JUNOS 12.3 and 12.10.
I'm starting to suspect it simply won't work on these models (or maybe on
EX-series at all, or maybe only on routing policies).
Using a dynamic-db prefix-list in a filter leads to NO packets passing on the
interface it is instantiated on. (tested on l2 and l3 interface filtering).
It seems to be a simple implementation (create the same prefix-list name in the
normal configuration as the dynamic-db prefix list and tag it 'dynamic-db',
then use in a filter), so I'm currently not suspecting myself as the culprit.
Combining manual prefixes with the dynamic-db in one prefix-list results in
only the manual prefixes being honored, while the dynamic-db ones are still
ignored (same as above).
Thanks list!
Also, here's my configuration's relevant parts:
DYNAMIC CONFIGURATION:
policy-options {
prefix-list badips {
192.168.75.35/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.75.35%2F32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
192.168.75.100/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.75.100%2F32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
192.168.100.251/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.100.251%2F32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
}
}
STATIC CONFIGURATION:
==
policy-options {
prefix-list badips {
dynamic-db;
1.1.1.1/32<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F1.1.1.1%2F32=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
}
}
firewall {
family inet {
filter blocktest {
term block-dy {
from {
destination-prefix-list {
badips;
}
}
then {
discard;
}
}
term allow-all-else {
then accept;
}
}
}
}
interfaces {
vlan {
unit 33 {
family inet {
filter {
input blocktest;
}
address
192.168.78.1/24<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg3LjyGCW8q-mCP4XX_G8VQsxsT56dNv4f7SpRnW02?t=http%3A%2F%2F192.168.78.1%2F24=6603779591372800=2f49fcc1-2375-495f-ad7d-295df3bd9fff>;
}
}
}
}
vlans {
noc24-test {
vlan-id 33;
interface {
ge-0/0/3.0;
}
l3-interface vlan.33;
}
}
Dan Farrell
Applied Innovations Corp.
d...@appliedi.net<mailto:d...@appliedi.net>
___
juniper-nsp mailing list
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 VC odd routing issues
You are encouraged to take your 4200 VC and upgrade it to 10.0S6.1. I realize that you are likely not using hundreds of RVI's, but if you are, this similar behavior can be exhibited. This is what happened- I had about 750 RVI's on a 4200 VC, and it was like a overfilled tomato truck of how many could actually be working at any given time (as one tomato gets on the front of the truck, one would fall off the back), and would randomly not work with some at random times. It was narrowed down to an issue specifically addressed in 10.0S1.1, now 10.0S6.1. There are other PR's mentioned that seem to touch protocols you're having issues with, you should review this link and use it- https://www.juniper.net/alerts/viewalert.jsp?actionBtn=SearchtxtAlertNumber=PSN-2010-06-820viewMode=view If you are interested in the details of my specific case I'll be happy to share them. Dan Farrell Applied Innovations Corp. da...@appliedi.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill Blackford Sent: Monday, August 09, 2010 2:06 PM To: 'juniper-nsp' Subject: [j-nsp] EX4200 VC odd routing issues EX4200-24T X2 (VC) Layer3 10.1R1.8 EX3200-48T (switch1 and switch2) Layer2 rack switches. 10.0S1.1 I don't have enough empirical data to offer but I figured I'd ask the group in case any of this behavior has been seen. Problem 1. Inter-vlan routing. I'm seeing issues with simple routing from vlanA on switch1 to vlanB on switch2. Both switch1 and switch2 connect via L2 ae trunks to the EX4200 VC. All Vlans are consistent throughout all switches. RVI's on the Layer3 VC are correct. I am also seeing a traceroute from hostA on switch1 to hostB on switch2 to return only the dest host, not the gateway (VC) followed by the dest host as would be expected (IOW, a single hop). The EX4200 just replaced a C3750 VC, the rack switches mentioned did not change. Problem 2. (separate issue) Multicast on same switch/same vlan. I have two hosts that can normally communicate via mcast that now that they're on a Juniper EX cannot. I haven't changed the default of igmp-snooping vlan all. I move these hosts back to the C switch and mcast functions again. Thank you in advance for any shred thoughts. -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD Logged into reality and abusing my sudo priviledges ___ 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] virtual-chassis and interfaces
I see the same thing on fresh configs - once I define something on one of those interfaces, it shows up. Dan Farrell Sent from my iPhone On Aug 6, 2010, at 4:45 PM, Stefan Fouant sfou...@shortestpathfirst.net wrote: -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of snort bsd Sent: Friday, August 06, 2010 3:01 PM To: juniper-nsp Subject: [j-nsp] virtual-chassis and interfaces Hi all: With virtual-chassis, after I login, I only see interfaces (under stanza interfaces) on master, not those interfaces on the back up mode or line card mode. How could I configure those interfaces that are not on master? do I have to login each physical switch in order to configure those interfaces? They might not necessarily show up in the configuration until you actually define them... it depends on how they were brought into the virtual- chassis. However if your Virtual-Chassis is set up correctly, they should still show up when you do a 'show interfaces terse'. The FPC portion of the interface naming convention is what is used to identify the interfaces on a given virtual-chassis member. In other words, interfaces on member-id 2 will show up in 'show interfaces terse' as ge-2/x/x or xe-2/x/x. You can verify that your virtual-chassis is working correctly by doing a 'show virtual-chassis status', or even a 'show chassis hardware' will give you a clue as to whether or not all the members are shown in the virtual-chassis. HTHs. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ 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] Sudden ping drops on EX4200 VC
I think stating to a voluntary list that you need an 'urgent response' is out of place. People here like sharing issues, helping others, and expanding their knowledge and community. This is not a volunteer firefighter team, however. Aside from that, you aren't providing the usuals, mainly the version of JUNOS you're running, and if it's happening under any specific conditions or just randomly. Have you pushed the configuration bounds of the platform (aka, too many VLANs or RVI's, which can produce this issue?) You need to provide some information if you want faster and more useful answers, as you seem to need by your call for an 'urgent response'. Just so you think I'm not being a jerk just to be a jerk, various 9.x versions of JUNOS caused problems for the EX series (even when not in a VC stack) and 10.x helped significantly, specifically 10.0S1.1. So it's actually helpful to know this information ahead of time. If you don't want to provide useful information here, try upgrading to what the Company itself recommends and see if you still experience problems. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Fahad Khan Sent: Thursday, June 24, 2010 7:14 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Sudden ping drops on EX4200 VC Dear Folks, Has any one experienced sudden ping drops (network outage) and then resume again in inter-valn routing on EX4200 VC?? Awaiting for urgent response regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com http://www.visualcv.com/g46ptnd ___ 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] EX 4200 stability with BGP and OSPF redistribution ?
Not in -this- version 10.0S1.1 . I sing the praises of the EX series because it fits our needs like a glove and Cisco wants more money for less product. But just 6 months ago it was a little rough because the platform, IMHO, was 'growing up' in the 9.X series. There were some definite operational problems we had on 9. With 10, aside from great stability, one noticeable difference is interface groups- in our environment (virtualization hosting) this has made configuring the devices significantly easier. At this point I can't fault them, and we are using 4200 VC stacks to slowly expand our core routing/switching, one chassis at a time (getting ready to add our first third chassis to a stacked core). We may eventually convert to the 8208 platform there, but right now the 4200's price point is so attractive it's hard not to continue in this direction. Dan -Original Message- From: Laurent HENRY [mailto:laurent.he...@ehess.fr] Sent: Tuesday, June 22, 2010 5:23 AM To: Dan Farrell Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Thank you ! No weird bugs encountered ? Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ 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] EX 4200 stability with BGP and OSPF redistribution ?
We experienced phantom routing and arp issues as well in the 9 series, but 10.0s1.1 has been very stable. -Original Message- From: Cyrill Malevanov [mailto:c...@n-home.ru] Sent: Tuesday, June 22, 2010 10:18 AM To: Dan Farrell Cc: Laurent HENRY; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? We have a lot of routing problems on EX4200 VC's. Standalone EX works fine, but routing on high loads using VC - is a pain. Some routing loss, packets loss etc. Cyrill On 22.06.2010 17:59, Dan Farrell wrote: Not in -this- version 10.0S1.1 . I sing the praises of the EX series because it fits our needs like a glove and Cisco wants more money for less product. But just 6 months ago it was a little rough because the platform, IMHO, was 'growing up' in the 9.X series. There were some definite operational problems we had on 9. With 10, aside from great stability, one noticeable difference is interface groups- in our environment (virtualization hosting) this has made configuring the devices significantly easier. At this point I can't fault them, and we are using 4200 VC stacks to slowly expand our core routing/switching, one chassis at a time (getting ready to add our first third chassis to a stacked core). We may eventually convert to the 8208 platform there, but right now the 4200's price point is so attractive it's hard not to continue in this direction. Dan -Original Message- From: Laurent HENRY [mailto:laurent.he...@ehess.fr] Sent: Tuesday, June 22, 2010 5:23 AM To: Dan Farrell Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Thank you ! No weird bugs encountered ? Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ 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] Logical-Systems Management SNMP
# set snmp community XPTO clients 10.31.0.236
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Gabriel Farias
Sent: Thursday, June 17, 2010 4:16 PM
To: juniper-nsp@puck.nether.net; juniper-nsp-boun...@puck.nether.net
Subject: Re: [j-nsp] Logical-Systems Management SNMP
Hi friends,
I used the following configuration, but I'm having error and the server
database can not read the information via snmp.
Do you have any hint of what is happening?
thanks
*Attempting Server*:
sa19rb1:/ # ping 10.251.42.230 -n 4
PING 10.251.42.230: 64 byte packets
64 bytes from 10.251.42.230: icmp_seq=0. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=1. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=2. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=3. time=1. ms
10.251.42.230 PING Statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
sa19rb1:/ # snmpwalk 10.251.42.230 system
snmpwalk: No response arrived before timeout.
*Configure used*
{master}[edit]
q...@ixr01rjo# show snmp
community XPTO {
authorization read-only;
logical-system RT30RJO {
routing-instance manager-snmp;
}
}
trap-options {
logical-system RT30RJO {
routing-instance manager-snmp {
source-address 10.251.42.230;
}
}
}
routing-instance-access;
traceoptions {
file debug-snmp;
flag all;
}
{master}[edit]
q...@ixr01rjo# run monitor start debug-snmp
*ERROR*:
{master}[edit]
q...@ixr01rjo#
*** debug-snmp ***
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 snmpd[5709] Get-Next-Request
Jun 17 16:35:28 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:28 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:28 snmpd[5709] Version: SNMPv1
Jun 17 16:35:28 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:28 snmpd[5709] Community: XPTO
Jun 17 16:35:28 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:28 snmpd[5709]OID : system
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:28 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 snmpd[5709] Get-Next-Request
Jun 17 16:35:29 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:29 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:29 snmpd[5709] Version: SNMPv1
Jun 17 16:35:29 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:29 snmpd[5709] Community: XPTO
Jun 17 16:35:29 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:29 snmpd[5709]OID : system
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:29 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 snmpd[5709] Get-Next-Request
Jun 17 16:35:32 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:32 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:32 snmpd[5709] Version: SNMPv1
Jun 17 16:35:32 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:32 snmpd[5709] Community: XPTO
Jun 17 16:35:32 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:32 snmpd[5709]OID : system
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:32 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Tranks
Gabriel Farias
2010/6/10 Gabriel Farias gabrielfaria...@gmail.com
Dear friends,
I have a router model M10i Junos 9.6R1.13 running and is working with
three-logical systems (LS1, LS2 and LS3), I need to manage all logical
systems using SNMP, the best way?
*I am using the command*:
set snmp community name-community logical-system name-system
In addition to this command that is needed?
Thanks,
Gabriel Farias
___
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] Logical-Systems Management SNMP
You might also want to try from your server-
# snmpwwalk -c XPTO 10.251.42.230 system
Dan
-Original Message-
From: Dan Farrell
Sent: Thursday, June 17, 2010 4:39 PM
To: 'Gabriel Farias'; juniper-nsp@puck.nether.net;
juniper-nsp-boun...@puck.nether.net
Subject: RE: [j-nsp] Logical-Systems Management SNMP
# set snmp community XPTO clients 10.31.0.236
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Gabriel Farias
Sent: Thursday, June 17, 2010 4:16 PM
To: juniper-nsp@puck.nether.net; juniper-nsp-boun...@puck.nether.net
Subject: Re: [j-nsp] Logical-Systems Management SNMP
Hi friends,
I used the following configuration, but I'm having error and the server
database can not read the information via snmp.
Do you have any hint of what is happening?
thanks
*Attempting Server*:
sa19rb1:/ # ping 10.251.42.230 -n 4
PING 10.251.42.230: 64 byte packets
64 bytes from 10.251.42.230: icmp_seq=0. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=1. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=2. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=3. time=1. ms
10.251.42.230 PING Statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
sa19rb1:/ # snmpwalk 10.251.42.230 system
snmpwalk: No response arrived before timeout.
*Configure used*
{master}[edit]
q...@ixr01rjo# show snmp
community XPTO {
authorization read-only;
logical-system RT30RJO {
routing-instance manager-snmp;
}
}
trap-options {
logical-system RT30RJO {
routing-instance manager-snmp {
source-address 10.251.42.230;
}
}
}
routing-instance-access;
traceoptions {
file debug-snmp;
flag all;
}
{master}[edit]
q...@ixr01rjo# run monitor start debug-snmp
*ERROR*:
{master}[edit]
q...@ixr01rjo#
*** debug-snmp ***
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 snmpd[5709] Get-Next-Request
Jun 17 16:35:28 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:28 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:28 snmpd[5709] Version: SNMPv1
Jun 17 16:35:28 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:28 snmpd[5709] Community: XPTO
Jun 17 16:35:28 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:28 snmpd[5709]OID : system
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:28 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 snmpd[5709] Get-Next-Request
Jun 17 16:35:29 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:29 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:29 snmpd[5709] Version: SNMPv1
Jun 17 16:35:29 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:29 snmpd[5709] Community: XPTO
Jun 17 16:35:29 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:29 snmpd[5709]OID : system
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:29 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 snmpd[5709] Get-Next-Request
Jun 17 16:35:32 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:32 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:32 snmpd[5709] Version: SNMPv1
Jun 17 16:35:32 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:32 snmpd[5709] Community: XPTO
Jun 17 16:35:32 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:32 snmpd[5709]OID : system
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:32 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Tranks
Gabriel Farias
2010/6/10 Gabriel Farias gabrielfaria...@gmail.com
Dear friends,
I have a router model M10i Junos 9.6R1.13 running and is working with
three-logical systems (LS1, LS2 and LS3), I need to manage all logical
systems using SNMP, the best way?
*I am using the command*:
set snmp community name-community logical-system name-system
In addition to this command that is needed?
Thanks,
Gabriel Farias
___
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] Solarwinds Monitoring Problem
And I doubt the Solarwinds app is pushing that kind of icmp traffic to a single host for monitoring. Now, if something else was already hitting it up... Dan Farrell Applied Innovations Corp. da...@appliedi.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chris Morrow Sent: Sunday, June 06, 2010 11:45 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Solarwinds Monitoring Problem On 06/06/10 11:37, sth...@nethelp.no wrote: Is there default rate limiting of ICMP traffic in JunOS? monitoring systems and stuff we've developed ourselves. Mind you, we don't have any EX switches. ex's have a default (unchangable) 1kpps limit toward the RE... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ Information from ESET NOD32 Antivirus, version of virus signature database 5176 (20100606) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5182 (20100608) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Immediate aging in EX-3200
Well, to clear something up on this I'll just copy my convo with a Juniper person via email verbatim here- convo - What are the total number of VLANS that can actually exist on a physical port (when configured as trunk)? - What are the total number of RVI's that can be configured on an EX device? 4000 VLANs on a given port (and in a system) and 1000 RVIs. /convo So it's not a VLANs per interface problem, unless you have more than 4k VLANs on the entire system (and you can really only have something like 93 or 94 more than that anyway). Are you seeing anything in your syslog entries? Personally, on my EX's, I'm running JUNOS 10.0S1.1 because it's the recommended release- I looked over the differences in 10.1 and 10.0 and couldn't find anything changed/improved that's relevant to my network. I'd recommend the same for yours. Dan Farrell Applied Innovations Corp. da...@appliedi.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Emil Katzarski Sent: Sunday, May 23, 2010 1:31 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Immediate aging in EX-3200 Hi, There is no link flap. At the same interface I have about 1000 other VLANS and about 5000 other MAC's and they don't flap. The problem affects only a one or a few MAC's at a time. I should double check for a bridging loop but I don't believe there is one. I use Junos 10.1R1 Regards: Emil On Sat, May 22, 2010 at 5:25 PM, Chuck Anderson c...@wpi.edu wrote: On Fri, May 21, 2010 at 06:13:42PM +0300, Emil Katzarski wrote: I have a switch EX3200-48T with quite simple L2 config. Once in a while I can see some MAC addresses learned on the correct interface and VLAN, but then (less than a second later) the MAC is deleted. I can also see the Immediate aging counter increasing. Are you seeing link flaps or port errors? Is it possible there is a bridging loop? What JUNOS version are you running? ___ 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 5139 (20100523) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5140 (20100524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5140 (20100524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junoscriptorium patches?
I'm sorry but I'm on the 'downloads' tab on the junoscriptorium page and don't see any scripts (or anything). What clue am I woefully missing here? Thanks, Dan Farrell Applied Innovations Corp. da...@appliedi.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Wednesday, May 12, 2010 9:49 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Junoscriptorium patches? Speaking of this, I wrote an XSLT library for binary functions, and then an IP library on top of that uses the binary library to do fun stuff like adding a decimal number to an IP address... to help automate provisioning. Anyone interested in this? How could I contribute to junoscriptorium? From: Tima Maryin t...@transtelecom.net To: Cougar cou...@random.ee Cc: juniper-nsp@puck.nether.net Sent: Wed, May 12, 2010 2:01:32 AM Subject: Re: [j-nsp] Junoscriptorium patches? Bah!... :-/ Thanks! Cougar wrote: What is your JUNOS version? Are you sure you didn't mess up when you copied this script from webpage to file? The best way to copy it is to select view source tab and then copy from there. md5sum dom.slax 372140186b2b865902565ac466fab566 dom.slax ___ 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 5113 (20100513) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5113 (20100513) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
Flash gets a bad rap. I think most people have heard of supposed horror stories or they see the cycle limit and get wary. But I'm wondering... has anyone in this list actually had a personal flash horror story? I don't have one of my own, and I'm swimming in network devices (some quite old) that use them. Dan Farrell Applied Innovations Corp. da...@appliedi.net On Wed, Mar 24, 2010 at 10:45:07PM -0700, Hoogen wrote: I think flash isn't going to be considered... It has a finite erase/write cycles.. yeah but 8200 could have had more storage.. Erm... what do you think it uses currently, a 2GB hard drive? :) -- __ Information from ESET NOD32 Antivirus, version of virus signature database 4974 (20100325) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] completely disable session (flow) in netscreen
Just taking a stab... ... if they are SSG/J boxes, what about loading JUNOS onto them, which is not flow-based? We had the opportunity to do this with a pair of SSG 520M's. It entailed getting a separate flash card from Juniper with the JUNOS image that physically replaced the Netscreen image flashcard in the box. Of course, if this were at all workable for you, it would entail a completely new configuration on your part, with you basically translating your Netscreen functionality into JUNOS. Not sure if that would even be worth it for you, but YMMV. Dan da...@appliedi.net From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] On Behalf Of Michel de Nostredame [d.nos...@gmail.com] Sent: Saturday, March 06, 2010 4:34 AM To: Juniper nsp Subject: [j-nsp] completely disable session (flow) in netscreen Hi, The problem I encountered is that I am doing many route-based tunnels on many NetScreen boxes, and sometimes there will be asymmetric routes over tunnels and physical interfaces. Asymmetric paths in traditional routers / L3-switches will not be a problem, but in NetScreen that will cause session drops and/or traceroute timeouts, in my case. I am wondering if there is any way to *completely* disable the concepts of session (or flow ...) in a NetScreen to make it acts like a router. Thanks in advance. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 upgrade
We use 10.0S1.1 in a heavy production environment (750+ RVI's across 21 downstream switches in a two-stack VC chassis setup) with no issues. knocking on wood 10.1.R.18 is nice, but had nothing we needed in our environment to upgrade to. I would compare 10.0.R2 release notes (what 10.0S1.1 fixed) with 10.1R1.8 before making a decision. It almost sounds like by the previous reply that Juniper feels safer with the S release over the latest R release. That all being said, I thought 10.1R.18 was just 10.0S1.1 with a couple more features (that we didn't need, so we didn't upgrade twice in a week). Am I wrong here? Dan da...@appliedi.net From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] On Behalf Of Michel de Nostredame [d.nos...@gmail.com] Sent: Saturday, March 06, 2010 3:15 PM To: Alexey Kholmov Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX4200 upgrade Hi Alexev, Current version for EX4200 is 10.1R1.8, but per Juniper that 10.0S1.1 is recommended. see https://www.juniper.net/customers/csc/software/junos_software_versions.jsp for more details. Regards, -- Michel~ On Sat, Mar 6, 2010 at 7:55 PM, Alexey Kholmov ale...@twine-networks.com wrote: Hi juniper-nsp, I need to upgrade EX4200. Please advise which version of JUNOS should I use? Thank you in advance! Regards, Alexey Kholmov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper.net website problems?
Works for me. dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, February 25, 2010 9:04 AM To: 'Juniper-Nsp' Subject: [j-nsp] Juniper.net website problems? Hi folks - am I the only person having issues with Juniper's website this morning? Doing a site search and get a We are sorry. the page or service you are trying to access Can login but as soon as I try to access any software I get the same error page.. anyone else having this issue or is it just special to me? ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ Information from ESET NOD32 Antivirus, version of virus signature database 4894 (20100225) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4894 (20100225) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Dot1q trunking between 2 juniper EX3200 switches
I’ve noticed that your email goes out twice. Also, without trying to peruse
your configs (respectfully, I’m not JTAC), are you having a problem? Is
something not working?
Me0 is not mandatory to manage the switch, but it is advised as an OOBM (Out Of
Band Management) channel for management purposes.
As far as your Jumbo Frames, you might want to check the MTU settings on the
connecting devices to these switches as well.
Dan Farrell
da...@appliedi.netmailto:da...@appliedi.net
From: Paul Waller [mailto:waller...@hotmail.com]
Sent: Monday, February 22, 2010 3:42 PM
To: Dan Farrell; juniper-nsp@puck.nether.net
Subject: RE: Dot1q trunking between 2 juniper EX3200 switches
I've only just started managing these switches so I don't know why flow-control
is off mtu not set higher. I'm assuming mtu should be higher to allow some
overhead on the packet. I have noticed that there are quite a few gaint frames
in the network.
Also do I need to use the me0 interface for management of the switch for access
?
For a better view I've attached the configs of both switches.
Regards
Paul
From: da...@appliedi.net
To: waller...@hotmail.com; juniper-nsp@puck.nether.net
Date: Mon, 22 Feb 2010 11:01:20 -0800
Subject: RE: [j-nsp] (no subject)
I think your setup is configured in a workable manner (with the exclusion of
RVI's, but you were referring to strict switching anyway and not L3
termination).
The example from production I'll give uses AE (Aggregated Ethernet links, or
multiple ethernet links bonded together) to form the link between the two
switches, which then pass vlans across the switched path. You could
substitute this for a regular physical interface. As you see, with the
exception of a few choices, our configurations are similar-
=
Switch-a
=
# show interfaces ae0
description nap-r14-pub-1 - vlan 3914 - ge/0/0/46-47;
mtu 9216;
aggregated-ether-options {
link-speed 1g;
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ 3914 3951 2102-2149 hvpubn14 hvclustmgmt2 2150-2320 2321-2349 ];
}
}
}
{master:1}[edit]
=
Switch-b
=
# show interfaces ae0
mtu 9216;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ 3914 3951 2102-2149 hvpubn14 hvclustmgmt2 2150-2320 2321-2349 ];
}
}
}
[edit]
1) establish the unit0 subinterface as a trunk port
2) designate the vlan membership
3) be sure you've done this on both sides.
I noticed in your setup you turned off flow-control. Is there a specific
reason you did that? We run iSCSI sans for hundreds of VPS' and we leave it
on (by default). Also, we run 9216 MTU for better performance on these links.
Dan Farrell
da...@appliedi.net
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Waller
Sent: Monday, February 22, 2010 5:25 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] (no subject)
Hi all,
Sorry but abit of a novice when it comes to layer2 switching and Juniper
switches.
What I think I need to do is trunk between 2 junipers EX3200 switches, int
g0/0/0 connects to the router int g0/0/1 connects to the other juniper. 1
switch will trunk between between the junipers then have a trunk port to
the router. It is only for 2 vlans, voice data. If anyone has a config
snippet on how I do this it would be appreciated.
router switch 1switch 2
My config of switch 1:
interfaces {
ge-0/0/0 {
apply-macro juniper-port-profile {
Desktop;
}
description Wan Router;
mtu 1514;
ether-options {
auto-negotiation;
no-flow-control;
link-mode automatic;
speed {
auto-negotiation;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [VOICE-VLAN DATA-VLAN];
}
}
}
}
ge-0/0/1 {
apply-macro juniper-port-profile {
Desktop;
}
description Connection to Juniper switch EX3200;
mtu 1514;
ether-options {
auto-negotiation;
no-flow-control;
link-mode automatic;
speed {
auto-negotiation;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [VOICE-VLAN DATA-VLAN];
}
}
}
}
Switch 2 trunk config:
-
ge-0/0/0 {
apply-macro juniper-port-profile {
Desktop;
}
description Connection to Juniper switch EX3200;
mtu 1514;
ether-options {
auto-negotiation;
no-flow-control;
link-mode automatic;
speed {
auto-negotiation;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [VOICE-VLAN DATA-VLAN];
}
}
}
}
Regards
Paul
_
Looking for a place to rent, share or buy? Find your next place with ninemsn
Property
http://clk.atdmt.com/NMN/go/157631292/direct/01/
___
juniper-nsp mailing list juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
TBH, I have no clue about the licensing ramifications, only that for the price I paid, I was given the ability to do OSPF, IBGP/EBGP. And it works, with a few kinks (full tables incoming seems to be an issue). Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TCIS List Acct Sent: Friday, February 19, 2010 12:02 AM To: juniper-nsp Subject: [j-nsp] EX series needs a special license for BGP? Hrmm -- from what I've read, it seems the EX series DOES need a license for BGP, but the J-series does not, unless you need the route-reflector functionality. Am I correct or ? Dan Farrell wrote: If I'm not mistaken I got an EX3200-24T for around $3k (give or take) and I have BGP peering on it. Dan Farrell da...@appliedi.net -Original Message- From: TCIS List Acct [mailto:lista...@tulsaconnect.com] Sent: Thursday, February 18, 2010 10:04 AM To: Patrik Olsson Cc: Dan Farrell; juniper-nsp Subject: Re: [j-nsp] J2320 as BGP router But don't you need the advanced feature license to do BGP on the EX3200 series? That license adds thousands to the cost.. --Mike --Mike ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ Information from ESET NOD32 Antivirus, version of virus signature database 4878 (20100218) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4880 (20100219) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
OMG! Jk :). Yeah, that's not a concern of ours at this particular point, with basic carrier failover and some basic route selection we're fine with what it handles. Dan -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Friday, February 19, 2010 12:13 PM To: juniper-nsp@puck.nether.net Cc: Dan Farrell; TCIS List Acct Subject: Re: [j-nsp] EX series needs a special license for BGP? On Friday 19 February 2010 10:52:22 pm Dan Farrell wrote: TBH, I have no clue about the licensing ramifications, only that for the price I paid, I was given the ability to do OSPF, IBGP/EBGP. And it works, with a few kinks (full tables incoming seems to be an issue). As you've probably realized, the platform won't support a full v4 table. Cheers, Mark. __ Information from ESET NOD32 Antivirus, version of virus signature database 4881 (20100219) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J2320 as BGP router
If you didn't need full routes you could go with the EX series for pretty cheap. Dan Farrell Applied Innovations Corp. da...@appliedi.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morten Isaksen Sent: Thursday, February 18, 2010 4:37 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] J2320 as BGP router Hi! I need a BGP router that can handle 2 transits with full routetable and 100-200 Mbit throughput - most of it is VOIP traffic so small packets. I am planning to buy a J2320 with 2 GB RAM. I am not planing to use any other features as BGP and a few access-lists. Can the J2320 handle this? -- Morten Isaksen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ Information from ESET NOD32 Antivirus, version of virus signature database 4876 (20100218) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4876 (20100218) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] maxium number of rvi's on ex series?
Are there any hard limits that anyone knows of? We use the 3200's and 4200's, and on the 4200's we're literally putting on hundreds of rvi's (eventually a couple thousand). Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cacti templates
That leaves out the specific CPU and TEMP counters though, right? I think that cacti link had those included. Dan Farrell -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of keegan.hol...@sungard.com Sent: Monday, February 08, 2010 2:28 PM To: Tomasz Mikołajek Cc: juniper-nsp-boun...@puck.nether.net; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] cacti templates Mem usage and interface stats are all part of the standards based MIB2 counters so you should be able to pool them using the standard templates. I think it says cisco router but it will still work. Be sure to check whether your device uses 32 or 64 bit counters. The EX and MX series will definitely be 64. I don't have much experience with the SRX though. From: Tomasz Mikołajek tmikola...@gmail.com To: matthew zeier mze...@gmail.com Cc: juniper-nsp@puck.nether.net Date: 02/08/2010 02:24 PM Subject: Re: [j-nsp] cacti templates Sent by: juniper-nsp-boun...@puck.nether.net Hello. I am using cacti templates for M10 in my M7i and I get everything working. I don't know if it works with switches, but default template in Cacti is able to collect data from interfaces. 2010/2/8 matthew zeier mze...@gmail.com Looking for cacti templates for a number of new Juniper gear (EX8200,4200, SRX3600 MX240). Mostly interested in trending interface usage and mem/cpu. I found http://forums.cacti.net/viewtopic.php?t=11320highlight=juniperbut not sure how multi-platform that is. ___ 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 4849 (20100208) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4849 (20100208) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 3200 - no arp entries after power failure
Believe it or not, 10.0.r2 is working like a charm for us so far. So far. Dan Farrell -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Malte von dem Hagen Sent: Monday, February 08, 2010 3:57 PM To: Paul Waller Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 3200 - no arp entries after power failure Hi, Am 08.02.10 21:33 schrieb Paul Waller: We have a EX 3200 running JunOS 9.2R2 release. you really should upgrade. 9.2R2 is really old, and early versions of JunOS for EX series contained lots of nasty bugs. 9.6R3 seems quite stable so far... rgds, Malte -- Malte v. dem Hagen Teamleitung Network Engineering Operation Abteilung Technik --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend __ Information from ESET NOD32 Antivirus, version of virus signature database 4849 (20100208) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4849 (20100208) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ex series odd message on ether-options deactivation
We are running into some wonky issues with some servers interfaces linking to
an EX-3200-48. In our troubleshooting, I set an interface (ge-0/0/1) to
hard-set 1G/full-duplex (instead of the default autoneg). That didn't cause any
'issues' per se, but when I attempted to deactivate this section of the
configuration, I got some odd messages, and I ended up having to delete the
options instead of merely deactivating them.
Configuration portion in question-
=
[edit interfaces ge-0/0/1]
da...@nap-r13-san-2# show
description hyperv12-san-2-2;
ether-options {
no-auto-negotiation;
link-mode full-duplex;
speed {
1g;
}
}
The command-
da...@nap-r13-san-2# deactivate ether-options
The error-
da...@nap-r13-san-2# commit check
error: could not add object to patricia tree
error: failed to add object created in interface-range
error: copy of interface-range hierarchy failed
error: interface-ranges expansion failed
[edit]
Like I said, when I deleted this section everything was fine- but has anyone
else run into this? Figured I'd ask here prior to opening a ticket with JTAC.
Thanks,
Dan Farrell
Director of Network Operations
Applied Innovations Corp.
da...@appliedi.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] tagged traffic on EX access port
Hey Guys, In reading the EX-series Software Guide for JUNOS10, it states the following limitations for tagged traffic- Creating tagged VLANs in a series has the following limitations: - Layer 3 interfaces do not support this feature. - Because an access interface can only support one VLAN member, access interfaces also do not support this feature. - Voice over IP (VoIP) configurations do not support a range of tagged VLANs. It's the second stipulation that I have a problem with- we have a server with VPS's hosted that are all currently using the same VLANID- but on the server (win2k8-dc) since there is only a single vlan defined on the port, it remains as access, not trunk. We can fake out the Juniper (EX3200-48T running [10.0R2.10]) by creating an additional vlan on the server nic for another VPS, but that wastes resources and/or makes the configuration a little more wonky. I messed with vlan-tagging on the physical interface, and it apparently will not play with 'family ethernet-switching' on the unit 0 of the interface, and demands that unit 0 take a vlan-id of 0 (not the vlan-id of the VPS'). It looks like most of that functionality is put together for tunneling (not for our operations). Anyway, if you have run into this and found a workaround in the switch itself, any guidance would be appreciated. Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net __ Information from ESET NOD32 Antivirus, version of virus signature database 4712 (20091223) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] prefix-limit effectiveness
A follow up from months ago- despite the fact that I was rejecting all of the
routes from my upstream peer on this router, and limiting the total to 5000, it
was still crowding out memory, and not all of the routes from OSPF neighbors
were making it into the routing table. Even though these routes were 'hidden'
they were still taking up space (which is to be expected.)
The keep none command in this particular peer configuration is what did the
trick- it actually removes the routes, not just positing them as 'hidden' which
then cleared up space in the router, and all of my OSPF routes finally had room
to populate within the 5000 prefix limit.
Just thought I'd drop this nugget here in case anyone runs into the same issue.
Thanks,
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell
Sent: Monday, February 09, 2009 11:33 AM
To: Richard A Steenbergen
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] prefix-limit effectiveness
Thanks for the information... I will let you know how it goes (though it seems
you already know hehehe, since this was your baby.)
Thanks,
Dan
-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
Sent: Thursday, February 05, 2009 7:04 PM
To: Dan Farrell
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] prefix-limit effectiveness
On Thu, Feb 05, 2009 at 02:05:14PM -0800, Dan Farrell wrote:
Then I limit the number of prefixes it will even look at to 5000 -
import default-route;
family inet {
unicast {
prefix-limit {
maximum 5000;
...
This is effective- I have only the default to use from my upstream.
But I keep generating tons of log messages because I keep getting (and
rejecting) tons of routes. Without asking the upstream to not
advertise the full route table, is there something I can do on my end
to limit the syslog messages I keep getting?
Feb 5 19:00:43 nap-r2-edge-2 rpd[82464]: RPD_RT_PREFIX_LIMIT_REACHED:
Number of prefixes (4000) in table inet.0 still exceeds or equals configured
maximum (4000)
Well technically speaking you can always filter by regexp anything that
you send to system, but what you really want is accepted-prefix-limit
instead of prefix-limit above.
Prefix-limit is applied to all routes received by the router, even if
they are rejected by your import policy. Basically this protects router
DRAM from something going wild and sending you a billion routes, but is
less useful as a policy protection, or in your case to limit the number
of routes being installed to FIB.
Accepted-prefix-limit is a relatively new feature added in 9.2 (and
pardon me while I do a little dance about it, but this is one of my
feature requests which I've been asking for for 6 years and it just
finally got implemented! :P) which limits the number of routes AFTER
your import policy has been applied. In the example above, even though
you are receiving a full table, you are rejecting all but 1 route in
policy, so the value that would be evaluated yb accepted-prefix-limit is
1.
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Trunking routed vlan interfaces on a Juniper mx960
This is how I do it... if this is not a recommended method, please let me know
(PLEASE!) I currently configure around 90 L3 interfaces in this manner right
now.
interfaces {
ge-0/0/20 {
description physical port;
unit 0 {
family ethernet-switching {
port-mode trunk;
native-vlan-id 3007;
}
}
}
vlan {
unit 98 {
description prov - vlan 98 - 8.0.0.0/30 - pri-switch -
fa0/3;
family inet {
address 8.0.0.1/30;
}
}
unit 4070 {
description psc - vlan 4070 - 10.254.0.128/26;
family inet {
address 10.254.0.129/26;
}
}
}
vlans {
prov {
description prov - vlan 98 - 8.0.0.0/30 - pri-switch - fa0/3;
vlan-id 98;
interface {
ge-0/0/20.0;
ge-0/0/1.0;
}
l3-interface vlan.98;
}
psc {
description psc - vlan 4070 - 10.254.0.128/26;
vlan-id 4070;
interface {
ge-0/0/20.0;
}
l3-interface vlan.4070;
}
Thanks,
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ??
Sent: Friday, August 21, 2009 1:34 PM
To: Michael Phung
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Trunking routed vlan interfaces on a Juniper mx960
interfaces {
ge-0/0/0 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 10;
}
}
}
ge-0/0/1 {
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 1-4000;
}
}
}
irb {
unit 10 {
family inet {
address 10.0.0.3/29
}
}
}
}
}
}
}
bridge-domains {
vlan10 {
vlan-id 10;
routing-interface irb.10;
}
}
On Sat, Aug 22, 2009 at 12:23 AM, Michael Phung cyto...@gmail.com wrote:
Hello everyone,
I just got my hands on a Juniper mx router and I'm starting the
initial config in preparation to convert from Cisco. As I configure
the interfaces, I can't seem to figure our how to create a routed vlan
interface and have the ability to trunk it down multiple physical
interfaces. I've looked up on the the web but was unable to find
anything that direct describes what I'm trying to achieve.
Below is a sample config from a Cisco;
!
spanning-tree mode pvst
spanning-tree vlan 200 priority 8192
!
interface GigabitEthernet2/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200
switchport mode trunk
switchport nonegotiate
!
interface GigabitEthernet2/10
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200
switchport mode trunk
switchport nonegotiate
!
interface Vlan200
ip address 10.10.10.2 255.255.255.192
no ip redirects
no ip unreachables
no ip proxy-arp
standby ip 10.10.10.1
!
Can this be done on a MX router? if so, can a sample config be provided?
Any help would be much appreciated.
Michael
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
BR!
James Chen
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] monitor interface rate
Cacti has plugins written by the community- one of them is known as 'thold' or
'threshold'. When installed in the cacti application, it can be set to monitor
and alert when a low or high threshold on a counter is met. This can be done on
anything cacti is monitoring (CPU, interface throughput, errors, etc.)
The alerting is done via email or syslog, and you can set alerting for
recoveries.
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of harbor235
Sent: Thursday, August 13, 2009 9:31 AM
To: Bit Gossip
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] monitor interface rate
Do you know ho wit does it? I am using HP OpenView, cannot change that. ;{
mike
On Thu, Aug 13, 2009 at 9:26 AM, Bit Gossip bit.gos...@chello.nl wrote:
cacti (http://cacti.net/) does it out-of-the box...
On Thu, 2009-08-13 at 09:06 -0400, harbor235 wrote:
To all,
I would like to monitor a juniper router interface via snmp, simple
enough.
However, I do not want bps, I want to monitor the interface as a
percentage
of it's total capacity. In the end I want to be notified if my interface
exceeds 70%
of capacity so I can initiate capacity management planning.
I know I can on an interface by interface basis figure out 70% and
program
that into
each interface collection, however, that does not scale. Is there anyone
out
there
that knows of a MIB obect that does this?
thanx,
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
[j-nsp] EX series VLAN filter verification
I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series VLAN filter verification
That seems to be applicable to interfaces, not to vlans themselves. It did not return information on the filter I've applied to a vlan itself. Maybe I'm confusing something. Dan -Original Message- From: Harry Reynolds [mailto:ha...@juniper.net] Sent: Tuesday, August 11, 2009 2:46 PM To: Dan Farrell; juniper-nsp@puck.nether.net Subject: RE: EX series VLAN filter verification Does show interfaces filters help? Regards -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell Sent: Tuesday, August 11, 2009 11:25 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX series VLAN filter verification I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Add vlan to multiple interfaces on EX series
I'm not sure that this is always a good idea, anyway. Let's say you reach a point where you want to prune your interface membership... you just want, let's say, to remove one interface from the range. Would that action of deleting the line and re-submitting it without the interface you want remove reset the membership of the others? It's not unreasonable to think that action would take place. IMHO in these instances I've always just dealt with it and added each one by hand, knowing I can prune any of the individually in the future with no possible effect on the remaining interfaces. Also, the worst it's going to get would be 42 interfaces... Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Matt Stevens Sent: Thursday, July 02, 2009 9:19 PM To: Matt Stevens; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Add vlan to multiple interfaces on EX series Sigh...from everyone's answers it appears the short answer to this question is no. I guess I'll take this up with my account team. Thanks everyone! -- matt On 7/2/09 12:25 PM, Matt Stevens m...@elevate.org wrote: Is there an easy way to add a new VLAN to multiple interfaces on the EX series switches? I'd like to be able to use a port range for both adding vlans to trunk ports and putting access ports into a specific vlan. Both seem to only allow actions to be performed on a single port at a time. ___ 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] 13 Tips for Passing Juniper Lab Tests
It seems as though you are criticizing someone by doing exactly what you accuse them of. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Calkins Sent: Monday, June 29, 2009 4:45 PM To: Richard A Steenbergen Cc: Juniper Puck Subject: Re: [j-nsp] 13 Tips for Passing Juniper Lab Tests DUUUDE Really? flame a guy for trying to be helpful. At least we don't need a comprehensive test for being an asshole. On Mon, Jun 29, 2009 at 2:22 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Mon, Jun 29, 2009 at 01:14:52PM -0600, Chris Grundemann wrote: New blog post that folks on this list might find interesting / worth reading: http://bit.ly/43A7K (13 Tips for Passing Juniper Lab Tests) ~Chris Dude, really? Study a lot, read the question thoroughly, manage your time carefully? What kind of pussy advice is this? :) I think you forgot eat a balanced breakfast and sharpen your #2 pencil. :) Only like 20% of the book it actually on the exam, the only thing studying left me with was a hurt liver from all the drinking it took to get that QoS crap out of my head afterwards. Seriously though, your best advice is item #1, have some experience. If you're new to this but you think you want to be a JNCIE, you will be infinitely better served by getting a job at a company with a decent network than you will be by putting 1000 olives in your basement and memorizing the handful of artificial scenerios that they were able to squeeze into an 8 hour lab. And probably have a lot more money at the end of the day too. I once had a quad CCIE customer who intentionally configured his router to leak a full table from their other transit provider to me, because (and I really wish I was joking here) why does it matter, your prefix-list will catch it anyways. Alas they haven't figured out a comprehensive way to test for stupid yet. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] prefix-limit effectiveness
Thanks for the information... I will let you know how it goes (though it seems
you already know hehehe, since this was your baby.)
Thanks,
Dan
-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
Sent: Thursday, February 05, 2009 7:04 PM
To: Dan Farrell
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] prefix-limit effectiveness
On Thu, Feb 05, 2009 at 02:05:14PM -0800, Dan Farrell wrote:
Then I limit the number of prefixes it will even look at to 5000 -
import default-route;
family inet {
unicast {
prefix-limit {
maximum 5000;
...
This is effective- I have only the default to use from my upstream.
But I keep generating tons of log messages because I keep getting (and
rejecting) tons of routes. Without asking the upstream to not
advertise the full route table, is there something I can do on my end
to limit the syslog messages I keep getting?
Feb 5 19:00:43 nap-r2-edge-2 rpd[82464]: RPD_RT_PREFIX_LIMIT_REACHED:
Number of prefixes (4000) in table inet.0 still exceeds or equals configured
maximum (4000)
Well technically speaking you can always filter by regexp anything that
you send to system, but what you really want is accepted-prefix-limit
instead of prefix-limit above.
Prefix-limit is applied to all routes received by the router, even if
they are rejected by your import policy. Basically this protects router
DRAM from something going wild and sending you a billion routes, but is
less useful as a policy protection, or in your case to limit the number
of routes being installed to FIB.
Accepted-prefix-limit is a relatively new feature added in 9.2 (and
pardon me while I do a little dance about it, but this is one of my
feature requests which I've been asking for for 6 years and it just
finally got implemented! :P) which limits the number of routes AFTER
your import policy has been applied. In the example above, even though
you are receiving a full table, you are rejecting all but 1 route in
policy, so the value that would be evaluated yb accepted-prefix-limit is
1.
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3831 (20090205) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3838 (20090209) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] prefix-limit effectiveness
I have asked for full and the default from an upstream I have connected to an
EX3200. For now I'm just wanting to use the default route-
import default-route;
policy-statement default-route {
term default {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term reject-rest {
then reject;
}
}
Then I limit the number of prefixes it will even look at to 5000 -
import default-route;
family inet {
unicast {
prefix-limit {
maximum 5000;
}
}
any {
prefix-limit {
maximum 5000;
}
}
}
This is effective- I have only the default to use from my upstream. But I keep
generating tons of log messages because I keep getting (and rejecting) tons of
routes. Without asking the upstream to not advertise the full route table, is
there something I can do on my end to limit the syslog messages I keep getting?
Feb 5 19:00:43 nap-r2-edge-2 rpd[82464]: RPD_RT_PREFIX_LIMIT_REACHED: Number
of prefixes (4000) in table inet.0 still exceeds or equals configured maximum
(4000)
Feb 5 19:02:43 nap-r2-edge-2 last message repeated 4 times
Feb 5 19:11:13 nap-r2-edge-2 last message repeated 17 times
Feb 5 19:11:43 nap-r2-edge-2 rpd[82464]: RPD_RT_PREFIX_LIMIT_BELOW: Number of
prefixes (3999) in table inet.0 is now less than the configured maximum (4000)
Thanks,
Dan Farrell
Applied Innovations Corp.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] The Switch is ON !!!
I wonder if that's because they're not trying to make an 'everything' package on their first stab in the marketplace. It sounds like they submitted a decent first attempt at the switching space and will wait to see what shakes out, and what people will say (as per your suggestion) what works and doesn't work for them. I'm not saying XFP won't enter the product line, but perhaps it will only be in some of the later versions of their products and not others. I think it wouldn't be the wisest move for them to have the feature-killer switch on their first attempt (with things like 1mil routes, full MPLS/VPLS, metro features, XFP, etc.), but instead see where the market takes what appears to be a decent (if not imperfect) product. I guess that's why the POE feature set kind of confused me- it strikes me as a significant feature to add with limited use in a datacenter. Personally, I'm excited. Already I view the low-end 3200 in many spaces of our network, as both switch and router (despite the 12k limitation- I don't think we have more than 1k OSPF routes right now anyway.) And the best part is that (given its performance) I can now suggest to management that we can go with one vendor for most of the network- before this we were resigned with Juniper for routing, Cisco (or someone else) for switching- now we can look at Juniper throughout the path. Wow does that make life easier for me. danno -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard A Steenbergen Sent: Wednesday, January 30, 2008 5:10 PM To: bill fumerola Cc: Juniper-NSP Mailing list Subject: Re: [j-nsp] The Switch is ON !!! On Wed, Jan 30, 2008 at 12:09:07PM -0800, bill fumerola wrote: so i agree with everything RAS said. per usual. :) Woo. :) BTW, I'd like to point out one additional item which is publicly available information but which generally seems to have been overlooked so far. If you take a close look at the coming not-very-soon EX8200 on page 6: http://www.juniper.net/solutions/literature/brochures/150057.pdf You'll notice 8 distinct 10G ports per blade. At first glance one might be tempted to believe they are XFP ports, but those are SFP+ ports. Why is this a problem? Because SFP+ achieve their density not by significantly reducing power draw, but by eliminating the higher end power classes which are necessary to drive medium and long reach optics (40km ER, 80km ZR, any DWDM tuned optics, etc). There is a thread on exactly why this sucks so bad over on cisco-nsp, but the bottom line is that if you have an SFP+ product you will NEVER be able to do long reach optics (let alone at the very reasonable prices or 40-channel DWDM frequencies available in commodity XFP today). I'm personally baffled by Juniper's decision here, it's not like they even need SFP+ to achieve the density required. On the Cisco Nexus 32-port 10G SFP+ blade (which also does FC), or the 48-port 10G SFP+ 1U Arastra box, there is a legitmate excuse for using SFP+ at the expense of long reach optics, but on the Juniper 8-port full-sized blade there is absolutely no reason Juniper should not be using XFP here. I would encourage anyone who is interested in this product and who might ever want to use long-reach optics in it to talk to their account team about XFP instead of SFP+ blades NOW before this horribly bad idea progresses any further. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] The Switch is ON !!!
Actually he can speak for us on this one, too. I asked my cohort here what devices we had in our datacenters that would need POE... you know what I heard? ... cricket... I told a vendor rep recently that there is no way we would ever buy POE switches for our hosting work... and now he's smiling because he knows I like the sound of Juniper switching. Getting ready to eat my words... dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Van Tol Sent: Tuesday, January 29, 2008 1:18 PM To: Rolf Mendelsohn; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] The Switch is ON !!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rolf Mendelsohn Sent: Tuesday, January 29, 2008 11:02 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] The Switch is ON !!! Hi Guys, Why do they have POE on all models, surely nobody in SP environment wants that? cheers /rolf Speak for yourself! There are plenty of reasons why an SP would want PoE, as there are no shortage of devices in an ISP network that might require it. WAPs, Ethernet demarcation devices, media converters, etc. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bgp path
As a newcomer to JUNOS I'm stumbling a little on the policy
configurations (in particular for prepending.) This really seems to
spell it out better than the Juniper reference.
One question- The 'then accept;' statement after term 2 ... is it
necessary? If so, what is it doing that wouldn't happen if it was gone?
Thanks,
danno
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Umar Ahmed
Sent: Thursday, January 03, 2008 10:06 AM
To: Erol KAHRAMAN; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] bgp path
An example :
policy-statement prepend {
term 1 {
from protocol aggregate;
then {
as-path-prepend 1234 1234 1234;
accept;
}
}
term 2 {
then reject;
}
then accept;
}
In this case im matching an aggregate route, then apply this policy
outbound on your peer :
bgp {
log-updown;
group Peer-1 {
type external;
export prepend;
neighbor x.x.x.x
peer-as 123456;
}
}
Any questions, give me a shout.
regards,
Umar Ahmed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Erol KAHRAMAN
Sent: 03 January 2008 13:41
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] bgp path
Hi guys,
How can i show one path more far with bgp. I need to repead my AS in my
advertisement for this.
--
Erol KAHRAMAN
System Network Administrator
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
**
Any opinions expressed in the e-mail are those of the individual and not
necessarily the company. This e-mail and any files transmitted with it
are confidential and solely for the use of the intended recipient. If
you are not the intended recipient or the person responsible for
delivering it to the intended recipient, be advised that you have
received this e-mail in error and that any dissemination, distribution,
copying or use is strictly prohibited.
If you have received this e-mail in error, or if you are concerned with
the content of this e-mail please e-mail to:
[EMAIL PROTECTED]
The contents of an attachment to this e-mail may contain software
viruses which could damage your own computer system. Whilst the sender
has taken every reasonable precaution to minimise this risk, we can not
accept liability for any damage which you sustain as a result of
software viruses. You should carry out your own virus checks before
opening this e-mail or any attachments to this e-mail.
This e-mail was sent from Vanco UK Limited a company registered in
England under number 2296733 and whose registered office is Units 12,
Great West Plaza, Riverbank Way, Brentford, TW8 9RE, UK
Please consider the environment before printing this e-mail.
**
___
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] bringing m7i FIC online
In trying to get a connection to work on my Gigabit FIC interface, I noticed that it appears (if I'm reading the output correctly) that the interface is offline- [EMAIL PROTECTED] show chassis fpc pic-status Slot 0 Online E-FPC PIC 0 Online 4x 1GE(LAN), IQ2 Slot 1 Online E-FPC PIC 2 Online ASP - Integrated (Layer-2-3) PIC 3 Offline I believe PIC 3 is the FIC interface itself. I think I had seen it labeled as ge-1/3/0 quite awhile ago but that doesn't appear in a show interfaces terse anymore, and I think that's because it's currently offline. So how does one bring the FIC 'online'? I checked the documentation, and googled, and came up empty. Thanks for any insight, Dan Farrell Applied Innovations Corp. [EMAIL PROTECTED] ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bringing m7i FIC online
I would like to thank a bunch of people that replied to me within minutes of me sending this question in- The proper command (from them, and it worked) is- request chassis pic online fpc-slot 1 pic-slot 3 The system will (or at least should) then prompt you to run the following command- show chassis fpc pic-status 1 Which should show the PIC online. And when I then do a show interfaces terse the ge-1/3/0 interface now appears. Thanks again guys! danno -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Farrell Sent: Monday, December 17, 2007 11:37 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] bringing m7i FIC online In trying to get a connection to work on my Gigabit FIC interface, I noticed that it appears (if I'm reading the output correctly) that the interface is offline- [EMAIL PROTECTED] show chassis fpc pic-status Slot 0 Online E-FPC PIC 0 Online 4x 1GE(LAN), IQ2 Slot 1 Online E-FPC PIC 2 Online ASP - Integrated (Layer-2-3) PIC 3 Offline I believe PIC 3 is the FIC interface itself. I think I had seen it labeled as ge-1/3/0 quite awhile ago but that doesn't appear in a show interfaces terse anymore, and I think that's because it's currently offline. So how does one bring the FIC 'online'? I checked the documentation, and googled, and came up empty. Thanks for any insight, Dan Farrell Applied Innovations Corp. [EMAIL PROTECTED] ___ 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] System board memory expansion on M7i
You're not incorrect that they can be ordered with that much RAM, however... any sales rep that didn't put you onto the new RE-850-1536-BB (the 850Mhz CPU with 1536 MB RAM) for the same price as the old 400 mhz RE isn't doing his/her job. I say this because we just got our new M7i with those very specs 5 days ago. Our sales rep originally had us on the 400 Mhz RE, and then zero-cost upgraded the quote to the 850 Mhz RE and we took it. Also, if you are looking into the M7i, you can get the Firewall ASM included/integrated on the FE, but if you order it later, you have to order it as a separate PIC, and it will cost more. danno -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Thursday, November 01, 2007 11:27 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] System board memory expansion on M7i Hi. M7i routers can be ordered with 256 or 512 MB RAM system board memory; any guidelines on what usage scenarios would make 512MB desirable or even mandatory ? Our need is a Internet router with 3 full-routing transit feeds and a bunch of peering connections that made us specify more memory for the routing engine, but that may or may not impact forwarding engine requirements. AS and J-Flow are already included in the RFP. Rubens ___ 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] Duplex settings for FastE ports
Hi,
Can you explain how you were able to actually set your GE interface to
100Mbps? Is it only specific GE interfaces that allow 100Mbps settings?
I ask because we just got an M7i, and it is not possible to duplicate
the configuration you have below with our own ge-0/0/0.
Thanks,
danno
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sabri Berisha
Sent: Friday, October 12, 2007 5:24 AM
To: Kanagaraj Krishna
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Duplex settings for FastE ports
Hi,
/[EMAIL PROTECTED] show configuration interfaces fe-0/2/0
description ;
speed 100m;
link-mode full-duplex;
unit 0 {
family inet {
address xxx.xxx.xxx.xxx/30;
}
}
[EMAIL PROTECTED] show interfaces fe-0/2/0 media
Autonegotiation information:
Negotiation status: Incomplete
When you manually configure speed and duplex-mode on an FE-PIC,
auto-negotiation is automatically disabled. You will have to make sure
the other end is not trying auto-negotiation as well otherwise it will
revert back to half-duplex en you end up with a broken link.
On a side note: on a GE-PIC this behaviour is different:
auto-negotiation is not automatically disabled and you need to
explicitly configure this under gigether-options:
ge-0/0/3 {
description cool link;
speed 100m;
link-mode full-duplex;
gigether-options
{
no-auto-negotiation;
}
unit 0 {
family inet {
address 192.168.1.1/30;
}
}
}
Thanks,
--
Sabri
___
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
