Re: [j-nsp] JNCIP EBGP Case Study...
Hoogen, Okay.. Earlier task required while accepting routes from peer to tag them with a community and prepend them with as number 65412 twice... I notice that when I deactivate that.. It works.. So obviously R3 is considering the routes received from R1 with prepend of 65412 for all P1 routes to be some sort of as loop... So I guess there is something wrong about it.. Page 568 of the JNCIP books... I guess for the solution to work we need to have autonomous-system 65001 loops 3; This would make sure we get those routes. it would, but I don't remember having to set as-loops when I worked through the JNCIP book. And I double-checked your initial email to find you might have a typo: l...@r1# run show route advertising-protocol bgp 10.0.3.3 inet.0: 65 destinations, 69 routes (63 active, 0 holddown, 4 hidden) Prefix Nexthop MED LclprefAS path * 3.4.0.0/20 10.0.5.254 10065412 65412 1492 I You prepend 65412 65412, where it should be 64512 64512 There's also a typo in at least r1 r3 configs: confederation 65412 members [ 65000 65001 65002 ]; your problems may be coming from those typos - if you consistently mistyped 64512 through your whole setup, it's probably ok, but I'd double-check all routers. Note that stuff like this will mess you up badly in the actual lab - double-check every number you type, it saves time in the long run :) Kind regards, Felix -- Felix Schüren Head of Network --- 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Restrictions in 802.3ad Links (Multicast)
Hello, can someone provide any information about restrictions (especially for multicast) on IEEE 802.3ad (Aggregated Ethernet) links in JunOS? We are currently using JunOS 8.5 in our lab-setup. - Can we use multicast on this AE links without any restrictions? - Is the load-balancing-behaviour on the different links in the bundle working for multicast traffic or is the bandwidth for multicast traffic limited to the bandwith of one link of the bundle (as an example we have an 5GE aggregated link with five 1GE links). We are looking forward to your information. Kind regards, Hendrik ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIP EBGP Case Study...
Hi Hoogen !
I see that there is a requirement as prepend them with as number 64512 twice
not 65412 twice
Because if prepend 65412 as we also have to enable as loop 3
From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net]
On Behalf Of juniper-nsp-requ...@puck.nether.net
[juniper-nsp-requ...@puck.nether.net]
Sent: Friday, October 30, 2009 2:42 PM
To: juniper-nsp@puck.nether.net
Subject: juniper-nsp Digest, Vol 83, Issue 54
Send juniper-nsp mailing list submissions to
juniper-nsp@puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
juniper-nsp-requ...@puck.nether.net
You can reach the person managing the list at
juniper-nsp-ow...@puck.nether.net
When replying, please edit your Subject line so it is more specific
than Re: Contents of juniper-nsp digest...
Today's Topics:
1. Re: death by branding (Adam Rothschild)
2. Re: JNCIP EBGP Case Study... (Hoogen)
3. Re: JNCIP EBGP Case Study... (Hoogen)
4. Re: death by branding (Ben Dale)
5. Re: JNCIP EBGP Case Study... (Felix Schueren)
--
Message: 1
Date: Thu, 29 Oct 2009 16:21:00 -0400
From: Adam Rothschild a...@latency.net
To: Richard A Steenbergen r...@e-gerbil.net
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] death by branding
Message-ID: 20091029202100.ga49...@latency.net
Content-Type: text/plain; charset=us-ascii
On 2009-10-29-14:58:32, Richard A Steenbergen r...@e-gerbil.net wrote:
http://www.e-gerbil.net/juniper_style_guide.pdf
This appears to return a forbidden.
-a
--
Message: 2
Date: Thu, 29 Oct 2009 14:56:29 -0700
From: Hoogen hooge...@gmail.com
To: Sean Clarke s...@clarke-3.demon.nl
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JNCIP EBGP Case Study...
Message-ID:
dffd2e730910291456m5bc70efap149362e8fd46c...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Okay.. Earlier task required while accepting routes from peer to tag them
with a community and prepend them with as number 65412 twice... I notice
that when I deactivate that.. It works.. So obviously R3 is considering the
routes received from R1 with prepend of 65412 for all P1 routes to be some
sort of as loop... So I guess there is something wrong about it..
Page 568 of the JNCIP books...
-Hoogen
On Thu, Oct 29, 2009 at 2:05 PM, Hoogen hooge...@gmail.com wrote:
R1
l...@r1 show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.10.0/24 reject;
route 192.168.100.0/24 reject;
route 10.0.0.0/8 {
next-hop 10.0.4.13;
qualified-next-hop 10.0.4.6 {
preference 10;
}
}
}
martians {
192.0.2.0/24 orlonger;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r1
l...@r1 show configuration protocols bgp
group 65000 {
type internal;
local-address 10.0.6.1;
export ibgp;
neighbor 10.0.3.3;
}
group p1 {
type external;
import peer-filter-in;
export p1-export;
neighbor 10.0.5.254 {
peer-as 1492;
}
}
l...@r1
l...@r1 show configuration policy-options policy-statement ibgp
term 1 {
from {
protocol static;
route-filter 192.168.10.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol static;
route-filter 192.168.100.0/24 exact;
}
then {
metric 101;
local-preference 101;
community add no-export;
accept;
}
}
l...@r1
R3 Configuration
l...@r3 show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.30.0/24 reject;
}
martians {
192.0.2.0/24 orlonger;
}
aggregate {
route 10.0.4.0/22;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r3
l...@r3 show configuration protocols bgp
advertise-inactive;
group 65000 {
type internal;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.6.1;
}
group c-bgp {
type external;
multihop;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.3.4 {
hold-time 180;
peer-as 65001;
}
neighbor 10.0.3.5 {
peer-as 65002;
}
}
group t1-t2 {
type external;
damping;
import [ damp trans-filter-in ];
export [ no-192-24s prepend ];
remove-private;
multipath;
neighbor 172.16.0.14 {
peer-as 65222;
}
neighbor 172.16.0.18 {
peer-as 65222;
}
}
l...@r3
l...@r3 show configuration policy-options policy-statement ibgp
term 1 {
from {
Re: [j-nsp] death by branding
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Richard A Steenbergen Sent: Thursday, October 29, 2009 4:21 PM To: Doug McPherson Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] death by branding On Thu, Oct 29, 2009 at 04:15:23PM -0400, Doug McPherson wrote: On Thu, Oct 29, 2009 at 2:58 PM, Richard A Steenbergen r...@e- gerbil.net wrote: http://www.e-gerbil.net/juniper_style_guide.pdf ? Possibe file protection problem on: http://www.e-gerbil.net/juniper_style_guide.pdf Sorry Juniper made me take it down. It seems that the new style guide isn't for public distribution, despite it saying absolutely nothing about being confidential or restricted in any way, and the fact that most every public company I know of publishes their logo usage guides publicly (including, if I'm not mistaken, the old Juniper logo). Basically it was a pretty standard guide for how not to misuse their new logo, specifically their burst element. You know the usual stuff, do not put the burst too close to the other text, do not crop too much of the burst, do not reposition the burst, do not alter the scale of the burst, do not alter the color of the burst. Apparently they also meant to include do not taunt the happy fun burst. :) ^^ - LOL Is it me or does Juniper's new favicon that shows up in the address bar look more like a Georgia O'Keefe painting than a cute little sunburst? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L3VPN on J series enhance services
can L3VPN run on J series enhance services? I 've configured by follow below
but never can reach by ping in routing instance l3vpn.
I can't put the interface by member of vrf onto security zone trust
interface .
interfaces {
ge-0/0/0 {
vlan-tagging;
unit 0 {
vlan-id 2;
family inet {
address 192.168.10.1/24;
}
}
unit 10 {
vlan-id 10;
family inet {
address 20.20.20.1/24;
}
}
unit 20 {
vlan-id 20;
family inet {
address 40.40.40.1/24;
}
}
}
ls-0/0/0 {
unit 1 {
family inet {
address 192.168.1.2/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.0.10/24;
}
}
}
ge-0/0/2 {
unit 0;
}
e1-4/0/0 {
clocking external;
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
e1-4/0/1 {
clocking external;
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.2/32;
}
}
}
vlan {
unit 10 {
family inet {
address 10.10.10.250/24;
}
}
}
}
routing-options {
autonomous-system 65000;
}
protocols {
mpls {
interface ls-0/0/0.1;
}
bgp {
group intern {
type internal;
local-address 1.1.1.2;
family inet-vpn {
unicast;
}
neighbor 1.1.1.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface ls-0/0/0.1;
}
}
ldp {
interface ls-0/0/0.1;
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000; ## Warning: 'queue-size' is deprecated
timeout 20;
}
land;
}
}
}
zones {
security-zone trust {
tcp-rst;
interfaces {
ls-0/0/0.1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/0.10 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/0.20 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/2.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
lo0.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
security-zone untrust {
screen untrust-screen;
}
}
policies {
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
Re: [j-nsp] Generating events based on day of week
If you are interested in a supported approach then take a look at the
day-event.slax event script that was just added to Junoscriptorium:
http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/event/utility/day-event/day-event.xml
It logs a syslog message every day in the format:
Oct 30 00:00:00 j4350 cscript: Day-Event: Fri Oct 30 00:00
So your event policies can trigger on it like this:
policy friday-policy {
events system;
attributes-match {
system.message matches Day-Event: Fri;
}
then {
...
}
}
It runs at 00:00 by default, but can run at other times if desired, see the
above weblink for details.
BTW, if the need is to do stateless firewall filters that change based on the
day of week then there is already a commit+event script in Junoscriptorium that
do all the heavy lifting for you. With them loaded, all you need to do is add
time-range macros to your filter terms:
term night {
apply-macro active-time-range {
start-time weekdays 17:00;
stop-time weekdays 20:00;
}
...
}
http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/event/filters/time-based-filters/time-based-filters.xml
http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/commit/filters/cs-time-based-filters/cs-time-based-filters.xml
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Network Liberation Movement???
http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network Liberation Movement???
Looks like a poorly thought out advertising campaign to be honest. The important message will be buy our stuff if I had to guess. m On Fri, 30 Oct 2009, Derick Winkworth wrote: http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this 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
Re: [j-nsp] vrrp groups
Until now we've always used a seperate vrrp groupid for each vlan.
But after reading this message I decided to give it a try, since I totally
agree that it adds some complexity.
If I understand the post correct something like this should work:
n...@xx# show
vlan-id 241;
family inet {
filter {
input netflow;
output netflow;
}
address xx/27 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
address yy/28 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
}
However, an error is returned:
edit interfaces ae1 unit 241 family inet address yy]
'vrrp-group 241'
Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and
address:
error: configuration check-out failed
[edit interfaces ae1 unit 241]
We're running JunOS 8.0R2.8 on a M7i.
Any ideas?
Thanks!
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski
Verzonden: dinsdag 29 september 2009 1:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] vrrp groups
On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote:
Note that while you can assign the same group number to multiple ifls
on the same IFD best practice is not to as this can cause some issues
with learning bridges as noted below, each group shares the same v-mac.
I have to say -- this is a recommendation from Juniper that I've never
understood. We've used group 1 exclusively for years (with hundreds of
VLANs per interface in some cases) without issue. Using separate group IDs
seems overly complex and unnecessary. As long as your switches aren't
bleeding VLANs together there's no conceivable harm. (And if they do, having
the same group ID ensures you'll discover the problem quickly. :-)
To clarify for the original poster: there's no *hard limit* which will
prevent you from configuring 300 VRRP groups (with non-unique group IDs) on
one physical interface. (Even though the documentation said otherwise up
until 9.6.) I would expect things to generally be okay with default timers
but I've never tried group counts in the hundreds with anything smaller than
an m40e.
-Terry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
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
Re: [j-nsp] death by branding
On Thu, 29 Oct 2009 15:20:42 -0500 Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Oct 29, 2009 at 04:15:23PM -0400, Doug McPherson wrote: On Thu, Oct 29, 2009 at 2:58 PM, Richard A Steenbergen r...@e-gerbil.net wrote: http://www.e-gerbil.net/juniper_style_guide.pdf ? Possibe file protection problem on: http://www.e-gerbil.net/juniper_style_guide.pdf Sorry Juniper made me take it down. It seems that the new style guide isn't for public distribution, despite it saying absolutely nothing about being confidential or restricted in any way, and the fact that most every public company I know of publishes their logo usage guides publicly (including, if I'm not mistaken, the old Juniper logo). Yes. The old logos, together with the usage guidlines, are still available at http://www.juniper.net/us/en/company/press-center/images/image-library/ The new logo is not there, as far as I can see. d. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network Liberation Movement???
Hi, Am 30.10.2009 15:22 Uhr schrieb Derick Winkworth: http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? 15 days, most likely. Looks like a commercial. rgds, .m signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp groups
Just to verify, the /28 isn't a sub-set of the /27 is it? Junipers tend not to
like setting up multiple netblocks(like a /28 that's inside a
previously-configured /27) within the same interface, especially if you attempt
to set them both using the same virtual-address.
Network Engineer, JNCIS-M
214-981-1954 (office)
214-642-4075 (cell)
jbrash...@hq.speakeasy.net
http://www.speakeasy.net
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Niels Ardts
Sent: Friday, October 30, 2009 10:02 AM
To: 'Terry Baranski'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vrrp groups
Until now we've always used a seperate vrrp groupid for each vlan.
But after reading this message I decided to give it a try, since I totally
agree that it adds some complexity.
If I understand the post correct something like this should work:
n...@xx# show
vlan-id 241;
family inet {
filter {
input netflow;
output netflow;
}
address xx/27 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
address yy/28 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
}
However, an error is returned:
edit interfaces ae1 unit 241 family inet address yy]
'vrrp-group 241'
Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and
address:
error: configuration check-out failed
[edit interfaces ae1 unit 241]
We're running JunOS 8.0R2.8 on a M7i.
Any ideas?
Thanks!
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski
Verzonden: dinsdag 29 september 2009 1:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] vrrp groups
On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote:
Note that while you can assign the same group number to multiple ifls
on the same IFD best practice is not to as this can cause some issues
with learning bridges as noted below, each group shares the same v-mac.
I have to say -- this is a recommendation from Juniper that I've never
understood. We've used group 1 exclusively for years (with hundreds of
VLANs per interface in some cases) without issue. Using separate group IDs
seems overly complex and unnecessary. As long as your switches aren't
bleeding VLANs together there's no conceivable harm. (And if they do, having
the same group ID ensures you'll discover the problem quickly. :-)
To clarify for the original poster: there's no *hard limit* which will
prevent you from configuring 300 VRRP groups (with non-unique group IDs) on
one physical interface. (Even though the documentation said otherwise up
until 9.6.) I would expect things to generally be okay with default timers
but I've never tried group counts in the hundreds with anything smaller than
an m40e.
-Terry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
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
Re: [j-nsp] Generating events based on day of week
On Fri, Oct 30, 2009 at 07:14:41AM -0700, Curtis Call wrote:
BTW, if the need is to do stateless firewall filters that change based on the
day of week then there is already a commit+event script in Junoscriptorium
that do all the heavy lifting for you. With them loaded, all you need to do
is add time-range macros to your filter terms:
term night {
apply-macro active-time-range {
start-time weekdays 17:00;
stop-time weekdays 20:00;
}
...
}
http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/event/filters/time-based-filters/time-based-filters.xml
http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/commit/filters/cs-time-based-filters/cs-time-based-filters.xml
Thanks for weblinks, Curtis.
Yeah, these some hundreds lines of SLAX code add nice functionality to
firewall filters.
Firstly, I don't want to start holy war but... compare it with Cisco IOS:
!
ip access-list extended acl-Night
permit icmp any host 10.0.0.1 time-range Night
[...]
!
time-range Night
periodic weekdays 17:00 to 20:00
!
Comparison does not look in favour of JunOS. Nevertheless, I have nothing
against JunOS scripts, they are really powerful stuff for implementation of
non-typical tasks. But the necessity to use such big scripts for solution of
very trivial tasks looks at least strange for me.
Secondly, my task was to change policer on interface
interfaces:
# show configuration interfaces ge-0/0/0 unit 400 family inet policer
input pol-50Mbit;
output pol-50Mbit;
I've written small op script that changes these policers and
added its invocation via cron daemon at the time that I need:
# Workdays
00 08 * * 1-5 /usr/sbin/cli op change-policer
interface ge-0/0/0 unit 400 policer-in pol-30Mbit policer-out pol-30Mbit
00 20 * * 1-5 /usr/sbin/cli op change-policer
interface ge-0/0/0 unit 400 policer-in pol-50Mbit policer-out pol-50Mbit
And now I do not see any reasons neither to detect day of week or month
by catching system events and analyzing them nor to write hundreds lines
of code.
Thirdly, my first event script that I've written failed to work right away.
It turned out, that it is a PR 436135: a bug in 9.5R1.8 (thank you Curtis
for information on that). Not very good impression. Who can guarantees
that all my big scripts (that do very simple things) will stay able to work
after next JunOS upgrade?
Summing up all thesises: simple problems should have simple solutions.
Matching current date/time in firefall filter or calling some scripts
at desired time/date are not very complicated, are they?
Kind Regards,
--
MINO-RIPE
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp groups
No, it is a different virtual address and also a completely different subnet!
-Oorspronkelijk bericht-
Van: Jonathan Brashear [mailto:jonathan.brash...@hq.speakeasy.net]
Verzonden: vrijdag 30 oktober 2009 17:11
Aan: Niels Ardts; 'Terry Baranski'; juniper-nsp@puck.nether.net
Onderwerp: RE: [j-nsp] vrrp groups
Just to verify, the /28 isn't a sub-set of the /27 is it? Junipers tend not to
like setting up multiple netblocks(like a /28 that's inside a
previously-configured /27) within the same interface, especially if you attempt
to set them both using the same virtual-address.
Network Engineer, JNCIS-M
214-981-1954 (office)
214-642-4075 (cell)
jbrash...@hq.speakeasy.net
http://www.speakeasy.net
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Niels Ardts
Sent: Friday, October 30, 2009 10:02 AM
To: 'Terry Baranski'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vrrp groups
Until now we've always used a seperate vrrp groupid for each vlan.
But after reading this message I decided to give it a try, since I totally
agree that it adds some complexity.
If I understand the post correct something like this should work:
n...@xx# show
vlan-id 241;
family inet {
filter {
input netflow;
output netflow;
}
address xx/27 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
address yy/28 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
}
However, an error is returned:
edit interfaces ae1 unit 241 family inet address yy]
'vrrp-group 241'
Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and
address:
error: configuration check-out failed
[edit interfaces ae1 unit 241]
We're running JunOS 8.0R2.8 on a M7i.
Any ideas?
Thanks!
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski
Verzonden: dinsdag 29 september 2009 1:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] vrrp groups
On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote:
Note that while you can assign the same group number to multiple ifls
on the same IFD best practice is not to as this can cause some issues
with learning bridges as noted below, each group shares the same v-mac.
I have to say -- this is a recommendation from Juniper that I've never
understood. We've used group 1 exclusively for years (with hundreds of
VLANs per interface in some cases) without issue. Using separate group IDs
seems overly complex and unnecessary. As long as your switches aren't
bleeding VLANs together there's no conceivable harm. (And if they do, having
the same group ID ensures you'll discover the problem quickly. :-)
To clarify for the original poster: there's no *hard limit* which will
prevent you from configuring 300 VRRP groups (with non-unique group IDs) on
one physical interface. (Even though the documentation said otherwise up
until 9.6.) I would expect things to generally be okay with default timers
but I've never tried group counts in the hundreds with anything smaller than
an m40e.
-Terry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
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
Re: [j-nsp] vrrp groups
On Fri, Oct 30, 2009 at 11:02AM, Niels Ardts wrote: However, an error is returned: edit interfaces ae1 unit 241 family inet address yy] 'vrrp-group 241' Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and address: error: configuration check-out failed [edit interfaces ae1 unit 241] We're running JunOS 8.0R2.8 on a M7i. Any ideas? You're trying to use a given VRRP group ID twice on the same VLAN/subinterface. I'm not surprised that this doesn't commit -- the VRRP protocol itself probably doesn't support such a configuration. What will work is using the same group ID multiple times on different VLAN/subinterfaces within the same physical interface. -Terry -Oorspronkelijk bericht- Van: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski Verzonden: dinsdag 29 september 2009 1:52 Aan: juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] vrrp groups On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote: Note that while you can assign the same group number to multiple ifls on the same IFD best practice is not to as this can cause some issues with learning bridges as noted below, each group shares the same v-mac. I have to say -- this is a recommendation from Juniper that I've never understood. We've used group 1 exclusively for years (with hundreds of VLANs per interface in some cases) without issue. Using separate group IDs seems overly complex and unnecessary. As long as your switches aren't bleeding VLANs together there's no conceivable harm. (And if they do, having the same group ID ensures you'll discover the problem quickly. :-) To clarify for the original poster: there's no *hard limit* which will prevent you from configuring 300 VRRP groups (with non-unique group IDs) on one physical interface. (Even though the documentation said otherwise up until 9.6.) I would expect things to generally be okay with default timers but I've never tried group counts in the hundreds with anything smaller than an m40e. -Terry ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Tenzij schriftelijk anders is overeengekomen, zijn op al onze rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze zijn middels deze directe link http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk van de hand gewezen. Nederlands recht is exclusief van toepassing. De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan. 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
[j-nsp] Gersham A Johnson/US/DNY is out of the office.
I will be out of the office starting 10/30/2009 and will not return until 11/02/2009. I will respond to your message when I return. If you have an urgent network request,please call the RRD Helpdesk: 1-800-rrd-help ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIP EBGP Case Study...
My Bad typo error...
Thanks to all...
On Fri, Oct 30, 2009 at 12:57 AM, Sean Clarke s...@clarke-3.demon.nlwrote:
Yes that's a solution, or workaround - but why do you want to prepend to
your internal peers ? Surely it only makes sense to prepend out of your
network, and use local preference to your internal peers ?
cheers
Sean
On 10/29/09 11:29 PM, Hoogen wrote:
I guess for the solution to work we need to have
autonomous-system 65001 loops 3;
This would make sure we get those routes.
-Hoogen
On Thu, Oct 29, 2009 at 2:56 PM, Hoogen hooge...@gmail.com wrote:
Okay.. Earlier task required while accepting routes from peer to tag them
with a community and prepend them with as number 65412 twice... I notice
that when I deactivate that.. It works.. So obviously R3 is considering the
routes received from R1 with prepend of 65412 for all P1 routes to be some
sort of as loop... So I guess there is something wrong about it..
Page 568 of the JNCIP books...
-Hoogen
On Thu, Oct 29, 2009 at 2:05 PM, Hoogen hooge...@gmail.com wrote:
R1
l...@r1 show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.10.0/24 reject;
route 192.168.100.0/24 reject;
route 10.0.0.0/8 {
next-hop 10.0.4.13;
qualified-next-hop 10.0.4.6 {
preference 10;
}
}
}
martians {
192.0.2.0/24 orlonger;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r1
l...@r1 show configuration protocols bgp
group 65000 {
type internal;
local-address 10.0.6.1;
export ibgp;
neighbor 10.0.3.3;
}
group p1 {
type external;
import peer-filter-in;
export p1-export;
neighbor 10.0.5.254 {
peer-as 1492;
}
}
l...@r1
l...@r1 show configuration policy-options policy-statement ibgp
term 1 {
from {
protocol static;
route-filter 192.168.10.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol static;
route-filter 192.168.100.0/24 exact;
}
then {
metric 101;
local-preference 101;
community add no-export;
accept;
}
}
l...@r1
R3 Configuration
l...@r3 show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.30.0/24 reject;
}
martians {
192.0.2.0/24 orlonger;
}
aggregate {
route 10.0.4.0/22;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r3
l...@r3 show configuration protocols bgp
advertise-inactive;
group 65000 {
type internal;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.6.1;
}
group c-bgp {
type external;
multihop;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.3.4 {
hold-time 180;
peer-as 65001;
}
neighbor 10.0.3.5 {
peer-as 65002;
}
}
group t1-t2 {
type external;
damping;
import [ damp trans-filter-in ];
export [ no-192-24s prepend ];
remove-private;
multipath;
neighbor 172.16.0.14 {
peer-as 65222;
}
neighbor 172.16.0.18 {
peer-as 65222;
}
}
l...@r3
l...@r3 show configuration policy-options policy-statement ibgp
term 1 {
from {
protocol static;
route-filter 192.168.30.0/24 exact;
}
then accept;
}
term 2 {
from community trans-1-2;
then {
next-hop self;
}
}
l...@r3
Thanks for your help guys..
-Hoogen
On Thu, Oct 29, 2009 at 3:36 AM, Sean Clarke s...@clarke-3.demon.nlwrote:
What is in your ibgp export policy from R1 to R3 ? Are you putting
something in there to cause an issue ?
On 10/29/09 10:43 AM, Hoogen wrote:
Hi Felix,
Thank you for the reply..
I am not sure how that 17 hidden routes came into play... But its not
there now.. I still see the issue..
I had already checked the hidden routes..and those are not the ones
which are hiding
l...@r3# run show route receive-protocol bgp 10.0.6.1 hidden
extensive
inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0
holddown, 0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r3#
l...@r3# run show route receive-protocol bgp 10.0.6.1
inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
Prefix Nexthop MED LclprefAS
path
* 192.168.10.0/24 10.0.6.1 100I
* 192.168.100.0/2410.0.6.1 101 101I
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0
holddown, 0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0
Re: [j-nsp] vrrp groups
Ah, yes that makes sense! Thanks for your explanation. -Niels Op 30 okt 2009 om 17:44 heeft Terry Baranski tbaran...@mail.com het volgende geschreven:\ On Fri, Oct 30, 2009 at 11:02AM, Niels Ardts wrote: However, an error is returned: edit interfaces ae1 unit 241 family inet address yy] 'vrrp-group 241' Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and address: error: configuration check-out failed [edit interfaces ae1 unit 241] We're running JunOS 8.0R2.8 on a M7i. Any ideas? You're trying to use a given VRRP group ID twice on the same VLAN/subinterface. I'm not surprised that this doesn't commit -- the VRRP protocol itself probably doesn't support such a configuration. What will work is using the same group ID multiple times on different VLAN/subinterfaces within the same physical interface. -Terry -Oorspronkelijk bericht- Van: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski Verzonden: dinsdag 29 september 2009 1:52 Aan: juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] vrrp groups On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote: Note that while you can assign the same group number to multiple ifls on the same IFD best practice is not to as this can cause some issues with learning bridges as noted below, each group shares the same v- mac. I have to say -- this is a recommendation from Juniper that I've never understood. We've used group 1 exclusively for years (with hundreds of VLANs per interface in some cases) without issue. Using separate group IDs seems overly complex and unnecessary. As long as your switches aren't bleeding VLANs together there's no conceivable harm. (And if they do, having the same group ID ensures you'll discover the problem quickly. :-) To clarify for the original poster: there's no *hard limit* which will prevent you from configuring 300 VRRP groups (with non-unique group IDs) on one physical interface. (Even though the documentation said otherwise up until 9.6.) I would expect things to generally be okay with default timers but I've never tried group counts in the hundreds with anything smaller than an m40e. -Terry ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Tenzij schriftelijk anders is overeengekomen, zijn op al onze rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze zijn middels deze directe link http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/ of kunnen op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk van de hand gewezen. Nederlands recht is exclusief van toepassing. De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan. 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
Re: [j-nsp] [c-nsp] Network Liberation Movement???
Only an idiot will make an important announcement on a Saturday. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Matlock, Kenneth L Sent: Friday, October 30, 2009 1:15 PM To: Drew Weaver; Derick Winkworth; Cisco NSP; juniper- n...@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Gibberish, and marketing speak. My guess is a linux-based 'router' they're trying to sell to unsuspecting mom-and-pop businesses. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Friday, October 30, 2009 9:38 AM To: 'Derick Winkworth'; Cisco NSP; juniper-nsp@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Just looks like a bunch of gibberish to me. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, October 30, 2009 10:23 AM To: Cisco NSP; juniper-nsp@puck.nether.net Subject: [c-nsp] Network Liberation Movement??? http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Network Liberation Movement???
It's a marketing campaign. A so-called viral campaign (according to their blog -- http://opinion.rapp.com/). The IP is hosted by Rapp Collins Worldwide, who's a marketing firm. Don't know the actual client is. oo On Fri, Oct 30, 2009 at 2:39 PM, Drew Weaver drew.wea...@thenap.com wrote: On Halloween, no less. My first thought was we're all going to be spammed by network resalers in the next few days when I looked at that, but I then just thought wow this is incomprehensible jibberish. -Drew -Original Message- From: Lynch, Tomas [mailto:tomas.ly...@globalcrossing.com] Sent: Friday, October 30, 2009 2:20 PM To: Matlock, Kenneth L; Drew Weaver; Derick Winkworth; Cisco NSP; juniper-nsp@puck.nether.net Subject: RE: [c-nsp] Network Liberation Movement??? Only an idiot will make an important announcement on a Saturday. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Matlock, Kenneth L Sent: Friday, October 30, 2009 1:15 PM To: Drew Weaver; Derick Winkworth; Cisco NSP; juniper- n...@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Gibberish, and marketing speak. My guess is a linux-based 'router' they're trying to sell to unsuspecting mom-and-pop businesses. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Friday, October 30, 2009 9:38 AM To: 'Derick Winkworth'; Cisco NSP; juniper-nsp@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Just looks like a bunch of gibberish to me. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, October 30, 2009 10:23 AM To: Cisco NSP; juniper-nsp@puck.nether.net Subject: [c-nsp] Network Liberation Movement??? http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Network Liberation Movement???
As long as they don't attempt to Liberate my Network =P Regards, - Chris. On 2009-10-30, at 12:19 PM, Lynch, Tomas wrote: Only an idiot will make an important announcement on a Saturday. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Matlock, Kenneth L Sent: Friday, October 30, 2009 1:15 PM To: Drew Weaver; Derick Winkworth; Cisco NSP; juniper- n...@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Gibberish, and marketing speak. My guess is a linux-based 'router' they're trying to sell to unsuspecting mom-and-pop businesses. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Friday, October 30, 2009 9:38 AM To: 'Derick Winkworth'; Cisco NSP; juniper-nsp@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Just looks like a bunch of gibberish to me. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, October 30, 2009 10:23 AM To: Cisco NSP; juniper-nsp@puck.nether.net Subject: [c-nsp] Network Liberation Movement??? http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Network Liberation Movement???
looks as if its working based on the activity in this thread... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN on J series enhance services
Samin-san
Please configure the J-series like this, it should be help...
PC-J4350-J2350--PC
L3vpn works well when you disable the security feature in Junos Enhance
Services
ade
root# show | no-more
## Last changed: 2009-10-31 09:05:56 UTC
version 9.2R4.4;
system {
root-authentication {
encrypted-password $1$9aQTmFHm$lNkr4e5JOZC0TYiq.TUe/1; ##
SECRET-DATA
}
login {
user lab {
uid 2001;
class super-user;
authentication {
encrypted-password $1$2Ef07UvV$lITxZrsWXDDBZFgNISmAj0; ##
SECRET-DATA
}
}
}
services {
ssh;
telnet;
web-management {
http {
interface [ ge-0/0/0.0 ge-2/0/0.0 ];
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
chassis {
fpc 2 {
pic 0 {
ethernet {
pic-mode enhanced-switching;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0;
}
ls-0/0/0 {
unit 1 {
family inet {
address 192.168.1.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0;
}
ge-2/0/0 {
unit 0 {
family inet {
address 50.50.50.3/24;
}
}
}
ge-2/0/1 {
unit 0;
}
e1-3/0/0 {
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
e1-3/0/1 {
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
}
}
routing-options {
autonomous-system 65000;
}
protocols {
mpls {
interface ls-0/0/0.1;
}
bgp {
group inte {
type internal;
local-address 1.1.1.1;
family inet-vpn {
unicast;
}
neighbor 1.1.1.2;
}
}
ospf {
area 0.0.0.0 {
interface ls-0/0/0.1;
interface lo0.0;
}
}
ldp {
interface ls-0/0/0.1;
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000; ## Warning: 'queue-size' is deprecated
timeout 20;
}
land;
}
}
}
zones {
security-zone untrust {
screen untrust-screen;
}
security-zone trust {
tcp-rst;
}
security-zone default {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
all;
}
}
}
policies {
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}
}
}
routing-instances {
l3vpn {
instance-type vrf;
interface ge-2/0/0.0;
route-distinguisher 65000:1;
vrf-target target:65000:1;
vrf-table-label;
}
}
[edit]
root# run ping routing-instance l3vpn 192.168.0.100
PING 192.168.0.100 (192.168.0.100): 56 data bytes
64 bytes from 192.168.0.100: icmp_seq=0 ttl=127 time=4.164 ms
64 bytes from
Re: [j-nsp] juniper trinity
The datasheet for the new MX 3D line cards is a little strange. Assuming that a find-and-replace of KB to K will make it more coherent, this is an awesome amount of queues when comparing to competitors. However, the new FPC/PIC-like card strategy is in 30Gb/s and 60Gb/s flavors. Given that the 16x10GE card is oversubscribed this looks like the old DPC 4x10Gb/s stacked complex design (except now it is 4x30Gb/s?). I guess this because the numbering is much like the DPC in that they are 0/0-3 1/0-3 2/0-3 3/0-3. Would Juniper really come out with a 30Gb/s (full duplex) chipset? With no 40GE announcement I can only assume this chipset is going to be damn hard (or expensive) to do 40GE interfaces. Am I just missing something? -J Scott On Mon, Oct 26, 2009 at 12:16 AM, magno massimo.magn...@gmail.com wrote: I agree, and I am pretty sure the new chipset will encompass and largely extend all the qos functionalities provided today by ez-chip chip. Cheers. Max On 24/10/2009, Richard A Steenbergen r...@e-gerbil.net wrote: On Sat, Oct 24, 2009 at 06:38:53PM +0200, magno wrote: I repeat, Trinity has nothing to do with ez-chip. My advice is to stop elucubrating around any ez-chip whatever. Ez-chip proved to be quite limited for some qos functions, so I really don't think juniper wants to be qos feature limited by a third-party chip anymore. I believe the original question was do the new asics integrate the functionality of ezchip, thus eliminating the need for it, and from what I've heard I believe the answer is yes. That is why we're talking about the ezchip in the first place. -- 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
[j-nsp] Fw: L3VPN on J series enhance services
Samin-san
Please configure the J-series like this, it should be help...
PC-J4350-J2350--PC
L3vpn works well when you disable the security feature in Junos Enhance
Services
ade
root# show | no-more
## Last changed: 2009-10-31 09:05:56 UTC
version 9.2R4.4;
system {
root-authentication {
encrypted-password $1$9aQTmFHm$lNkr4e5JOZC0TYiq.TUe/1; ##
SECRET-DATA
}
login {
user lab {
uid 2001;
class super-user;
authentication {
encrypted-password $1$2Ef07UvV$lITxZrsWXDDBZFgNISmAj0; ##
SECRET-DATA
}
}
}
services {
ssh;
telnet;
web-management {
http {
interface [ ge-0/0/0.0 ge-2/0/0.0 ];
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
chassis {
fpc 2 {
pic 0 {
ethernet {
pic-mode enhanced-switching;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0;
}
ls-0/0/0 {
unit 1 {
family inet {
address 192.168.1.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0;
}
ge-2/0/0 {
unit 0 {
family inet {
address 50.50.50.3/24;
}
}
}
ge-2/0/1 {
unit 0;
}
e1-3/0/0 {
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
e1-3/0/1 {
e1-options {
framing unframed;
}
unit 0 {
family mlppp {
bundle ls-0/0/0.1;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
}
}
routing-options {
autonomous-system 65000;
}
protocols {
mpls {
interface ls-0/0/0.1;
}
bgp {
group inte {
type internal;
local-address 1.1.1.1;
family inet-vpn {
unicast;
}
neighbor 1.1.1.2;
}
}
ospf {
area 0.0.0.0 {
interface ls-0/0/0.1;
interface lo0.0;
}
}
ldp {
interface ls-0/0/0.1;
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000; ## Warning: 'queue-size' is deprecated
timeout 20;
}
land;
}
}
}
zones {
security-zone untrust {
screen untrust-screen;
}
security-zone trust {
tcp-rst;
}
security-zone default {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
all;
}
}
}
policies {
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}
}
}
routing-instances {
l3vpn {
instance-type vrf;
interface ge-2/0/0.0;
route-distinguisher 65000:1;
vrf-target target:65000:1;
vrf-table-label;
}
}
[edit]
root# run ping routing-instance l3vpn 192.168.0.100
PING 192.168.0.100 (192.168.0.100): 56 data bytes
64 bytes from 192.168.0.100: icmp_seq=0 ttl=127 time=4.164 ms
64 bytes from 192.168.0.100:
