From df at webkom.se  Mon Mar  1 03:41:35 2010
From: df at webkom.se (Patrik Olsson)
Date: Mon, 01 Mar 2010 09:41:35 +0100
Subject: [j-nsp] Routing instance limitation in Juniper J series
In-Reply-To: <377574fc1002280505qf08a4b7g383b6d63502ea8ea@mail.gmail.com>
References: <377574fc1002280505qf08a4b7g383b6d63502ea8ea@mail.gmail.com>
Message-ID: <4B8B7DBF.4000200@webkom.se>

The way I see it it is not the number of vrf:s that is the limitation,
it will be the rib and fib size. Then how you distribute that between
vrf:s wont matter.

I havent seen any official tests of number of vrf:s, but assume that 500
vrf:s should work. But I figure 4000 vrf:s might work aswell.

This is based on that Juniper creates a label per vrf and PE, not per
route and PE that Cisco does, so L3VPN is not consuming so much fib. But
all routes will be in rib of course.

Patrik

From debashis.office at gmail.com  Mon Mar  1 03:50:10 2010
From: debashis.office at gmail.com (Debashis Pal)
Date: Mon, 1 Mar 2010 14:50:10 +0600
Subject: [j-nsp] Routing instance limitation in Juniper J series
In-Reply-To: <4B8B7DBF.4000200@webkom.se>
References: <377574fc1002280505qf08a4b7g383b6d63502ea8ea@mail.gmail.com>
	<4B8B7DBF.4000200@webkom.se>
Message-ID: <377574fc1003010050w1d664e18q842f8adfd5ded35a@mail.gmail.com>

Hi Patrik

Thanks for your information.

-- 
With Thanks,
~~~~~~~~~~~~~
Debashis

On Mon, Mar 1, 2010 at 2:41 PM, Patrik Olsson <df at webkom.se> wrote:

> The way I see it it is not the number of vrf:s that is the limitation,
> it will be the rib and fib size. Then how you distribute that between
> vrf:s wont matter.
>
> I havent seen any official tests of number of vrf:s, but assume that 500
> vrf:s should work. But I figure 4000 vrf:s might work aswell.
>
> This is based on that Juniper creates a label per vrf and PE, not per
> route and PE that Cisco does, so L3VPN is not consuming so much fib. But
> all routes will be in rib of course.
>
> Patrik
>

From cscosunny at gmail.com  Mon Mar  1 07:04:25 2010
From: cscosunny at gmail.com (SunnyDay)
Date: Mon, 1 Mar 2010 14:04:25 +0200
Subject: [j-nsp] DNS
Message-ID: <523b55ec1003010404o6a7df428o3bfb247ce495913b@mail.gmail.com>

Hello
I Have 2 netscreen firewall connected on behind the other.
                     eth0    eth1       eth3
 internet     <-------FW1<---------->FW2

My problem is that FW2 from the cli is not able to do name resolution.eg:
ping www.google.com.FW1 is able to ping www.google.com
I configured on FW2 open dns with source interface eth3 with no luck any
ideas?

Regards

From barnys at juniper.net  Mon Mar  1 08:10:43 2010
From: barnys at juniper.net (Barny Sanchez)
Date: Mon, 1 Mar 2010 05:10:43 -0800
Subject: [j-nsp] DNS
In-Reply-To: <523b55ec1003010404o6a7df428o3bfb247ce495913b@mail.gmail.com>
References: <523b55ec1003010404o6a7df428o3bfb247ce495913b@mail.gmail.com>
Message-ID: <A9A8CD31-884C-49CB-81C8-DB3ABD12D23E@juniper.net>

1) Can you verify that you can ping from FW2 to 4.2.2.2?.  If it works, then probably you have a DNS misconfigured.
2) If the previous doesn't work, can you verity that you have a correct routing in place and also that FW1 has a proper policy in place, you can start by testing with a any to any policy.


This is the bare minimal things to check, but there are other problems to consider, such as:
1) NAT misconfiguration.
2) Routing missconfiguration.
3) Without knowing anyting more about your environment, could be a vsys problem (high-end firewalls).
4) VPNs involved?

Thanks,



Barny Sanchez | Consulting Engineer - Security Systems | Juniper Networks




On Mar 1, 2010, at 7:04 AM, SunnyDay wrote:

Hello
I Have 2 netscreen firewall connected on behind the other.
                    eth0    eth1       eth3
internet     <-------FW1<---------->FW2

My problem is that FW2 from the cli is not able to do name resolution.eg:
ping www.google.com.FW1<http://www.google.com.FW1> is able to ping www.google.com<http://www.google.com>
I configured on FW2 open dns with source interface eth3 with no luck any
ideas?

Regards
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp



From rubensk at gmail.com  Mon Mar  1 10:13:09 2010
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 1 Mar 2010 12:13:09 -0300
Subject: [j-nsp] IPv6 BGP support on EX-series
Message-ID: <6bb5f5b11003010713o50b501ebhe0383c5f74094f1a@mail.gmail.com>

Hi.

I was considering Juniper EX-4200 with AFL to an IPv4+IPv6 BGP
scenario where the number of FIB routes is enough, but this part of
the specs(http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf)
is worrying me:

Layer 3 Features: IPv4
? Max number of ARP entries: 16,000
? Max number of IPv4 unicast routes in hardware: 10,000
? Max number of IPv4 multicast routes in hardware: 2,000
? Routing protocols: RIPv1/v2, OSPF, BGP, IS-IS
? Static routing
? Routing policy
? Bidirectional Forwarding Detection
? Layer 3 redundancy: VRRP
Layer 3 Features: IPv6
? Max number of Neighbor Discovery (ND) entries: 16,000 (shared with IPv4)
? Max number of IPv6 unicast routes in hardware: 1,000
? Routing protocols: RIPng, OSPFv3
? Static routing

Would that mean that there is no BGP IPv6 support ? Wouldn't that
contradict with the supported RFCs section ?

RFC 2283 Multiprotocol Extensions for BGP-4
RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

I can especulate that there is no support for IPv6 BGP neighbors but
there is support for IPv6 address-family in IPv4 BGP sessions, is that
so ?

(As for JunOS version goes, it seems it would run 9.5R4 for starters)


Rubens


From mtinka at globaltransit.net  Mon Mar  1 12:23:36 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 2 Mar 2010 01:23:36 +0800
Subject: [j-nsp] IPv6 BGP support on EX-series
In-Reply-To: <6bb5f5b11003010713o50b501ebhe0383c5f74094f1a@mail.gmail.com>
References: <6bb5f5b11003010713o50b501ebhe0383c5f74094f1a@mail.gmail.com>
Message-ID: <201003020123.37525.mtinka@globaltransit.net>

On Monday 01 March 2010 11:13:09 pm Rubens Kuhl wrote:

> Would that mean that there is no BGP IPv6 support ?
>  Wouldn't that contradict with the supported RFCs section
>  ?

BGP support for IPv6 is supported on the EX4200 platform. I 
have two systems running fine (JUNOS 9.5R3.7 - yes, they 
need to be upgraded).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100302/f2034c52/attachment.bin>

From ramkrishna at subisu.net.np  Tue Mar  2 00:46:40 2010
From: ramkrishna at subisu.net.np (Ram Krishna)
Date: Tue, 2 Mar 2010 11:31:40 +0545 (NPT)
Subject: [j-nsp] Junos on GNS3
In-Reply-To: <mailman.5.1267462807.93610.juniper-nsp@puck.nether.net>
References: <mailman.5.1267462807.93610.juniper-nsp@puck.nether.net>
Message-ID: <7dfa4e4893ccc1fd8e5e2e4ac5d273b2.squirrel@mail.subisu.net.np>

Dear All,

I have tried to configure Junos on GNS3 but cannot run. Could you please
Advice

Regards

Ram Krishna


From atif.jauhar at gmail.com  Tue Mar  2 01:59:07 2010
From: atif.jauhar at gmail.com (Muhammad Atif Jauahar)
Date: Tue, 2 Mar 2010 11:59:07 +0500
Subject: [j-nsp] Junos on GNS3
In-Reply-To: <7dfa4e4893ccc1fd8e5e2e4ac5d273b2.squirrel@mail.subisu.net.np>
References: <mailman.5.1267462807.93610.juniper-nsp@puck.nether.net>
	<7dfa4e4893ccc1fd8e5e2e4ac5d273b2.squirrel@mail.subisu.net.np>
Message-ID: <6a51198a1003012259y185a255t2d327abf9d3f315f@mail.gmail.com>

Hi,

You can get more informaiton from this link.

http://blog.gns3.net/2009/10/olive-juniper/

Regards,
Atif.

On Tue, Mar 2, 2010 at 10:46 AM, Ram Krishna <ramkrishna at subisu.net.np>wrote:

> Dear All,
>
> I have tried to configure Junos on GNS3 but cannot run. Could you please
> Advice
>
> Regards
>
> Ram Krishna
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Regards,

Muhammad Atif Jauhar
(+92-33-3346-0000)

From cscosunny at gmail.com  Tue Mar  2 02:13:29 2010
From: cscosunny at gmail.com (SunnyDay)
Date: Tue, 02 Mar 2010 09:13:29 +0200
Subject: [j-nsp] DNS
In-Reply-To: <A9A8CD31-884C-49CB-81C8-DB3ABD12D23E@juniper.net>
References: <523b55ec1003010404o6a7df428o3bfb247ce495913b@mail.gmail.com>
	<A9A8CD31-884C-49CB-81C8-DB3ABD12D23E@juniper.net>
Message-ID: <4B8CBA99.6030602@gmail.com>

FW1 is doing a source based nat and i can ping from FW2 any dns even google.

On 1/3/2010 3:10 ??, Barny Sanchez wrote:
> 1) Can you verify that you can ping from FW2 to 4.2.2.2?.  If it works, then probably you have a DNS misconfigured.
> 2) If the previous doesn't work, can you verity that you have a correct routing in place and also that FW1 has a proper policy in place, you can start by testing with a any to any policy.
>
>
> This is the bare minimal things to check, but there are other problems to consider, such as:
> 1) NAT misconfiguration.
> 2) Routing missconfiguration.
> 3) Without knowing anyting more about your environment, could be a vsys problem (high-end firewalls).
> 4) VPNs involved?
>
> Thanks,
>
>
>
> Barny Sanchez | Consulting Engineer - Security Systems | Juniper Networks
>
>
>
>
> On Mar 1, 2010, at 7:04 AM, SunnyDay wrote:
>
> Hello
> I Have 2 netscreen firewall connected on behind the other.
>                      eth0    eth1       eth3
> internet<-------FW1<---------->FW2
>
> My problem is that FW2 from the cli is not able to do name resolution.eg:
> ping www.google.com.FW1<http://www.google.com.FW1>  is able to ping www.google.com<http://www.google.com>
> I configured on FW2 open dns with source interface eth3 with no luck any
> ideas?
>
> Regards
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>    


From uttam.shrestha.rana at gmail.com  Tue Mar  2 04:47:52 2010
From: uttam.shrestha.rana at gmail.com (Uttam Shrestha Rana)
Date: Tue, 2 Mar 2010 15:32:52 +0545
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
Message-ID: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>

Dear ALL,

On juniper M10i with JUNOS 9.2, we have flow exported by the routing engine
sampling packets headers and had aggregated them into flows.We have two
upstream and peered number of customers, we have packet sampling done by
defining a firewall filter to accept and sample all traffic and that rule
has been applied to the provider facing interfaces.

In our case, when we had two upstream previously and sampled, it was quite
related to the flow extracted but recently we get peered with another
upstream and did the same configuration for sampling but we are not getting
the exact flow , we are getting it decreased by half. What can be the reason
behind this?, it will be great support if any excellence put his/her idea
and really appriciates for that.

Regards,
Uttam S R

From ilovebgp4 at gmail.com  Tue Mar  2 06:45:58 2010
From: ilovebgp4 at gmail.com (Chen Jiang)
Date: Tue, 2 Mar 2010 19:45:58 +0800
Subject: [j-nsp] [port mirrorong M320]
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA2653A66F@ESESSCMS0364.eemea.ericsson.se>
References: <201002272028.o1RKSoTr070835@idle.juniper.net>
	<7B520BC9477F5B45B50F8A193CDD55DA2653A66F@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <71e413951003020345s40a48242q195c84ee5d8e173d@mail.gmail.com>

hi!

This is a example for L3 mirror:

1.Define  Port-Mirror Properties
.....

forwarding-options {

port-mirroring {

        input {

            rate 1;

        }

        family inet {

            output {

                interface ge-2/0/3.0 {                       #define output
interface

                    next-hop 192.168.100.1;              #define destination
host

                }

            }

        }

    }
}

2.Define Firewall filter to mirror

firewall {

    family inet {

        filter l3-mirror {

            term 10 {

                then {

                    port-mirror;

                    accept;

                }

            }

        }

    }
}

3. Apply fireall filter in source interafce that need be mirrored

 interfaces {

    ge-2/0/0 {

        unit 0 {

            family inet {

                filter {

                    input l3-mirror;

                    output l3-mirror;

                }

                address 192.168.0.2/30;

            }

        }

    }



 On Sun, Feb 28, 2010 at 5:14 PM, Ibariouen Khalid <
ibariouen.khalid at ericsson.com> wrote:

>
> Dear community
>
> i have a question regarding port mirroring on juniper router;
> I'll be implementing port mirroring on M320 router forever ( I mean the
> mirroring will stay configured for ever ), this router is handling around
> 2.5G of traffic ; does the mirroring impact the performance of the router as
> it is mentioned in some documents ?
> I'll appreciate if some can send me a template of a configuration.
> Regards/
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
BR!



          James Chen

From felix.schueren at hosteurope.de  Tue Mar  2 09:23:19 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Tue, 02 Mar 2010 15:23:19 +0100
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
In-Reply-To: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>
Message-ID: <4B8D1F57.9040701@hosteurope.de>

Uttam,

> On juniper M10i with JUNOS 9.2, we have flow exported by the routing engine
> sampling packets headers and had aggregated them into flows.We have two
> upstream and peered number of customers, we have packet sampling done by
> defining a firewall filter to accept and sample all traffic and that rule
> has been applied to the provider facing interfaces.
> 
please paste your current "forwarding-options sampling" configuration.

> In our case, when we had two upstream previously and sampled, it was quite
> related to the flow extracted but recently we get peered with another
> upstream and did the same configuration for sampling but we are not getting
> the exact flow , we are getting it decreased by half. What can be the reason
> behind this?
it could be that you're hitting the built-in rate limit for sampling, or 
maybe your firewall filters aren't working right, or your multipathing 
isn't what you'd want it to be. Do you have an advanced services pic / 
MS-PIC in the m10i? If in doubt, paste a  "show chassis hardware 
clei-models" (clei-models to easily obscure the serial numbers).

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

From uttam.shrestha.rana at gmail.com  Tue Mar  2 10:09:09 2010
From: uttam.shrestha.rana at gmail.com (Uttam Shrestha Rana)
Date: Tue, 2 Mar 2010 20:54:09 +0545
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
In-Reply-To: <4B8D1F57.9040701@hosteurope.de>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>
	<4B8D1F57.9040701@hosteurope.de>
Message-ID: <75af52521003020709s1fce8db4v4cd8692a8c5cefb8@mail.gmail.com>

Hello,

Here is what we have configured.


show configuration interfaces fe-0/0/0
description " Connected to NTT Singapore ";
unit 0 {
    family inet {
        filter {
            input filter-ntt;
        }
        sampling {
            input;
        }
        address 116.51.XX.XX/30;
    }
}
-----------------------------------------
show configuration interfaces fe-0/0/3
description " Connected to NTT London ";
fastether-options {
    ignore-l3-incompletes;
}
unit 0 {
    family inet {
        filter {
            input filter-ntt;
        }
        sampling {
            input;
        }
        address 83.231.XX.XX/30;
    }
}

-----------------------------------------
show configuration interfaces so-0/1/1
traceoptions {
    flag media;
}
hold-time up 200 down 15000;
clocking external;
encapsulation cisco-hdlc;
framing {
    sonet;
}
sonet-options {
    fcs 32;
    path-trace nep-so-0/1/1;
    trigger {
        lol ignore;
        pll ignore;
        lof ignore;
        los ignore;
        ais-l ignore;
        rfi-l ignore;
        ber-sd {
            hold-time up 100 down 1000;
        }
        ber-sf {
            hold-time up 100 down 1000;
        }
        ais-p hold-time up 100 down 10000;
        lop-p hold-time up 100 down 10000;
        rfi-p ignore;
        uneq-p hold-time up 100 down 10000;
        plm-p hold-time up 100 down 10000;
    }
    payload-scrambler;
    bytes {
        c2 1;
    }
}
unit 0 {
    family inet {
        filter {
            input filter-tata;
        }
        sampling {
            input;
        }
        address 209.58.xx.xx/30;
    }
}
--------------------------------------------

show configuration forwarding-options
sampling {
    input {
        family inet {
            rate 1;
            run-length 0;
            max-packets-per-second 7000;
        }
    }
    output {
        cflowd 202.51.XXX.XXX {
            port 9990;
            source-address 202.51.XX.XX;
            version 5;
            autonomous-system-type origin;
        }
        cflowd 202.63.XX.XXX {
            port 9998;
            source-address 116.66.XX.XXX;
            version 5;
            autonomous-system-type origin;
        }
        flow-inactive-timeout 300;
        flow-active-timeout 300;
    }
}

------------------------------------------------
show configuration firewall filter sampling
term 1 {
    then {
        sample;
        accept;
    }
}

and hardware of our M10i: we don;t have PIC/MS-Pic



Hoping for your suggestions  and support.

Regards,
Uttam

On Tue, Mar 2, 2010 at 8:08 PM, Felix Schueren <felix.schueren at hosteurope.de
> wrote:

> Uttam,
>
>
>  On juniper M10i with JUNOS 9.2, we have flow exported by the routing
>> engine
>> sampling packets headers and had aggregated them into flows.We have two
>> upstream and peered number of customers, we have packet sampling done by
>> defining a firewall filter to accept and sample all traffic and that rule
>> has been applied to the provider facing interfaces.
>>
>>  please paste your current "forwarding-options sampling" configuration.
>
>
>  In our case, when we had two upstream previously and sampled, it was quite
>> related to the flow extracted but recently we get peered with another
>> upstream and did the same configuration for sampling but we are not
>> getting
>> the exact flow , we are getting it decreased by half. What can be the
>> reason
>> behind this?
>>
> it could be that you're hitting the built-in rate limit for sampling, or
> maybe your firewall filters aren't working right, or your multipathing isn't
> what you'd want it to be. Do you have an advanced services pic / MS-PIC in
> the m10i? If in doubt, paste a  "show chassis hardware clei-models"
> (clei-models to easily obscure the serial numbers).
>
> 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
>

From meryem_z at hotmail.com  Wed Mar  3 05:44:31 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Wed, 3 Mar 2010 10:44:31 +0000
Subject: [j-nsp] Prioritizing LSPs for a special routing instance
In-Reply-To: <4B8D1F57.9040701@hosteurope.de>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>,
	<4B8D1F57.9040701@hosteurope.de>
Message-ID: <BLU113-W78628D819960B52E6AF0EE13A0@phx.gbl>



Hello Community,

For testing purposes I need to force the traffic to take a the secondary LSP between two routers instead of the direct path. I need to do this only for one routing instance.

It is possible to do this ? and How?

Thanks a lot.

Meryem.

 		 	   		  
_________________________________________________________________
Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e Microsoft
https://signup.live.com/signup.aspx?id=60969

From rameshkarki at gmail.com  Wed Mar  3 05:49:12 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Wed, 3 Mar 2010 16:34:12 +0545
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
In-Reply-To: <75af52521003020709s1fce8db4v4cd8692a8c5cefb8@mail.gmail.com>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>
	<4B8D1F57.9040701@hosteurope.de>
	<75af52521003020709s1fce8db4v4cd8692a8c5cefb8@mail.gmail.com>
Message-ID: <bb76118f1003030249i2253783cv93579e48cd7d6b0f@mail.gmail.com>

hello,

I have configured sampling traffic input on all the interfaces, and
configured forwarding-option with max-packet per second 7000, rate 100 and
run-length 0, means 1 packet out of 100. I am using RE based sampling. On
the server side we are using flow-tool FlowScan as a data collector. In my
view the router is exporting exactly as we have configured on the
forwarding-option. But we want exact ( our total BW as we can see on MRTG)
traffic graph on flow-tool flowScan data collector. To do this I think there
can be an option on flow-tool so it can calculate the exported data and show
exact traffic.

Is there any idea how ??

Thank you,



On Tue, Mar 2, 2010 at 8:54 PM, Uttam Shrestha Rana <
uttam.shrestha.rana at gmail.com> wrote:

> Hello,
>
> Here is what we have configured.
>
>
> show configuration interfaces fe-0/0/0
> description " Connected to NTT Singapore ";
> unit 0 {
>    family inet {
>        filter {
>            input filter-ntt;
>        }
>        sampling {
>            input;
>        }
>        address 116.51.XX.XX/30;
>    }
> }
> -----------------------------------------
> show configuration interfaces fe-0/0/3
> description " Connected to NTT London ";
> fastether-options {
>    ignore-l3-incompletes;
> }
> unit 0 {
>    family inet {
>        filter {
>            input filter-ntt;
>        }
>        sampling {
>            input;
>        }
>        address 83.231.XX.XX/30;
>    }
> }
>
> -----------------------------------------
> show configuration interfaces so-0/1/1
> traceoptions {
>    flag media;
> }
> hold-time up 200 down 15000;
> clocking external;
> encapsulation cisco-hdlc;
> framing {
>    sonet;
> }
> sonet-options {
>    fcs 32;
>    path-trace nep-so-0/1/1;
>    trigger {
>        lol ignore;
>        pll ignore;
>        lof ignore;
>        los ignore;
>        ais-l ignore;
>        rfi-l ignore;
>        ber-sd {
>            hold-time up 100 down 1000;
>        }
>        ber-sf {
>            hold-time up 100 down 1000;
>        }
>        ais-p hold-time up 100 down 10000;
>        lop-p hold-time up 100 down 10000;
>        rfi-p ignore;
>        uneq-p hold-time up 100 down 10000;
>        plm-p hold-time up 100 down 10000;
>    }
>    payload-scrambler;
>    bytes {
>        c2 1;
>    }
> }
> unit 0 {
>    family inet {
>        filter {
>            input filter-tata;
>        }
>        sampling {
>            input;
>        }
>        address 209.58.xx.xx/30;
>    }
> }
> --------------------------------------------
>
> show configuration forwarding-options
> sampling {
>    input {
>        family inet {
>            rate 1;
>            run-length 0;
>            max-packets-per-second 7000;
>        }
>    }
>    output {
>        cflowd 202.51.XXX.XXX {
>            port 9990;
>            source-address 202.51.XX.XX;
>            version 5;
>            autonomous-system-type origin;
>        }
>        cflowd 202.63.XX.XXX {
>            port 9998;
>            source-address 116.66.XX.XXX;
>            version 5;
>            autonomous-system-type origin;
>        }
>        flow-inactive-timeout 300;
>        flow-active-timeout 300;
>    }
> }
>
> ------------------------------------------------
> show configuration firewall filter sampling
> term 1 {
>    then {
>        sample;
>        accept;
>    }
> }
>
> and hardware of our M10i: we don;t have PIC/MS-Pic
>
>
>
> Hoping for your suggestions  and support.
>
> Regards,
> Uttam
>
> On Tue, Mar 2, 2010 at 8:08 PM, Felix Schueren <
> felix.schueren at hosteurope.de
> > wrote:
>
> > Uttam,
> >
> >
> >  On juniper M10i with JUNOS 9.2, we have flow exported by the routing
> >> engine
> >> sampling packets headers and had aggregated them into flows.We have two
> >> upstream and peered number of customers, we have packet sampling done by
> >> defining a firewall filter to accept and sample all traffic and that
> rule
> >> has been applied to the provider facing interfaces.
> >>
> >>  please paste your current "forwarding-options sampling" configuration.
> >
> >
> >  In our case, when we had two upstream previously and sampled, it was
> quite
> >> related to the flow extracted but recently we get peered with another
> >> upstream and did the same configuration for sampling but we are not
> >> getting
> >> the exact flow , we are getting it decreased by half. What can be the
> >> reason
> >> behind this?
> >>
> > it could be that you're hitting the built-in rate limit for sampling, or
> > maybe your firewall filters aren't working right, or your multipathing
> isn't
> > what you'd want it to be. Do you have an advanced services pic / MS-PIC
> in
> > the m10i? If in doubt, paste a  "show chassis hardware clei-models"
> > (clei-models to easily obscure the serial numbers).
> >
> > 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From sthaug at nethelp.no  Wed Mar  3 06:57:32 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 03 Mar 2010 12:57:32 +0100 (CET)
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
In-Reply-To: <bb76118f1003030249i2253783cv93579e48cd7d6b0f@mail.gmail.com>
References: <4B8D1F57.9040701@hosteurope.de>
	<75af52521003020709s1fce8db4v4cd8692a8c5cefb8@mail.gmail.com>
	<bb76118f1003030249i2253783cv93579e48cd7d6b0f@mail.gmail.com>
Message-ID: <20100303.125732.74717633.sthaug@nethelp.no>

> I have configured sampling traffic input on all the interfaces, and
> configured forwarding-option with max-packet per second 7000, rate 100 and
> run-length 0, means 1 packet out of 100. I am using RE based sampling. On
> the server side we are using flow-tool FlowScan as a data collector. In my
> view the router is exporting exactly as we have configured on the
> forwarding-option. But we want exact ( our total BW as we can see on MRTG)
> traffic graph on flow-tool flowScan data collector. To do this I think there
> can be an option on flow-tool so it can calculate the exported data and show
> exact traffic.

If you expect flow-tools to provide such an option you should probably
ask on an appropriate mailing list - this is *not* a Juniper problem.

Oh btw, as far as I know flow-tools doesn't have an option to multiply
by the sampling rate.

Another point here - when you are doing sampling, you cannot expect
"exact traffic" if you mean something which matches the SNMP interface
counters exactly.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From ctracy at es.net  Wed Mar  3 09:41:19 2010
From: ctracy at es.net (Chris Tracy)
Date: Wed, 3 Mar 2010 09:41:19 -0500
Subject: [j-nsp] Sampling Traffic Problem--- Urgent
In-Reply-To: <20100303.125732.74717633.sthaug@nethelp.no>
References: <4B8D1F57.9040701@hosteurope.de>
	<75af52521003020709s1fce8db4v4cd8692a8c5cefb8@mail.gmail.com>
	<bb76118f1003030249i2253783cv93579e48cd7d6b0f@mail.gmail.com>
	<20100303.125732.74717633.sthaug@nethelp.no>
Message-ID: <04415E68-704F-4DDD-93AD-0E3B5A4E022C@es.net>

>> But we want exact ( our total BW as we can see on MRTG)
>> traffic graph on flow-tool flowScan data collector. To do this I think there
>> can be an option on flow-tool so it can calculate the exported data and show
>> exact traffic.
> 
> If you expect flow-tools to provide such an option you should probably
> ask on an appropriate mailing list - this is *not* a Juniper problem.
> 
> Oh btw, as far as I know flow-tools doesn't have an option to multiply
> by the sampling rate.

Agreed, the flow-tools mailing list is a better place to ask about this.  However, just for everybody's reference (and regarding accuracy issues in general below), this is exactly what one of the uses for the -X to flow-capture is for.  You can define a 'scale-up' translation, such as the one below if you are using 1:100 sampling:

===
xlate-action scale
  type scale
    scale 100

xlate-definition scale-up
  term
    action scale
===

Stick the above in a file, reference that file using flow-capture -x [filename] -X scale-up.  Now all of your flow records simply get multiplied by 100, so...

> Another point here - when you are doing sampling, you cannot expect
> "exact traffic" if you mean something which matches the SNMP interface
> counters exactly.

As Steinar pointed out, you *must* expect some error due to sampling.  You can see with the flow-capture example I gave above that you are simply padding on two zeros onto the # of flows/octets/packets fields of *every* single flow record.  I am not sure how other flow capture tools handle this.

If you want a high level of accuracy in your flow data, you need to use an MS-PIC (or MS-DPC on the MX) and not sample.  This will eat disk space much faster, of course.  :-)

Cheers,
-Chris

--
Chris Tracy <ctracy at es.net>
Energy Sciences Network (ESnet)
Lawrence Berkeley National Laboratory






From paul at paulstewart.org  Wed Mar  3 13:40:06 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 3 Mar 2010 13:40:06 -0500
Subject: [j-nsp] EX4200 Images
Message-ID: <001301cabb00$f20972a0$d61c57e0$@org>

Hi there..

 

We are waiting on a J-Care order to come back - I need to get an image up on
an EX4200-24F .. is the image from a EX4200-48T the same as I have those?

 

Appreciate it,

 

Paul

 

 

 


From msa at latt.net  Wed Mar  3 14:14:11 2010
From: msa at latt.net (Majdi S. Abbas)
Date: Wed, 3 Mar 2010 12:14:11 -0700
Subject: [j-nsp] EX3200 DHCP forwarding
Message-ID: <20100303191411.GC52516@puck.nether.net>


	Given a fairly standard configuration:

	EX3200# show forwarding-options helpers bootp
	server A.B.C.D;
	interface {
	    vlan.XXXX;
	}

	(The vlan configuration consists of an IP address only.)

		And running 10.1R1.8 on an EX3200, why is this counter
	incrementing:

	EX3200> show helper statistics
	BOOTP:
	  Received packets: 25
	  Forwarded packets: 15
	  Dropped packets: 10
	    Due to no interface in DHCP Relay database: 0
	    Due to no matching routing instance: 0
	    Due to an error during packet read: 0
	    Due to an error during packet send: 0
	    Due to invalid server address: 0
	    Due to no valid local address: 10
	    Due to no route to server/client: 0

	The same apparent configuration works on another device.
What is meant by "no valid local address" -- the documentation is not
particularly enlightening on this point.

	Thanks,

	--msa

From paul at paulstewart.org  Wed Mar  3 14:59:04 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 3 Mar 2010 14:59:04 -0500
Subject: [j-nsp] EX4200 Images
In-Reply-To: <20100303195256.GA24127@mork.no>
References: <001301cabb00$f20972a0$d61c57e0$@org>
	<20100303195256.GA24127@mork.no>
Message-ID: <001901cabb0b$fa1ab890$ee5029b0$@org>

Thank you ;)

-----Original Message-----
From: Kari Asheim [mailto:ka at mork.no] 
Sent: Wednesday, March 03, 2010 2:53 PM
To: Paul Stewart
Cc: 'jnsp'
Subject: Re: [j-nsp] EX4200 Images

> We are waiting on a J-Care order to come back - I need to get an image up
on
> an EX4200-24F .. is the image from a EX4200-48T the same as I have those?

Yes, and as you see this filename only includess ex-4200:

jinstall-ex-4200-10.0S1.1-domestic-signed.tgz

Kari


From ka at mork.no  Wed Mar  3 14:52:56 2010
From: ka at mork.no (Kari Asheim)
Date: Wed, 3 Mar 2010 20:52:56 +0100
Subject: [j-nsp] EX4200 Images
In-Reply-To: <001301cabb00$f20972a0$d61c57e0$@org>
References: <001301cabb00$f20972a0$d61c57e0$@org>
Message-ID: <20100303195256.GA24127@mork.no>

> We are waiting on a J-Care order to come back - I need to get an image up on
> an EX4200-24F .. is the image from a EX4200-48T the same as I have those?

Yes, and as you see this filename only includess ex-4200:

jinstall-ex-4200-10.0S1.1-domestic-signed.tgz

Kari

From tbaranski at mail.com  Wed Mar  3 17:52:56 2010
From: tbaranski at mail.com (Terry Baranski)
Date: Wed, 3 Mar 2010 17:52:56 -0500
Subject: [j-nsp] Prioritizing LSPs for a special routing instance
In-Reply-To: <BLU113-W78628D819960B52E6AF0EE13A0@phx.gbl>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>,
	<4B8D1F57.9040701@hosteurope.de>
	<BLU113-W78628D819960B52E6AF0EE13A0@phx.gbl>
Message-ID: <000201cabb24$44ca0ef0$ce5e2cd0$@com>

> Hello Community,
> 
> For testing purposes I need to force the traffic to take a the secondary 
> LSP between two routers instead of the direct path. I need to do this 
> only for one routing instance.
>
> It is possible to do this ? and How?

Not exactly what you asked about, but you can force a routing instance to
use a different LSP like this:

policy-statement lsp-mapper {
	term 1 {
    		from {
        		rib bgp.l3vpn.0;
        		community use-lsp;
    		}
    		then {
        		install-nexthop strict lsp lsp;
        		accept;
    		}
	}
	term 2 {
    		from rib bgp.l3vpn.0;
    		then {
        		install-nexthop strict except lsp lsp;
        		accept;
    		}
	}
}

set routing-options forwarding-table export lsp-mapper

The LSP named "lsp" will be used for routes with the "use-lsp" community,
which can be set by the VRF's export policy on the originating router.  All
other routes will use anything except "lsp".

I doubt it's possible to have a VRF use a given LSP's secondary path.

-Terry



From meryem_z at hotmail.com  Thu Mar  4 07:14:42 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Thu, 4 Mar 2010 12:14:42 +0000
Subject: [j-nsp] Juniper SBR : does modifying servtype.ini file need restart
	?
In-Reply-To: <000201cabb24$44ca0ef0$ce5e2cd0$@com>
References: <75af52521003020147x69e4df7wad59ccc1d5ebafb6@mail.gmail.com>,
	<4B8D1F57.9040701@hosteurope.de>
	<BLU113-W78628D819960B52E6AF0EE13A0@phx.gbl>,
	<000201cabb24$44ca0ef0$ce5e2cd0$@com>
Message-ID: <BLU113-W89F22FE591021057298D6E1390@phx.gbl>


Thank you.

 		 	   		  
_________________________________________________________________
Hotmail : une messagerie fiable avec la protection anti-spam performante de Microsoft
https://signup.live.com/signup.aspx?id=60969

From fahadaqeel at hotmail.com  Thu Mar  4 10:58:27 2010
From: fahadaqeel at hotmail.com (Fahad Aqeel)
Date: Thu, 4 Mar 2010 15:58:27 +0000
Subject: [j-nsp] VPLS clients Inaccessible
Message-ID: <BLU147-W34CD88900273EB2EA2D588D9390@phx.gbl>


Hi Experts

I have One MX480 and Two MX240 routers connected with each others. Running VPLS and L3 services b/w them.
In MX480 2 (1Gbps) port connect with server machine configure as vpls access port.
In Mx240 1 (1Gbps) port connect with Cisco switch configure as vpls Trunk port.

The issue is i m not able to ping from server to vlan on cisco switch,but
when i change MX240 port as access port same as cisco switch it can accessible.
What i observe problem is in trunk port may be. 

- vpls nodes show UP.
- Mac address of clients show in vpls mac-table.

My configs.

MX480:-

 ge-1/1/3 {
        encapsulation ethernet-vpls;
        unit 0 {
            family vpls;
        }
    }


Local site: AccessZTE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    3                         rmt   Up     Mar  4 04:45:39 2010           1
      Remote PE: 192.168.3.3, Negotiated control-word: No
      Incoming label: 262163, Outgoing label: 262201
      Local interface: lsi.1050624, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS local site 1 remote site 3


MAC flags (S -static MAC, D -dynamic MAC,
           SE -Statistics enabled, NM -Non configured MAC)
Routing instance : VPLS
 Bridging domain : __VPLS__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   00:19:c6:1c:9f:00   D        ge-1/1/5.0           
   00:1f:16:2c:de:4f   D        ge-1/1/3.0           
   00:d0:d0:a1:2e:92   D        ge-1/1/2.0           
   00:d0:d0:a1:71:b0   D        ge-1/1/4.0           
   64:16:8d:f6:f9:15   D        lsi.1050624      



MX240:-    

    ge-1/1/0 {
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 1 {
            encapsulation vlan-vpls;
            vlan-id 1;
            input-vlan-map pop;
            output-vlan-map push;
            family vpls;
        }
        unit 2 {
            encapsulation vlan-vpls;
            vlan-id 2;
            input-vlan-map pop;
            output-vlan-map push;
            family vpls;
        }
    }


Instance: VPLS
  Local site: AccessZTE1 (3)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   Up     Mar  4 04:44:34 2010           1
      Remote PE: 192.168.1.1, Negotiated control-word: No
      Incoming label: 262201, Outgoing label: 262163
      Local interface: lsi.1051136, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS local site 3 remote site 1


MAC flags (S -static MAC, D -dynamic MAC,
           SE -Statistics enabled, NM -Non configured MAC)
Routing instance : VPLS
 Bridging domain : __VPLS__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   00:1f:16:2c:de:4f   D        lsi.1051136          
   00:d0:d0:a1:2e:92   D        lsi.1051136          
   00:d0:d0:a1:71:b0   D        lsi.1051136          
   64:16:8d:f6:f9:15   D        ge-1/1/0.2           


 

Thanks in advance

 FAS





 
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/

From p.mayers at imperial.ac.uk  Thu Mar  4 12:40:33 2010
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 04 Mar 2010 17:40:33 +0000
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?
Message-ID: <4B8FF091.2020607@imperial.ac.uk>

All,

I'm working with JTAC on this, but they're stumped so far and I thought 
I'd throw it out here.

We have an NSRP pair of netscreen 5400s in a slightly complex configuration.

Each firewall has a single 10gig port with multiple sub-ints. Each 
sub-int is bound to a zone and the netscreens route traffic between them 
(and apply policy). Rather than using VSIs we configure downstream BGP 
routing policy to split traffic between the firewalls very successfully. 
Effectively, the NSRP serves only to sync up the address & policy configs.

We have recently discovered that UDP flows with any (src,port) to a 
specific (dst,port) pair seem to be capped at the weirdly precise value 
of 5.8Mbit/sec. See below for more info on the exact traffic pattern.

That is, if we have:

source1, sport 1234, dport 5000 - offers 10mbit/sec of UDP
source2, sport 5678, dport 5000 - offers 10mbit/sec of UDP

At the receiver, destination port 5000 receives 5.8mbit/sec total, split 
approx 50/50 between the two senders i.e. ~3mbit/sec received 
per-sender, ~70% loss per flow. Stopping one sender means the other gets 
the full ~5.8Mbit/sec.

There are no apparently traffic limits using TCP or, weirdly, GRE (using 
GRE p2p interfaces on source->dest). I'm using two linux boxes and iperf 
to generate the test traffic:

iperf -i 1 -u -c dest -b 10M

...but the original report was for real UDP traffic.

Now, there are as far as I'm aware no rate-limiting, bandwidth, QoS or 
other policies configured either on the firewall and definitely not on 
the router it is attached to. JTAC have not spotted anything.

If I take a SPAN (port mirror) of the 10gig port on the router facing 
the firewall, I see the following traffic pattern, correlating in/out 
packets by IP IP# and source/dest MAC address:

0.00 - 0.59 seconds - packets flow normally (~725kbyte of data)
0.60 - 0.99 seconds - packets go into the netscreen but do not come back out
1.00 - 1.59 seconds - packets flow normally

...and so on.

It's frankly bizarre.

I have verified that this still occurs with "no-hw-sess" on the policy 
after being advised to try this by JTAC.

ScreenOS version is 6.2.0r4.0, hardware is M2 management blades and 2XGE 
10gig linecards.

The router attached to the firewall is a 6509/sup720 and I have 
confidence it is not implicated in the loss.

Any suggestions?

Cheers,
Phil

From p.mayers at imperial.ac.uk  Thu Mar  4 12:42:59 2010
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 04 Mar 2010 17:42:59 +0000
Subject: [j-nsp] Rerouting of sessions in ScreenOS
In-Reply-To: <4B88DCE9.4090200@te3networks.de>
References: <4B88DCE9.4090200@te3networks.de>
Message-ID: <4B8FF123.4090307@imperial.ac.uk>

On 27/02/10 08:50, Thomas Eichhorn wrote:

> ***************    ***********           *******     **********
> * Destination *----* Router 1*----BGP ---* SSG * --- * SOURCE *
> ***************    ***********           *******     **********
>                                              |
>                                        *************
>                                        * Default GW*
>                                        *************
>
> The problem looks like that:
>
> Source is always sending traffic to destination,
> but if the SSG has rebooted, it has not yet established
> the BGP to router 1, so the traffic flows to default gw.
>
> This remains until I reset manually the session, because
> of beeing the traffic UDP there is no session timeout.
>
> Do I have any possibility to get the device automatically
> to notice that it have a better route now, and change/clear
> the session?

IIRC there are various options to control whether flows "stick" to 
routes upon route change.

Try:

set flow route-change-timeout

From alex.arseniev at gmail.com  Fri Mar  5 05:10:13 2010
From: alex.arseniev at gmail.com (Alex)
Date: Fri, 5 Mar 2010 10:10:13 -0000
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?
References: <4B8FF091.2020607@imperial.ac.uk>
Message-ID: <F71780005DBD470B8B2EB1D052BC2692@jnpr.net>

Phil,
Do you have UDP flood screen enabled? If yes what is the threshold and UDP 
packet size you are using?
What you descibe below is very similar to how UDP (and ICMP) flood screen 
operates.
Rgds
Alex

----- Original Message ----- 
From: "Phil Mayers" <p.mayers at imperial.ac.uk>
To: <juniper-nsp at puck.nether.net>
Sent: Thursday, March 04, 2010 5:40 PM
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?


> All,
>
> I'm working with JTAC on this, but they're stumped so far and I thought 
> I'd throw it out here.
>
> We have an NSRP pair of netscreen 5400s in a slightly complex 
> configuration.
>
> Each firewall has a single 10gig port with multiple sub-ints. Each sub-int 
> is bound to a zone and the netscreens route traffic between them (and 
> apply policy). Rather than using VSIs we configure downstream BGP routing 
> policy to split traffic between the firewalls very successfully. 
> Effectively, the NSRP serves only to sync up the address & policy configs.
>
> We have recently discovered that UDP flows with any (src,port) to a 
> specific (dst,port) pair seem to be capped at the weirdly precise value of 
> 5.8Mbit/sec. See below for more info on the exact traffic pattern.
>
> That is, if we have:
>
> source1, sport 1234, dport 5000 - offers 10mbit/sec of UDP
> source2, sport 5678, dport 5000 - offers 10mbit/sec of UDP
>
> At the receiver, destination port 5000 receives 5.8mbit/sec total, split 
> approx 50/50 between the two senders i.e. ~3mbit/sec received per-sender, 
> ~70% loss per flow. Stopping one sender means the other gets the full 
> ~5.8Mbit/sec.
>
> There are no apparently traffic limits using TCP or, weirdly, GRE (using 
> GRE p2p interfaces on source->dest). I'm using two linux boxes and iperf 
> to generate the test traffic:
>
> iperf -i 1 -u -c dest -b 10M
>
> ...but the original report was for real UDP traffic.
>
> Now, there are as far as I'm aware no rate-limiting, bandwidth, QoS or 
> other policies configured either on the firewall and definitely not on the 
> router it is attached to. JTAC have not spotted anything.
>
> If I take a SPAN (port mirror) of the 10gig port on the router facing the 
> firewall, I see the following traffic pattern, correlating in/out packets 
> by IP IP# and source/dest MAC address:
>
> 0.00 - 0.59 seconds - packets flow normally (~725kbyte of data)
> 0.60 - 0.99 seconds - packets go into the netscreen but do not come back 
> out
> 1.00 - 1.59 seconds - packets flow normally
>
> ...and so on.
>
> It's frankly bizarre.
>
> I have verified that this still occurs with "no-hw-sess" on the policy 
> after being advised to try this by JTAC.
>
> ScreenOS version is 6.2.0r4.0, hardware is M2 management blades and 2XGE 
> 10gig linecards.
>
> The router attached to the firewall is a 6509/sup720 and I have confidence 
> it is not implicated in the loss.
>
> Any suggestions?
>
> Cheers,
> Phil
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From p.mayers at imperial.ac.uk  Fri Mar  5 05:15:45 2010
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 05 Mar 2010 10:15:45 +0000
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?
In-Reply-To: <F71780005DBD470B8B2EB1D052BC2692@jnpr.net>
References: <4B8FF091.2020607@imperial.ac.uk>
	<F71780005DBD470B8B2EB1D052BC2692@jnpr.net>
Message-ID: <4B90D9D1.60509@imperial.ac.uk>

On 03/05/2010 10:10 AM, Alex wrote:
> Phil,
> Do you have UDP flood screen enabled? If yes what is the threshold and UDP
> packet size you are using?

Not on the zones through which the traffic is flowing (Untrust & Trust) 
according to the CLI & webUI:

set zone "Untrust" screen tear-drop
set zone "Untrust" screen syn-flood
set zone "Untrust" screen ping-death
set zone "Untrust" screen ip-filter-src
set zone "Untrust" screen land
set zone "V1-Untrust" screen tear-drop
set zone "V1-Untrust" screen syn-flood
set zone "V1-Untrust" screen ping-death
set zone "V1-Untrust" screen ip-filter-src
set zone "V1-Untrust" screen land
set zone "Halls" screen alarm-without-drop
set zone "Halls" screen icmp-flood
set zone "Halls" screen udp-flood
set zone "Halls" screen syn-flood

Damn... wait a minute.

I recall something about screen options and vlan sub-ints, in the 
release notes.

Hmm.

From p.mayers at imperial.ac.uk  Fri Mar  5 05:17:46 2010
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 05 Mar 2010 10:17:46 +0000
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?
In-Reply-To: <4B90D9D1.60509@imperial.ac.uk>
References: <4B8FF091.2020607@imperial.ac.uk>
	<F71780005DBD470B8B2EB1D052BC2692@jnpr.net>
	<4B90D9D1.60509@imperial.ac.uk>
Message-ID: <4B90DA4A.1020900@imperial.ac.uk>

On 03/05/2010 10:15 AM, Phil Mayers wrote:
>
> Damn... wait a minute.
>
> I recall something about screen options and vlan sub-ints, in the
> release notes.
>
> Hmm.

Blast.

Yes - it was the UDP screen. Even though it's applied on a zone bound to 
a sub-int, evidently it works on a per-physical-interface basis.

Making it nearly useless for us, sigh.

Good suggestion, thanks for the pointer.

From p.mayers at imperial.ac.uk  Fri Mar  5 05:32:28 2010
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 05 Mar 2010 10:32:28 +0000
Subject: [j-nsp] Netscreen 5400 per-UDP-port bandwidth cap?
In-Reply-To: <4B90DA4A.1020900@imperial.ac.uk>
References: <4B8FF091.2020607@imperial.ac.uk>
	<F71780005DBD470B8B2EB1D052BC2692@jnpr.net>
	<4B90D9D1.60509@imperial.ac.uk> <4B90DA4A.1020900@imperial.ac.uk>
Message-ID: <4B90DDBC.2010903@imperial.ac.uk>

On 03/05/2010 10:17 AM, Phil Mayers wrote:
> On 03/05/2010 10:15 AM, Phil Mayers wrote:
>>
>> Damn... wait a minute.
>>
>> I recall something about screen options and vlan sub-ints, in the
>> release notes.
>>
>> Hmm.
>
> Blast.
>
> Yes - it was the UDP screen. Even though it's applied on a zone bound to
> a sub-int, evidently it works on a per-physical-interface basis.

In fact, the ScreenOS 6.2r4 release notes state:

"""Flood Screens ? On ISG 1000, ISG 2000, NetScreen-5000 Series devices,
the UDP and ICMP flood screens apply to the physical interface and
therefore require that the zone be bound to a physical interface. The
following limitations apply:

   * When zones are bound to a sub-interface, the ICMP and UDP flood
screen are not enforced unless the zone is also bound to a physical
interface.

   * When ICMP and UDP flood screen options are configured for different
zones and on the same physical interface, the flood threshold is applied
based on the last configured zone threshold.
"""

I would argue this is misleading wording and it does not in fact 
represent our exact config - but disabling the "UDP Flood" option on the 
"Foo" zone does indeed allow UDP traffic between "Trust" and "Untrust" 
zones whose sub-ints are on the same physical int as "Foo".

One wonders why the screen options are configured on a zone basis if 
they apply to physical ints on this platform...

From snar at snar.spb.ru  Fri Mar  5 06:26:59 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Fri, 5 Mar 2010 14:26:59 +0300
Subject: [j-nsp] EX-series automation, NETCONF woes
In-Reply-To: <20090128204010.GD13982@kallisti.us>
References: <20090127212328.GB3042@kallisti.us>
	<9BDABFEC-F8C2-4B9E-B273-D4434AF93C65@hopcount.ca>
	<20090128173413.GC13982@kallisti.us>
	<500573.14540.qm@web180007.mail.gq1.yahoo.com>
	<20090128204010.GD13982@kallisti.us>
Message-ID: <20100305112659.GB90104@snar.spb.ru>

On Wed, Jan 28, 2009 at 03:40:10PM -0500, Ross Vandegrift wrote:
> On Wed, Jan 28, 2009 at 11:17:11AM -0800, Derick Winkworth wrote:
> > xpath notation can help you find "junos-interface:interfaces" no
> > matter where its located.
> 
> Can you do that without providing a map that maps the abbreviated
> namespace back to the fully-qualified namespace?  If so, I'd love to
> know how.

Just run into the same problem myself, and workaround is here:
you can use local-name() function to do namespace-agnostic 
searches, and you can use partial checks on namespaces to be
sure that you getting what you want. 

Example: iterate over physical interfaces:  

    <xsl:for-each select="//*[local-name()='physical-interface' and 
        starts-with(namespace-uri(), 'http://xml.juniper.net/junos/')]">

Select operational state: 

        <xsl:variable name="oper"
            select="normalize-space(*[local-name()='oper-status'])"/>

Select dropped packets for first queue: 

        select="normalize-space(*[local-name()='queue-counters']/*[local-name()='queue' and *[local-name()='queue-number']=0]/*[local-name()='queue-counters-red-packets'])"/>


Syntax is ugly, but it works... 


> In my understanding, the XPath query ".//junos-interface:interfaces" [1]
> only matches
> "<http://xml.juniper.net/junos/9.3R2/junos-interface:interfaces>" if I
> can somewhere say that
> "junos-interface = http://xml.juniper.net/junos/9.3R2/junos-interface".
> 
> That just moves the problem to one of making a namespace map.
> 
> 
> Ross
> 
> [1] - that's the XPath to find the element named "interfaces" from the
> namespace that's been abbreviated "junos-interface" in any subtree.
> 
> -- 
> Ross Vandegrift
> ross at kallisti.us
> 
> "If the fight gets hot, the songs get hotter.  If the going gets tough,
> the songs get tougher."
> 	--Woody Guthrie
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

From ross at kallisti.us  Fri Mar  5 07:51:37 2010
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 5 Mar 2010 07:51:37 -0500
Subject: [j-nsp] EX-series automation, NETCONF woes
In-Reply-To: <20100305112659.GB90104@snar.spb.ru>
References: <20090127212328.GB3042@kallisti.us>
	<9BDABFEC-F8C2-4B9E-B273-D4434AF93C65@hopcount.ca>
	<20090128173413.GC13982@kallisti.us>
	<500573.14540.qm@web180007.mail.gq1.yahoo.com>
	<20090128204010.GD13982@kallisti.us>
	<20100305112659.GB90104@snar.spb.ru>
Message-ID: <20100305125137.GB8238@kallisti.us>

On Fri, Mar 05, 2010 at 02:26:59PM +0300, Alexandre Snarskii wrote:
> On Wed, Jan 28, 2009 at 03:40:10PM -0500, Ross Vandegrift wrote:
> > Can you do that without providing a map that maps the abbreviated
> > namespace back to the fully-qualified namespace?  If so, I'd love to
> > know how.
> 
> Just run into the same problem myself, and workaround is here:
> you can use local-name() function to do namespace-agnostic 
> searches, and you can use partial checks on namespaces to be
> sure that you getting what you want. 
> 
> Example: iterate over physical interfaces:  
> 
>     <xsl:for-each select="//*[local-name()='physical-interface' and 
>         starts-with(namespace-uri(), 'http://xml.juniper.net/junos/')]">
> 
> Select operational state: 
> 
>         <xsl:variable name="oper"
>             select="normalize-space(*[local-name()='oper-status'])"/>
> 
> Select dropped packets for first queue: 
> 
>         select="normalize-space(*[local-name()='queue-counters']/*[local-name()='queue' and *[local-name()='queue-number']=0]/*[local-name()='queue-counters-red-packets'])"/>
> 
> 
> Syntax is ugly, but it works... 

I've been meaning to write up my solution to this, but haven't had the
chance.  It turns out that lxml exposes namespace assignments in a
programmatically accessible manner.

Building the map I mention above ends up being very easy and means I
can rid myself of all the absurd XSLT mangling I had to do.  I wish
the exposure of the namespace information had been more clearly
documented - or that I had noticed it earlier!

For Python folks, suppose that ncdoc is a netconf document.  Then
here's the quick version of how to build an appropriate map of
specific namespaces from a given JUNOS response:

namepsaces = set()
nsmap = dict()

for i in ncdoc.getiterator():
	namespaces.update(set(i.nsmap.values()))
for ns in namespaces:
	shortname = ns.split('/')[-1]
	nsmap[shortname]

# Now you can use normal XML tree traversal techniques
e = nsdoc.getroot()
name = e.xpath("./junos-interface:name/text()", namespaces=nsmap)
operstat = e.xpath("./junos-interface:oper-status/text()", namespaces=nsmap)
...etc...

This should works for any JUNOS platform that uses the consistent
namespace abbreviations we're all used to reading.  Hopefully that's
all of them, forever :)

Ross

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100305/b6d6016f/attachment-0001.bin>

From d.nostra at gmail.com  Sat Mar  6 04:34:35 2010
From: d.nostra at gmail.com (Michel de Nostredame)
Date: Sat, 6 Mar 2010 09:34:35 +0000
Subject: [j-nsp] completely disable session (flow) in netscreen
Message-ID: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>

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~

From davidm at futureinquestion.net  Sat Mar  6 04:14:42 2010
From: davidm at futureinquestion.net (David Monosov)
Date: Sat, 06 Mar 2010 10:14:42 +0100
Subject: [j-nsp] JUNOSe multi-topology IS-IS support?
Message-ID: <4B921D02.6070802@futureinquestion.net>

Dear juniper-nsp,

It recently came to my attention that JUNOSe up to and incl. ver. 11.0 appears
to offer no support for multi-topology IS-IS (RFC 5120).

Did other JUNOSe users on this list previously encounter this unfortunate
limitation (or expect to in a planned IPv6 deployment) and would like to
collectively push this issue so that it could gain some momentum within Juniper
Networks?

Does anyone have any experiences (or ideas) to share on the subject of elegantly
integrating JUNOSe devices into multi-topology IPv4 and IPv6 IS-IS domains
without this feature?

--
Respectfully yours,

David Monosov


From eric at atlantech.net  Sat Mar  6 07:53:41 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Sat, 6 Mar 2010 07:53:41 -0500
Subject: [j-nsp] Strange IS-IS Problem
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>

Hi all,
I've got a strange ISIS problem and I'm hoping another set of eyes can help me identify what is wrong here.  I've got an MX960 logically connected to a J2320 through two EX2500 switches:

MX960 <==> EX2500 <==> EX2500 <==> J2320

I'm simply trying to get ISIS working between the two routers and it's not coming up.  Traceoptions don't show anything out of the ordinary.

MX960:
xe-1/2/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.99/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.74/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface xe-1/2/0.1;
        interface lo0.0 {
            passive;
        }
    }
}


J2320:
ge-0/0/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.100/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.75/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface ge-0/0/0.1;
        interface lo0.0 {
            passive;
        }
    }
}

I can ping fine between the two:

root at router1# run ping x.x.x.99 source x.x.x.100    
PING x.x.x.99 (x.x.x.99): 56 data bytes
64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
^C
--- x.x.x.99 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms

If I monitor traffic on either of the interfaces, I see ISIS packets leaving, but nothing coming in.  The EX2500s have a very vanilla config and I'm doing no filtering on them.

Any ideas?

Thanks,
evt


From walaaez at bmc.com.sa  Sat Mar  6 08:24:00 2010
From: walaaez at bmc.com.sa (Walaa Abdel razzak)
Date: Sat, 6 Mar 2010 16:24:00 +0300
Subject: [j-nsp] Strange IS-IS Problem
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
Message-ID: <E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>

Hi

- If you have an aggregate between switches, routers... make sure they
are correctly configured from both sides?
- Also Try to check duplex. 
- Is there is possibility to connect the routers directly? This will
isolate the problem.

Best Regards,
Walaa Abdel Razzak

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
Sent: Saturday, March 06, 2010 3:54 PM
To: Juniper-Nsp
Subject: [j-nsp] Strange IS-IS Problem

Hi all,
I've got a strange ISIS problem and I'm hoping another set of eyes can
help me identify what is wrong here.  I've got an MX960 logically
connected to a J2320 through two EX2500 switches:

MX960 <==> EX2500 <==> EX2500 <==> J2320

I'm simply trying to get ISIS working between the two routers and it's
not coming up.  Traceoptions don't show anything out of the ordinary.

MX960:
xe-1/2/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.99/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.74/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface xe-1/2/0.1;
        interface lo0.0 {
            passive;
        }
    }
}


J2320:
ge-0/0/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.100/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.75/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface ge-0/0/0.1;
        interface lo0.0 {
            passive;
        }
    }
}

I can ping fine between the two:

root at router1# run ping x.x.x.99 source x.x.x.100    
PING x.x.x.99 (x.x.x.99): 56 data bytes
64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
^C
--- x.x.x.99 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms

If I monitor traffic on either of the interfaces, I see ISIS packets
leaving, but nothing coming in.  The EX2500s have a very vanilla config
and I'm doing no filtering on them.

Any ideas?

Thanks,
evt

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
 

__________ Information from ESET Smart Security, version of virus
signature database 4920 (20100306) __________

The message was checked by ESET Smart Security.

http://www.eset.com
 
 

__________ Information from ESET Smart Security, version of virus
signature database 4920 (20100306) __________

The message was checked by ESET Smart Security.

http://www.eset.com
 


From sfouant at shortestpathfirst.net  Sat Mar  6 09:41:11 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 6 Mar 2010 14:41:11 +0000
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
Message-ID: <1897172699-1267886536-cardhu_decombobulator_blackberry.rim.net-1054015706-@bda294.bisx.prod.on.blackberry>

What happens when you reduce the physical MTUs on the MX and the J-Series to something smaller?  Same behavior?

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Eric Van Tol <eric at atlantech.net>
Date: Sat, 6 Mar 2010 07:53:41 
To: Juniper-Nsp<juniper-nsp at puck.nether.net>
Subject: [j-nsp] Strange IS-IS Problem

Hi all,
I've got a strange ISIS problem and I'm hoping another set of eyes can help me identify what is wrong here.  I've got an MX960 logically connected to a J2320 through two EX2500 switches:

MX960 <==> EX2500 <==> EX2500 <==> J2320

I'm simply trying to get ISIS working between the two routers and it's not coming up.  Traceoptions don't show anything out of the ordinary.

MX960:
xe-1/2/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.99/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.74/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface xe-1/2/0.1;
        interface lo0.0 {
            passive;
        }
    }
}


J2320:
ge-0/0/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.100/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.75/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface ge-0/0/0.1;
        interface lo0.0 {
            passive;
        }
    }
}

I can ping fine between the two:

root at router1# run ping x.x.x.99 source x.x.x.100    
PING x.x.x.99 (x.x.x.99): 56 data bytes
64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
^C
--- x.x.x.99 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms

If I monitor traffic on either of the interfaces, I see ISIS packets leaving, but nothing coming in.  The EX2500s have a very vanilla config and I'm doing no filtering on them.

Any ideas?

Thanks,
evt

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From BBlackford at nwresd.k12.or.us  Sat Mar  6 09:55:28 2010
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Sat, 6 Mar 2010 06:55:28 -0800
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <1897172699-1267886536-cardhu_decombobulator_blackberry.rim.net-1054015706-@bda294.bisx.prod.on.blackberry>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<1897172699-1267886536-cardhu_decombobulator_blackberry.rim.net-1054015706-@bda294.bisx.prod.on.blackberry>
Message-ID: <6069A203FD01884885C037F81DD750801748C4B7BD@wsc-mail-01.intra.nwresd.k12.or.us>

Are the EX2500's configured for jumbos?

-b

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Stefan Fouant
Sent: Saturday, March 06, 2010 6:41 AM
To: Eric Van Tol; juniper-nsp-bounces at puck.nether.net; Juniper-Nsp
Subject: Re: [j-nsp] Strange IS-IS Problem

What happens when you reduce the physical MTUs on the MX and the J-Series to something smaller?  Same behavior?

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Eric Van Tol <eric at atlantech.net>
Date: Sat, 6 Mar 2010 07:53:41 
To: Juniper-Nsp<juniper-nsp at puck.nether.net>
Subject: [j-nsp] Strange IS-IS Problem

Hi all,
I've got a strange ISIS problem and I'm hoping another set of eyes can help me identify what is wrong here.  I've got an MX960 logically connected to a J2320 through two EX2500 switches:

MX960 <==> EX2500 <==> EX2500 <==> J2320

I'm simply trying to get ISIS working between the two routers and it's not coming up.  Traceoptions don't show anything out of the ordinary.

MX960:
xe-1/2/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.99/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.74/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface xe-1/2/0.1;
        interface lo0.0 {
            passive;
        }
    }
}


J2320:
ge-0/0/0 {
    vlan-tagging;
    mtu 9192;
    unit 1 {
        vlan-id 1;
        family inet {
            mtu 1500;
            address x.x.x.100/28;
        }
        family iso;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 127.0.0.1/32;
            address x.x.x.75/32;
        }
        family iso {
            address 47.0001.xxxx.xxxx.xxxx.00;
        }
    }
}
...
protocols {
    isis {
        interface ge-0/0/0.1;
        interface lo0.0 {
            passive;
        }
    }
}

I can ping fine between the two:

root at router1# run ping x.x.x.99 source x.x.x.100    
PING x.x.x.99 (x.x.x.99): 56 data bytes
64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
^C
--- x.x.x.99 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms

If I monitor traffic on either of the interfaces, I see ISIS packets leaving, but nothing coming in.  The EX2500s have a very vanilla config and I'm doing no filtering on them.

Any ideas?

Thanks,
evt

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From cra at WPI.EDU  Sat Mar  6 11:06:16 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 6 Mar 2010 11:06:16 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
Message-ID: <20100306160616.GA25459@angus.ind.WPI.EDU>

On Sat, Mar 06, 2010 at 07:53:41AM -0500, Eric Van Tol wrote:
> MX960:
> xe-1/2/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.99/28;
>         }
>         family iso;
>     }
> }

Can you try configuring family iso mtu 1500?


From cra at WPI.EDU  Sat Mar  6 11:11:35 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 6 Mar 2010 11:11:35 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <20100306160616.GA25459@angus.ind.WPI.EDU>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<20100306160616.GA25459@angus.ind.WPI.EDU>
Message-ID: <20100306161135.GB25459@angus.ind.WPI.EDU>

On Sat, Mar 06, 2010 at 11:06:16AM -0500, Chuck Anderson wrote:
> On Sat, Mar 06, 2010 at 07:53:41AM -0500, Eric Van Tol wrote:
> > MX960:
> > xe-1/2/0 {
> >     vlan-tagging;
> >     mtu 9192;
> >     unit 1 {
> >         vlan-id 1;
> >         family inet {
> >             mtu 1500;
> >             address x.x.x.99/28;
> >         }
> >         family iso;
> >     }
> > }
> 
> Can you try configuring family iso mtu 1500?

Actually, you may need mtu 1497:

http://www.juniper.net/techpubs/software/junos/junos56/swconfig56-interfaces/html/interfaces-physical-config5.html

From alexei at twine-networks.com  Sat Mar  6 14:55:38 2010
From: alexei at twine-networks.com (Alexey Kholmov)
Date: Sat, 6 Mar 2010 22:55:38 +0300
Subject: [j-nsp] EX4200 upgrade
Message-ID: <77C85974-CFC0-4A83-9DE0-9F7A17E6ECFF@twine-networks.com>

Hi juniper-nsp,

I need to upgrade EX4200.

Please advise which version of JUNOS should I use?

Thank you in advance!

Regards,
Alexey Kholmov


From d.nostra at gmail.com  Sat Mar  6 15:15:11 2010
From: d.nostra at gmail.com (Michel de Nostredame)
Date: Sat, 6 Mar 2010 20:15:11 +0000
Subject: [j-nsp] EX4200 upgrade
In-Reply-To: <77C85974-CFC0-4A83-9DE0-9F7A17E6ECFF@twine-networks.com>
References: <77C85974-CFC0-4A83-9DE0-9F7A17E6ECFF@twine-networks.com>
Message-ID: <454d328c1003061215l5b65f59dk4d1b8893d29d02e5@mail.gmail.com>

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
<alexei at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From eric at atlantech.net  Sat Mar  6 16:07:23 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Sat, 6 Mar 2010 16:07:23 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C904@exchange.aoihq.local>

Answers to several questions from various sources below:

> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?

The EX2500s are connected together via two 10G ports, aggregated into a portchannel.  No errors on that or the interfaces on the EX2500s.

> - Also Try to check duplex.

Duplex is not a problem.

> - Is there is possibility to connect the routers directly? This will
> isolate the problem.

There is, but I am not physically in front of the routers at the moment.  My next test on Monday was to connect the J2320 up to ge-1/0/0 on the MX960.

> What happens when you reduce the physical MTUs on the MX and the 
> J-Series to something smaller?  Same behavior?

Unfortunately, yes, I get the same behavior.

> Are the EX2500's configured for jumbos?

I thought of this earlier and checked the documentation, but while it does state that the EX2500 supports jumbo frames, there is absolutley nothing in the docs that says how to configure this feature.  A search for 'jumbo' yields two hits and a search for 'mtu' yields nothing.  I *can* ping from one router to the other with 1472-byte packets with the df-bit set, so I know that my 1500-byte packet can get through no problem.

> Try adding the point-to-point command under protocols Isis xxx  
> interface.

This does nothing, unfortunately.  Besides, the original setup was supposed to be that xe-1/2/0.1 be in a bridge-group with interface irb.1 as its routing interface, so point-to-point wouldn't meet my end goal.  When that didn't work, I simplified it for troubleshooting to just be a plain vlan trunk routed interface.

> Can you try configuring family iso mtu 1500?

I've tried 1497 and 1500 to no avail. :-(

My feeling is that there is something happening inside the EX2500s of which I am not aware.  These are brand new switches that I've no experience configuring, but I would think that if I can ping through them after configuring trunk and portchannel interfaces, that there'd really be no other config necessary in this very simple topology (besides MSTP).

Thanks to all for your suggestions thus far.

-evt

> -----Original Message-----
> From: Walaa Abdel razzak [mailto:walaaez at bmc.com.sa]
> Sent: Saturday, March 06, 2010 8:24 AM
> To: Eric Van Tol; Juniper-Nsp
> Subject: RE: [j-nsp] Strange IS-IS Problem
> 
> Hi
> 
> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?
> - Also Try to check duplex.
> - Is there is possibility to connect the routers directly? This will
> isolate the problem.
> 
> Best Regards,
> Walaa Abdel Razzak
> 
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Saturday, March 06, 2010 3:54 PM
> To: Juniper-Nsp
> Subject: [j-nsp] Strange IS-IS Problem
> 
> Hi all,
> I've got a strange ISIS problem and I'm hoping another set of eyes can
> help me identify what is wrong here.  I've got an MX960 logically
> connected to a J2320 through two EX2500 switches:
> 
> MX960 <==> EX2500 <==> EX2500 <==> J2320
> 
> I'm simply trying to get ISIS working between the two routers and it's
> not coming up.  Traceoptions don't show anything out of the ordinary.
> 
> MX960:
> xe-1/2/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.99/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.74/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface xe-1/2/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
> 
> 
> J2320:
> ge-0/0/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.100/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.75/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface ge-0/0/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
> 
> I can ping fine between the two:
> 
> root at router1# run ping x.x.x.99 source x.x.x.100
> PING x.x.x.99 (x.x.x.99): 56 data bytes
> 64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
> 64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
> 64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
> 64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
> 64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
> ^C
> --- x.x.x.99 ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms
> 
> If I monitor traffic on either of the interfaces, I see ISIS packets
> leaving, but nothing coming in.  The EX2500s have a very vanilla config
> and I'm doing no filtering on them.
> 
> Any ideas?
> 
> Thanks,
> evt
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
> 
> The message was checked by ESET Smart Security.
> 
> http://www.eset.com
> 
> 
> 
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
> 
> The message was checked by ESET Smart Security.
> 
> http://www.eset.com
> 


From dwinkworth at att.net  Sun Mar  7 01:25:56 2010
From: dwinkworth at att.net (Derick Winkworth)
Date: Sat, 6 Mar 2010 22:25:56 -0800 (PST)
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C904@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C904@exchange.aoihq.local>
Message-ID: <209782.88507.qm@web180011.mail.gq1.yahoo.com>

If its JUNOS, then just configure the MTU normally in the interface config on the switch.



________________________________
From: Eric Van Tol <eric at atlantech.net>
To: Juniper-Nsp <juniper-nsp at puck.nether.net>
Sent: Sat, March 6, 2010 3:07:23 PM
Subject: Re: [j-nsp] Strange IS-IS Problem

Answers to several questions from various sources below:

> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?

The EX2500s are connected together via two 10G ports, aggregated into a portchannel.  No errors on that or the interfaces on the EX2500s.

> - Also Try to check duplex.

Duplex is not a problem.

> - Is there is possibility to connect the routers directly? This will
> isolate the problem.

There is, but I am not physically in front of the routers at the moment.  My next test on Monday was to connect the J2320 up to ge-1/0/0 on the MX960.

> What happens when you reduce the physical MTUs on the MX and the 
> J-Series to something smaller?  Same behavior?

Unfortunately, yes, I get the same behavior.

> Are the EX2500's configured for jumbos?

I thought of this earlier and checked the documentation, but while it does state that the EX2500 supports jumbo frames, there is absolutley nothing in the docs that says how to configure this feature.  A search for 'jumbo' yields two hits and a search for 'mtu' yields nothing.  I *can* ping from one router to the other with 1472-byte packets with the df-bit set, so I know that my 1500-byte packet can get through no problem.

> Try adding the point-to-point command under protocols Isis xxx  
> interface.

This does nothing, unfortunately.  Besides, the original setup was supposed to be that xe-1/2/0.1 be in a bridge-group with interface irb.1 as its routing interface, so point-to-point wouldn't meet my end goal.  When that didn't work, I simplified it for troubleshooting to just be a plain vlan trunk routed interface.

> Can you try configuring family iso mtu 1500?

I've tried 1497 and 1500 to no avail. :-(

My feeling is that there is something happening inside the EX2500s of which I am not aware.  These are brand new switches that I've no experience configuring, but I would think that if I can ping through them after configuring trunk and portchannel interfaces, that there'd really be no other config necessary in this very simple topology (besides MSTP).

Thanks to all for your suggestions thus far.

-evt

> -----Original Message-----
> From: Walaa Abdel razzak [mailto:walaaez at bmc.com.sa]
> Sent: Saturday, March 06, 2010 8:24 AM
> To: Eric Van Tol; Juniper-Nsp
> Subject: RE: [j-nsp] Strange IS-IS Problem
> 
> Hi
> 
> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?
> - Also Try to check duplex.
> - Is there is possibility to connect the routers directly? This will
> isolate the problem.
> 
> Best Regards,
> Walaa Abdel Razzak
> 
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Saturday, March 06, 2010 3:54 PM
> To: Juniper-Nsp
> Subject: [j-nsp] Strange IS-IS Problem
> 
> Hi all,
> I've got a strange ISIS problem and I'm hoping another set of eyes can
> help me identify what is wrong here.  I've got an MX960 logically
> connected to a J2320 through two EX2500 switches:
> 
> MX960 <==> EX2500 <==> EX2500 <==> J2320
> 
> I'm simply trying to get ISIS working between the two routers and it's
> not coming up.  Traceoptions don't show anything out of the ordinary.
> 
> MX960:
> xe-1/2/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.99/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.74/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface xe-1/2/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
> 
> 
> J2320:
> ge-0/0/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.100/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.75/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface ge-0/0/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
> 
> I can ping fine between the two:
> 
> root at router1# run ping x.x.x.99 source x.x.x.100
> PING x.x.x.99 (x.x.x.99): 56 data bytes
> 64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
> 64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
> 64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
> 64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
> 64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
> ^C
> --- x.x.x.99 ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms
> 
> If I monitor traffic on either of the interfaces, I see ISIS packets
> leaving, but nothing coming in.  The EX2500s have a very vanilla config
> and I'm doing no filtering on them.
> 
> Any ideas?
> 
> Thanks,
> evt
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
> 
> The message was checked by ESET Smart Security.
> 
> http://www.eset.com
> 
> 
> 
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
> 
> The message was checked by ESET Smart Security.
> 
> http://www.eset.com
> 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

From danno at appliedi.net  Sun Mar  7 01:56:43 2010
From: danno at appliedi.net (Dan Farrell)
Date: Sat, 6 Mar 2010 22:56:43 -0800
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
References: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
Message-ID: <06275CB4814DA94AB880409FDD8D779C148E4C688F@EXMBXCLUS01.citservers.local>

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

danno at appliedi.net

________________________________________
From: juniper-nsp-bounces at puck.nether.net [juniper-nsp-bounces at puck.nether.net] On Behalf Of Michel de Nostredame [d.nostra at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From danno at appliedi.net  Sun Mar  7 02:06:19 2010
From: danno at appliedi.net (Dan Farrell)
Date: Sat, 6 Mar 2010 23:06:19 -0800
Subject: [j-nsp] EX4200 upgrade
In-Reply-To: <454d328c1003061215l5b65f59dk4d1b8893d29d02e5@mail.gmail.com>
References: <77C85974-CFC0-4A83-9DE0-9F7A17E6ECFF@twine-networks.com>,
	<454d328c1003061215l5b65f59dk4d1b8893d29d02e5@mail.gmail.com>
Message-ID: <06275CB4814DA94AB880409FDD8D779C148E4C6890@EXMBXCLUS01.citservers.local>

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
danno at appliedi.net

________________________________________
From: juniper-nsp-bounces at puck.nether.net [juniper-nsp-bounces at puck.nether.net] On Behalf Of Michel de Nostredame [d.nostra at gmail.com]
Sent: Saturday, March 06, 2010 3:15 PM
To: Alexey Kholmov
Cc: juniper-nsp at 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
<alexei at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From xmin0s at gmail.com  Sun Mar  7 02:11:08 2010
From: xmin0s at gmail.com (Tim Eberhard)
Date: Sun, 7 Mar 2010 01:11:08 -0600
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
References: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
Message-ID: <2c52b84e1003062311y1ea45749t753e0e43a536eb34@mail.gmail.com>

To deal with asymmetric routing problems you can disable tcp-syn-checking.
That will disable the stateful enforcement (and greatly weaken security of
the box). I'd also ensure you disable syn-checking in the tunnel (since
you're using ipsec tunnels).

Beyond that, write your policy bi-directionally ensuring any side can create
the session and that should fit your needs. Even if the session times out
with syn-checking disabled and it's permitted by policy it will be instantly
recreated with the next packet.

Hope this helps,
-Tim Eberhard

On Sat, Mar 6, 2010 at 3:34 AM, Michel de Nostredame <d.nostra at gmail.com>wrote:

> 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From david.roy at orange-ftgroup.com  Sun Mar  7 03:19:12 2010
From: david.roy at orange-ftgroup.com (david.roy at orange-ftgroup.com)
Date: Sun, 7 Mar 2010 09:19:12 +0100
Subject: [j-nsp] RE :  Strange IS-IS Problem
In-Reply-To: <209782.88507.qm@web180011.mail.gq1.yahoo.com>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C904@exchange.aoihq.local>,
	<209782.88507.qm@web180011.mail.gq1.yahoo.com>
Message-ID: <22006_1267950052_4B9361E4_22006_24276_1_153490EA03CE634EBD317768617B6310471E951A7B@PMEXCB1A.intranet-paris.francetelecom.fr>

Hi 

Did you try to check via Tcpdump on your MX, the size of the MX ISIS Hello packet (with the hello padding) ? 

Regards,
 David

________________________________________
De : juniper-nsp-bounces at puck.nether.net [juniper-nsp-bounces at puck.nether.net] de la part de Derick Winkworth [dwinkworth at att.net]
Date d'envoi : dimanche 7 mars 2010 07:25
? : Eric Van Tol; Juniper-Nsp
Objet : Re: [j-nsp] Strange IS-IS Problem

If its JUNOS, then just configure the MTU normally in the interface config on the switch.



________________________________
From: Eric Van Tol <eric at atlantech.net>
To: Juniper-Nsp <juniper-nsp at puck.nether.net>
Sent: Sat, March 6, 2010 3:07:23 PM
Subject: Re: [j-nsp] Strange IS-IS Problem

Answers to several questions from various sources below:

> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?

The EX2500s are connected together via two 10G ports, aggregated into a portchannel.  No errors on that or the interfaces on the EX2500s.

> - Also Try to check duplex.

Duplex is not a problem.

> - Is there is possibility to connect the routers directly? This will
> isolate the problem.

There is, but I am not physically in front of the routers at the moment.  My next test on Monday was to connect the J2320 up to ge-1/0/0 on the MX960.

> What happens when you reduce the physical MTUs on the MX and the
> J-Series to something smaller?  Same behavior?

Unfortunately, yes, I get the same behavior.

> Are the EX2500's configured for jumbos?

I thought of this earlier and checked the documentation, but while it does state that the EX2500 supports jumbo frames, there is absolutley nothing in the docs that says how to configure this feature.  A search for 'jumbo' yields two hits and a search for 'mtu' yields nothing.  I *can* ping from one router to the other with 1472-byte packets with the df-bit set, so I know that my 1500-byte packet can get through no problem.

> Try adding the point-to-point command under protocols Isis xxx
> interface.

This does nothing, unfortunately.  Besides, the original setup was supposed to be that xe-1/2/0.1 be in a bridge-group with interface irb.1 as its routing interface, so point-to-point wouldn't meet my end goal.  When that didn't work, I simplified it for troubleshooting to just be a plain vlan trunk routed interface.

> Can you try configuring family iso mtu 1500?

I've tried 1497 and 1500 to no avail. :-(

My feeling is that there is something happening inside the EX2500s of which I am not aware.  These are brand new switches that I've no experience configuring, but I would think that if I can ping through them after configuring trunk and portchannel interfaces, that there'd really be no other config necessary in this very simple topology (besides MSTP).

Thanks to all for your suggestions thus far.

-evt

> -----Original Message-----
> From: Walaa Abdel razzak [mailto:walaaez at bmc.com.sa]
> Sent: Saturday, March 06, 2010 8:24 AM
> To: Eric Van Tol; Juniper-Nsp
> Subject: RE: [j-nsp] Strange IS-IS Problem
>
> Hi
>
> - If you have an aggregate between switches, routers... make sure they
> are correctly configured from both sides?
> - Also Try to check duplex.
> - Is there is possibility to connect the routers directly? This will
> isolate the problem.
>
> Best Regards,
> Walaa Abdel Razzak
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Saturday, March 06, 2010 3:54 PM
> To: Juniper-Nsp
> Subject: [j-nsp] Strange IS-IS Problem
>
> Hi all,
> I've got a strange ISIS problem and I'm hoping another set of eyes can
> help me identify what is wrong here.  I've got an MX960 logically
> connected to a J2320 through two EX2500 switches:
>
> MX960 <==> EX2500 <==> EX2500 <==> J2320
>
> I'm simply trying to get ISIS working between the two routers and it's
> not coming up.  Traceoptions don't show anything out of the ordinary.
>
> MX960:
> xe-1/2/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.99/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.74/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface xe-1/2/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
>
>
> J2320:
> ge-0/0/0 {
>     vlan-tagging;
>     mtu 9192;
>     unit 1 {
>         vlan-id 1;
>         family inet {
>             mtu 1500;
>             address x.x.x.100/28;
>         }
>         family iso;
>     }
> }
> lo0 {
>     unit 0 {
>         family inet {
>             address 127.0.0.1/32;
>             address x.x.x.75/32;
>         }
>         family iso {
>             address 47.0001.xxxx.xxxx.xxxx.00;
>         }
>     }
> }
> ...
> protocols {
>     isis {
>         interface ge-0/0/0.1;
>         interface lo0.0 {
>             passive;
>         }
>     }
> }
>
> I can ping fine between the two:
>
> root at router1# run ping x.x.x.99 source x.x.x.100
> PING x.x.x.99 (x.x.x.99): 56 data bytes
> 64 bytes from x.x.x.99: icmp_seq=0 ttl=64 time=4.890 ms
> 64 bytes from x.x.x.99: icmp_seq=1 ttl=64 time=2.098 ms
> 64 bytes from x.x.x.99: icmp_seq=2 ttl=64 time=2.095 ms
> 64 bytes from x.x.x.99: icmp_seq=3 ttl=64 time=2.130 ms
> 64 bytes from x.x.x.99: icmp_seq=4 ttl=64 time=4.217 ms
> ^C
> --- x.x.x.99 ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 2.095/3.086/4.890/1.217 ms
>
> If I monitor traffic on either of the interfaces, I see ISIS packets
> leaving, but nothing coming in.  The EX2500s have a very vanilla config
> and I'm doing no filtering on them.
>
> Any ideas?
>
> Thanks,
> evt
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 4920 (20100306) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************



From eric at atlantech.net  Sun Mar  7 05:42:22 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Sun, 7 Mar 2010 05:42:22 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <209782.88507.qm@web180011.mail.gq1.yahoo.com>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46C903@exchange.aoihq.local>
	<E2C120A806ED3349A9F9E9913E0C8C1F5E7723@bmcserver.bmc.com.sa>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C904@exchange.aoihq.local>
	<209782.88507.qm@web180011.mail.gq1.yahoo.com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C905@exchange.aoihq.local>

> From: Derick Winkworth [mailto:dwinkworth at att.net] 
> Sent: Sunday, March 07, 2010 1:26 AM
> To: Eric Van Tol; Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> If its JUNOS, then just configure the MTU normally in the interface
> config on the switch.

It does not run JUNOS and there is no config option for MTU that I can find.  I don't believe that it's configurable, but it "just works".  Without configuring anything on the EX2500, I was able to pass 2000-byte sized IP packets between the Junipers.

-evt




From sfouant at shortestpathfirst.net  Sun Mar  7 08:04:19 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sun, 7 Mar 2010 13:04:19 +0000
Subject: [j-nsp] Strange IS-IS Problem
Message-ID: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>

I could be wrong but if I recall correctly the Hello PDU uses a padding TLV to pad the initial hello to the maximum MTU size.  I don't believe these packets are fragmentable if I recall considering it's a CLNS frame, i.e. no IP header and thus no fragment options.  I think it's already been said but the fact that you are using jumbo frames and also because you are using EX 2500s (not native JUNOS) makes it extremely suspect that you are likely running into some form of MTU issue.

One other thing you might want to check on the EX 2500 - interface counters - look for L2 Channel errors or other inconsistencies which might indicate the EX doesn't recognize the Ethertype, etc.

Stefan Fouant
------Original Message------
From: Eric Van Tol
Sender: juniper-nsp-bounces at puck.nether.net
To: Derick Winkworth
To: Juniper-Nsp
Subject: Re: [j-nsp] Strange IS-IS Problem
Sent: Mar 7, 2010 4:42 AM

> From: Derick Winkworth [mailto:dwinkworth at att.net] 
> Sent: Sunday, March 07, 2010 1:26 AM
> To: Eric Van Tol; Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> If its JUNOS, then just configure the MTU normally in the interface
> config on the switch.

It does not run JUNOS and there is no config option for MTU that I can find.  I don't believe that it's configurable, but it "just works".  Without configuring anything on the EX2500, I was able to pass 2000-byte sized IP packets between the Junipers.

-evt



_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent from my Verizon Wireless BlackBerry


From netprodata at gmail.com  Sun Mar  7 13:02:29 2010
From: netprodata at gmail.com (networking alcatel)
Date: Sun, 7 Mar 2010 23:32:29 +0530
Subject: [j-nsp] ISG 1000
Message-ID: <abebb50b1003071002v5e8cd684w3d755b12af700269@mail.gmail.com>

Hi

I have got a ISG 1000 firewall which has the default 4 interfaces, i need to
configure 4 zones on a single interface and 1 zone which is the untrusted
zone on another interface , the other 2 interfaces will be used for HA and
heartbeat as there are 2 ISG 1000 my point is

   - can i have 4 different zones on a single interface these are all
   trusted (inside) and require to communicate with one another and also with
   the outside interface
   - can the DMZ zone and the trusted zone be binded with the same interface
   (sub-interfaces are proposed using vlan tagging)

will this type of solution work.

From netprodata at gmail.com  Sun Mar  7 13:09:29 2010
From: netprodata at gmail.com (networking alcatel)
Date: Sun, 7 Mar 2010 23:39:29 +0530
Subject: [j-nsp] ISG 1000
Message-ID: <abebb50b1003071009s3b2aff56y83dee2dcf2c1e091@mail.gmail.com>

Hi

I have got a ISG 1000 firewall which has the default 4 interfaces, i need to
configure 4 zones on a single interface and 1 zone which is the untrusted
zone on another interface , the other 2 interfaces will be used for HA and
heartbeat as there are 2 ISG 1000 my point is

   - can i have 4 different zones on a single interface these are all
   trusted (inside) and require to communicate with one another and also with
   the outside interface
   - can the DMZ zone and the trusted zone be binded with the same interface
   (sub-interfaces are proposed using vlan tagging)

will this type of solution work.

From barnys at juniper.net  Sun Mar  7 13:10:19 2010
From: barnys at juniper.net (Barny Sanchez)
Date: Sun, 7 Mar 2010 10:10:19 -0800
Subject: [j-nsp] ISG 1000
Message-ID: <4D2B132DE2E6F240BB6A440B4DBC5F815622187731@EMBX02-HQ.jnpr.net>

Yes, no problems supporting all of this.

Thanks,



Barny Sanchez | Consulting Engineer - Security Solutions | Juniper Networks  |  Direct: +1.774.318.9140 | barnys at juniper.net <mailto:barnys at juniper.net>
(Message sent via my mobile device, sorry for any typos and shortness of my response)

----- Original Message -----
From: juniper-nsp-bounces at puck.nether.net <juniper-nsp-bounces at puck.nether.net>
To: juniper-nsp at puck.nether.net <juniper-nsp at puck.nether.net>
Sent: Sun Mar 07 10:02:29 2010
Subject: [j-nsp] ISG 1000

Hi

I have got a ISG 1000 firewall which has the default 4 interfaces, i need to
configure 4 zones on a single interface and 1 zone which is the untrusted
zone on another interface , the other 2 interfaces will be used for HA and
heartbeat as there are 2 ISG 1000 my point is

   - can i have 4 different zones on a single interface these are all
   trusted (inside) and require to communicate with one another and also with
   the outside interface
   - can the DMZ zone and the trusted zone be binded with the same interface
   (sub-interfaces are proposed using vlan tagging)

will this type of solution work.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From sidney.boumendil at gmail.com  Sun Mar  7 13:24:53 2010
From: sidney.boumendil at gmail.com (Sidney Boumendil)
Date: Sun, 7 Mar 2010 19:24:53 +0100
Subject: [j-nsp] ISG 1000
In-Reply-To: <abebb50b1003071002v5e8cd684w3d755b12af700269@mail.gmail.com>
References: <abebb50b1003071002v5e8cd684w3d755b12af700269@mail.gmail.com>
Message-ID: <41522e901003071024q2920caabi53b5069b3b286419@mail.gmail.com>

On Sun, Mar 7, 2010 at 7:02 PM, networking alcatel <netprodata at gmail.com> wrote:
> Hi
>
> I have got a ISG 1000 firewall which has the default 4 interfaces, i need to
> configure 4 zones on a single interface and 1 zone which is the untrusted
> zone on another interface , the other 2 interfaces will be used for HA and
> heartbeat as there are 2 ISG 1000 my point is
>
> ? - can i have 4 different zones on a single interface these are all
> ? trusted (inside) and require to communicate with one another and also with
> ? the outside interface
> ? - can the DMZ zone and the trusted zone be binded with the same interface
> ? (sub-interfaces are proposed using vlan tagging)
>
> will this type of solution work.

Yes it works, juste use vlan tagged sub-interfaces. You can bind
sub-interfaces to any zone you want.

Be sure to check your licence supports the number of zone you want to create.


From d.nostra at gmail.com  Sun Mar  7 22:33:01 2010
From: d.nostra at gmail.com (Michel de Nostredame)
Date: Mon, 8 Mar 2010 03:33:01 +0000
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <2c52b84e1003062311y1ea45749t753e0e43a536eb34@mail.gmail.com>
References: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
	<2c52b84e1003062311y1ea45749t753e0e43a536eb34@mail.gmail.com>
Message-ID: <454d328c1003071933l512251a3j7d4aca804dfc5348@mail.gmail.com>

Hi Tim and Dan,

Unfortunately, upgrade to JUNOS will not able to be an option as I am using
SSG5, 20, and 140 box, they are not like SSG3xxm or 5xxm that can host
JUNOS.

I do have following settings in my config that related to "flow", but I am
not sure if something I still missing...

unset flow no-tcp-seq-check
unset flow tcp-syn-check
unset flow tcp-syn-bit-check
unset flow tcp-syn-check-in-tunnel

also the policy is to permit all traffic between zones.

I put "set zone trust asymmetric-vpn" to my config and perform the test
again, that I am able to establish connection under asymmetric route, but
somehow there are still "timeout" during tracerout that I expect to have
response from SSG's interface IP.

My testing setup looks like this way,

  [pc1]--[R1]--[ssg1]--VPN tunnel A--[ssg2]--[R2]--[pc2]
                  |                            |
                  +-----VPN tunnel B--[ssg3]---+

So the path from pc1 to pc2 is
"[pc1]-[Rt1]-[ssg1]-[tunA]-[ssg2]-[Rt2]-[pc2]"
and return path is "[pc2]-[R2]-[ssg3]-[tunB]-[ssg1]-[R1]-[pc1]"
where [R1] and [R2] is L3 switch (Cisco 3750G), all interface between
devices are pure L3 interface.

When perform traceroute from pc1 to pc2, I expect to see response on [R2]
with IP of interface facing to ssg2, but I got "*" (timeout). However I am
able to connect (telnet) from PC1 to PC2, and vice versa.


Thanks,
--
Michel~




On Sun, Mar 7, 2010 at 7:11 AM, Tim Eberhard <xmin0s at gmail.com> wrote:
> To deal with asymmetric routing problems you can disable tcp-syn-checking.
> That will disable the stateful enforcement (and greatly weaken security of
> the box). I'd also ensure you disable syn-checking in the tunnel (since
> you're using ipsec tunnels).
>
> Beyond that, write your policy bi-directionally ensuring any side can
create
> the session and that should fit your needs. Even if the session times out
> with syn-checking disabled and it's permitted by policy it will be
instantly
> recreated with the next packet.
>
> Hope this helps,
> -Tim Eberhard
>
> On Sat, Mar 6, 2010 at 3:34 AM, Michel de Nostredame <d.nostra at gmail.com>
> wrote:
>>
>> 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

From tony.frank at ericsson.com  Sun Mar  7 23:43:45 2010
From: tony.frank at ericsson.com (Tony Frank)
Date: Mon, 8 Mar 2010 12:43:45 +0800
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <454d328c1003071933l512251a3j7d4aca804dfc5348@mail.gmail.com>
References: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
	<2c52b84e1003062311y1ea45749t753e0e43a536eb34@mail.gmail.com>
	<454d328c1003071933l512251a3j7d4aca804dfc5348@mail.gmail.com>
Message-ID: <534B1E4DC291B94FA65461AE7B26E82601C7D3C630@ESGSCCMS0002.eapac.ericsson.se>

Hi Michel,
 
> I do have following settings in my config that related to "flow", but I am not sure if something I still missing...

If you have not already tried, the command 'get flow' gives details of flow configuration.

Some in particular:

set flow reverse-route clear-text prefer
set flow reverse-route tunnel prefer

I believe default is 'always' and that results in dropped packets if return path is different.
This should relax the route lookup rules when creating session, which may help your scenario.

Regards,
Tony



From d.nostra at gmail.com  Mon Mar  8 03:36:44 2010
From: d.nostra at gmail.com (Michel de Nostredame)
Date: Mon, 8 Mar 2010 08:36:44 +0000
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <534B1E4DC291B94FA65461AE7B26E82601C7D3C630@ESGSCCMS0002.eapac.ericsson.se>
References: <454d328c1003060134t170a301cu3cc40ad75b7970b6@mail.gmail.com>
	<2c52b84e1003062311y1ea45749t753e0e43a536eb34@mail.gmail.com>
	<454d328c1003071933l512251a3j7d4aca804dfc5348@mail.gmail.com>
	<534B1E4DC291B94FA65461AE7B26E82601C7D3C630@ESGSCCMS0002.eapac.ericsson.se>
Message-ID: <454d328c1003080036y6019e97dnf95efd27e1dbba4a@mail.gmail.com>

Hi Tony,

I just put the two parameters,

set flow reverse-route clear-text prefer
set flow reverse-route tunnel prefer

into those 3 SSG boxes, but no luck there. I am re-read all documents and
wish I can find something.


Regards,
--
Michel~



On Mon, Mar 8, 2010 at 4:43 AM, Tony Frank <tony.frank at ericsson.com> wrote:

> Hi Michel,
>
> > I do have following settings in my config that related to "flow", but I
> am not sure if something I still missing...
>
> If you have not already tried, the command 'get flow' gives details of flow
> configuration.
>
> Some in particular:
>
> set flow reverse-route clear-text prefer
> set flow reverse-route tunnel prefer
>
> I believe default is 'always' and that results in dropped packets if return
> path is different.
> This should relax the route lookup rules when creating session, which may
> help your scenario.
>
> Regards,
> Tony
>
>

From fahad.khan at gmail.com  Mon Mar  8 04:51:54 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Mon, 8 Mar 2010 14:51:54 +0500
Subject: [j-nsp] ISG 1000
In-Reply-To: <41522e901003071024q2920caabi53b5069b3b286419@mail.gmail.com>
References: <abebb50b1003071002v5e8cd684w3d755b12af700269@mail.gmail.com>
	<41522e901003071024q2920caabi53b5069b3b286419@mail.gmail.com>
Message-ID: <d0cc41791003080151h650e7c26xbf6ec59d4d1768d@mail.gmail.com>

Yes, simply make sub-interfaces and relevant vlan tagging, then connect that
port with your switch over trunk using dot1q.

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Sun, Mar 7, 2010 at 11:24 PM, Sidney Boumendil <
sidney.boumendil at gmail.com> wrote:

> On Sun, Mar 7, 2010 at 7:02 PM, networking alcatel <netprodata at gmail.com>
> wrote:
> > Hi
> >
> > I have got a ISG 1000 firewall which has the default 4 interfaces, i need
> to
> > configure 4 zones on a single interface and 1 zone which is the untrusted
> > zone on another interface , the other 2 interfaces will be used for HA
> and
> > heartbeat as there are 2 ISG 1000 my point is
> >
> >   - can i have 4 different zones on a single interface these are all
> >   trusted (inside) and require to communicate with one another and also
> with
> >   the outside interface
> >   - can the DMZ zone and the trusted zone be binded with the same
> interface
> >   (sub-interfaces are proposed using vlan tagging)
> >
> > will this type of solution work.
>
> Yes it works, juste use vlan tagged sub-interfaces. You can bind
> sub-interfaces to any zone you want.
>
> Be sure to check your licence supports the number of zone you want to
> create.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From eric at atlantech.net  Mon Mar  8 10:39:27 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 8 Mar 2010 10:39:27 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C921@exchange.aoihq.local>

> -----Original Message-----
> From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net]
> Sent: Sunday, March 07, 2010 8:04 AM
> To: Eric Van Tol; juniper-nsp-bounces at puck.nether.net; Derick Winkworth;
> Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> I could be wrong but if I recall correctly the Hello PDU uses a padding
> TLV to pad the initial hello to the maximum MTU size.  I don't believe
> these packets are fragmentable if I recall considering it's a CLNS frame,
> i.e. no IP header and thus no fragment options.  I think it's already been
> said but the fact that you are using jumbo frames and also because you are
> using EX 2500s (not native JUNOS) makes it extremely suspect that you are
> likely running into some form of MTU issue.

But if I can push through a baby giant packet without even configuring anything, wouldn't that mean that large packets are allowed through?

> One other thing you might want to check on the EX 2500 - interface
> counters - look for L2 Channel errors or other inconsistencies which might
> indicate the EX doesn't recognize the Ethertype, etc.

I checked the various counter stats and could not find any errors on any of the ports.  In fact, I see this:

Received valid L2 unicast packets:  18473
Received valid IPv4 unicast packets:  18473
Received valid L2 multicast packets:  123024
Received valid non-IP multicast packets:  123000
Received valid IPv4 multicast packets:  24
Received 64 byte packets:  23
Received 65-127 byte packets:  123032
Received 128-255 byte packets:  1
Received 1024-1522 byte packets:  8393
Received 1523-2047 byte packets:  10048
Received octets:  48192973
Received octets in valid non-IP packets:  15127879
Received octets in valid IPv4 packets:  33065094

As an aside, it appears that OSPF works fine if I set that up.  Not a long term solution, though.  I do believe that you are on to something, though.  Unfortunately, I can't see anywhere to configure the EX2500 ports to accept specific ethertypes.

Does anyone else have ISIS running _through_ an EX2500?

> Stefan Fouant

-evt
> ------Original Message------
> From: Eric Van Tol
> Sender: juniper-nsp-bounces at puck.nether.net
> To: Derick Winkworth
> To: Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> Sent: Mar 7, 2010 4:42 AM
> 
> > From: Derick Winkworth [mailto:dwinkworth at att.net]
> > Sent: Sunday, March 07, 2010 1:26 AM
> > To: Eric Van Tol; Juniper-Nsp
> > Subject: Re: [j-nsp] Strange IS-IS Problem
> >
> > If its JUNOS, then just configure the MTU normally in the interface
> > config on the switch.
> 
> It does not run JUNOS and there is no config option for MTU that I can
> find.  I don't believe that it's configurable, but it "just works".
> Without configuring anything on the EX2500, I was able to pass 2000-byte
> sized IP packets between the Junipers.
> 
> -evt
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> Sent from my Verizon Wireless BlackBerry


From jonlooney at gmail.com  Mon Mar  8 10:57:03 2010
From: jonlooney at gmail.com (Jonathan Looney)
Date: Mon, 8 Mar 2010 10:57:03 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
Message-ID: <ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>

On Sun, Mar 7, 2010 at 8:04 AM, Stefan Fouant <sfouant at shortestpathfirst.net
> wrote:

> I could be wrong but if I recall correctly the Hello PDU uses a padding TLV
> to pad the initial hello to the maximum MTU size.  I don't believe these
> packets are fragmentable if I recall considering it's a CLNS frame, i.e. no
> IP header and thus no fragment options.




This is also my understanding.  And, this makes me think that you really
should make the MTUs on both sides consistent before you try to troubleshoot
anything else.

-Jon

From gwong at above.net  Mon Mar  8 10:27:12 2010
From: gwong at above.net (Wong, Gah (Norman))
Date: Mon, 8 Mar 2010 10:27:12 -0500
Subject: [j-nsp] completely disable session (flow) in netscreen
In-Reply-To: <mailman.5.1267981201.72431.juniper-nsp@puck.nether.net>
References: <mailman.5.1267981201.72431.juniper-nsp@puck.nether.net>
Message-ID: <EF314CFAE1FB3E46979694F1EDD48D4C044217EB@IADXMB01.na.above.net>

'Bow Tie' VPN
----------------
SSG1      SSG2
  |  \   /  |
  |   \ /   |
  |   / \   |
ISG1------ISG2

One more thing to consider is the 'bow-tie' effect. It is stated in
(KB11915), where asymmetric routing breaks between remote VPN sites with
multiple tunnels. If you network is similar in desgin as the bow-tie
vpn, then you are more than likely running into this issue. Where host
behind SSG1 would initiate traffic bound to a host in any of the other
sites and the return path is not the prefered tunnel interface of SSG1,
then its gonna be dropped by session firewall. 

Warm Regards,

~Norman





From eric at atlantech.net  Mon Mar  8 11:57:55 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 8 Mar 2010 11:57:55 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>

Both MTUs are consistent and always have been.  I started out with 9216 physical MTU and 1500 inet MTU, but have since just deleted the custom MTU and went with the defaults.  I am quite sure now that this is not an MTU issue, but rather a deficiency with the EX2500.  I've opened up a JTAC case and will let the list know what the problem turns out to be.

-evt

From: Jonathan Looney [mailto:jonlooney at gmail.com]
Sent: Monday, March 08, 2010 10:57 AM
To: Eric Van Tol
Cc: Juniper-Nsp
Subject: Re: [j-nsp] Strange IS-IS Problem


On Sun, Mar 7, 2010 at 8:04 AM, Stefan Fouant <sfouant at shortestpathfirst.net<mailto:sfouant at shortestpathfirst.net>> wrote:
I could be wrong but if I recall correctly the Hello PDU uses a padding TLV to pad the initial hello to the maximum MTU size.  I don't believe these packets are fragmentable if I recall considering it's a CLNS frame, i.e. no IP header and thus no fragment options.



This is also my understanding.  And, this makes me think that you really should make the MTUs on both sides consistent before you try to troubleshoot anything else.

-Jon

From eric at atlantech.net  Mon Mar  8 12:51:33 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 8 Mar 2010 12:51:33 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C938@exchange.aoihq.local>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Monday, March 08, 2010 11:58 AM
> To: Jonathan Looney
> Cc: Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> Both MTUs are consistent and always have been.  I started out with 9216
> physical MTU and 1500 inet MTU, but have since just deleted the custom MTU
> and went with the defaults.  I am quite sure now that this is not an MTU
> issue, but rather a deficiency with the EX2500.  I've opened up a JTAC
> case and will let the list know what the problem turns out to be.
> 
> -evt

Sorry for responding to my own post here.  Another helpful tip came in to use 'point-to-point' in the ISIS config, which had been brought up before but never tried.  It appears that this actually works.  The person who suggested it also mentioned having similar problems on Force10 switches.  Unfortunately, the point-to-point solution won't work for me in the long term :-(

-evt


From cra at WPI.EDU  Mon Mar  8 12:55:29 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 12:55:29 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
Message-ID: <20100308175529.GE12615@angus.ind.WPI.EDU>

On Mon, Mar 08, 2010 at 11:57:55AM -0500, Eric Van Tol wrote:
> Both MTUs are consistent and always have been.  I started out with 
> 9216 physical MTU and 1500 inet MTU, but have since just deleted the 
> custom MTU and went with the defaults.  I am quite sure now that 
> this is not an MTU issue, but rather a deficiency with the EX2500.  
> I've opened up a JTAC case and will let the list know what the 
> problem turns out to be.

But you didn't have the iso mtu set.  Which means iso was probably 
using 9216-6-6-4-2-3 = 9195 (or 9192-6-6-4-2-3 = 9171) by default for 
a VLAN encapsulated 802.2 LLC frame. Changing the inet MTU doesn't 
affect any non-IP protocols' MTUs.

From sfouant at shortestpathfirst.net  Mon Mar  8 13:00:07 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 8 Mar 2010 18:00:07 +0000
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry><ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com><2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
Message-ID: <486170691-1268071263-cardhu_decombobulator_blackberry.rim.net-661814105-@bda294.bisx.prod.on.blackberry>

One thing to add - you are probably already aware of this, but the family inet MTU won't have any bearing on those CLNS frames - have you tried either setting a physical MTU or a family iso MTU at something much lower?  I'd even try an MTU size of 1400 just to completely rule that out.

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Eric Van Tol <eric at atlantech.net>
Date: Mon, 8 Mar 2010 11:57:55 
To: Jonathan Looney<jonlooney at gmail.com>
Cc: Juniper-Nsp<juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Strange IS-IS Problem

Both MTUs are consistent and always have been.  I started out with 9216 physical MTU and 1500 inet MTU, but have since just deleted the custom MTU and went with the defaults.  I am quite sure now that this is not an MTU issue, but rather a deficiency with the EX2500.  I've opened up a JTAC case and will let the list know what the problem turns out to be.

-evt

From: Jonathan Looney [mailto:jonlooney at gmail.com]
Sent: Monday, March 08, 2010 10:57 AM
To: Eric Van Tol
Cc: Juniper-Nsp
Subject: Re: [j-nsp] Strange IS-IS Problem


On Sun, Mar 7, 2010 at 8:04 AM, Stefan Fouant <sfouant at shortestpathfirst.net<mailto:sfouant at shortestpathfirst.net>> wrote:
I could be wrong but if I recall correctly the Hello PDU uses a padding TLV to pad the initial hello to the maximum MTU size.  I don't believe these packets are fragmentable if I recall considering it's a CLNS frame, i.e. no IP header and thus no fragment options.



This is also my understanding.  And, this makes me think that you really should make the MTUs on both sides consistent before you try to troubleshoot anything else.

-Jon
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From cra at WPI.EDU  Mon Mar  8 13:54:46 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 13:54:46 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46C938@exchange.aoihq.local>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C938@exchange.aoihq.local>
Message-ID: <20100308185446.GF12615@angus.ind.WPI.EDU>

On Mon, Mar 08, 2010 at 12:51:33PM -0500, Eric Van Tol wrote:
> Sorry for responding to my own post here.  Another helpful tip came 
> in to use 'point-to-point' in the ISIS config, which had been 
> brought up before but never tried.  It appears that this actually 
> works.  The person who suggested it also mentioned having similar 
> problems on Force10 switches.  Unfortunately, the point-to-point 
> solution won't work for me in the long term :-(

Ah.  I wonder if that is because the IS-IS Hello PDUs are being sent 
as Ethernet Multicast frames.  L1 LAN Hellos, L2 LAN Hellos, and P2P 
Hellos use different destination Ethernet Multicast addresses that the 
EX2500 might not be flooding like it should.  Or could it be that you 
have a Level or Area mismatch (I guess not because you haven't turned 
off any Levels, and Level 2 adjacencies don't require matching Area 
IDs)?

What does "monitor traffic interface xe-1/2/0 no-resolve 
layer2-headers extensive" show?

When I tested with and without point-to-point, I see the following:

normal ethernet, Level 1 LAN Hello:

0:90:69:bc:2c:7e > 1:80:c2:0:0:14, ethertype 802.1Q (0x8100), length 
69: vlan 999, p 6, LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) 
Command, ctrl 0x03: OSI NLPID IS-IS (0x83): length 48
	L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

normal ethernet, Level 2 LAN Hello:

0:90:69:bc:2c:7e > 1:80:c2:0:0:15, ethertype 802.1Q (0x8100), length 
75: vlan 999, p 6, LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) 
Command, ctrl 0x03: OSI NLPID IS-IS (0x83): length 54
	L2 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

point-to-point, P2P Hello:

0:90:69:bc:2c:7e > 9:0:2b:0:0:5, ethertype 802.1Q (0x8100), length 
69: vlan 999, p 6, LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) 
Command, ctrl 0x03: OSI NLPID IS-IS (0x83): length 48
	p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

From eric at atlantech.net  Mon Mar  8 14:01:14 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 8 Mar 2010 14:01:14 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <20100308175529.GE12615@angus.ind.WPI.EDU>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
	<20100308175529.GE12615@angus.ind.WPI.EDU>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46C93E@exchange.aoihq.local>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Chuck Anderson
> Sent: Monday, March 08, 2010 12:55 PM
> To: Juniper-Nsp
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> On Mon, Mar 08, 2010 at 11:57:55AM -0500, Eric Van Tol wrote:
> > Both MTUs are consistent and always have been.  I started out with
> > 9216 physical MTU and 1500 inet MTU, but have since just deleted the
> > custom MTU and went with the defaults.  I am quite sure now that
> > this is not an MTU issue, but rather a deficiency with the EX2500.
> > I've opened up a JTAC case and will let the list know what the
> > problem turns out to be.
> 
> But you didn't have the iso mtu set.  Which means iso was probably
> using 9216-6-6-4-2-3 = 9195 (or 9192-6-6-4-2-3 = 9171) by default for
> a VLAN encapsulated 802.2 LLC frame. Changing the inet MTU doesn't
> affect any non-IP protocols' MTUs.

Another person had previously suggested setting iso MTU, which I did, and that did not change anything.  The issue seems to be that the EX2500 is dropping the ISIS hellos upon ingress.  I've updated the JTAC case and they are attempting to replicate it in the lab.  

- evt


From cra at WPI.EDU  Mon Mar  8 14:37:11 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 14:37:11 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <20100308175529.GE12615@angus.ind.WPI.EDU>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
	<20100308175529.GE12615@angus.ind.WPI.EDU>
Message-ID: <20100308193711.GG12615@angus.ind.WPI.EDU>

On Mon, Mar 08, 2010 at 12:55:29PM -0500, Chuck Anderson wrote:
> On Mon, Mar 08, 2010 at 11:57:55AM -0500, Eric Van Tol wrote:
> > Both MTUs are consistent and always have been.  I started out with 
> > 9216 physical MTU and 1500 inet MTU, but have since just deleted the 
> > custom MTU and went with the defaults.  I am quite sure now that 
> > this is not an MTU issue, but rather a deficiency with the EX2500.  
> > I've opened up a JTAC case and will let the list know what the 
> > problem turns out to be.
> 
> But you didn't have the iso mtu set.  Which means iso was probably 
> using 9216-6-6-4-2-3 = 9195 (or 9192-6-6-4-2-3 = 9171) by default for 
> a VLAN encapsulated 802.2 LLC frame. Changing the inet MTU doesn't 
> affect any non-IP protocols' MTUs.

Just to confirm this I tested with a physical mtu 9192, family inet 
mtu 1500 and no family iso mtu configured:

interfaces {
    fe-1/0/0 {
        vlan-tagging;
        mtu 9192;
        unit 999 {
            vlan-id 999;
	    family inet {
	        mtu 1500;
	    }		
            family iso;
        }
    }
}

You can see that iso is using an MTU of 9171:

lab at main> show interfaces fe-1/0/0 extensive | match mtu 
  Link-level type: Ethernet, MTU: 9192, Speed: 10m, Loopback: Disabled,
    FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
    Protocol inet, MTU: 1500, Generation: 283, Route table: 3
      Flags: User-MTU
    Protocol iso, MTU: 9171, Generation: 282, Route table: 3

But even so, the Hellos don't look to be padded out to the MTU 
(ethernet length is only 75):

	0:90:69:bc:2c:7e > 1:80:c2:0:0:15, ethertype 802.1Q (0x8100), 
length 75: vlan 999, p 6, LLC, dsap OSI (0xfe) Individual, ssap OSI 
(0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): length 54
	L2 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

This contradicts what it says in the JNCIA Study Guide, page 291:

"Therefore, each interface must support the transmission of the 
maximum IS-IS PDU of 1492 bytes. To enforce this requirement, the 
IS-IS Hello PDUs are padded to this maximum value. If the hello gets 
to the neighboring router, the connecting interface supports the 
maximum PDU size. Should the hello not be received by the neighboring 
router, no adjacency forms and this link is not used by IS-IS."

I'm not seeing the IIH's being padded at all (JUNOS 8.4R3.3).

-Chuck, in the middle of preparing for the JNCIE exam.

From cra at WPI.EDU  Mon Mar  8 14:40:44 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 14:40:44 -0500
Subject: [j-nsp] EX4200 upgrade
In-Reply-To: <06275CB4814DA94AB880409FDD8D779C148E4C6890@EXMBXCLUS01.citservers.local>
References: <454d328c1003061215l5b65f59dk4d1b8893d29d02e5@mail.gmail.com>
	<06275CB4814DA94AB880409FDD8D779C148E4C6890@EXMBXCLUS01.citservers.local>
Message-ID: <20100308194043.GH12615@angus.ind.WPI.EDU>

And now 10.0S3.1 is out with yet more fixes, but not yet on the 
"recommended releases" page.  Wee!

On Sat, Mar 06, 2010 at 11:06:19PM -0800, Dan Farrell wrote:
> 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>

From phil.pierotti at gmail.com  Mon Mar  8 15:18:19 2010
From: phil.pierotti at gmail.com (Phil Pierotti)
Date: Tue, 9 Mar 2010 07:18:19 +1100
Subject: [j-nsp] JunOSe / ERX / ERX-310
Message-ID: <5574b2241003081218wd218d8eodc6bd6d574daa00c@mail.gmail.com>

Hi All,

Can anyone out there using the ERX series comment on their
features/functionality/useability etc?

Loves/Hates and caveats in general? Comparisons to other/similar
products (eg Cisco, Redback, ?)

We're specifically investigating rolling out several ERX-310 for L2TP
tunnel switching, driven by RADIUS.

In our current setup all downstream tunnel config comes from RADIUS,
and we're hoping to be able to do the same with JunOSe

Thanks,
Phil P

From ras at e-gerbil.net  Mon Mar  8 15:29:50 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 8 Mar 2010 14:29:50 -0600
Subject: [j-nsp] EX4200 upgrade
In-Reply-To: <20100308194043.GH12615@angus.ind.WPI.EDU>
References: <454d328c1003061215l5b65f59dk4d1b8893d29d02e5@mail.gmail.com>
	<06275CB4814DA94AB880409FDD8D779C148E4C6890@EXMBXCLUS01.citservers.local>
	<20100308194043.GH12615@angus.ind.WPI.EDU>
Message-ID: <20100308202950.GL75640@gerbil.cluepon.net>

On Mon, Mar 08, 2010 at 02:40:44PM -0500, Chuck Anderson wrote:
> And now 10.0S3.1 is out with yet more fixes, but not yet on the 
> "recommended releases" page.  Wee!

Personally I think they just don't update the "recommended releases" 
page, based on several other extremely out of date values I've seen 
there. 

Speaking of EX and sucking, has anybody else noticed the hardcoded 512MB
rlimit on rpd on EX8200? :)

Process (55002,rpd) attempted to exceed RLIMIT_DATA: attempted 524412 KB Max 524288 KB 
pid 55002 (rpd), uid 0: exited on signal 6 (core dumped)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sdanelli at gmail.com  Mon Mar  8 15:43:57 2010
From: sdanelli at gmail.com (Sergio D.)
Date: Mon, 8 Mar 2010 13:43:57 -0700
Subject: [j-nsp] Strange IS-IS Problem
Message-ID: <aa2d13131003081243u6e198f1evafc3cda1b450a6b6@mail.gmail.com>

Only the first few hellos are padded, please see link from Jeff Doyle's ISIS
OSPF book:

http://gyazo.com/1b872a14f35bd27f859a722ecc3849c5.png

(I have a hard copy of that book as well)

-- 
Sergio Danelli
JNCIE #170

From cra at WPI.EDU  Mon Mar  8 15:58:17 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 15:58:17 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <aa2d13131003081243u6e198f1evafc3cda1b450a6b6@mail.gmail.com>
References: <aa2d13131003081243u6e198f1evafc3cda1b450a6b6@mail.gmail.com>
Message-ID: <20100308205817.GJ12615@angus.ind.WPI.EDU>

On Mon, Mar 08, 2010 at 01:43:57PM -0700, Sergio D. wrote:
> Only the first few hellos are padded, please see link from Jeff Doyle's ISIS
> OSPF book:
> 
> http://gyazo.com/1b872a14f35bd27f859a722ecc3849c5.png
> 
> (I have a hard copy of that book as well)

I was testing with a not-yet-up adjacency, with no neighboring routers 
available.  So these were initial hellos I was looking at.  None were 
padded at all.

From cra at WPI.EDU  Mon Mar  8 16:08:26 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Mar 2010 16:08:26 -0500
Subject: [j-nsp] Class E IP addresses
Message-ID: <20100308210826.GK12615@angus.ind.WPI.EDU>

>From 9.6 release notes:

  Class E addresses?The JUNOS Software now allows Class E addresses to be
  configured on interfaces. To allow Class E addresses to be configured on
  interfaces, remove the Class E prefix from the list of martian addresses by
  including the [edit routing-options martians 240/4 orlonger allow] configuration
  statement.

Whoa.  What is the use of this?  While it sounds like a neat idea to 
reclaim Class E for actual use in this age of IPv4 depletion, the idea 
loses its appeal once you realize the huge numbers of legacy devices 
that won't want to have anything to do with Class E.

From oberman at es.net  Mon Mar  8 16:16:10 2010
From: oberman at es.net (Kevin Oberman)
Date: Mon, 08 Mar 2010 13:16:10 -0800
Subject: [j-nsp] EX4200 upgrade
In-Reply-To: Your message of "Mon, 08 Mar 2010 14:29:50 CST."
	<20100308202950.GL75640@gerbil.cluepon.net> 
Message-ID: <20100308211610.B623E1CC0B@ptavv.es.net>

> Date: Mon, 8 Mar 2010 14:29:50 -0600
> From: Richard A Steenbergen <ras at e-gerbil.net>
> Sender: juniper-nsp-bounces at puck.nether.net
> 
> On Mon, Mar 08, 2010 at 02:40:44PM -0500, Chuck Anderson wrote:
> > And now 10.0S3.1 is out with yet more fixes, but not yet on the 
> > "recommended releases" page.  Wee!
> 
> Personally I think they just don't update the "recommended releases" 
> page, based on several other extremely out of date values I've seen 
> there. 
> 
> Speaking of EX and sucking, has anybody else noticed the hardcoded 512MB
> rlimit on rpd on EX8200? :)
> 
> Process (55002,rpd) attempted to exceed RLIMIT_DATA: attempted 524412 KB Max 524288 KB 
> pid 55002 (rpd), uid 0: exited on signal 6 (core dumped)

I seem to recall that, back when we first were told about the EX systems
and long before any 8200 ever hit the streets, that there would be
limits on the the system so that it would not cannibalize the MX. Looks
like this is at least part of how they did it.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

From ras at e-gerbil.net  Mon Mar  8 16:30:50 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 8 Mar 2010 15:30:50 -0600
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <aa2d13131003081243u6e198f1evafc3cda1b450a6b6@mail.gmail.com>
References: <aa2d13131003081243u6e198f1evafc3cda1b450a6b6@mail.gmail.com>
Message-ID: <20100308213049.GO75640@gerbil.cluepon.net>

On Mon, Mar 08, 2010 at 01:43:57PM -0700, Sergio D. wrote:
> Only the first few hellos are padded, please see link from Jeff Doyle's ISIS
> OSPF book:
> 
> http://gyazo.com/1b872a14f35bd27f859a722ecc3849c5.png
> 
> (I have a hard copy of that book as well)

Of course most people claim isis hello padding is deprecated, including 
Juniper. :)

http://www.nanog.org/meetings/nanog19/presentations/katz.ppt

Also, turning on isis point-to-point also eliminates all of that DR
election nonsense as well as getting rid of the pesky multicast hello
packets which occasionally break things, but it's always a pain to
remember to turn it on. Personally I wish there was just an interface
unit level "point-to-point" flag you could set that told all associated
protocols this was a p2p even if it's over ethernet.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From mtinka at globaltransit.net  Tue Mar  9 06:18:57 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 9 Mar 2010 19:18:57 +0800
Subject: [j-nsp] JUNOSe multi-topology IS-IS support?
In-Reply-To: <4B921D02.6070802@futureinquestion.net>
References: <4B921D02.6070802@futureinquestion.net>
Message-ID: <201003091919.02298.mtinka@globaltransit.net>

On Saturday 06 March 2010 05:14:42 pm David Monosov wrote:

> Does anyone have any experiences (or ideas) to share on
>  the subject of elegantly integrating JUNOSe devices into
>  multi-topology IPv4 and IPv6 IS-IS domains without this
>  feature?

Have no experience with JUNOSe, but if the code is anything 
like the spec., ST- and MT-configured routers will have a 
hard time 'sync'ing up' on the same wire.

You either have ST both ways, or MT both ways (and I know 
not of any implementation which allows you to turn this off 
per-interface)

Surprised, though, that JUNOSe won't do MT.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100309/d230b0c6/attachment.bin>

From juniper at arnes.si  Tue Mar  9 08:38:51 2010
From: juniper at arnes.si (=?windows-1252?Q?Matja=9E_Straus?=)
Date: Tue, 9 Mar 2010 14:38:51 +0100
Subject: [j-nsp] netflow v9 on a Juniper MX
Message-ID: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>

Hi there!

We are using 9.6R3.8 on our Juniper MX routers and we wish to enable netflow v9 for IPv6 traffic flow sampling. Our local Juniper partner claims that a special Multiservices DPC card is needed for netflow v9. DPCE 4x 10GE R can run tunnels like GRE, IP-in-IP but not netflow services :-(. I can't understand why such a complex card is needed for netflow v9 functionality and I'll be glad to get some feedback from the list about the issue. Are there any plans to port netflow v9 functionality to 10GE DPCs?

Kind regards,
	Matja?

---
Matja? Straus, Arnes
http://www.arnes.si

Tel: +386 1 4798-877
Fax: +386 1 4798-878
matjaz.straus at arnes.si
MS6745-RIPE
PGP 490F3B4F 2009-10-21
Fingerprint = 6172 7BF8 B0B7 1F09 47B3  AFA3 0946 1701 490F 3B4F



From sronan at fattoc.com  Tue Mar  9 08:46:07 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Tue, 9 Mar 2010 08:46:07 -0500
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <20100308185446.GF12615@angus.ind.WPI.EDU>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C938@exchange.aoihq.local>
	<20100308185446.GF12615@angus.ind.WPI.EDU>
Message-ID: <66A8D063-2044-4465-ACF8-23E694BF6B92@fattoc.com>


On Mar 8, 2010, at 1:54 PM, Chuck Anderson wrote:

> I wonder if that is because the IS-IS Hello PDUs are being sent
> as Ethernet Multicast frames


This had been my suspicion as well. Is it possible to disable igmp- 
snooping on the EX2500's?

-Shane


From ross at kallisti.us  Tue Mar  9 09:11:52 2010
From: ross at kallisti.us (Ross Vandegrift)
Date: Tue, 9 Mar 2010 09:11:52 -0500
Subject: [j-nsp] bridge-domains and L2 virtual switches
Message-ID: <20100309141152.GA2206@kallisti.us>

Hey everyone,

I'm working on replacing some datacenter Cat 6500s with Juniper MX and
the more I read about bridge domains and L2 virtual switches, the more
I'm completely mystified.  Our current deployment is VLAN-based (one
per customer installation).  L3 services are provided on SVIs.

If I create IRB interfaces without creating a bridge domain, is there
any way to extend beyond 4094 VLANs?  What I *want* is to carve off
virtualized L2/L3 aggregation routers with isolated VLAN ID domains
and STP instances.

Looks like a bridge domain can only have a single L3 interface.  Am I
supposed to configure a bridge domain per installation?  If so, is
there a limit to the number of bridge domains?

The Layer 2 Virtual Switch feature appears to require the creation of
a bridge domain, and thus is subject to the same constraints.  Any way
around that?

I could create multiple logical systems: one to handle all L3
services, and a few to behave as L2 aggregation.  Then, hand off
logical tunnels from the first to each of the second.  This doesn't
seem that bad, but I'm worried I'll hit surprising limitations down
the road.

I could keep the Cat 6500s as L2 aggregation and just hand-off normal
L3 interfaces.  This isn't so attractive, since it ties us to the
keeping the existing boxes and just doing less with them.  But it

Am I missing any options?

Ross

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100309/a081d199/attachment.bin>

From sean1207 at gmail.com  Tue Mar  9 09:29:05 2010
From: sean1207 at gmail.com (Sean Clarke)
Date: Tue, 09 Mar 2010 15:29:05 +0100
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
Message-ID: <4B965B31.7000109@gmail.com>

On 3/9/10 2:38 PM, Matja? Straus wrote:
> We are using 9.6R3.8 on our Juniper MX routers and we wish to enable netflow v9 for IPv6 traffic flow sampling. Our local Juniper partner claims that a special Multiservices DPC card is needed for netflow v9. DPCE 4x 10GE R can run tunnels like GRE, IP-in-IP but not netflow services:-(. I can't understand why such a complex card is needed for netflow v9 functionality and I'll be glad to get some feedback from the list about the issue. Are there any plans to port netflow v9 functionality to 10GE DPCs?
>    

This is correct. To do v9 is far more processor intensive, hence you 
really don't want to be doing this on the Routing Engine, as is the case 
with v5. All this functionality is off loaded onto the MS-DPC instead.

cheers
Sean



From ctracy at es.net  Tue Mar  9 09:53:36 2010
From: ctracy at es.net (Chris Tracy)
Date: Tue, 9 Mar 2010 09:53:36 -0500
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
Message-ID: <B21D115E-9D18-4C8D-B32F-C1079752BC63@es.net>

Hi Matja?,

You are correct that the MS-DPC cards are needed for NetFlow v9 functionality.  I believe that you also need a software license to activate this feature once you obtain the MS-DPC.  My understanding is that an MS-PIC (and s/w license) is needed for NFv9 on M- and T-series routers.  Others on the list, please correct me if I'm wrong, as I am also interested in this topic.  Some documentation seems to indicate it can be done with an AS-PIC, but I was informed that an MS-PIC was required.

NetFlow v5 is a fixed-record format, while NetFlow v9 is template based -- see the diagram at the bottom of http://is.gd/a2mha, and also see http://is.gd/a2p30.  Although the flexibility of NFv9 is nice, the overhead must be significantly higher than NFv5.  I'm guessing that this is the reason that only up to NFv5 is supported on the REs, but I'd like to know what others think.

Cheers,
-Chris


On Mar 9, 2010, at 8:38 AM, Matja? Straus wrote:

> Hi there!
> 
> We are using 9.6R3.8 on our Juniper MX routers and we wish to enable netflow v9 for IPv6 traffic flow sampling. Our local Juniper partner claims that a special Multiservices DPC card is needed for netflow v9. DPCE 4x 10GE R can run tunnels like GRE, IP-in-IP but not netflow services :-(. I can't understand why such a complex card is needed for netflow v9 functionality and I'll be glad to get some feedback from the list about the issue. Are there any plans to port netflow v9 functionality to 10GE DPCs?
> 
> Kind regards,
> 	Matja?
> 
> ---
> Matja? Straus, Arnes
> http://www.arnes.si
> 
> Tel: +386 1 4798-877
> Fax: +386 1 4798-878
> matjaz.straus at arnes.si
> MS6745-RIPE
> PGP 490F3B4F 2009-10-21
> Fingerprint = 6172 7BF8 B0B7 1F09 47B3  AFA3 0946 1701 490F 3B4F
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

--
Chris Tracy <ctracy at es.net>
Energy Sciences Network (ESnet)
Lawrence Berkeley National Laboratory






From ross at kallisti.us  Tue Mar  9 10:34:42 2010
From: ross at kallisti.us (Ross Vandegrift)
Date: Tue, 9 Mar 2010 10:34:42 -0500
Subject: [j-nsp] bridge-domains and L2 virtual switches
In-Reply-To: <171e61641003090644t5004d450w560382f738756eba@mail.gmail.com>
References: <20100309141152.GA2206@kallisti.us>
	<171e61641003090644t5004d450w560382f738756eba@mail.gmail.com>
Message-ID: <20100309153442.GB2805@kallisti.us>

On Tue, Mar 09, 2010 at 02:44:06PM +0000, Humair Ali wrote:
> you could use a routing instance , with layer 2 virtual switch, and use
> multiple bridge domain as part of that virtual switch routing instance ,
> with the L3 interface

How many such instances would you expect to work?  With all the config
that entails, I'd rather put every customer into a VPLS instance.  I
know that at least 8000 are supported, so that's better than 4094 and
it at least comes with the benefit that I could turn up VPLS service
for any customer at any time if they happened to want it.  But if I
could support 16k instances via bridge domains, that would definitely
be worth the added complexity.

I'm hoping there's a way that keeps most setups simple, will let me
scale out the number of VLANs I'm serving, and doesn't require me to
sacrifice the ability to sell a customer a VPN.

> If really you need more than 4094 Vlans, you could possibly used PVLAN
> (Private VLAN) it would allegedly split the domain into multiple isolated
> broadcast ?subdomains" without you having to use much of the vlan's ID and
> have STP as well.

It's a good theory, but it doesn't work in practice.  PVLANs come with
far too many limitations on the various platforms we have in
production.  It might be great if the datacenter were for our internal
use, but we're a hosting services provider and customers expect
(fairly!) to have access to the full range of network services on
their installations.

If a PVLAN could be trunked, then it could help me.  But so long as it
requires access ports, it's worthless for me.

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100309/a31ce808/attachment.bin>

From ras at e-gerbil.net  Tue Mar  9 10:40:18 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 9 Mar 2010 09:40:18 -0600
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <4B965B31.7000109@gmail.com>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
	<4B965B31.7000109@gmail.com>
Message-ID: <20100309154018.GW75640@gerbil.cluepon.net>

On Tue, Mar 09, 2010 at 03:29:05PM +0100, Sean Clarke wrote:
> This is correct. To do v9 is far more processor intensive, hence you 
> really don't want to be doing this on the Routing Engine, as is the case 
> with v5. All this functionality is off loaded onto the MS-DPC instead.

Nonsense. The CPU usage might be ever so slightly higher in v9, but
neither is a major contributor to overall load even at the maximum
supported RE sampling rate. The only time you *need* a services card is
when you want to do a much higher rate than the RE can support (i.e. you 
want to do some 1:1 sampling, etc). The only reason you need a MS-DPC 
for v9 is they just never got around to writing it for the RE.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sean1207 at gmail.com  Tue Mar  9 11:01:19 2010
From: sean1207 at gmail.com (Sean Clarke)
Date: Tue, 09 Mar 2010 17:01:19 +0100
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <20100309154018.GW75640@gerbil.cluepon.net>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
	<4B965B31.7000109@gmail.com>
	<20100309154018.GW75640@gerbil.cluepon.net>
Message-ID: <4B9670CF.4080506@gmail.com>

On 3/9/10 4:40 PM, Richard A Steenbergen wrote:
> Nonsense. The CPU usage might be ever so slightly higher in v9, but
> neither is a major contributor to overall load even at the maximum
> supported RE sampling rate. The only time you*need*  a services card is
> when you want to do a much higher rate than the RE can support (i.e. you
> want to do some 1:1 sampling, etc). The only reason you need a MS-DPC
> for v9 is they just never got around to writing it for the RE.
>    

I'm telling you what it's doing.. I'm not saying it's impossible in 
theory on the RE.

It's just Juniper don't do it, probably to stop people breaking stuff, 
i.e. protocol handling.
If you want that to change why not talk to your sales team



From felix.schueren at hosteurope.de  Tue Mar  9 11:38:32 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Tue, 09 Mar 2010 17:38:32 +0100
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <20100309154018.GW75640@gerbil.cluepon.net>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>	<4B965B31.7000109@gmail.com>
	<20100309154018.GW75640@gerbil.cluepon.net>
Message-ID: <4B967988.6040009@hosteurope.de>

> Nonsense. The CPU usage might be ever so slightly higher in v9, but
> neither is a major contributor to overall load even at the maximum
> supported RE sampling rate. The only time you *need* a services card is
> when you want to do a much higher rate than the RE can support (i.e. you 
> want to do some 1:1 sampling, etc). The only reason you need a MS-DPC 
> for v9 is they just never got around to writing it for the RE.
> 
100% agreed. I've stumbled across this as well, and it's annyoing as 
hell. I'd even settle for a max-pps one magnitude less than for the 
current v5 stuff, i.e. something like 700pps maximum. Or a maximum rate 
of 1 in 10000 packets, anything really. Right now it simply goes like this:

me: "Boss, we need to order a dozen MS-DPCs for millions of dollars that 
we don't actually need to get ipv6 netflow data"
boss: "(laughs, then points me to the exit)"

I've already complained to my sales people and my SE. Bitching on this 
list won't hurt. :)

btw, I've already asked to implement two hidden knobs:

set system violate-arp-rfcs;
set system allow-routing-engine-overloading;

or actually, alias it with
set system user-knows-he-can-break-stuff;

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen



From ras at e-gerbil.net  Tue Mar  9 15:49:57 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 9 Mar 2010 14:49:57 -0600
Subject: [j-nsp] netflow v9 on a Juniper MX
In-Reply-To: <4B9670CF.4080506@gmail.com>
References: <91F8523E-87D4-471A-983E-D205E6DC1119@arnes.si>
	<4B965B31.7000109@gmail.com>
	<20100309154018.GW75640@gerbil.cluepon.net>
	<4B9670CF.4080506@gmail.com>
Message-ID: <20100309204957.GA75640@gerbil.cluepon.net>

On Tue, Mar 09, 2010 at 05:01:19PM +0100, Sean Clarke wrote:
> I'm telling you what it's doing.. I'm not saying it's impossible in 
> theory on the RE.
> 
> It's just Juniper don't do it, probably to stop people breaking stuff, 
> i.e. protocol handling.
> If you want that to change why not talk to your sales team

Somebody is smoking some serious crack if they claimed v9 can't be
supported in CPU. Yes the templates and extra fields might mean you have
to move a pointer around a few more times and write a few extra bytes of
data, but this is all absurdly trivial stuff for a CPU to do even a few
thousand times a second. Think about it this way, if the flow protocol 
was really significantly more heavy weight you'd have a much harder time 
processing the results on the collector side too.

To put it into perspective, you're burning FAR more cpu and memory in
wasted overhead copying data for your entire routing table between the
rpd and sampled processes just to populate that "asn" field with either
the neighbor or origin value. I've asked for a knob to turn that off
(since I don't care about that data and it would save ~100MB of ram) for
years and nobody cared (though perhaps rightfully so, because it's a
pretty small amount of cpu/memory and a non-issue on a modern RE). Hell
my chassisd process burns WAY more cpu time than my sampled. :)

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
 1164 root        1  97    0 34740K 18552K select 179.0H  5.32% chassisd
 1879 root        1 111   15   120M   120M RUN    951:29  0.05% sampled

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From chmorl at wm.edu  Tue Mar  9 15:36:55 2010
From: chmorl at wm.edu (Clarke Morledge)
Date: Tue, 9 Mar 2010 15:36:55 -0500 (EST)
Subject: [j-nsp]  netflow v9 on a Juniper MX
In-Reply-To: <mailman.11.1268154005.91416.juniper-nsp@puck.nether.net>
References: <mailman.11.1268154005.91416.juniper-nsp@puck.nether.net>
Message-ID: <Pine.SOC.4.60.1003091524420.23426@stat.wm.edu>

My understanding is that new Trio card for the MX will allow you to do 
Netflow processing on the line card itself, without the need for a 
separate Multiservices DPC card.

What I don't know is if there is some flavor of 10.x available where this 
is currently supported on these new cards.  In other words, the hardware 
is there, but the software isn't ready yet.   Does anyone know for sure?

Of course, this doesn't really help you if you only have the DPCE 4x 10GE 
R cards.


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187


From ras at e-gerbil.net  Tue Mar  9 16:32:27 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 9 Mar 2010 15:32:27 -0600
Subject: [j-nsp] 512MB ought to be enough for anybody
Message-ID: <20100309213227.GB75640@gerbil.cluepon.net>

Ok so, I'm currently beating my head against the inpenetrable wall of
anti-clue that is JTAC (yes I know what you're asking, when am I not? 
:P), and I've apparently reached a point of impasse where I need to 
solicit some external assistance to help get the point across.

The other day we discovered a neat little issue on the EX8200 (all
available code), there is a hard coded resource limit being set by RPD
(not even in the usual places like login.conf class settings that you
can hack around) that limits the size of the data segment to 512MB. When
you try to exceed that limit, rpd coredumps like so:

Process (55002,rpd) attempted to exceed RLIMIT_DATA: attempted 524412 KB Max 524288 KB 
pid 55002 (rpd), uid 0: exited on signal 6 (core dumped)

Now, while sane and rational people might see this as a pretty big
problem, Juniper actually believes that this is working as designed and
a perfectly good thing. Here is the response I got back from Advanced
JTAC:

> As per my communication with the engineering, the current limitation  
> of the memory allocation for "RPD" process is sufficient enough handle 
> 500k+ routes in EX switch, so theoretically we should not see any 
> memory usage issue here. But, there could be other issues such memory 
> leak etc. which can cause process to hog more memory. It is important 
> to analyze core dump of "rpd" so that we can look into root cause of 
> the issue. 

I of course tried to explain the concept of multiple paths learned from
multiple neighbors in the RIB vs the routes exported to the FIB, and
that my 512MB of rpd utilization was perfectly normal considering the
number of BGP paths we had (which for us is actually pretty darn small,
most of our MX960 routers are doing closer to 1GB in rpd):

Groups: 15 Peers: 14 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0            933817     332257          0          0          0          0
inetflow.0            50         25          0          0          0          0
inet6.0             4774       2545          0          0          0          0

But they've flatly refused to believe me that this is normal and that a 
512MB cap is very very broken, and continue to try and "find the source 
of the memory leak". That I'm still having this argument with them, and 
that EX engineering doesn't understand 512MB doesn't support that many 
paths, frankly boggles the mind.

I sortof understand why they think they need to cap the memory usage of 
rpd. One of the problems with the EX platform is that they don't ship 
any real storage on the RE, for example this 8208 RE has only 2GB TOTAL, 
with very little free space:

Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/da0s1a      366M    123M    214M    37%    /
/dev/da0s1f      244M     20M    205M     9%    /var
/dev/da0s3d      630M    612K    579M     0%    /var/tmp
/dev/da0s3e      111M    1.8M    100M     2%    /config

How they plan to handle writing 2GB dumps to disk when the kernel panics
is beyond me, this available space (after I removed EVERYTHING possible)
wasn't even enough for me to untar the rpd coredump and gdb it locally.
But the other consequence to no real storage is no swap, so when the
router does run out of memory things are going to go south in a hurry.
That said, at the point rpd is crashing there is almost 1GB of ram left
in the free state, so clearly 512MB is far too low of a limit for
practical use. The problem itself is bad enough, but the bigger problem
here is that these guys really don't seem to understand why this is a
bad thing.

So, can somebody at Juniper please go break the glass on the emergency 
cluebat, go find the EX guys, and beat them upside the head with it 
until they get detached retinas? Pretty please? :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From bruno.juniper at gmail.com  Wed Mar 10 02:08:58 2010
From: bruno.juniper at gmail.com (scot tony)
Date: Wed, 10 Mar 2010 15:08:58 +0800
Subject: [j-nsp] Juniper ISIS leak problem
Message-ID: <3eca27001003092308w5f59c1dl9bdb2874b0bea8b2@mail.gmail.com>

Dear all,

When I do some ISIS lab, I found a interesting question. The topo in
attachment. when i did ISIS Leak on R2 and R3,interesting thing occur. I
check the route on R2,I found the R3's loopback is suboptimum,not go R2-R3
link directly.It go through R4. I found Juniper document,It said Juniper
prefered L1 intra route than L2 intra route.On Cisco device,It doesn't have
this kind problem.Could some guy have some idea to solve this problem on
Juniper device?

Best Regards,
Bruno

From truman at suspicious.org  Wed Mar 10 03:23:52 2010
From: truman at suspicious.org (Truman Boyes)
Date: Wed, 10 Mar 2010 19:23:52 +1100
Subject: [j-nsp] 512MB ought to be enough for anybody
In-Reply-To: <20100309213227.GB75640@gerbil.cluepon.net>
References: <20100309213227.GB75640@gerbil.cluepon.net>
Message-ID: <F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>

Hi Richard, you bring up some good points. I will chat with some ex  
people on the rpd memory limitation on ex. It doesn't seem to be  
necessary but there may be some design considerations on the static  
value.

Truman


On 10/03/2010, at 8:32 AM, Richard A Steenbergen <ras at e-gerbil.net>  
wrote:

> Ok so, I'm currently beating my head against the inpenetrable wall of
> anti-clue that is JTAC (yes I know what you're asking, when am I not?
> :P), and I've apparently reached a point of impasse where I need to
> solicit some external assistance to help get the point across.
>
> The other day we discovered a neat little issue on the EX8200 (all
> available code), there is a hard coded resource limit being set by RPD
> (not even in the usual places like login.conf class settings that you
> can hack around) that limits the size of the data segment to 512MB.  
> When
> you try to exceed that limit, rpd coredumps like so:
>
> Process (55002,rpd) attempted to exceed RLIMIT_DATA: attempted  
> 524412 KB Max 524288 KB
> pid 55002 (rpd), uid 0: exited on signal 6 (core dumped)
>
> Now, while sane and rational people might see this as a pretty big
> problem, Juniper actually believes that this is working as designed  
> and
> a perfectly good thing. Here is the response I got back from Advanced
> JTAC:
>
>> As per my communication with the engineering, the current limitation
>> of the memory allocation for "RPD" process is sufficient enough  
>> handle
>> 500k+ routes in EX switch, so theoretically we should not see any
>> memory usage issue here. But, there could be other issues such memory
>> leak etc. which can cause process to hog more memory. It is important
>> to analyze core dump of "rpd" so that we can look into root cause of
>> the issue.
>
> I of course tried to explain the concept of multiple paths learned  
> from
> multiple neighbors in the RIB vs the routes exported to the FIB, and
> that my 512MB of rpd utilization was perfectly normal considering the
> number of BGP paths we had (which for us is actually pretty darn  
> small,
> most of our MX960 routers are doing closer to 1GB in rpd):
>
> Groups: 15 Peers: 14 Down peers: 1
> Table          Tot Paths  Act Paths Suppressed    History Damp  
> State    Pending
> inet.0            933817     332257          0          0           
> 0          0
> inetflow.0            50         25          0          0           
> 0          0
> inet6.0             4774       2545          0          0           
> 0          0
>
> But they've flatly refused to believe me that this is normal and  
> that a
> 512MB cap is very very broken, and continue to try and "find the  
> source
> of the memory leak". That I'm still having this argument with them,  
> and
> that EX engineering doesn't understand 512MB doesn't support that many
> paths, frankly boggles the mind.
>
> I sortof understand why they think they need to cap the memory usage  
> of
> rpd. One of the problems with the EX platform is that they don't ship
> any real storage on the RE, for example this 8208 RE has only 2GB  
> TOTAL,
> with very little free space:
>
> Filesystem       Size    Used   Avail Capacity  Mounted on
> /dev/da0s1a      366M    123M    214M    37%    /
> /dev/da0s1f      244M     20M    205M     9%    /var
> /dev/da0s3d      630M    612K    579M     0%    /var/tmp
> /dev/da0s3e      111M    1.8M    100M     2%    /config
>
> How they plan to handle writing 2GB dumps to disk when the kernel  
> panics
> is beyond me, this available space (after I removed EVERYTHING  
> possible)
> wasn't even enough for me to untar the rpd coredump and gdb it  
> locally.
> But the other consequence to no real storage is no swap, so when the
> router does run out of memory things are going to go south in a hurry.
> That said, at the point rpd is crashing there is almost 1GB of ram  
> left
> in the free state, so clearly 512MB is far too low of a limit for
> practical use. The problem itself is bad enough, but the bigger  
> problem
> here is that these guys really don't seem to understand why this is a
> bad thing.
>
> So, can somebody at Juniper please go break the glass on the emergency
> cluebat, go find the EX guys, and beat them upside the head with it
> until they get detached retinas? Pretty please? :)
>
> -- 
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From meryem_z at hotmail.com  Wed Mar 10 07:16:59 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Wed, 10 Mar 2010 12:16:59 +0000
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>
References: <20100309213227.GB75640@gerbil.cluepon.net>,
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>
Message-ID: <BLU113-W68D30979FF07726567EEFE1330@phx.gbl>


hello Community,

I configured a forwarding class with high priority loss. Now I need to verify that the traffic sent under this forwarding class ( using a traffic generator) has a high priority loss. The "show interface queue " doesn't show this information. is there any other way to do it ?

Thank you.


 		 	   		  
_________________________________________________________________
Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live Hotmail, c'est gratuit !
https://signup.live.com/signup.aspx?id=60969

From david.roy at orange-ftgroup.com  Wed Mar 10 08:12:10 2010
From: david.roy at orange-ftgroup.com (david.roy at orange-ftgroup.com)
Date: Wed, 10 Mar 2010 14:12:10 +0100
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <BLU113-W68D30979FF07726567EEFE1330@phx.gbl>
References: <20100309213227.GB75640@gerbil.cluepon.net>,
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>
Message-ID: <14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>

Hi,

You can view drops at the fabric level via the command :
 
 show class-of-service fabric statistics

David



 
David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com
 

-----Message d'origine-----
De : juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
Envoy? : mercredi 10 mars 2010 13:17
Cc : juniper-nsp at puck.nether.net
Objet : [j-nsp] Verify loss priority for a forwarding class


hello Community,

I configured a forwarding class with high priority loss. Now I need to verify that the traffic sent under this forwarding class ( using a traffic generator) has a high priority loss. The "show interface queue " doesn't show this information. is there any other way to do it ?

Thank you.


 		 	   		  
_________________________________________________________________
Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live Hotmail, c'est gratuit !
https://signup.live.com/signup.aspx?id=60969
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************



From js at tnib.de  Wed Mar 10 09:14:15 2010
From: js at tnib.de (Joerg Staedele)
Date: Wed, 10 Mar 2010 15:14:15 +0100
Subject: [j-nsp] What is latest JunOS 9.3 SR?
Message-ID: <c2e04b47-bafd-48bb-86b0-a8f8e17383dc@tnib.de>

Dear colleages,

someone might tell me what Servicerelease is the latest for JunOS 9.3? Maybe with the (direct) Downloadlink to the J Website?

There are no informations on the Website and I don't want to install an "old" image when there's a new one (with more fixes) available.

Thanks!

Best regards,
 Joerg




From pgoyette at juniper.net  Wed Mar 10 09:27:07 2010
From: pgoyette at juniper.net (Paul Goyette)
Date: Wed, 10 Mar 2010 06:27:07 -0800
Subject: [j-nsp] What is latest JunOS 9.3 SR?
In-Reply-To: <c2e04b47-bafd-48bb-86b0-a8f8e17383dc@tnib.de>
References: <c2e04b47-bafd-48bb-86b0-a8f8e17383dc@tnib.de>
Message-ID: <01E990EBBCA96443B7181E382C024A0656BA9AA879@EMBX02-HQ.jnpr.net>

You really need to open a JTAC case to determine which is
the most-recent available service release for your device.

Not all service releases are available for all platforms.


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

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of 
> Joerg Staedele
> Sent: Wednesday, March 10, 2010 6:14 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] What is latest JunOS 9.3 SR?
> Importance: High
> 
> Dear colleages,
> 
> someone might tell me what Servicerelease is the latest for 
> JunOS 9.3? Maybe with the (direct) Downloadlink to the J Website?
> 
> There are no informations on the Website and I don't want to 
> install an "old" image when there's a new one (with more 
> fixes) available.
> 
> Thanks!
> 
> Best regards,
>  Joerg
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

From tima at transtelecom.net  Wed Mar 10 09:32:43 2010
From: tima at transtelecom.net (Tima Maryin)
Date: Wed, 10 Mar 2010 17:32:43 +0300
Subject: [j-nsp] What is latest JunOS 9.3 SR?
In-Reply-To: <c2e04b47-bafd-48bb-86b0-a8f8e17383dc@tnib.de>
References: <c2e04b47-bafd-48bb-86b0-a8f8e17383dc@tnib.de>
Message-ID: <4B97AD8B.2050701@transtelecom.net>

The latest release is 9.3S8 (as far as i know)


But due to some retarded Juniper policy you can't download it from web site, you 
can only get it via case or your juniper representative.



Joerg Staedele wrote:
> Dear colleages,
> 
> someone might tell me what Servicerelease is the latest for JunOS 9.3? Maybe with the (direct) Downloadlink to the J Website?
> 
> There are no informations on the Website and I don't want to install an "old" image when there's a new one (with more fixes) available.
> 
> Thanks!
> 
> Best regards,
>  Joerg

From js at tnib.de  Wed Mar 10 11:25:51 2010
From: js at tnib.de (Joerg Staedele)
Date: Wed, 10 Mar 2010 17:25:51 +0100
Subject: [j-nsp] ISSU Timeouts too small?
Message-ID: <b2b4f7de-2c34-4980-abe3-3f19bccc1e31@tnib.de>

Hi there,

i just tried ISSU (9.5R3 to 9.5R4) on a MX240 and it FAILED .. but it seems that it just failed because after rebooting the (upgraded) Backup RE, the NSR for BGP wasn't syncing fast enough and then the whole ISSU was aborted.

Log shows:

Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_DAEMON_ERROR: Daemon [rpd] state:<ABORT> error:<NSR sync not complete: BGP>
Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_ERROR: Daemon ISSU Abort -1(NSR sync not complete: BGP)

The router has a lot of bgp Sessions so I think that syncing takes some time and that there's a (too small) timeout while the ISSU is done.

Anyone else expirienced the same problem already?

Regards,
 Joerg



From sfouant at shortestpathfirst.net  Wed Mar 10 15:21:15 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 10 Mar 2010 13:21:15 -0700
Subject: [j-nsp] ISSU Timeouts too small?
In-Reply-To: <b2b4f7de-2c34-4980-abe3-3f19bccc1e31@tnib.de>
References: <b2b4f7de-2c34-4980-abe3-3f19bccc1e31@tnib.de>
Message-ID: <002001cac08f$3d483880$b7d8a980$@net>

Are you using BFD by any chance?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Joerg Staedele
> Sent: Wednesday, March 10, 2010 9:26 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] ISSU Timeouts too small?
> 
> Hi there,
> 
> i just tried ISSU (9.5R3 to 9.5R4) on a MX240 and it FAILED .. but it
> seems that it just failed because after rebooting the (upgraded) Backup
> RE, the NSR for BGP wasn't syncing fast enough and then the whole ISSU
> was aborted.
> 
> Log shows:
> 
> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_DAEMON_ERROR: Daemon
> [rpd] state:<ABORT> error:<NSR sync not complete: BGP>
> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_ERROR: Daemon ISSU Abort
> -1(NSR sync not complete: BGP)
> 
> The router has a lot of bgp Sessions so I think that syncing takes some
> time and that there's a (too small) timeout while the ISSU is done.
> 
> Anyone else expirienced the same problem already?
> 
> Regards,
>  Joerg
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From js at tnib.de  Wed Mar 10 15:45:48 2010
From: js at tnib.de (Joerg Staedele)
Date: 10 Mar 2010 20:45:48 +0000
Subject: [j-nsp] ISSU Timeouts too small?
Message-ID: <201003102047.o2AKlPxc026886@puck.nether.net>

No BFD... 

-----Originalnachricht-----
Von: Stefan Fouant
Gesendet: Mi 10.03.2010 21:21
An: 'Joerg Staedele';juniper-nsp at puck.nether.net
Betreff: RE: [j-nsp] ISSU Timeouts too small?
 

Are you using BFD by any chance?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Joerg Staedele
> Sent: Wednesday, March 10, 2010 9:26 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] ISSU Timeouts too small?
> 
> Hi there,
> 
> i just tried ISSU (9.5R3 to 9.5R4) on a MX240 and it FAILED .. but it
> seems that it just failed because after rebooting the (upgraded) Backup
> RE, the NSR for BGP wasn't syncing fast enough and then the whole ISSU
> was aborted.
> 
> Log shows:
> 
> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_DAEMON_ERROR: Daemon
> [rpd] state:<ABORT> error:<NSR sync not complete: BGP>
> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_ERROR: Daemon ISSU Abort
> -1(NSR sync not complete: BGP)
> 
> The router has a lot of bgp Sessions so I think that syncing takes some
> time and that there's a (too small) timeout while the ISSU is done.
> 
> Anyone else expirienced the same problem already?
> 
> Regards,
>  Joerg
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp




From davidtball at gmail.com  Wed Mar 10 16:19:04 2010
From: davidtball at gmail.com (David Ball)
Date: Wed, 10 Mar 2010 14:19:04 -0700
Subject: [j-nsp] ISSU Timeouts too small?
In-Reply-To: <201003102047.o2AKlPxc026886@puck.nether.net>
References: <201003102047.o2AKlPxc026886@puck.nether.net>
Message-ID: <8d4861b01003101319x94f843cnbbcec430ebb3a7de@mail.gmail.com>

  Prior to ISSU, I don't suppose you noted the uptime of the
replicated BGP sessions on your backup RE?  We're about to do a major
code upgrade to fix numerous things, one of which involves the
premature closing of a socket related to BGP session replication to
the backup RE.  This results in the sessions on our backup REs never
being up for more than 30secs.

David B


On 10 March 2010 13:45, Joerg Staedele <js at tnib.de> wrote:
> No BFD...
>
> -----Originalnachricht-----
> Von: Stefan Fouant
> Gesendet: Mi 10.03.2010 21:21
> An: 'Joerg Staedele';juniper-nsp at puck.nether.net
> Betreff: RE: [j-nsp] ISSU Timeouts too small?
>
>
> Are you using BFD by any chance?
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>
>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Joerg Staedele
>> Sent: Wednesday, March 10, 2010 9:26 AM
>> To: juniper-nsp at puck.nether.net
>> Subject: [j-nsp] ISSU Timeouts too small?
>>
>> Hi there,
>>
>> i just tried ISSU (9.5R3 to 9.5R4) on a MX240 and it FAILED .. but it
>> seems that it just failed because after rebooting the (upgraded) Backup
>> RE, the NSR for BGP wasn't syncing fast enough and then the whole ISSU
>> was aborted.
>>
>> Log shows:
>>
>> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_DAEMON_ERROR: Daemon
>> [rpd] state:<ABORT> error:<NSR sync not complete: BGP>
>> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_ERROR: Daemon ISSU Abort
>> -1(NSR sync not complete: BGP)
>>
>> The router has a lot of bgp Sessions so I think that syncing takes some
>> time and that there's a (too small) timeout while the ISSU is done.
>>
>> Anyone else expirienced the same problem already?
>>
>> Regards,
>>  Joerg
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From charlie at playlouder.com  Wed Mar 10 20:25:27 2010
From: charlie at playlouder.com (Charlie Allom)
Date: Thu, 11 Mar 2010 01:25:27 +0000
Subject: [j-nsp] EX4200 firewall only filters on physical ingress/egress?
Message-ID: <20100311012524.GA14727@spodder.com>

Hello,

has anyone come up against this with the EX4200's? That a firewall
filter will only affect a packet traversing a physical interface..

==trunk==>[port A] (RVI A)..(RVI B) [port B]--access-->
                               ^
   filter applied here --------|

I was expecting the filter on 'input' on RVI B to block traffic, but it
only works entirely when you filter on its 'output'.

Else the host behind [port B] gets the SYN, SYNACKs back, and /then/ it
is blocked by the ethernet-switching or inet filter.

The docs don't mention this, except they never give an example of
filtering on an RVI, just physical routed interfaces. But they DO say
you can do it.. page 1368 of the "Software Guide for EX Series Ethernet
Switches, Release 10.0".

What gives? (I have a case open with JTAC but it's hopeless trying to
convince them to grasp and replicate, so far)


  C.
-- 
 020 7729 4797
 http://blog.playlouder.com/

From js at tnib.de  Thu Mar 11 01:20:05 2010
From: js at tnib.de (Joerg Staedele)
Date: Thu, 11 Mar 2010 07:20:05 +0100
Subject: [j-nsp] ISSU Timeouts too small?
Message-ID: <7ce6833c-50c4-4729-ad8d-42802d8c2a74@tnib.de>

Hi David,

when i checked the sessions on the backup RE the last time, they were up as long as the backup RE was up... so no problem(s) there.

-Joerg

-----Original Message-----
From: David Ball [mailto:davidtball at gmail.com] 
Sent: Wednesday, March 10, 2010 10:19 PM
To: Joerg Staedele
Cc: Stefan Fouant; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] ISSU Timeouts too small?

  Prior to ISSU, I don't suppose you noted the uptime of the
replicated BGP sessions on your backup RE?  We're about to do a major
code upgrade to fix numerous things, one of which involves the
premature closing of a socket related to BGP session replication to
the backup RE.  This results in the sessions on our backup REs never
being up for more than 30secs.

David B


On 10 March 2010 13:45, Joerg Staedele <js at tnib.de> wrote:
> No BFD...
>
> -----Originalnachricht-----
> Von: Stefan Fouant
> Gesendet: Mi 10.03.2010 21:21
> An: 'Joerg Staedele';juniper-nsp at puck.nether.net
> Betreff: RE: [j-nsp] ISSU Timeouts too small?
>
>
> Are you using BFD by any chance?
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>
>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Joerg Staedele
>> Sent: Wednesday, March 10, 2010 9:26 AM
>> To: juniper-nsp at puck.nether.net
>> Subject: [j-nsp] ISSU Timeouts too small?
>>
>> Hi there,
>>
>> i just tried ISSU (9.5R3 to 9.5R4) on a MX240 and it FAILED .. but it
>> seems that it just failed because after rebooting the (upgraded) Backup
>> RE, the NSR for BGP wasn't syncing fast enough and then the whole ISSU
>> was aborted.
>>
>> Log shows:
>>
>> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_DAEMON_ERROR: Daemon
>> [rpd] state:<ABORT> error:<NSR sync not complete: BGP>
>> Mar 10 15:25:49 chassisd[1240]: CHASSISD_ISSU_ERROR: Daemon ISSU Abort
>> -1(NSR sync not complete: BGP)
>>
>> The router has a lot of bgp Sessions so I think that syncing takes some
>> time and that there's a (too small) timeout while the ISSU is done.
>>
>> Anyone else expirienced the same problem already?
>>
>> Regards,
>>  Joerg
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



From vyaaghrah-eng at yahoo.com  Thu Mar 11 05:44:15 2010
From: vyaaghrah-eng at yahoo.com (Abhi)
Date: Thu, 11 Mar 2010 02:44:15 -0800 (PST)
Subject: [j-nsp] Screen OS OSPF Area 0
Message-ID: <857862.61604.qm@web113919.mail.gq1.yahoo.com>

Hi everybody
need to know weather their is way i can disable the default created OSPF area 0 on the screen OS ISG1000 firewall after the OSPF is enabled, as i need all the interfaces of the firewall in same area x to which it belongs.

Also if i keep this area 0 as it is and dont assign any interface is that ok, and rest of the interfaces belong to Area X, should this work fine.

I have not work screen os box and we are currently deciding how this can be deployed in the upcoming network.


 
Regards
Abhijeet.C


From meryem_z at hotmail.com  Thu Mar 11 06:39:31 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Thu, 11 Mar 2010 11:39:31 +0000
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>
References: <20100309213227.GB75640@gerbil.cluepon.net>, ,
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>,
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>,
	<14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>
Message-ID: <BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>


Hello David ,

Thanks for your response, but this command is supported M320 routers and T-series routing platforms only..
Is there any equivalent for M7i routers ?


Thank you.


> From: david.roy at orange-ftgroup.com
> To: meryem_z at hotmail.com
> CC: juniper-nsp at puck.nether.net
> Date: Wed, 10 Mar 2010 14:12:10 +0100
> Subject: RE: [j-nsp] Verify loss priority for a forwarding class
> 
> Hi,
> 
> You can view drops at the fabric level via the command :
>  
>  show class-of-service fabric statistics
> 
> David
> 
> 
> 
>  
> David Roy
> Orange France - RBCI IP Technical Assistance Center
> Tel.   +33(0)299876472
> Mob. +33(0)685522213
> Email. david.roy at orange-ftgroup.com
>  
> 
> -----Message d'origine-----
> De : juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
> Envoy? : mercredi 10 mars 2010 13:17
> Cc : juniper-nsp at puck.nether.net
> Objet : [j-nsp] Verify loss priority for a forwarding class
> 
> 
> hello Community,
> 
> I configured a forwarding class with high priority loss. Now I need to verify that the traffic sent under this forwarding class ( using a traffic generator) has a high priority loss. The "show interface queue " doesn't show this information. is there any other way to do it ?
> 
> Thank you.
> 
> 
>  		 	   		  
> _________________________________________________________________
> Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live Hotmail, c'est gratuit !
> https://signup.live.com/signup.aspx?id=60969
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
> 
 		 	   		  
_________________________________________________________________
Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e Microsoft
https://signup.live.com/signup.aspx?id=60969

From addy.mathur at gmail.com  Thu Mar 11 07:14:31 2010
From: addy.mathur at gmail.com (Addy Mathur)
Date: Thu, 11 Mar 2010 07:14:31 -0500
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>
References: <20100309213227.GB75640@gerbil.cluepon.net>
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>
	<14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>
	<BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>
Message-ID: <df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>

Meryem:

Maybe try a firewall filter with a counter on the egress interface?
Something like:

from forwarding-class <forwarding-class_name>
from loss-priority high
then count fc-blah_lp-high
then accept

--Addy.


On 3/11/10, meryem Z <meryem_z at hotmail.com> wrote:
>
> Hello David ,
>
> Thanks for your response, but this command is supported M320 routers and
> T-series routing platforms only..
> Is there any equivalent for M7i routers ?
>
>
> Thank you.
>
>
>> From: david.roy at orange-ftgroup.com
>> To: meryem_z at hotmail.com
>> CC: juniper-nsp at puck.nether.net
>> Date: Wed, 10 Mar 2010 14:12:10 +0100
>> Subject: RE: [j-nsp] Verify loss priority for a forwarding class
>>
>> Hi,
>>
>> You can view drops at the fabric level via the command :
>>
>>  show class-of-service fabric statistics
>>
>> David
>>
>>
>>
>>
>> David Roy
>> Orange France - RBCI IP Technical Assistance Center
>> Tel.   +33(0)299876472
>> Mob. +33(0)685522213
>> Email. david.roy at orange-ftgroup.com
>>
>>
>> -----Message d'origine-----
>> De : juniper-nsp-bounces at puck.nether.net
>> [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
>> Envoy? : mercredi 10 mars 2010 13:17
>> Cc : juniper-nsp at puck.nether.net
>> Objet : [j-nsp] Verify loss priority for a forwarding class
>>
>>
>> hello Community,
>>
>> I configured a forwarding class with high priority loss. Now I need to
>> verify that the traffic sent under this forwarding class ( using a traffic
>> generator) has a high priority loss. The "show interface queue " doesn't
>> show this information. is there any other way to do it ?
>>
>> Thank you.
>>
>>
>>  		 	   		
>> _________________________________________________________________
>> Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live
>> Hotmail, c'est gratuit !
>> https://signup.live.com/signup.aspx?id=60969
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> *********************************
>> This message and any attachments (the "message") are confidential and
>> intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered,
>> changed or falsified.
>> If you are not the intended addressee of this message, please cancel it
>> immediately and inform the sender.
>> ********************************
>>
>  		 	   		
> _________________________________________________________________
> Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e
> Microsoft
> https://signup.live.com/signup.aspx?id=60969
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

-- 
Sent from my mobile device


From david.reader at zeninternet.co.uk  Thu Mar 11 09:43:33 2010
From: david.reader at zeninternet.co.uk (David Reader)
Date: Thu, 11 Mar 2010 14:43:33 +0000
Subject: [j-nsp] M20 FE PIC
Message-ID: <20100311144333.9d064351.david.reader@zeninternet.co.uk>


Hi all,

Can any of you confirm if the P-4FE-TX module for the M20 supports 10-Base-T operation, or if it is 100Mbit only?

Thanks,
d.




From ObrienH at missouri.edu  Thu Mar 11 10:29:55 2010
From: ObrienH at missouri.edu (OBrien, Will)
Date: Thu, 11 Mar 2010 09:29:55 -0600
Subject: [j-nsp] training suggestions for advanced MX router kung fu
Message-ID: <50A80C09-F589-4DE4-B488-4D1FB703B52F@missouri.edu>

Hey guys,
I'd like to hunt down some advanced training for the MX platform. Any suggestions/reviews? To give you a feel for what I'm after, mine are border gateways with full BGP feeds from I1 and I2 and police traffic per individual user ip address to destination ip for a couple of /16s. From there, I generate default routes to the rest of my network via OSPF.

>From here I'm hoping to collapse some Nortel 8600s into virtual routers and possibly replace some of my firewall functionality with a MS-DPC to free up some netscreen 5400s (and then put the 5400s into a dual chassis HA mode for my data center....

Will

From jared at puck.nether.net  Thu Mar 11 10:53:53 2010
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 11 Mar 2010 10:53:53 -0500
Subject: [j-nsp] M20 FE PIC
In-Reply-To: <20100311144333.9d064351.david.reader@zeninternet.co.uk>
References: <20100311144333.9d064351.david.reader@zeninternet.co.uk>
Message-ID: <7D15D1BD-250E-42DF-BDAB-84D0E322D4E3@puck.nether.net>


On Mar 11, 2010, at 9:43 AM, David Reader wrote:

> Can any of you confirm if the P-4FE-TX module for the M20 supports 10-Base-T operation, or if it is 100Mbit only?

100m only.

- Jared

From meryem_z at hotmail.com  Thu Mar 11 11:44:17 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Thu, 11 Mar 2010 16:44:17 +0000
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>
References: <20100309213227.GB75640@gerbil.cluepon.net>,
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>,
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>,
	<14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>,
	<BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>,
	<df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>
Message-ID: <BLU113-W9E7CADE6AAE1CA3E68F68E1320@phx.gbl>


it seems a good idea , i will test it.

thank you.



> Date: Thu, 11 Mar 2010 07:14:31 -0500
> Subject: Re: [j-nsp] Verify loss priority for a forwarding class
> From: addy.mathur at gmail.com
> To: meryem_z at hotmail.com; david.roy at orange-ftgroup.com; juniper-nsp at puck.nether.net
> 
> Meryem:
> 
> Maybe try a firewall filter with a counter on the egress interface?
> Something like:
> 
> from forwarding-class <forwarding-class_name>
> from loss-priority high
> then count fc-blah_lp-high
> then accept
> 
> --Addy.
> 
> 
> On 3/11/10, meryem Z <meryem_z at hotmail.com> wrote:
> >
> > Hello David ,
> >
> > Thanks for your response, but this command is supported M320 routers and
> > T-series routing platforms only..
> > Is there any equivalent for M7i routers ?
> >
> >
> > Thank you.
> >
> >
> >> From: david.roy at orange-ftgroup.com
> >> To: meryem_z at hotmail.com
> >> CC: juniper-nsp at puck.nether.net
> >> Date: Wed, 10 Mar 2010 14:12:10 +0100
> >> Subject: RE: [j-nsp] Verify loss priority for a forwarding class
> >>
> >> Hi,
> >>
> >> You can view drops at the fabric level via the command :
> >>
> >>  show class-of-service fabric statistics
> >>
> >> David
> >>
> >>
> >>
> >>
> >> David Roy
> >> Orange France - RBCI IP Technical Assistance Center
> >> Tel.   +33(0)299876472
> >> Mob. +33(0)685522213
> >> Email. david.roy at orange-ftgroup.com
> >>
> >>
> >> -----Message d'origine-----
> >> De : juniper-nsp-bounces at puck.nether.net
> >> [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
> >> Envoy? : mercredi 10 mars 2010 13:17
> >> Cc : juniper-nsp at puck.nether.net
> >> Objet : [j-nsp] Verify loss priority for a forwarding class
> >>
> >>
> >> hello Community,
> >>
> >> I configured a forwarding class with high priority loss. Now I need to
> >> verify that the traffic sent under this forwarding class ( using a traffic
> >> generator) has a high priority loss. The "show interface queue " doesn't
> >> show this information. is there any other way to do it ?
> >>
> >> Thank you.
> >>
> >>
> >>  		 	   		
> >> _________________________________________________________________
> >> Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live
> >> Hotmail, c'est gratuit !
> >> https://signup.live.com/signup.aspx?id=60969
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >> *********************************
> >> This message and any attachments (the "message") are confidential and
> >> intended solely for the addressees.
> >> Any unauthorised use or dissemination is prohibited.
> >> Messages are susceptible to alteration.
> >> France Telecom Group shall not be liable for the message if altered,
> >> changed or falsified.
> >> If you are not the intended addressee of this message, please cancel it
> >> immediately and inform the sender.
> >> ********************************
> >>
> >  		 	   		
> > _________________________________________________________________
> > Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e
> > Microsoft
> > https://signup.live.com/signup.aspx?id=60969
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> 
> -- 
> Sent from my mobile device
 		 	   		  
_________________________________________________________________
Hotmail : un service de messagerie gratuit, fiable et complet
https://signup.live.com/signup.aspx?id=60969

From sfouant at shortestpathfirst.net  Thu Mar 11 12:08:19 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Thu, 11 Mar 2010 10:08:19 -0700
Subject: [j-nsp] Screen OS OSPF Area 0
In-Reply-To: <857862.61604.qm@web113919.mail.gq1.yahoo.com>
References: <857862.61604.qm@web113919.mail.gq1.yahoo.com>
Message-ID: <000601cac13d$73e51800$5baf4800$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Abhi
> Sent: Thursday, March 11, 2010 3:44 AM
> To: Juniper Puck
> Subject: [j-nsp] Screen OS OSPF Area 0
> 
> Hi everybody
> need to know weather their is way i can disable the default created
> OSPF area 0 on the screen OS ISG1000 firewall after the OSPF is
> enabled, as i need all the interfaces of the firewall in same area x to
> which it belongs.
> 
> Also if i keep this area 0 as it is and dont assign any interface is
> that ok, and rest of the interfaces belong to Area X, should this work
> fine.
> 
> I have not work screen os box and we are currently deciding how this
> can be deployed in the upcoming network.

You can just configure new areas and add your interfaces to their respective
areas.  As long as you don't have any interfaces bound to Area 0 you will be
fine.  IIRC you can't delete this default created Area in ScreenOS.

HTHs.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From sronan at fattoc.com  Thu Mar 11 18:52:42 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 18:52:42 -0500
Subject: [j-nsp] Prefer RIP Neighbor
Message-ID: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>

Hello list,

I have exhausted all of my capabilities to figure out the answer to  
this question, so I am hoping you can help.

I have two connections to the same network, which both provide me  
routes via RIP for Multicast sources.

Is there a way for me to prefer the routes I receive via one of the  
connections over there other?

Thanks,
Shane


From mailinglists.chk at gmail.com  Thu Mar 11 19:29:07 2010
From: mailinglists.chk at gmail.com (chk)
Date: Thu, 11 Mar 2010 16:29:07 -0800
Subject: [j-nsp] Netscreen NAT and TCP window scaling issues
Message-ID: <4B998AD3.4000200@gmail.com>

I have a client sitting behind a netscreen firewall that is seeing a 
delay when trying to connect via tcp to a server on the internet while 
being natted to the netscreens external IP and TCP window scaling is 
enabled. If I create a one-to-one nat mapping specifically for the 
client the connection is instant.

Here is the tcpdump on the server when the client tries to connect while 
being natted to the netscreens external IP with TCP window scaling enabled

16:23:08.847308 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981609 0,sackOK,eol>
16:23:09.755649 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981618 0,sackOK,eol>
16:23:10.756198 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981628 0,sackOK,eol>
16:23:11.756782 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981638 0,sackOK,eol>
16:23:12.757413 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981648 0,sackOK,eol>
16:23:13.758127 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981658 0,sackOK,eol>
16:23:15.759429 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 153981678 0,sackOK,eol>
16:23:19.762105 IP x.x.x.x.42852 > y.y.y.177.22: S 
3899166006:3899166006(0) win 65535 <mss 1380,sackOK,eol>
16:23:19.762130 IP y.y.y.177.22 > x.x.x.x.42852: S 
4286889391:4286889391(0) ack 3899166007 win 5840 <mss 1460>


Here is the tcpdump on the server when the client tries to connect while 
a one-to-one nat is in place with TCP window scaling enabled

17:51:42.373439 IP x.x.x.x.49165 > y.y.y.177.22: S 
1731332088:1731332088(0) win 65535 <mss 1380,nop,wscale 
3,nop,nop,timestamp 409029697 0,sackOK,eol>
17:51:42.438272 IP y.y.y.177.22 > x.x.x.49165: S 
1297584268:1297584268(0) ack 1731332089 win 5792 <mss 
1460,nop,nop,timestamp 1704280650 409029697,nop,wscale 9>

When the client is being natted to the netscreens public IP we see the 
SYN makes it to the server, but the server ignores the SYN if the TCP 
window scale option is set. As soon as the client leaves the window 
scale option unset the server responds with a SYN-ACK. So it appears 
there is an issue with window scaling and we verified that disabling 
window scaling on the client resulted in instant connection. With that 
being said, we also saw that connections were not delayed if windows 
scaling was enabled and the client had a one-to-one mapping on the 
netscreen. Any ideas on why there is an issue with window scaling and 
one-to-many nat mappings?


From sronan at fattoc.com  Thu Mar 11 21:08:28 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 21:08:28 -0500
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <dffd2e731003111616s2c3ee45uca4a4560ead4da92@mail.gmail.com>
References: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>
	<dffd2e731003111616s2c3ee45uca4a4560ead4da92@mail.gmail.com>
Message-ID: <C82B960C-5300-4818-8AAD-0D9F2269EBBC@fattoc.com>

I tried this, but it seems to set the metric for the route, and does  
cause the router to choose one interface over the other.

Shane

On Mar 11, 2010, at 7:16 PM, Hoogen wrote:

> This should work..
>
> set protocols rip group rip neighbor <int> metric-in <metric>
>
> -Hoogen
>
> On Thu, Mar 11, 2010 at 3:52 PM, Shane Ronan <sronan at fattoc.com>  
> wrote:
> Hello list,
>
> I have exhausted all of my capabilities to figure out the answer to  
> this question, so I am hoping you can help.
>
> I have two connections to the same network, which both provide me  
> routes via RIP for Multicast sources.
>
> Is there a way for me to prefer the routes I receive via one of the  
> connections over there other?
>
> Thanks,
> Shane
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


From sronan at fattoc.com  Thu Mar 11 21:12:44 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 21:12:44 -0500
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <C82B960C-5300-4818-8AAD-0D9F2269EBBC@fattoc.com>
References: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>
	<dffd2e731003111616s2c3ee45uca4a4560ead4da92@mail.gmail.com>
	<C82B960C-5300-4818-8AAD-0D9F2269EBBC@fattoc.com>
Message-ID: <2F7412EE-D00E-4496-93C2-1F27721206EA@fattoc.com>

Should have read "does not cause" sorry

On Mar 11, 2010, at 9:08 PM, Shane Ronan wrote:

> I tried this, but it seems to set the metric for the route, and does
> cause the router to choose one interface over the other.
>
> Shane
>
> On Mar 11, 2010, at 7:16 PM, Hoogen wrote:
>
>> This should work..
>>
>> set protocols rip group rip neighbor <int> metric-in <metric>
>>
>> -Hoogen
>>
>> On Thu, Mar 11, 2010 at 3:52 PM, Shane Ronan <sronan at fattoc.com>
>> wrote:
>> Hello list,
>>
>> I have exhausted all of my capabilities to figure out the answer to
>> this question, so I am hoping you can help.
>>
>> I have two connections to the same network, which both provide me
>> routes via RIP for Multicast sources.
>>
>> Is there a way for me to prefer the routes I receive via one of the
>> connections over there other?
>>
>> Thanks,
>> Shane
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From sfouant at shortestpathfirst.net  Thu Mar 11 21:28:35 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Thu, 11 Mar 2010 19:28:35 -0700
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>
References: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>
Message-ID: <002601cac18b$becf6c00$3c6e4400$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Shane Ronan
> Sent: Thursday, March 11, 2010 4:53 PM
> To: Juniper Puck
> Subject: [j-nsp] Prefer RIP Neighbor
> 
> Hello list,
> 
> I have exhausted all of my capabilities to figure out the answer to
> this question, so I am hoping you can help.
> 
> I have two connections to the same network, which both provide me
> routes via RIP for Multicast sources.
> 
> Is there a way for me to prefer the routes I receive via one of the
> connections over there other?

Real stupid question, but did you try the metric-in statement to adjust the
metric for the route from one of the neighbors, assuming both neighbors are
not on the same interface...

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From sronan at fattoc.com  Thu Mar 11 21:32:34 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 21:32:34 -0500
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <002601cac18b$becf6c00$3c6e4400$@net>
References: <FE30FC05-5FC4-48B3-8839-60E1E7413ACF@fattoc.com>
	<002601cac18b$becf6c00$3c6e4400$@net>
Message-ID: <A38A5A7D-1F2D-495E-AA02-BCEE4DE21DBD@fattoc.com>

I did, and it seems to set the metric on the route, regardless of  
interface.

On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:

>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Shane Ronan
>> Sent: Thursday, March 11, 2010 4:53 PM
>> To: Juniper Puck
>> Subject: [j-nsp] Prefer RIP Neighbor
>>
>> Hello list,
>>
>> I have exhausted all of my capabilities to figure out the answer to
>> this question, so I am hoping you can help.
>>
>> I have two connections to the same network, which both provide me
>> routes via RIP for Multicast sources.
>>
>> Is there a way for me to prefer the routes I receive via one of the
>> connections over there other?
>
> Real stupid question, but did you try the metric-in statement to  
> adjust the
> metric for the route from one of the neighbors, assuming both  
> neighbors are
> not on the same interface...
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>


From sfouant at shortestpathfirst.net  Thu Mar 11 21:45:41 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Fri, 12 Mar 2010 02:45:41 +0000
Subject: [j-nsp] Prefer RIP Neighbor
Message-ID: <217949006-1268361988-cardhu_decombobulator_blackberry.rim.net-1710966483-@bda294.bisx.prod.on.blackberry>

Are you setting the metric-in statement at the global level or the neighbor level?

Stefan Fouant
------Original Message------
From: Shane Ronan
To: Stefan Fouant
Cc: 'Juniper Puck'
Subject: Re: [j-nsp] Prefer RIP Neighbor
Sent: Mar 11, 2010 7:32 PM

I did, and it seems to set the metric on the route, regardless of  
interface.

On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:

>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Shane Ronan
>> Sent: Thursday, March 11, 2010 4:53 PM
>> To: Juniper Puck
>> Subject: [j-nsp] Prefer RIP Neighbor
>>
>> Hello list,
>>
>> I have exhausted all of my capabilities to figure out the answer to
>> this question, so I am hoping you can help.
>>
>> I have two connections to the same network, which both provide me
>> routes via RIP for Multicast sources.
>>
>> Is there a way for me to prefer the routes I receive via one of the
>> connections over there other?
>
> Real stupid question, but did you try the metric-in statement to  
> adjust the
> metric for the route from one of the neighbors, assuming both  
> neighbors are
> not on the same interface...
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>



Sent from my Verizon Wireless BlackBerry


From sronan at fattoc.com  Thu Mar 11 21:53:56 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 21:53:56 -0500
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <217949006-1268361988-cardhu_decombobulator_blackberry.rim.net-1710966483-@bda294.bisx.prod.on.blackberry>
References: <217949006-1268361988-cardhu_decombobulator_blackberry.rim.net-1710966483-@bda294.bisx.prod.on.blackberry>
Message-ID: <C3933A87-424D-4694-A044-5B47B39417C4@fattoc.com>

Neighbor level, this is not at all how I expected it to behave.

On Mar 11, 2010, at 9:45 PM, Stefan Fouant wrote:

> Are you setting the metric-in statement at the global level or the  
> neighbor level?
>
> Stefan Fouant
> ------Original Message------
> From: Shane Ronan
> To: Stefan Fouant
> Cc: 'Juniper Puck'
> Subject: Re: [j-nsp] Prefer RIP Neighbor
> Sent: Mar 11, 2010 7:32 PM
>
> I did, and it seems to set the metric on the route, regardless of
> interface.
>
> On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:
>
>>> -----Original Message-----
>>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>>> bounces at puck.nether.net] On Behalf Of Shane Ronan
>>> Sent: Thursday, March 11, 2010 4:53 PM
>>> To: Juniper Puck
>>> Subject: [j-nsp] Prefer RIP Neighbor
>>>
>>> Hello list,
>>>
>>> I have exhausted all of my capabilities to figure out the answer to
>>> this question, so I am hoping you can help.
>>>
>>> I have two connections to the same network, which both provide me
>>> routes via RIP for Multicast sources.
>>>
>>> Is there a way for me to prefer the routes I receive via one of the
>>> connections over there other?
>>
>> Real stupid question, but did you try the metric-in statement to
>> adjust the
>> metric for the route from one of the neighbors, assuming both
>> neighbors are
>> not on the same interface...
>>
>> Stefan Fouant, CISSP, JNCIE-M/T
>> www.shortestpathfirst.net
>> GPG Key ID: 0xB5E3803D
>>
>
>
>
> Sent from my Verizon Wireless BlackBerry


From sfouant at shortestpathfirst.net  Thu Mar 11 21:58:53 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Fri, 12 Mar 2010 02:58:53 +0000
Subject: [j-nsp] Prefer RIP Neighbor
Message-ID: <2106420766-1268362779-cardhu_decombobulator_blackberry.rim.net-2135623752-@bda294.bisx.prod.on.blackberry>

Show us your config for 'protocols rip'.

Stefan Fouant
------Original Message------
From: Shane Ronan
To: sfouant at shortestpathfirst.net
Cc: 'Juniper Puck'
Subject: Re: [j-nsp] Prefer RIP Neighbor
Sent: Mar 11, 2010 7:53 PM

Neighbor level, this is not at all how I expected it to behave.

On Mar 11, 2010, at 9:45 PM, Stefan Fouant wrote:

> Are you setting the metric-in statement at the global level or the  
> neighbor level?
>
> Stefan Fouant
> ------Original Message------
> From: Shane Ronan
> To: Stefan Fouant
> Cc: 'Juniper Puck'
> Subject: Re: [j-nsp] Prefer RIP Neighbor
> Sent: Mar 11, 2010 7:32 PM
>
> I did, and it seems to set the metric on the route, regardless of
> interface.
>
> On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:
>
>>> -----Original Message-----
>>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>>> bounces at puck.nether.net] On Behalf Of Shane Ronan
>>> Sent: Thursday, March 11, 2010 4:53 PM
>>> To: Juniper Puck
>>> Subject: [j-nsp] Prefer RIP Neighbor
>>>
>>> Hello list,
>>>
>>> I have exhausted all of my capabilities to figure out the answer to
>>> this question, so I am hoping you can help.
>>>
>>> I have two connections to the same network, which both provide me
>>> routes via RIP for Multicast sources.
>>>
>>> Is there a way for me to prefer the routes I receive via one of the
>>> connections over there other?
>>
>> Real stupid question, but did you try the metric-in statement to
>> adjust the
>> metric for the route from one of the neighbors, assuming both
>> neighbors are
>> not on the same interface...
>>
>> Stefan Fouant, CISSP, JNCIE-M/T
>> www.shortestpathfirst.net
>> GPG Key ID: 0xB5E3803D
>>
>
>
>
> Sent from my Verizon Wireless BlackBerry



Sent from my Verizon Wireless BlackBerry


From hoogen82 at gmail.com  Thu Mar 11 22:42:21 2010
From: hoogen82 at gmail.com (Hoogen)
Date: Thu, 11 Mar 2010 19:42:21 -0800
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <2106420766-1268362779-cardhu_decombobulator_blackberry.rim.net-2135623752-@bda294.bisx.prod.on.blackberry>
References: <2106420766-1268362779-cardhu_decombobulator_blackberry.rim.net-2135623752-@bda294.bisx.prod.on.blackberry>
Message-ID: <dffd2e731003111942t54aad715m40f01a4d2d633d92@mail.gmail.com>

Config with a small snapshot of the routing table would be nice..

-Hoogen

On Thu, Mar 11, 2010 at 6:58 PM, Stefan Fouant <
sfouant at shortestpathfirst.net> wrote:

> Show us your config for 'protocols rip'.
>
> Stefan Fouant
> ------Original Message------
> From: Shane Ronan
> To: sfouant at shortestpathfirst.net
> Cc: 'Juniper Puck'
> Subject: Re: [j-nsp] Prefer RIP Neighbor
> Sent: Mar 11, 2010 7:53 PM
>
> Neighbor level, this is not at all how I expected it to behave.
>
> On Mar 11, 2010, at 9:45 PM, Stefan Fouant wrote:
>
> > Are you setting the metric-in statement at the global level or the
> > neighbor level?
> >
> > Stefan Fouant
> > ------Original Message------
> > From: Shane Ronan
> > To: Stefan Fouant
> > Cc: 'Juniper Puck'
> > Subject: Re: [j-nsp] Prefer RIP Neighbor
> > Sent: Mar 11, 2010 7:32 PM
> >
> > I did, and it seems to set the metric on the route, regardless of
> > interface.
> >
> > On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:
> >
> >>> -----Original Message-----
> >>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> >>> bounces at puck.nether.net] On Behalf Of Shane Ronan
> >>> Sent: Thursday, March 11, 2010 4:53 PM
> >>> To: Juniper Puck
> >>> Subject: [j-nsp] Prefer RIP Neighbor
> >>>
> >>> Hello list,
> >>>
> >>> I have exhausted all of my capabilities to figure out the answer to
> >>> this question, so I am hoping you can help.
> >>>
> >>> I have two connections to the same network, which both provide me
> >>> routes via RIP for Multicast sources.
> >>>
> >>> Is there a way for me to prefer the routes I receive via one of the
> >>> connections over there other?
> >>
> >> Real stupid question, but did you try the metric-in statement to
> >> adjust the
> >> metric for the route from one of the neighbors, assuming both
> >> neighbors are
> >> not on the same interface...
> >>
> >> Stefan Fouant, CISSP, JNCIE-M/T
> >> www.shortestpathfirst.net
> >> GPG Key ID: 0xB5E3803D
> >>
> >
> >
> >
> > Sent from my Verizon Wireless BlackBerry
>
>
>
> Sent from my Verizon Wireless BlackBerry
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From sronan at fattoc.com  Thu Mar 11 23:50:47 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Thu, 11 Mar 2010 23:50:47 -0500
Subject: [j-nsp] Prefer RIP Neighbor
In-Reply-To: <dffd2e731003111942t54aad715m40f01a4d2d633d92@mail.gmail.com>
References: <2106420766-1268362779-cardhu_decombobulator_blackberry.rim.net-2135623752-@bda294.bisx.prod.on.blackberry>
	<dffd2e731003111942t54aad715m40f01a4d2d633d92@mail.gmail.com>
Message-ID: <9513F733-D2E3-40C0-A981-DCAD4B5D7A97@fattoc.com>

config snippet, show rip neighbors and rip routes are below.

As you can see in the routes, despite the higher metric on  
ge-0/1/2.10, some routes are preferred via ge-0/1/0.10

Thoughts?
Thanks for your help!
---------------------------------------------------------------


set protocols rip send multicast
set protocols rip receive version-2
set protocols rip holddown 75
set protocols rip update-interval 30
set protocols rip group SFTI export advertise-rip-route
set protocols rip group SFTI neighbor ge-0/0/3.0
set protocols rip group SFTI neighbor ge-0/1/1.10
set protocols rip group SFTI neighbor ge-0/1/0.0
set protocols rip group SFTI neighbor ge-0/1/2.10 metric-in 5

                          Source          Destination     Send    
Receive   In
Neighbor          State  Address         Address         Mode    
Mode     Met
--------          -----  -------         -----------     ----    
-------  ---
ge-0/0/3.0           Up 10.0.1.44       224.0.0.9       mcast  v2  
only    1
ge-0/1/0.0           Up 10.4.1.65       224.0.0.9       mcast  v2  
only    1
ge-0/1/1.10          Up 10.152.1.173    224.0.0.9       mcast  v2  
only    1
ge-0/1/2.10          Up 10.170.3.177    224.0.0.9       mcast  v2  
only    5

sronan at pe02.ny2.fat> show route receive-protocol rip 10.170.3.178

inet.0: 319246 destinations, 638064 routes (319245 active, 0 holddown,  
27 hidden)
+ = Active Route, - = Last Active, * = Both

8.9.19.128/25      *[RIP/100] 04:47:01, metric 6, tag 1025
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
8.9.33.128/25      *[RIP/100] 04:47:01, metric 6, tag 1025
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
63.211.72.128/25   *[RIP/100] 04:47:01, metric 6, tag 1025
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
156.48.100.192/28  *[RIP/100] 04:47:01, metric 6, tag 1035
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
156.48.100.208/28  *[RIP/100] 04:47:01, metric 6, tag 1035
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
156.48.101.192/28  *[RIP/100] 04:47:01, metric 6, tag 1035
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.33.5/32    *[RIP/100] 04:47:01, metric 6, tag 15
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.41.72/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.41.80/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.41.88/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.41.120/29  *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.41.168/29  *[RIP/100] 04:47:01, metric 6, tag 1015
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.42.72/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.42.80/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.42.88/29   *[RIP/100] 04:47:01, metric 6, tag 1005
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.42.120/29  *[RIP/100] 04:47:01, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.42.168/29  *[RIP/100] 04:47:00, metric 6, tag 1015
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.53.128/26  *[RIP/100] 04:47:00, metric 6, tag 1025
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.54.128/26  *[RIP/100] 04:47:00, metric 6, tag 1025
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.58.104/29  *[RIP/100] 04:47:00, metric 6, tag 1025
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.61.72/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.61.80/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.61.88/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.61.120/29  *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.61.168/29  *[RIP/100] 04:47:00, metric 6, tag 1015
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.62.72/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.62.80/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
198.140.62.88/29   *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.62.120/29  *[RIP/100] 04:47:00, metric 6, tag 1005
                     > to 10.152.1.174 via ge-0/1/1.10
                       to 10.170.3.178 via ge-0/1/2.10
198.140.62.168/29  *[RIP/100] 04:47:00, metric 6, tag 1015
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10
208.92.194.128/25  *[RIP/100] 04:47:01, metric 6, tag 1025
                       to 10.152.1.174 via ge-0/1/1.10
                     > to 10.170.3.178 via ge-0/1/2.10



On Mar 11, 2010, at 10:42 PM, Hoogen wrote:

> Config with a small snapshot of the routing table would be nice..
>
> -Hoogen
>
> On Thu, Mar 11, 2010 at 6:58 PM, Stefan Fouant <sfouant at shortestpathfirst.net 
> > wrote:
> Show us your config for 'protocols rip'.
>
> Stefan Fouant
> ------Original Message------
> From: Shane Ronan
> To: sfouant at shortestpathfirst.net
> Cc: 'Juniper Puck'
> Subject: Re: [j-nsp] Prefer RIP Neighbor
> Sent: Mar 11, 2010 7:53 PM
>
> Neighbor level, this is not at all how I expected it to behave.
>
> On Mar 11, 2010, at 9:45 PM, Stefan Fouant wrote:
>
> > Are you setting the metric-in statement at the global level or the
> > neighbor level?
> >
> > Stefan Fouant
> > ------Original Message------
> > From: Shane Ronan
> > To: Stefan Fouant
> > Cc: 'Juniper Puck'
> > Subject: Re: [j-nsp] Prefer RIP Neighbor
> > Sent: Mar 11, 2010 7:32 PM
> >
> > I did, and it seems to set the metric on the route, regardless of
> > interface.
> >
> > On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote:
> >
> >>> -----Original Message-----
> >>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> >>> bounces at puck.nether.net] On Behalf Of Shane Ronan
> >>> Sent: Thursday, March 11, 2010 4:53 PM
> >>> To: Juniper Puck
> >>> Subject: [j-nsp] Prefer RIP Neighbor
> >>>
> >>> Hello list,
> >>>
> >>> I have exhausted all of my capabilities to figure out the answer  
> to
> >>> this question, so I am hoping you can help.
> >>>
> >>> I have two connections to the same network, which both provide me
> >>> routes via RIP for Multicast sources.
> >>>
> >>> Is there a way for me to prefer the routes I receive via one of  
> the
> >>> connections over there other?
> >>
> >> Real stupid question, but did you try the metric-in statement to
> >> adjust the
> >> metric for the route from one of the neighbors, assuming both
> >> neighbors are
> >> not on the same interface...
> >>
> >> Stefan Fouant, CISSP, JNCIE-M/T
> >> www.shortestpathfirst.net
> >> GPG Key ID: 0xB5E3803D
> >>
> >
> >
> >
> > Sent from my Verizon Wireless BlackBerry
>
>
>
> Sent from my Verizon Wireless BlackBerry
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


From techtalm at gmail.com  Fri Mar 12 01:24:02 2010
From: techtalm at gmail.com (Techtalm)
Date: Fri, 12 Mar 2010 08:24:02 +0200
Subject: [j-nsp] SRX in HA with OSPF failover time
Message-ID: <013601cac1ac$9d709fe0$d851dfa0$@com>

Hi All,

 

I have configured 2x SRX-3600 in high availability mode in front 2x 6500,
the HA mode is active/passive.

OSPF is running and I have configured graceful restart on the SRX in order
to make the transition between the active and the passive more smoothly.

But still when I take down the active machine it takes like 14 sec before
the network become stable again.

Does anyone has any idea regarding this situation?

 

BR,

Tal M

 


From pekkas at netcore.fi  Fri Mar 12 02:32:27 2010
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 12 Mar 2010 09:32:27 +0200 (EET)
Subject: [j-nsp] M20 FE PIC
In-Reply-To: <7D15D1BD-250E-42DF-BDAB-84D0E322D4E3@puck.nether.net>
References: <20100311144333.9d064351.david.reader@zeninternet.co.uk>
	<7D15D1BD-250E-42DF-BDAB-84D0E322D4E3@puck.nether.net>
Message-ID: <alpine.LRH.2.00.1003120928400.32056@netcore.fi>

On Thu, 11 Mar 2010, Jared Mauch wrote:
> On Mar 11, 2010, at 9:43 AM, David Reader wrote:
>> Can any of you confirm if the P-4FE-TX module for the M20 supports 10-Base-T operation, or if it is 100Mbit only?
>
> 100m only.

Hmm. I wonder how our PICs work fine with 10mbit/s as well? :-)
Officially it isn't supported, I think, though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From sean1207 at gmail.com  Fri Mar 12 03:07:54 2010
From: sean1207 at gmail.com (Sean Clarke)
Date: Fri, 12 Mar 2010 09:07:54 +0100
Subject: [j-nsp] M20 FE PIC
In-Reply-To: <alpine.LRH.2.00.1003120928400.32056@netcore.fi>
References: <20100311144333.9d064351.david.reader@zeninternet.co.uk>	<7D15D1BD-250E-42DF-BDAB-84D0E322D4E3@puck.nether.net>
	<alpine.LRH.2.00.1003120928400.32056@netcore.fi>
Message-ID: <4B99F65A.2020006@gmail.com>

On 3/12/10 8:32 AM, Pekka Savola wrote:
> Hmm. I wonder how our PICs work fine with 10mbit/s as well? :-)
> Officially it isn't supported, I think, though. 

Yes officially not, but mostly it did ... and you didn't even need to 
pay for a licence ;-)



From vyaaghrah-eng at yahoo.com  Fri Mar 12 04:47:29 2010
From: vyaaghrah-eng at yahoo.com (Abhi)
Date: Fri, 12 Mar 2010 01:47:29 -0800 (PST)
Subject: [j-nsp] Screen OS OSPF Area 0
In-Reply-To: <000601cac13d$73e51800$5baf4800$@net>
References: <857862.61604.qm@web113919.mail.gq1.yahoo.com>
	<000601cac13d$73e51800$5baf4800$@net>
Message-ID: <721381.69535.qm@web113913.mail.gq1.yahoo.com>

thanks 

 
Regards
Abhijeet.C




----- Original Message ----
From: Stefan Fouant <sfouant at shortestpathfirst.net>
To: Abhi <vyaaghrah-eng at yahoo.com>; Juniper Puck <juniper-nsp at puck.nether.net>
Sent: Thu, March 11, 2010 10:38:19 PM
Subject: RE: [j-nsp] Screen OS OSPF Area 0

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Abhi
> Sent: Thursday, March 11, 2010 3:44 AM
> To: Juniper Puck
> Subject: [j-nsp] Screen OS OSPF Area 0
> 
> Hi everybody
> need to know weather their is way i can disable the default created
> OSPF area 0 on the screen OS ISG1000 firewall after the OSPF is
> enabled, as i need all the interfaces of the firewall in same area x to
> which it belongs.
> 
> Also if i keep this area 0 as it is and dont assign any interface is
> that ok, and rest of the interfaces belong to Area X, should this work
> fine.
> 
> I have not work screen os box and we are currently deciding how this
> can be deployed in the upcoming network.

You can just configure new areas and add your interfaces to their respective
areas.  As long as you don't have any interfaces bound to Area 0 you will be
fine.  IIRC you can't delete this default created Area in ScreenOS.

HTHs.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From david at davidcoulson.net  Fri Mar 12 09:34:38 2010
From: david at davidcoulson.net (David Coulson)
Date: Fri, 12 Mar 2010 09:34:38 -0500
Subject: [j-nsp] local switching l2circuit not passing traffic
Message-ID: <4B9A50FE.9020003@davidcoulson.net>

I have what I thought was a pretty simple config - Two VLANs on two GigE 
interfaces, on a MX240 running 9.4R2.9 which are cross-connected within 
the MX using a l2circuit.

If I remove the 'vlan-ccc' encap from the units and assign an IP, we can 
ping to something on the other end - So at least we know end-to-end 
works on both interfaces. Once it's reassembled as a l2circuit, there is 
no connectivity between the two end points. I'm sure it's something 
pretty elementary, but I can't determine what it is. Is there a way to 
sniff or capture traffic on the l2circuit to see what is going on?

Config and 'sh l2circuit connections' is below.

  Local Switch ge-1/0/5.3525
     Interface                 Type  St     Time last up          # Up trans
     ge-1/0/5.3525(vc 0)       loc   Up     Mar 11 12:48:35 2010           1
       Local interface: ge-1/0/5.3525, Status: Up, Encapsulation: VLAN
         Description:
       Local interface: ge-1/0/3.1701, Status: Up, Encapsulation: VLAN

dcoulson at ar2-re0.kth.clev.oh> show configuration interfaces ge-1/0/5
per-unit-scheduler;
vlan-tagging;
speed 1g;
link-mode full-duplex;
encapsulation flexible-ethernet-services;
gigether-options {
     no-auto-negotiation;
}
unit 3525 {
     encapsulation vlan-ccc;
     vlan-id 3525;
     family ccc;
}

dcoulson at ar2-re0.kth.clev.oh> ... configuration interfaces ge-1/0/3
per-unit-scheduler;
vlan-tagging;
speed 1g;
link-mode full-duplex;
encapsulation flexible-ethernet-services;
gigether-options {
     no-auto-negotiation;
}
unit 1700 {
     vlan-id 1700;
     family inet {
         address X.X.X.X/30;
     }
}
unit 1701 {
     encapsulation vlan-ccc;
     vlan-id 1701;
     family ccc;
}


From david at davidcoulson.net  Fri Mar 12 09:47:14 2010
From: david at davidcoulson.net (David Coulson)
Date: Fri, 12 Mar 2010 09:47:14 -0500
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <4B9A5348.600@inetc.co.uk>
References: <4B9A50FE.9020003@davidcoulson.net> <4B9A5348.600@inetc.co.uk>
Message-ID: <4B9A53F2.8080403@davidcoulson.net>

Is there an alternative method of doing this without having consistent 
VLAN IDs?

On 3/12/2010 9:44 AM, Andy Harding wrote:
> The VLAN numbers at both ends of the l2circuit need to be the same for 
> it to work.
>
> This is a very poorly documented limitation of the l2circuit feature.
>

From andy at inetc.co.uk  Fri Mar 12 09:44:24 2010
From: andy at inetc.co.uk (Andy Harding)
Date: Fri, 12 Mar 2010 14:44:24 +0000
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <4B9A50FE.9020003@davidcoulson.net>
References: <4B9A50FE.9020003@davidcoulson.net>
Message-ID: <4B9A5348.600@inetc.co.uk>

David Coulson wrote:
> I have what I thought was a pretty simple config - Two VLANs on two GigE 
> interfaces, on a MX240 running 9.4R2.9 which are cross-connected within 
> the MX using a l2circuit.
> 
> If I remove the 'vlan-ccc' encap from the units and assign an IP, we can 
> ping to something on the other end - So at least we know end-to-end 
> works on both interfaces. Once it's reassembled as a l2circuit, there is 
> no connectivity between the two end points. I'm sure it's something 
> pretty elementary, but I can't determine what it is. Is there a way to 
> sniff or capture traffic on the l2circuit to see what is going on?
> 

The VLAN numbers at both ends of the l2circuit need to be the same for 
it to work.

This is a very poorly documented limitation of the l2circuit feature.

-- 
Regards

Andy Harding
Internet Connections Ltd

Phone: 020 7531 5655
Mobile: 07813 975 459
Fax: 01538 382596
Web: www.inetc.co.uk
Email: andy at inetc.co.uk

From andy at inetc.co.uk  Fri Mar 12 10:53:06 2010
From: andy at inetc.co.uk (Andy Harding)
Date: Fri, 12 Mar 2010 15:53:06 +0000
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <4B9A53F2.8080403@davidcoulson.net>
References: <4B9A50FE.9020003@davidcoulson.net> <4B9A5348.600@inetc.co.uk>
	<4B9A53F2.8080403@davidcoulson.net>
Message-ID: <4B9A6362.2020405@inetc.co.uk>

David Coulson wrote:
> Is there an alternative method of doing this without having consistent 
> VLAN IDs?
> 
> On 3/12/2010 9:44 AM, Andy Harding wrote:
>> The VLAN numbers at both ends of the l2circuit need to be the same for 
>> it to work.
>>
>> This is a very poorly documented limitation of the l2circuit feature.
>>

I believe if you have the IQ SFP PICs you can use the VLAN rewriting 
features to accomplish what you need. However, I'm not lucky enough to 
have any of these PICs and haven't been able to try it out.

-- 
Regards

Andy Harding
Internet Connections Ltd

Phone: 020 7531 5655
Mobile: 07813 975 459
Fax: 01538 382596
Web: www.inetc.co.uk
Email: andy at inetc.co.uk

From ras at e-gerbil.net  Fri Mar 12 11:06:50 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 12 Mar 2010 10:06:50 -0600
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <4B9A53F2.8080403@davidcoulson.net>
References: <4B9A50FE.9020003@davidcoulson.net> <4B9A5348.600@inetc.co.uk>
	<4B9A53F2.8080403@davidcoulson.net>
Message-ID: <20100312160650.GF75640@gerbil.cluepon.net>

On Fri, Mar 12, 2010 at 09:47:14AM -0500, David Coulson wrote:
> Is there an alternative method of doing this without having consistent 
> VLAN IDs?

On your vlan units, use:

input-vlan-map pop;
output-vlan-map push;

This will strip the vlan tag off the packet before encapsulating it 
across the wire, and re-add a new vlan tag of potentially a different 
value on the other side. This of course requires hardware which supports 
it, i.e. MX, T, M120, M7i/M10i with CFEB-E, or I believe even SFP based 
GE PICs on FPC-E on first generation routers will work. What definitely 
won't work are the original fixed-optics SX, LX, or LH PICs.

Also in my experience it was actually much less of a hassle to use CCC
than to do local-switching on a l2circuit, especially if you're trying
to automate the deployment of the circuits (l2circuit local switching
has a really weird and config hierarchy). It's also simpler for the
router to run CCC for local switching.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sthaug at nethelp.no  Fri Mar 12 11:17:15 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Fri, 12 Mar 2010 17:17:15 +0100 (CET)
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <4B9A5348.600@inetc.co.uk>
References: <4B9A50FE.9020003@davidcoulson.net>
	<4B9A5348.600@inetc.co.uk>
Message-ID: <20100312.171715.74734471.sthaug@nethelp.no>

> > I have what I thought was a pretty simple config - Two VLANs on two GigE 
> > interfaces, on a MX240 running 9.4R2.9 which are cross-connected within 
> > the MX using a l2circuit.
> > 
> > If I remove the 'vlan-ccc' encap from the units and assign an IP, we can 
> > ping to something on the other end - So at least we know end-to-end 
> > works on both interfaces. Once it's reassembled as a l2circuit, there is 
> > no connectivity between the two end points. I'm sure it's something 
> > pretty elementary, but I can't determine what it is. Is there a way to 
> > sniff or capture traffic on the l2circuit to see what is going on?
> > 
> 
> The VLAN numbers at both ends of the l2circuit need to be the same for 
> it to work.
> 
> This is a very poorly documented limitation of the l2circuit feature.

With MX you have ample possibilities to push/pop/rewrite VLAN tags, so
VLAN IDs at each end do *not* need to match given a suitable rewrite.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From david at davidcoulson.net  Fri Mar 12 12:38:16 2010
From: david at davidcoulson.net (David Coulson)
Date: Fri, 12 Mar 2010 12:38:16 -0500
Subject: [j-nsp] local switching l2circuit not passing traffic
In-Reply-To: <20100312160650.GF75640@gerbil.cluepon.net>
References: <4B9A50FE.9020003@davidcoulson.net> <4B9A5348.600@inetc.co.uk>
	<4B9A53F2.8080403@davidcoulson.net>
	<20100312160650.GF75640@gerbil.cluepon.net>
Message-ID: <4B9A7C08.1070807@davidcoulson.net>

On 3/12/2010 11:06 AM, Richard A Steenbergen wrote:
> On your vlan units, use:
>
> input-vlan-map pop;
> output-vlan-map push;
Still did not work after that, so I got rid of the l2circuit and created 
a interface-switch... Maybe that will work better.

David

From listacct at tulsaconnect.com  Fri Mar 12 15:13:17 2010
From: listacct at tulsaconnect.com (TCIS List Acct)
Date: Fri, 12 Mar 2010 14:13:17 -0600
Subject: [j-nsp] Logging default deny traffic on SSG-550?
Message-ID: <4B9AA05D.2080806@tulsaconnect.com>

We've got a pair of Juniper SSG-550's in HA mode running Screen OS 6.1.0r4.0. 
For the life of me I can't figure out how to enable logging for denied/blocked 
traffic for the implicit default-deny rule.  I've followed the instructions 
found in the Screen OS Cookbook with no results.

Anyone have any pointers?

Thanks.

--Mike

From evans.584 at osu.edu  Fri Mar 12 15:23:09 2010
From: evans.584 at osu.edu (Kyle Evans)
Date: Fri, 12 Mar 2010 15:23:09 -0500
Subject: [j-nsp] Logging default deny traffic on SSG-550?
In-Reply-To: <4B9AA05D.2080806@tulsaconnect.com>
References: <4B9AA05D.2080806@tulsaconnect.com>
Message-ID: <4B9AA2AD.6070509@osu.edu>

We have those too, and I don't think you can enable logging for the 
default deny.  We get the functionality by making a global deny policy 
and logging it.  Here is the command:

set policy global any any any deny log


Kyle



TCIS List Acct wrote:
> We've got a pair of Juniper SSG-550's in HA mode running Screen OS 
> 6.1.0r4.0. For the life of me I can't figure out how to enable logging 
> for denied/blocked traffic for the implicit default-deny rule.  I've 
> followed the instructions found in the Screen OS Cookbook with no 
> results.
>
> Anyone have any pointers?
>
> Thanks.
>
> --Mike
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From barnys at juniper.net  Fri Mar 12 15:22:49 2010
From: barnys at juniper.net (Barny Sanchez)
Date: Fri, 12 Mar 2010 12:22:49 -0800
Subject: [j-nsp] Logging default deny traffic on SSG-550?
Message-ID: <4D2B132DE2E6F240BB6A440B4DBC5F815622187742@EMBX02-HQ.jnpr.net>

The easiest is to configure a global policy with a default action of deny and enable logging on it. In that any traffic from any zone to any zone that reaches the default deny policy gets denied (as usual) and logged.  
Conversely you can do a any any any policy for every pair of zones, action deny and enable logging. Depending on how many zones you have then you will end up configuring a whole bunch of these policies, so the first solution offered is more effective.

If you go with the first approach please be careful with the intra-zone traffic if you have any, as this will be dropped. So you would need to configure explicit intra-zone policies where needed.

Thanks,



Barny Sanchez | Consulting Engineer - Security Solutions | Juniper Networks  |  Direct: +1.774.318.9140 | barnys at juniper.net <mailto:barnys at juniper.net>
(Message sent via my mobile device, sorry for any typos and shortness of my response)

----- Original Message -----
From: juniper-nsp-bounces at puck.nether.net <juniper-nsp-bounces at puck.nether.net>
To: 'juniper-nsp at puck.nether.net' <juniper-nsp at puck.nether.net>
Sent: Fri Mar 12 12:13:17 2010
Subject: [j-nsp] Logging default deny traffic on SSG-550?

We've got a pair of Juniper SSG-550's in HA mode running Screen OS 6.1.0r4.0. 
For the life of me I can't figure out how to enable logging for denied/blocked 
traffic for the implicit default-deny rule.  I've followed the instructions 
found in the Screen OS Cookbook with no results.

Anyone have any pointers?

Thanks.

--Mike
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From walaaez at bmc.com.sa  Sat Mar 13 06:41:03 2010
From: walaaez at bmc.com.sa (Walaa Abdel razzak)
Date: Sat, 13 Mar 2010 14:41:03 +0300
Subject: [j-nsp] Logical Routers QoS
Message-ID: <E2C120A806ED3349A9F9E9913E0C8C1F5E7BA5@bmcserver.bmc.com.sa>

Hi Experts

 

I tried configuring QoS on logical routers on M7i router (JUNOS 9.2R3.5)
but it's not applicable, the problem I have faced is that the CoS can be
configured only on the physical router, then when assigning the CoS
components to the interfaces, it's not applicable as the interfaces are
belonging to the logical routers, there is no way to assign the CoS
components to the logical routers interfaces. Any suggestions?

 

 BR,


From meryem_z at hotmail.com  Sat Mar 13 16:31:02 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Sat, 13 Mar 2010 21:31:02 +0000
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>
References: <20100309213227.GB75640@gerbil.cluepon.net>,
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>,
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>,
	<14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>,
	<BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>,
	<df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>
Message-ID: <BLU113-W104EFA520C593ADA43D185E1300@phx.gbl>


Hello ,

There is no "loss-priority" criteria to match on it.
Possible completions are below: 

Thanks.



# set firewall filter test_plp term 1 from ?
Possible completions:
> address              Match IP source or destination address
+ ah-spi               Match IPSec AH SPI value
+ ah-spi-except        Do not match IPSec AH SPI value
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> destination-address  Match IP destination address
+ destination-class    Match destination class
+ destination-class-except  Do not match destination class
+ destination-port     Match TCP/UDP destination port
+ destination-port-except  Do not match TCP/UDP destination port
> destination-prefix-list  Match IP destination prefixes in named list
+ dscp                 Match Differentiated Services (DiffServ) code point
+ dscp-except          Do not match Differentiated Services (DiffServ) code point
+ esp-spi              Match IPSec ESP SPI value
+ esp-spi-except       Do not match IPSec ESP SPI value
  first-fragment       Match if packet is the first fragment
+ forwarding-class     Match forwarding class
+ forwarding-class-except  Do not match forwarding class
  fragment-flags       Match fragment flags (in symbolic or hex formats)
+ fragment-offset      Match fragment offset
+ fragment-offset-except  Do not match fragment offset
+ icmp-code            Match ICMP message code
+ icmp-code-except     Do not match ICMP message code
+ icmp-type            Match ICMP message type
+ icmp-type-except     Do not match ICMP message type
> interface            Match interface name
+ interface-group      Match interface group
+ interface-group-except  Do not match interface group
> interface-set        Match interface in set
+ ip-options           Match IP options
+ ip-options-except    Do not match IP options
  is-fragment          Match if packet is a fragment
+ packet-length        Match packet length
+ packet-length-except  Do not match packet length
+ port                 Match TCP/UDP source or destination port
+ port-except          Do not match TCP/UDP source or destination port
+ precedence           Match IP precedence value
+ precedence-except    Do not match IP precedence value
> prefix-list          Match IP source or destination prefixes in named list
+ protocol             Match IP protocol type
+ protocol-except      Do not match IP protocol type
  service-filter-hit   Match if service-filter-hit is set
> source-address       Match IP source address
+ source-class         Match source class
+ source-class-except  Do not match source class
+ source-port          Match TCP/UDP source port
+ source-port-except   Do not match TCP/UDP source port
> source-prefix-list   Match IP source prefixes in named list
  tcp-established      Match packet of an established TCP connection
  tcp-flags            Match TCP flags (in symbolic or hex formats)
  tcp-initial          Match initial packet of a TCP connection
[edit]
Meriem at liscr2# set firewall filter test_plp term 1 from  

> Date: Thu, 11 Mar 2010 07:14:31 -0500
> Subject: Re: [j-nsp] Verify loss priority for a forwarding class
> From: addy.mathur at gmail.com
> To: meryem_z at hotmail.com; david.roy at orange-ftgroup.com; juniper-nsp at puck.nether.net
> 
> Meryem:
> 
> Maybe try a firewall filter with a counter on the egress interface?
> Something like:
> 
> from forwarding-class <forwarding-class_name>
> from loss-priority high
> then count fc-blah_lp-high
> then accept
> 
> --Addy.
> 
> 
> On 3/11/10, meryem Z <meryem_z at hotmail.com> wrote:
> >
> > Hello David ,
> >
> > Thanks for your response, but this command is supported M320 routers and
> > T-series routing platforms only..
> > Is there any equivalent for M7i routers ?
> >
> >
> > Thank you.
> >
> >
> >> From: david.roy at orange-ftgroup.com
> >> To: meryem_z at hotmail.com
> >> CC: juniper-nsp at puck.nether.net
> >> Date: Wed, 10 Mar 2010 14:12:10 +0100
> >> Subject: RE: [j-nsp] Verify loss priority for a forwarding class
> >>
> >> Hi,
> >>
> >> You can view drops at the fabric level via the command :
> >>
> >>  show class-of-service fabric statistics
> >>
> >> David
> >>
> >>
> >>
> >>
> >> David Roy
> >> Orange France - RBCI IP Technical Assistance Center
> >> Tel.   +33(0)299876472
> >> Mob. +33(0)685522213
> >> Email. david.roy at orange-ftgroup.com
> >>
> >>
> >> -----Message d'origine-----
> >> De : juniper-nsp-bounces at puck.nether.net
> >> [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
> >> Envoy? : mercredi 10 mars 2010 13:17
> >> Cc : juniper-nsp at puck.nether.net
> >> Objet : [j-nsp] Verify loss priority for a forwarding class
> >>
> >>
> >> hello Community,
> >>
> >> I configured a forwarding class with high priority loss. Now I need to
> >> verify that the traffic sent under this forwarding class ( using a traffic
> >> generator) has a high priority loss. The "show interface queue " doesn't
> >> show this information. is there any other way to do it ?
> >>
> >> Thank you.
> >>
> >>
> >>  		 	   		
> >> _________________________________________________________________
> >> Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live
> >> Hotmail, c'est gratuit !
> >> https://signup.live.com/signup.aspx?id=60969
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >> *********************************
> >> This message and any attachments (the "message") are confidential and
> >> intended solely for the addressees.
> >> Any unauthorised use or dissemination is prohibited.
> >> Messages are susceptible to alteration.
> >> France Telecom Group shall not be liable for the message if altered,
> >> changed or falsified.
> >> If you are not the intended addressee of this message, please cancel it
> >> immediately and inform the sender.
> >> ********************************
> >>
> >  		 	   		
> > _________________________________________________________________
> > Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e
> > Microsoft
> > https://signup.live.com/signup.aspx?id=60969
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> 
> -- 
> Sent from my mobile device
 		 	   		  
_________________________________________________________________
Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e Microsoft
https://signup.live.com/signup.aspx?id=60969

From addy.mathur at gmail.com  Sat Mar 13 18:18:31 2010
From: addy.mathur at gmail.com (Addy Mathur)
Date: Sat, 13 Mar 2010 18:18:31 -0500
Subject: [j-nsp] Verify loss priority for a forwarding class
In-Reply-To: <BLU113-W104EFA520C593ADA43D185E1300@phx.gbl>
References: <20100309213227.GB75640@gerbil.cluepon.net>
	<F5D543A6-B5C2-406A-BDC0-B0D6AB7CDF44@suspicious.org>
	<BLU113-W68D30979FF07726567EEFE1330@phx.gbl>
	<14439_1268226731_4B979AAB_14439_705_1_153490EA03CE634EBD317768617B6310471E9C1FC6@PMEXCB1A.intranet-paris.francetelecom.fr>
	<BLU113-W217F20DAA82549C6D557F7E1320@phx.gbl>
	<df6c4e8c1003110414i712f2a26xc443f3196b22e43e@mail.gmail.com>
	<BLU113-W104EFA520C593ADA43D185E1300@phx.gbl>
Message-ID: <df6c4e8c1003131518l7f7e43bcv2fe87a24c70a6ccb@mail.gmail.com>

Just realized that you're using an M7i - this is not supported.  The
other thing I can think of would be to configure a tos/dscp rewrite
rule on egress for that specific forwarding-class and loss-priority
high, and confirm the tos/dscp values on the tester.

--Addy.


On 3/13/10, meryem Z <meryem_z at hotmail.com> wrote:
>
> Hello ,
>
> There is no "loss-priority" criteria to match on it.
> Possible completions are below:
>
> Thanks.
>
>
>
> # set firewall filter test_plp term 1 from ?
> Possible completions:
>> address              Match IP source or destination address
> + ah-spi               Match IPSec AH SPI value
> + ah-spi-except        Do not match IPSec AH SPI value
> + apply-groups         Groups from which to inherit configuration data
> + apply-groups-except  Don't inherit configuration data from these groups
>> destination-address  Match IP destination address
> + destination-class    Match destination class
> + destination-class-except  Do not match destination class
> + destination-port     Match TCP/UDP destination port
> + destination-port-except  Do not match TCP/UDP destination port
>> destination-prefix-list  Match IP destination prefixes in named list
> + dscp                 Match Differentiated Services (DiffServ) code point
> + dscp-except          Do not match Differentiated Services (DiffServ) code
> point
> + esp-spi              Match IPSec ESP SPI value
> + esp-spi-except       Do not match IPSec ESP SPI value
>   first-fragment       Match if packet is the first fragment
> + forwarding-class     Match forwarding class
> + forwarding-class-except  Do not match forwarding class
>   fragment-flags       Match fragment flags (in symbolic or hex formats)
> + fragment-offset      Match fragment offset
> + fragment-offset-except  Do not match fragment offset
> + icmp-code            Match ICMP message code
> + icmp-code-except     Do not match ICMP message code
> + icmp-type            Match ICMP message type
> + icmp-type-except     Do not match ICMP message type
>> interface            Match interface name
> + interface-group      Match interface group
> + interface-group-except  Do not match interface group
>> interface-set        Match interface in set
> + ip-options           Match IP options
> + ip-options-except    Do not match IP options
>   is-fragment          Match if packet is a fragment
> + packet-length        Match packet length
> + packet-length-except  Do not match packet length
> + port                 Match TCP/UDP source or destination port
> + port-except          Do not match TCP/UDP source or destination port
> + precedence           Match IP precedence value
> + precedence-except    Do not match IP precedence value
>> prefix-list          Match IP source or destination prefixes in named list
> + protocol             Match IP protocol type
> + protocol-except      Do not match IP protocol type
>   service-filter-hit   Match if service-filter-hit is set
>> source-address       Match IP source address
> + source-class         Match source class
> + source-class-except  Do not match source class
> + source-port          Match TCP/UDP source port
> + source-port-except   Do not match TCP/UDP source port
>> source-prefix-list   Match IP source prefixes in named list
>   tcp-established      Match packet of an established TCP connection
>   tcp-flags            Match TCP flags (in symbolic or hex formats)
>   tcp-initial          Match initial packet of a TCP connection
> [edit]
> Meriem at liscr2# set firewall filter test_plp term 1 from
>
>> Date: Thu, 11 Mar 2010 07:14:31 -0500
>> Subject: Re: [j-nsp] Verify loss priority for a forwarding class
>> From: addy.mathur at gmail.com
>> To: meryem_z at hotmail.com; david.roy at orange-ftgroup.com;
>> juniper-nsp at puck.nether.net
>>
>> Meryem:
>>
>> Maybe try a firewall filter with a counter on the egress interface?
>> Something like:
>>
>> from forwarding-class <forwarding-class_name>
>> from loss-priority high
>> then count fc-blah_lp-high
>> then accept
>>
>> --Addy.
>>
>>
>> On 3/11/10, meryem Z <meryem_z at hotmail.com> wrote:
>> >
>> > Hello David ,
>> >
>> > Thanks for your response, but this command is supported M320 routers and
>> > T-series routing platforms only..
>> > Is there any equivalent for M7i routers ?
>> >
>> >
>> > Thank you.
>> >
>> >
>> >> From: david.roy at orange-ftgroup.com
>> >> To: meryem_z at hotmail.com
>> >> CC: juniper-nsp at puck.nether.net
>> >> Date: Wed, 10 Mar 2010 14:12:10 +0100
>> >> Subject: RE: [j-nsp] Verify loss priority for a forwarding class
>> >>
>> >> Hi,
>> >>
>> >> You can view drops at the fabric level via the command :
>> >>
>> >>  show class-of-service fabric statistics
>> >>
>> >> David
>> >>
>> >>
>> >>
>> >>
>> >> David Roy
>> >> Orange France - RBCI IP Technical Assistance Center
>> >> Tel.   +33(0)299876472
>> >> Mob. +33(0)685522213
>> >> Email. david.roy at orange-ftgroup.com
>> >>
>> >>
>> >> -----Message d'origine-----
>> >> De : juniper-nsp-bounces at puck.nether.net
>> >> [mailto:juniper-nsp-bounces at puck.nether.net] De la part de meryem Z
>> >> Envoy? : mercredi 10 mars 2010 13:17
>> >> Cc : juniper-nsp at puck.nether.net
>> >> Objet : [j-nsp] Verify loss priority for a forwarding class
>> >>
>> >>
>> >> hello Community,
>> >>
>> >> I configured a forwarding class with high priority loss. Now I need to
>> >> verify that the traffic sent under this forwarding class ( using a
>> >> traffic
>> >> generator) has a high priority loss. The "show interface queue "
>> >> doesn't
>> >> show this information. is there any other way to do it ?
>> >>
>> >> Thank you.
>> >>
>> >>
>> >>  		 	   		
>> >> _________________________________________________________________
>> >> Votre messagerie et bien plus o? que vous soyez. Passez ? Windows Live
>> >> Hotmail, c'est gratuit !
>> >> https://signup.live.com/signup.aspx?id=60969
>> >> _______________________________________________
>> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>
>> >> *********************************
>> >> This message and any attachments (the "message") are confidential and
>> >> intended solely for the addressees.
>> >> Any unauthorised use or dissemination is prohibited.
>> >> Messages are susceptible to alteration.
>> >> France Telecom Group shall not be liable for the message if altered,
>> >> changed or falsified.
>> >> If you are not the intended addressee of this message, please cancel it
>> >> immediately and inform the sender.
>> >> ********************************
>> >>
>> >  		 	   		
>> > _________________________________________________________________
>> > Hotmail : une messagerie performante et gratuite avec une s?curit?
>> > sign?e
>> > Microsoft
>> > https://signup.live.com/signup.aspx?id=60969
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>>
>> --
>> Sent from my mobile device
>  		 	   		
> _________________________________________________________________
> Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e
> Microsoft
> https://signup.live.com/signup.aspx?id=60969

-- 
Sent from my mobile device


From singh.taqdir at gmail.com  Sat Mar 13 22:41:45 2010
From: singh.taqdir at gmail.com (Taqdir Singh)
Date: Sat, 13 Mar 2010 19:41:45 -0800 (PST)
Subject: [j-nsp] Invitation to connect on LinkedIn
Message-ID: <289179219.4635257.1268538105568.JavaMail.app@ech3-cdn12.prod>

LinkedIn
------------Taqdir Singh pidi? a?adirte como contacto en LinkedIn:
------------------------------------------

Juniper,

I'd like to add you to my professional network on LinkedIn.

- Taqdir

Aceptar invitaci?n de Taqdir Singh
http://www.linkedin.com/e/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I587813619_3/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cRYVcjoPcjwTe3l9bRZnpj1luClIbP4OcjoMcjkQcj4LrCBxbOYWrSlI/EML_comm_afe/

Ver invitaci?n de Taqdir Singh
http://www.linkedin.com/e/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I587813619_3/0PnPANdzcNe3sUdkALqnpPbOYWrSlI/svi/ 
------------------------------------------

?SAB?AS que LinkedIn te puede ayudar a encontrar a los proveedores de servicio adecuados utilizando recomendaciones de tu red? Por medio de los Servicios de LinkedIn, puedes eliminar las arriesgadas conjeturas al seleccionar proveedores de servicios leyendo las recomendaciones de socios cre?bles y confiables de tu red. 
http://www.linkedin.com/e/svp/inv-25/

 
------
(c) 2010, LinkedIn Corporation

From snar at snar.spb.ru  Sun Mar 14 07:25:49 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Sun, 14 Mar 2010 14:25:49 +0300
Subject: [j-nsp] mysterious microbursts ?
Message-ID: <20100314112549.GA76596@snar.spb.ru>


Hi!

During routine maintenance on my ex-3200 switches I found that 
some devices, connected with 100mbit/full-duplex observe minor
packet loss. Well, there is nothing too unexpected, you can 
see it mostly every time when traffic enters switch using 1ge (2x1ge
aggregate in my case) link and exits using 100mbit, switch ports
just do not have enough buffer space to handle bursts well, but... 
That's where the strangeness begins: 
a) these 100mbit ports used to connect VoIP devices handling RTP 
traffic, so there should be no bursts at all.
b) there are more than 30 such devices in my network, and I see 
that loss only on half of them - on that half that is connected 
to even-numbered switches, there are no packet loss on devices 
connected to odd-numbered ones.

Logical topology is just "a vlan connected to a router (two routers
in VRRP master/slave scenario)", physical is classic ring (some rings 
actually, each odd-numbered access switch connected to coresw1, 
even-numbered - to coresw2): 

  router1                  router2(backup, no traffic right now)
    |                        |
  coresw1 ================ coresw2
    |                        |
    |                        |
  accsw1 -------- x ------ accsw2

link between core switches is 10ge, links core-access and access-access
is 2x ge aggregated ethernet, access-access links are blocked by STP. 
Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4.

Well, these losses is about 0.1% and I can live with that, but
I'd like to have any idea on why it happens only on half of 
devices, and I don't have one :( 
Any clue ? 

Example interface with errors: 

Physical interface: ge-0/0/26, Enabled, Physical link is Up
  Interface index: 165, SNMP ifIndex: 174, Generation: 168
  Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, MAC-REWRITE Error: None,
  Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Disabled,
  Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Hold-times     : Up 0 ms, Down 0 ms
  Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a
  Last flapped   : 2010-03-05 04:36:34 PST (1w1d 22:21 ago)
  Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago)
  Traffic statistics:
   Input  bytes  :          88312256790                    0 bps
   Output bytes  :          88616684644                 5984 bps
   Input  packets:            443797702                    0 pps
   Output packets:            412072442                   10 pps
   IPv6 transit statistics:
    Input  bytes  :                   0 
    Output bytes  :                   0
    Input  packets:                   0
    Output packets:                   0
  Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0,
    L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
  Output errors:
    Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0,
    MTU errors: 0, Resource errors: 0
  Egress queues: 8 supported, 4 in use
  Queue counters:       Queued packets  Transmitted packets      Dropped packets
    0 best-effort                    0            411934501               454642
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    1 assured-forw                   0                    0                    0
    5 expedited-fo                   0                    0                    0
    7 network-cont                   0               137336                    0
  Active alarms  : None
  Active defects : None
  MAC statistics:                      Receive         Transmit
    Total octets                   88312256790      88616684644
    Total packets                    443797702        412072442
    Unicast packets                  443796941        410096125
    Broadcast packets                      761           447035
    Multicast packets                        0          1529282
    CRC/Align errors                         0                0
    FIFO errors                              0                0
    MAC control frames                       0                0
    MAC pause frames                         0                0
    Oversized frames                         0
    Jabber frames                            0
    Fragment frames                          0
    Code violations                          0
  Autonegotiation information:
    Negotiation status: Incomplete
  Packet Forwarding Engine configuration:
    Destination slot: 0
    Direction : Output 
    CoS transmit queue               Bandwidth               Buffer Priority   Limit
                              %            bps     %           usec
    0 best-effort            95       95000000    95             NA      low    none
    7 network-control         5        5000000     5             NA      low    none


From alexei at twine-networks.com  Sun Mar 14 08:10:52 2010
From: alexei at twine-networks.com (Alexey Kholmov)
Date: Sun, 14 Mar 2010 15:10:52 +0300
Subject: [j-nsp] Adding vsd-less cluster to NSM 20091.r1
Message-ID: <3FFDAE96-178E-4CA2-B9FF-A0E57B35FB54@twine-networks.com>

Hi,

we have 2 NSMXpress devices running in HA mode. The NSM version is  
2009.1r1.
We are trying to add a cluster of two isg2000 in VSD-less mode.

Using the NSM GUI we add the cluster and then the 1st member. The  
connection from NSM to the member isg2000 device works fine, the nsm  
related config is sent to the firewall. But when the firewall tries to  
connect to the NSM device server we see following entries in the /var/ 
netscreen/DevSvr/errorLog/deviceDaemon.0

[03/14/2010 12:22:55.970] [Error] [3086997184-nsRSA.c:189] RSA invalid  
header
[03/14/2010 12:22:55.970] [Error] [3086997184-nsCryptoMTMPlug.c:1403]  
Could not verify connect message!
[03/14/2010 12:22:55.970] [Error] [3086997184-nsCryptoMTMPlug.c:2203]  
nsCryptoMTMPlugServerRecv_S1() failed
[03/14/2010 12:22:55.970] [Warning] [3086997184-nthConnPlug.c:374]  
NTHCONN: SSP device 10.247.1.52 (domainId 1, deviceId 30): denied  
connection due to key exchange failure
[03/14/2010 12:22:55.971] [Notice] [3086997184-sessionPlug.c:3581]  
session returns NETPLUG_SEND_DISCONNECTED

We searched the net for solution and found following solution, the  
devices are still able to establish the SSP connection to NSM. The / 
var/netscreen/DevSvr/errorLog/deviceDaemon.0  file has following  
entries:

[03/14/2010 12:23:48.015] [Warning] [3086997184-nsCryptoMTMPlug.c: 
2184] Device is attempting a first connection but DB thinks reconnect,  
repairing
[03/14/2010 12:23:48.015] [Error] [3086997184-nsCryptoMTMPlug.c:897]  
Validation of key exchange request failed!
[03/14/2010 12:23:48.015] [Warning] [3086997184-nthConnPlug.c:374]  
NTHCONN: SSP device 10.247.1.52 (domainId 1, deviceId 30): denied  
connection due to OTP mismatch
[03/14/2010 12:23:48.015] [Notice] [3086997184-sessionPlug.c:3581]  
session returns NETPLUG_SEND_DISCONNECTED

We tried also to import the device as not reachable - but the result  
was the same.

Could you please advise us how to proceed?

Thanks
Alex

From chrisccnpspam2 at gmail.com  Sun Mar 14 09:18:39 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Sun, 14 Mar 2010 13:18:39 +0000
Subject: [j-nsp] mysterious microbursts ?
In-Reply-To: <20100314112549.GA76596@snar.spb.ru>
References: <20100314112549.GA76596@snar.spb.ru>
Message-ID: <1920897981-1268572714-cardhu_decombobulator_blackberry.rim.net-746799913-@bda069.bisx.prod.on.blackberry>

One thing I would check for first is unicast flooding.  It sounds like the backup router is flooding all traffic as it doesn't have any arp/mac tables created for traffic that comes ingress to it. Would be hard to pinpoint the issue unless you can provide some traffic flow stats. 


Unicast flooding is a common problem with active/backup switching environments. If this is the case we can work on modifying the mac and arp timers to resolve it. 

Hope this helps


Sent via BlackBerry by AT&T

-----Original Message-----
From: Alexandre Snarskii <snar at snar.spb.ru>
Date: Sun, 14 Mar 2010 14:25:49 
To: Juniper-NSP Mailing list<juniper-nsp at puck.nether.net>
Subject: [j-nsp] mysterious microbursts ?


Hi!

During routine maintenance on my ex-3200 switches I found that 
some devices, connected with 100mbit/full-duplex observe minor
packet loss. Well, there is nothing too unexpected, you can 
see it mostly every time when traffic enters switch using 1ge (2x1ge
aggregate in my case) link and exits using 100mbit, switch ports
just do not have enough buffer space to handle bursts well, but... 
That's where the strangeness begins: 
a) these 100mbit ports used to connect VoIP devices handling RTP 
traffic, so there should be no bursts at all.
b) there are more than 30 such devices in my network, and I see 
that loss only on half of them - on that half that is connected 
to even-numbered switches, there are no packet loss on devices 
connected to odd-numbered ones.

Logical topology is just "a vlan connected to a router (two routers
in VRRP master/slave scenario)", physical is classic ring (some rings 
actually, each odd-numbered access switch connected to coresw1, 
even-numbered - to coresw2): 

  router1                  router2(backup, no traffic right now)
    |                        |
  coresw1 ================ coresw2
    |                        |
    |                        |
  accsw1 -------- x ------ accsw2

link between core switches is 10ge, links core-access and access-access
is 2x ge aggregated ethernet, access-access links are blocked by STP. 
Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4.

Well, these losses is about 0.1% and I can live with that, but
I'd like to have any idea on why it happens only on half of 
devices, and I don't have one :( 
Any clue ? 

Example interface with errors: 

Physical interface: ge-0/0/26, Enabled, Physical link is Up
  Interface index: 165, SNMP ifIndex: 174, Generation: 168
  Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, MAC-REWRITE Error: None,
  Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Disabled,
  Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Hold-times     : Up 0 ms, Down 0 ms
  Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a
  Last flapped   : 2010-03-05 04:36:34 PST (1w1d 22:21 ago)
  Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago)
  Traffic statistics:
   Input  bytes  :          88312256790                    0 bps
   Output bytes  :          88616684644                 5984 bps
   Input  packets:            443797702                    0 pps
   Output packets:            412072442                   10 pps
   IPv6 transit statistics:
    Input  bytes  :                   0 
    Output bytes  :                   0
    Input  packets:                   0
    Output packets:                   0
  Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0,
    L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
  Output errors:
    Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0,
    MTU errors: 0, Resource errors: 0
  Egress queues: 8 supported, 4 in use
  Queue counters:       Queued packets  Transmitted packets      Dropped packets
    0 best-effort                    0            411934501               454642
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    1 assured-forw                   0                    0                    0
    5 expedited-fo                   0                    0                    0
    7 network-cont                   0               137336                    0
  Active alarms  : None
  Active defects : None
  MAC statistics:                      Receive         Transmit
    Total octets                   88312256790      88616684644
    Total packets                    443797702        412072442
    Unicast packets                  443796941        410096125
    Broadcast packets                      761           447035
    Multicast packets                        0          1529282
    CRC/Align errors                         0                0
    FIFO errors                              0                0
    MAC control frames                       0                0
    MAC pause frames                         0                0
    Oversized frames                         0
    Jabber frames                            0
    Fragment frames                          0
    Code violations                          0
  Autonegotiation information:
    Negotiation status: Incomplete
  Packet Forwarding Engine configuration:
    Destination slot: 0
    Direction : Output 
    CoS transmit queue               Bandwidth               Buffer Priority   Limit
                              %            bps     %           usec
    0 best-effort            95       95000000    95             NA      low    none
    7 network-control         5        5000000     5             NA      low    none

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From chrisccnpspam2 at gmail.com  Sun Mar 14 09:48:58 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sun, 14 Mar 2010 09:48:58 -0400
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <3172b9cb1002181755r42c3cf7fh40e7953f19b64534@mail.gmail.com>
References: <28527.97594.qm@web53607.mail.re2.yahoo.com>
	<6C2151DD-7889-4248-B310-ED808E43C280@missouri.edu>
	<3172b9cb1002181755r42c3cf7fh40e7953f19b64534@mail.gmail.com>
Message-ID: <419dba611003140648m2ff12cb2xf068bbb057fa2f11@mail.gmail.com>

So we obtained a MX480 to eval in our lab with the 2 x 10GigE and 20x GigE
DPC-R card.. I did a simple 64byte line rate test and got somewhat similar
results.. I could only run about 94.75% line rate (using an IXIA appliance)
with full-duplex flows @ 64byte frame size. In a L2 config it was even
worse, I could only get about 53% line rate before drops started..

I have a JTAC case open on it and thye state that this is a known PR and
should have been fixed in 9.6R3 which I am testing. The PR# is 469135. I
tested the same test on an EX4200 and had no packet loss. Now it's just
getting JTAC to believe the issue is there..

On Thu, Feb 18, 2010 at 9:55 PM, Judah Scott <judah.scott.iam at gmail.com>wrote:

> Yes what you see is correct behavior (for those MX DPCs).  I doubt it's a
> cell size issue or you would see a saw-tooth.  Instead what you can infer
> is
> that each of the 4 PFE's are limited to the packets-per-second they can
> process depending on the transport type involved.  I.E. VPLS is really bad
> at low packet sizes but pure L3 is good.
>
> -J Scott
>
>
> On Thu, Feb 18, 2010 at 5:08 PM, OBrien, Will <ObrienH at missouri.edu>
> wrote:
>
> > We have been running 10G R cards exclusively in our pair of MX960s - so
> far
> > we have had no issues with vpn tunnels coming in/out and we have many of
> > them. We don't run voip over that particular connection either. In fact,
> > we've really seen no problems with traffic going through them at all. We
> do
> > run them exclusively at the edge of our network as border routers for I1
> and
> > I2 traffic.
> >
> > Typical I1 load is near a Gb and I2 usually has a few.
> >
> > Will
> >
> > On Feb 18, 2010, at 6:28 PM, Serge Vautour wrote:
> >
> > > Hello,
> > >
> > > We recently used a traffic generator to run RFC2544 tests against a
> > Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame
> > sizes.
> > >
> > > The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to
> 25%
> > packets with certain small frames (ex: 70 byte frames). The packet loss
> goes
> > away almost completely for frames larger than 100 bytes. Our SE tells us
> > this is normal and is due to how the MX chops the frames up into 64 byte
> > cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G
> port)
> > and each of them has 10G of bandwidth. 10G of small frames essentially
> > creates more than 10G of traffic inside the PFE. That explanation may not
> be
> > 100% correct but I think it paints the right picture.
> > >
> > > Now the questions. Is this a problem on production networks with real
> > world traffic? What about on VPN networks with alot of small frames like
> > VoIP? Has anyone seen this problem creep it's head in production?
> > >
> > > It seems very unlikely to me that a maxed 10Gbps link would carry
> 7.5Gbps
> > of frame sizes less than 100 byte. I would expect larger frames to use up
> > the majority of the bandwidth. Can anyone correlate this with real world
> > traffic?
> > >
> > > As usual, the help received on this distribution list is invaluable.
> > Thanks in advance to anyone who replies.
> > >
> > > Serge
> > >
> > >
> > >      __________________________________________________________________
> > > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
> your
> > favourite sites. Download it now
> > > http://ca.toolbar.yahoo.com.
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From jof at thejof.com  Sun Mar 14 13:55:01 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Sun, 14 Mar 2010 10:55:01 -0700
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <28527.97594.qm@web53607.mail.re2.yahoo.com>
References: <28527.97594.qm@web53607.mail.re2.yahoo.com>
Message-ID: <1268588715-sup-8727@sfo.thejof.com>

Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
> Hello,
> 
> We recently used a traffic generator to run RFC2544 tests against a Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame sizes. 
> 
> The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to 25% packets with certain small frames (ex: 70 byte frames). The packet loss goes away almost completely for frames larger than 100 bytes. Our SE tells us this is normal and is due to how the MX chops the frames up into 64 byte cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port) and each of them has 10G of bandwidth. 10G of small frames essentially creates more than 10G of traffic inside the PFE. That explanation may not be 100% correct but I think it paints the right picture.
> 
> Now the questions. Is this a problem on production networks with real world traffic? What about on VPN networks with alot of small frames like VoIP? Has anyone seen this problem creep it's head in production?

Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
Ethernet 802.3 requires this.

Wouldn't this make the problem moot if you're just running Ethernet?

Might be a problem with small ATM cells?

Cheers,
jof

From js at tnib.de  Sun Mar 14 15:14:36 2010
From: js at tnib.de (Joerg Staedele)
Date: Sun, 14 Mar 2010 20:14:36 +0100
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
Message-ID: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>

Hi,

so this means that this Linecard is not able to do line-rate forwarding with small frame sizes? What about other cards (20xSFP+2x10G) .. I guess they use exactly the same PFE hardware? So they have this limitation aswell?

I am really confused now because in every document you read that the DPCE's are able to do line-rate at any frame-size?

Regards,
 Joerg

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Lassoff
Sent: Sunday, March 14, 2010 6:55 PM
To: Serge Vautour
Cc: juniper-nsp
Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports

Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
> Hello,
> 
> We recently used a traffic generator to run RFC2544 tests against a Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame sizes. 
> 
> The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to 25% packets with certain small frames (ex: 70 byte frames). The packet loss goes away almost completely for frames larger than 100 bytes. Our SE tells us this is normal and is due to how the MX chops the frames up into 64 byte cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port) and each of them has 10G of bandwidth. 10G of small frames essentially creates more than 10G of traffic inside the PFE. That explanation may not be 100% correct but I think it paints the right picture.
> 
> Now the questions. Is this a problem on production networks with real world traffic? What about on VPN networks with alot of small frames like VoIP? Has anyone seen this problem creep it's head in production?

Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
Ethernet 802.3 requires this.

Wouldn't this make the problem moot if you're just running Ethernet?

Might be a problem with small ATM cells?

Cheers,
jof
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



From chrisccnpspam2 at gmail.com  Sun Mar 14 15:28:26 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sun, 14 Mar 2010 15:28:26 -0400
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>
References: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>
Message-ID: <419dba611003141228w1901b75au5a9dab1eeb47c5c2@mail.gmail.com>

Joerg,

The hardware we have in our lab is the 20xSFP + 2x10Gig.. JTAC says this
'should' work but obviously it doesn't.. I tested it on an EX switch and it
had no issues.. In a simple L2 mode the MX lost about 47% packets at 64byte
10Gig line rates. In L3 mode is lost about 5.2%.. This is when testing full
duplex flows. This was with 9.6R3.8.. There is a known PR related to this
issue.

Hope to have some resolution sometime this week..

On Sun, Mar 14, 2010 at 3:14 PM, Joerg Staedele <js at tnib.de> wrote:

> Hi,
>
> so this means that this Linecard is not able to do line-rate forwarding
> with small frame sizes? What about other cards (20xSFP+2x10G) .. I guess
> they use exactly the same PFE hardware? So they have this limitation aswell?
>
> I am really confused now because in every document you read that the DPCE's
> are able to do line-rate at any frame-size?
>
> Regards,
>  Joerg
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:
> juniper-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Lassoff
> Sent: Sunday, March 14, 2010 6:55 PM
> To: Serge Vautour
> Cc: juniper-nsp
> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>
> Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
> > Hello,
> >
> > We recently used a traffic generator to run RFC2544 tests against a
> Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame
> sizes.
> >
> > The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to 25%
> packets with certain small frames (ex: 70 byte frames). The packet loss goes
> away almost completely for frames larger than 100 bytes. Our SE tells us
> this is normal and is due to how the MX chops the frames up into 64 byte
> cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port)
> and each of them has 10G of bandwidth. 10G of small frames essentially
> creates more than 10G of traffic inside the PFE. That explanation may not be
> 100% correct but I think it paints the right picture.
> >
> > Now the questions. Is this a problem on production networks with real
> world traffic? What about on VPN networks with alot of small frames like
> VoIP? Has anyone seen this problem creep it's head in production?
>
> Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
> Ethernet 802.3 requires this.
>
> Wouldn't this make the problem moot if you're just running Ethernet?
>
> Might be a problem with small ATM cells?
>
> Cheers,
> jof
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From saku at ytti.fi  Sun Mar 14 16:26:53 2010
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 14 Mar 2010 22:26:53 +0200
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <1268588715-sup-8727@sfo.thejof.com>
References: <28527.97594.qm@web53607.mail.re2.yahoo.com>
	<1268588715-sup-8727@sfo.thejof.com>
Message-ID: <20100314202653.GA14565@mx.ytti.net>

On (2010-03-14 10:55 -0700), Jonathan Lassoff wrote:
 
> Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
> Ethernet 802.3 requires this.

Correct. 

L1 = 84bytes (preamble, SFD, MAC, type/len, payload, crc, IFG)
L2 = 64bytes (MAC, type/len, payload, crc)

Payload minimum is 46B, IP packet can be smaller, if so, ethernet will pad
the frame to 46B. Interestingly enough in ethernetII this means ethernet
does not guarantee data integrity for small packets, but obviously IP at L3
will know the packet length and can discard L2 padding.

But IIRC L2 is not included in jcells at all. So you'd get most impact with
least work by sending 65bytes IP packet.

-- 
  ++ytti

From alex.arseniev at gmail.com  Sun Mar 14 17:04:56 2010
From: alex.arseniev at gmail.com (Alex)
Date: Sun, 14 Mar 2010 21:04:56 -0000
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
References: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>
	<419dba611003141228w1901b75au5a9dab1eeb47c5c2@mail.gmail.com>
Message-ID: <A0CB4A8E43FA4EADB20347B5D3DDBF84@jnpr.net>

Chris,
Line rate on one 10G port could be different from line-rate on another 10G 
port because Ethernet is not bit-synchronous.
LAN-PHY 10GBASE-S allowed transmitter clock tolerance is 10.3125Gbd +/1 
100ppm (parts per million) and LAN-PHY 10GBASE-S allowed receiver clock 
tolerance is also 10.3125Gbd +/- 100ppm. See IEEE 802.3-2008 spec sections 
52.5.1 and 52.5.2.
So in reality the Rx on ingress port could run at 10.31353125Gbd and Tx on 
egress port could run at 10.31146875Gbd. This 0.0020625Gbd=2.0625Mbd 
difference causes ingress buffer to grow until there is no more room and 
eventually an "overspill" and packet drop. Please run Your tests at 99% line 
rate, I am sure there will be no packet loss at all.
Rgds
Alex


----- Original Message ----- 
From: "Chris Evans" <chrisccnpspam2 at gmail.com>
To: "Joerg Staedele" <js at tnib.de>
Cc: "juniper-nsp" <juniper-nsp at puck.nether.net>
Sent: Sunday, March 14, 2010 7:28 PM
Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports


> Joerg,
>
> The hardware we have in our lab is the 20xSFP + 2x10Gig.. JTAC says this
> 'should' work but obviously it doesn't.. I tested it on an EX switch and 
> it
> had no issues.. In a simple L2 mode the MX lost about 47% packets at 
> 64byte
> 10Gig line rates. In L3 mode is lost about 5.2%.. This is when testing 
> full
> duplex flows. This was with 9.6R3.8.. There is a known PR related to this
> issue.
>
> Hope to have some resolution sometime this week..
>
> On Sun, Mar 14, 2010 at 3:14 PM, Joerg Staedele <js at tnib.de> wrote:
>
>> Hi,
>>
>> so this means that this Linecard is not able to do line-rate forwarding
>> with small frame sizes? What about other cards (20xSFP+2x10G) .. I guess
>> they use exactly the same PFE hardware? So they have this limitation 
>> aswell?
>>
>> I am really confused now because in every document you read that the 
>> DPCE's
>> are able to do line-rate at any frame-size?
>>
>> Regards,
>>  Joerg
>>
>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:
>> juniper-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Lassoff
>> Sent: Sunday, March 14, 2010 6:55 PM
>> To: Serge Vautour
>> Cc: juniper-nsp
>> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>>
>> Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
>> > Hello,
>> >
>> > We recently used a traffic generator to run RFC2544 tests against a
>> Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame
>> sizes.
>> >
>> > The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to 
>> > 25%
>> packets with certain small frames (ex: 70 byte frames). The packet loss 
>> goes
>> away almost completely for frames larger than 100 bytes. Our SE tells us
>> this is normal and is due to how the MX chops the frames up into 64 byte
>> cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G 
>> port)
>> and each of them has 10G of bandwidth. 10G of small frames essentially
>> creates more than 10G of traffic inside the PFE. That explanation may not 
>> be
>> 100% correct but I think it paints the right picture.
>> >
>> > Now the questions. Is this a problem on production networks with real
>> world traffic? What about on VPN networks with alot of small frames like
>> VoIP? Has anyone seen this problem creep it's head in production?
>>
>> Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
>> Ethernet 802.3 requires this.
>>
>> Wouldn't this make the problem moot if you're just running Ethernet?
>>
>> Might be a problem with small ATM cells?
>>
>> Cheers,
>> jof
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From chrisccnpspam2 at gmail.com  Sun Mar 14 17:13:53 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sun, 14 Mar 2010 17:13:53 -0400
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <A0CB4A8E43FA4EADB20347B5D3DDBF84@jnpr.net>
References: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>
	<419dba611003141228w1901b75au5a9dab1eeb47c5c2@mail.gmail.com>
	<A0CB4A8E43FA4EADB20347B5D3DDBF84@jnpr.net>
Message-ID: <419dba611003141413k32d9f577sa531adac88cf2a65@mail.gmail.com>

Alex,

Thanks for you input. While what you stay is true, there are still issues
with the MX platform. As stated in my previous postings, I can only push
line rate or 94.78% max before drops start.. This is that % on a full duplex
stream.. If I shutdown one of the streams I can then push 100% line rate,
packet loss is only there when there are full duplex flows.. It's really
either down to a bug or just the PFE cannot forward the PPS. If you take the
frame size up to 69 bytes, you can do 100% line rate full duplex.

Putting the MX into a layer2 mode (meaning setting it up as a typical
ethernet switch) brings another issue with even much larger % of packet loss
unfortunately.

I am using an IXIA XM12 appliance and IXNetwork.

On Sun, Mar 14, 2010 at 5:04 PM, Alex <alex.arseniev at gmail.com> wrote:

> Chris,
> Line rate on one 10G port could be different from line-rate on another 10G
> port because Ethernet is not bit-synchronous.
> LAN-PHY 10GBASE-S allowed transmitter clock tolerance is 10.3125Gbd +/1
> 100ppm (parts per million) and LAN-PHY 10GBASE-S allowed receiver clock
> tolerance is also 10.3125Gbd +/- 100ppm. See IEEE 802.3-2008 spec sections
> 52.5.1 and 52.5.2.
> So in reality the Rx on ingress port could run at 10.31353125Gbd and Tx on
> egress port could run at 10.31146875Gbd. This 0.0020625Gbd=2.0625Mbd
> difference causes ingress buffer to grow until there is no more room and
> eventually an "overspill" and packet drop. Please run Your tests at 99% line
> rate, I am sure there will be no packet loss at all.
> Rgds
> Alex
>
>
> ----- Original Message ----- From: "Chris Evans" <chrisccnpspam2 at gmail.com
> >
> To: "Joerg Staedele" <js at tnib.de>
> Cc: "juniper-nsp" <juniper-nsp at puck.nether.net>
> Sent: Sunday, March 14, 2010 7:28 PM
>
> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>
>
>  Joerg,
>>
>> The hardware we have in our lab is the 20xSFP + 2x10Gig.. JTAC says this
>> 'should' work but obviously it doesn't.. I tested it on an EX switch and
>> it
>> had no issues.. In a simple L2 mode the MX lost about 47% packets at
>> 64byte
>> 10Gig line rates. In L3 mode is lost about 5.2%.. This is when testing
>> full
>> duplex flows. This was with 9.6R3.8.. There is a known PR related to this
>> issue.
>>
>> Hope to have some resolution sometime this week..
>>
>> On Sun, Mar 14, 2010 at 3:14 PM, Joerg Staedele <js at tnib.de> wrote:
>>
>>  Hi,
>>>
>>> so this means that this Linecard is not able to do line-rate forwarding
>>> with small frame sizes? What about other cards (20xSFP+2x10G) .. I guess
>>> they use exactly the same PFE hardware? So they have this limitation
>>> aswell?
>>>
>>> I am really confused now because in every document you read that the
>>> DPCE's
>>> are able to do line-rate at any frame-size?
>>>
>>> Regards,
>>>  Joerg
>>>
>>> -----Original Message-----
>>> From: juniper-nsp-bounces at puck.nether.net [mailto:
>>> juniper-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Lassoff
>>> Sent: Sunday, March 14, 2010 6:55 PM
>>> To: Serge Vautour
>>> Cc: juniper-nsp
>>> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>>>
>>> Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
>>> > Hello,
>>> >
>>> > We recently used a traffic generator to run RFC2544 tests against a
>>> Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame
>>> sizes.
>>> >
>>> > The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to >
>>> 25%
>>> packets with certain small frames (ex: 70 byte frames). The packet loss
>>> goes
>>> away almost completely for frames larger than 100 bytes. Our SE tells us
>>> this is normal and is due to how the MX chops the frames up into 64 byte
>>> cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G
>>> port)
>>> and each of them has 10G of bandwidth. 10G of small frames essentially
>>> creates more than 10G of traffic inside the PFE. That explanation may not
>>> be
>>> 100% correct but I think it paints the right picture.
>>> >
>>> > Now the questions. Is this a problem on production networks with real
>>> world traffic? What about on VPN networks with alot of small frames like
>>> VoIP? Has anyone seen this problem creep it's head in production?
>>>
>>> Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
>>> Ethernet 802.3 requires this.
>>>
>>> Wouldn't this make the problem moot if you're just running Ethernet?
>>>
>>> Might be a problem with small ATM cells?
>>>
>>> Cheers,
>>> jof
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>  _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>

From andhy.indarto at indosat.com  Sun Mar 14 22:55:14 2010
From: andhy.indarto at indosat.com (Andhy Indarto)
Date: Mon, 15 Mar 2010 09:55:14 +0700
Subject: [j-nsp] VOOT : Data Center in Rome
Message-ID: <2233A6BE8D55AE4C9119D7870748FC311019C40F@isatjkt-msg01.office.corp.indosat.com>

Dear all,

Do you have any suggestion for Data Center service provider in Rome ?

Thank you in advanced.

Regards,

andhi indarto

 




*****
"This message is intended only for recipients who are authorized to receive it. 
It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall  protect this confidential information disclosed pursuant to provisions of Indosat's policy.
If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. 
Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful".
*****

From vyaaghrah-eng at yahoo.com  Mon Mar 15 06:36:23 2010
From: vyaaghrah-eng at yahoo.com (Abhi)
Date: Mon, 15 Mar 2010 03:36:23 -0700 (PDT)
Subject: [j-nsp] BackUp Link also L3 VPN
Message-ID: <830264.56728.qm@web113914.mail.gq1.yahoo.com>

Hi Everybody

wanna discuss a scenario of  using  L3 VPN as Back Up  with 2 different Service Providers.

The question which i see as of now are 

1) weather such a scenario would work ?  ( my first thought suggest this should work)
2) the challenge on customer site is both SP are providing the same AS Number for the configuration on the last CE router, weather this would work, if not what would be reason.

Suggestion on what would work are welcome.


 
Regards
Abhijeet.C


From wjackson at sapphire.gi  Mon Mar 15 06:46:42 2010
From: wjackson at sapphire.gi (William Jackson)
Date: Mon, 15 Mar 2010 11:46:42 +0100
Subject: [j-nsp] Automating Deployment
Message-ID: <9D30659ABCA7FB428CF91E386C3A574401CF87B6@hermes.sapphire-int.gi>

Hi all

 

We are wondering how people automate the deployment of juniper customer
edge Routers.

 

We were considering using unnumbered Ethernet interfaces on the edge
router and on the next upstream nodes so that we do not need to have
pre-knowledge of IP addressing. 

The idea was then to run ISIS over the unnumbered interfaces.  So that
all we would have to know pre-deployment is the loopback of the new
router

 

This new box would then talk back to an NSM server and pull its complete
config.

 

We have tested with 10.1 and ISIS doesn't seem to work on the unnumbered
Ethernet interfaces.

 

What do other people do?

 

Ideas?

 

thanks


From quochoang at yahoo.com  Mon Mar 15 11:41:46 2010
From: quochoang at yahoo.com (Quoc Hoang)
Date: Mon, 15 Mar 2010 08:41:46 -0700 (PDT)
Subject: [j-nsp] Trunking on SRX
Message-ID: <247154.45009.qm@web30507.mail.mud.yahoo.com>

Hi,
   Looking to trunk (vlan tagging) on the SRX 3600 to reduce the number of physical interfaces required. Anyone currently using it that can provide feedback or issues? Good or bad idea? 

Doesn't appear to be any details of vlan tagging in the srx docs so not sure if it's officially supported.

TIA,
quoc


From mhernand1 at comcast.net  Mon Mar 15 12:02:38 2010
From: mhernand1 at comcast.net (manolo hernandez)
Date: Mon, 15 Mar 2010 12:02:38 -0400
Subject: [j-nsp] Trunking on SRX
In-Reply-To: <247154.45009.qm@web30507.mail.mud.yahoo.com>
References: <247154.45009.qm@web30507.mail.mud.yahoo.com>
Message-ID: <4B9E5A1E.7050600@comcast.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/15/10 11:41 AM, Quoc Hoang wrote:
> Hi,
>    Looking to trunk (vlan tagging) on the SRX 3600 to reduce the number of physical interfaces required. Anyone currently using it that can provide feedback or issues? Good or bad idea? 
> 
> Doesn't appear to be any details of vlan tagging in the srx docs so not sure if it's officially supported.
> 
> TIA,
> quoc
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
Quoc,

   This is a Junos feature and is supported in SRX. We have seen no
issues with dot1q and the SRX-650 we have.



Manolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLnloeAAoJEOcnyWxdB1Ir2jAIAMQoiBWKjL722A9od6YWmbPV
xAH4QpmbexX3uzqtGiJyxXd+tZxKF1DxLv3S1PAnfJQdQAzs/bQ7mh9NwZWmZcce
sBlX1DxJRIonnDMVD426cNxakKrlh8ieVT0NL/C92HR5GtkDKSW2k/skoiEqJxOw
QVYNSvu6+L03/xtWKXZ/YlmW3Hi4kcctfVkJ1kzWQsadM6HfEpAZwzx8d/0ySQlf
bEHGPTe7v47mgz7l039Xt6zV3wxfgTAYW8phm026za5hNy7UMtYfbEFVFITej5Rv
C96q/gdY7Obgck0Ktn8rlFSUMzzsMfYLbX7lMduTy/77x8ai4IIaZIg1Ezsa9aQ=
=RRN6
-----END PGP SIGNATURE-----

From bdfleming at kanren.net  Mon Mar 15 12:26:07 2010
From: bdfleming at kanren.net (Brad Fleming)
Date: Mon, 15 Mar 2010 11:26:07 -0500
Subject: [j-nsp] Trunking on SRX
In-Reply-To: <247154.45009.qm@web30507.mail.mud.yahoo.com>
References: <247154.45009.qm@web30507.mail.mud.yahoo.com>
Message-ID: <41F66432-5524-4A12-A6DE-E46A28FCEBF6@kanren.net>

Be mindful of the software version you are using. We stumbled across a  
problem on the SRX240 (different class of device, I know). When we  
SNMP querry a VLAN interface, there was a memory leak. Over time, it  
caused all control plane memory to be consumed. When that happened,  
the SRX would stop learning new ARP entries and all kinds of things  
broke.

We were running Junos 9.6R2 when we first saw the issue. I believe  
9.6R3 has a fix for the issue. I'm not sure what (if any) versions of  
10.x are impacted.

I'd suggest building one box with your VLAN configuration and watching  
it for 3-4 weeks. Just be sure to point your supporting systems at it  
as well. If you suddenly start seeing a log message similar to this,  
get worried:
/kernel: kmem type tlv_stat using 143048K, exceeding limit 91352K
--
Brad Fleming

On Mar 15, 2010, at 10:41 AM, Quoc Hoang wrote:

> Hi,
>   Looking to trunk (vlan tagging) on the SRX 3600 to reduce the  
> number of physical interfaces required. Anyone currently using it  
> that can provide feedback or issues? Good or bad idea?
>
> Doesn't appear to be any details of vlan tagging in the srx docs so  
> not sure if it's officially supported.
>
> TIA,
> quoc
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


From mzeier at gmail.com  Mon Mar 15 13:28:41 2010
From: mzeier at gmail.com (matthew zeier)
Date: Mon, 15 Mar 2010 10:28:41 -0700
Subject: [j-nsp] Trunking on SRX
In-Reply-To: <41F66432-5524-4A12-A6DE-E46A28FCEBF6@kanren.net>
References: <247154.45009.qm@web30507.mail.mud.yahoo.com>
	<41F66432-5524-4A12-A6DE-E46A28FCEBF6@kanren.net>
Message-ID: <A2907895-880A-4717-9954-650F853145FD@gmail.com>

This is exactly what we're doing at Mozilla on 10.1R1.8.  Boxes have been up since 10.1R1.8 was loaded 21 days ago:

mrz at phx-fw1> show system uptime 
node0:
--------------------------------------------------------------------------
Current time: 2010-03-15 17:27:33 UTC
System booted: 2010-02-22 05:57:50 UTC (3w0d 11:29 ago)
Protocols started: 2010-02-22 05:58:59 UTC (3w0d 11:28 ago)
Last configured: 2010-03-11 00:29:07 UTC (4d 16:58 ago) by dmoore
 5:27PM  up 21 days, 11:30, 1 user, load averages: 0.00, 0.00, 0.00

node1:
--------------------------------------------------------------------------
Current time: 2010-03-15 17:27:33 UTC
System booted: 2010-02-22 06:25:30 UTC (3w0d 11:02 ago)
Last configured: 2010-03-11 00:29:05 UTC (4d 16:58 ago) by dmoore
 5:27PM  up 21 days, 11:02, 0 users, load averages: 0.06, 0.03, 0.00

> 
>> Hi,
>>  Looking to trunk (vlan tagging) on the SRX 3600 to reduce the number of physical interfaces required. Anyone currently using it that can provide feedback or issues? Good or bad idea?
>> 
>> Doesn't appear to be any details of vlan tagging in the srx docs so not sure if it's officially supported.



From eric at atlantech.net  Mon Mar 15 14:21:57 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 15 Mar 2010 14:21:57 -0400
Subject: [j-nsp] JUNOS 9.6R3.8 on MX
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFC46CB24@exchange.aoihq.local>

Hi all,
Any experiences with 9.6R3.8 on MX?  I have 9.5R4.3 installed on some newly acquired MX boxes, per the advice of this list.  However, I greatly require the ability to do bridge-domains within logical-systems and it appears this is supported starting with 9.6.  We plan on utilizing our MX boxes primarily for core routing and distribution, as well as MPLS P-routers - nothing too magical.  Is 9.6R3.8 just a recipe for disaster?

-evt





From ras at e-gerbil.net  Mon Mar 15 15:15:47 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 15 Mar 2010 14:15:47 -0500
Subject: [j-nsp] JUNOS 9.6R3.8 on MX
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46CB24@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46CB24@exchange.aoihq.local>
Message-ID: <20100315191547.GM75640@gerbil.cluepon.net>

On Mon, Mar 15, 2010 at 02:21:57PM -0400, Eric Van Tol wrote:
> Hi all,
> Any experiences with 9.6R3.8 on MX?  I have 9.5R4.3 installed on some
> newly acquired MX boxes, per the advice of this list.  However, I
> greatly require the ability to do bridge-domains within
> logical-systems and it appears this is supported starting with 9.6. 
> We plan on utilizing our MX boxes primarily for core routing and
> distribution, as well as MPLS P-routers - nothing too magical.  Is
> 9.6R3.8 just a recipe for disaster?

We've been playing with 9.6R3 on a couple routers with low risk of
customer impact, but 9.5R4 is still our weapon of choice since it is a
known element and has been relatively stable. The weirdest thing I've
seen so far under 9.6R3 was a semi-persistent BGP flap when talking to a
SRC2 IOS box, due to a BGP protocol error. Of course SRC2 is pretty old
and nasty, and has plenty of its own bugs to deal with, but this box
does have a 1.5y uptime and never experienced this issue prior to
upgrading the Juniper it was talking to via IBGP (upgraded from 9.5R3,
plus several versions of junos prior to that).

Mar 1 02:22:17.735 re1.router rpd[1281]: %DAEMON-4:
bgp_read_v4_message:8655: NOTIFICATION sent to x.x.x.x (Internal AS
xxxx): code 1 (Message Header Error) subcode 2 (bad length) value 65535, 
Reason: peer x.x.x.x (Internal AS xxxx): invalid message header 
length 65535 count 4011 errno 0 
Mar 1 02:22:17.738 re1.router rpd[1281]: 
%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x
(Internal AS xxxx) changed state from Established to Idle (event 
TransportError) 
Mar 1 02:22:28.128 re1.router rpd[1281]: %DAEMON-4: bgp_pp_recv: 
peer x.x.x.x (Internal AS xxxx) sent unexpected extra data, probably insane 
Mar 1 02:22:28.130 re1.router rpd[1281]: %DAEMON-4:
bgp_read_message: peer x.x.x.x (Internal AS xxxx): Update arrived,
expected KeepAlive or Notification 
Mar 1 02:22:28.131 re1.router rpd[1281]: %DAEMON-4: 
bgp_read_message:1979: NOTIFICATION sent to x.x.x.x (Internal AS 
xxxx): code 5 (Finite State Machine Error) 

It flapped like this several times after the initial upgrade, but
eventually settled down and has been stable since. JTAC wasn't
immediately helpful in determining if it was a known issue or not, and
we have far to many bigger more important bugs to deal with as it is, so
this got stashed on the back burner.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From quochoang at yahoo.com  Mon Mar 15 15:56:07 2010
From: quochoang at yahoo.com (Quoc Hoang)
Date: Mon, 15 Mar 2010 12:56:07 -0700 (PDT)
Subject: [j-nsp] Trunking on SRX
In-Reply-To: <A2907895-880A-4717-9954-650F853145FD@gmail.com>
Message-ID: <340733.100.qm@web30507.mail.mud.yahoo.com>

Thanks for the feedback.

With vlan routing interfaces (vri), anyone using it in different virtual routers and zones.

quoc

--- On Mon, 3/15/10, matthew zeier <mzeier at gmail.com> wrote:

> From: matthew zeier <mzeier at gmail.com>
> Subject: Re: [j-nsp] Trunking on SRX
> To: juniper-nsp at puck.nether.net
> Date: Monday, March 15, 2010, 10:28 AM
> This is exactly what we're doing at
> Mozilla on 10.1R1.8.? Boxes have been up since 10.1R1.8
> was loaded 21 days ago:
> 
> mrz at phx-fw1> show system uptime 
> node0:
> --------------------------------------------------------------------------
> Current time: 2010-03-15 17:27:33 UTC
> System booted: 2010-02-22 05:57:50 UTC (3w0d 11:29 ago)
> Protocols started: 2010-02-22 05:58:59 UTC (3w0d 11:28
> ago)
> Last configured: 2010-03-11 00:29:07 UTC (4d 16:58 ago) by
> dmoore
>  5:27PM? up 21 days, 11:30, 1 user, load averages:
> 0.00, 0.00, 0.00
> 
> node1:
> --------------------------------------------------------------------------
> Current time: 2010-03-15 17:27:33 UTC
> System booted: 2010-02-22 06:25:30 UTC (3w0d 11:02 ago)
> Last configured: 2010-03-11 00:29:05 UTC (4d 16:58 ago) by
> dmoore
>  5:27PM? up 21 days, 11:02, 0 users, load averages:
> 0.06, 0.03, 0.00
> 
> > 
> >> Hi,
> >>? Looking to trunk (vlan tagging) on the SRX
> 3600 to reduce the number of physical interfaces required.
> Anyone currently using it that can provide feedback or
> issues? Good or bad idea?
> >> 
> >> Doesn't appear to be any details of vlan tagging
> in the srx docs so not sure if it's officially supported.
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From sergevautour at yahoo.ca  Tue Mar 16 08:51:39 2010
From: sergevautour at yahoo.ca (Serge Vautour)
Date: Tue, 16 Mar 2010 05:51:39 -0700 (PDT)
Subject: [j-nsp] OSPF LFA and LDP LSPs
Message-ID: <322112.87522.qm@web53605.mail.re2.yahoo.com>

Hello,

We are testing MPLS in our lab using two MX960s with a few LS to add more routers. I'm using OSPF as the IGP and LDP for transport labels. We're on 10.0 code so I've been testing OSPF LFA. It appears to be doing something strange and I can't tell if it's per design or a bug.

Here's a PE's route to a destination PE loopback:

----------------------
se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail    

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
        *OSPF   Preference: 10
                Next hop type: Router, Next hop index: 1192
                Next-hop reference count: 40
                Next hop: 10.10.81.10 via xe-0/3/0.0, selected
                State: <Active Int>
                Local AS:   855 
                Age: 2  Metric: 2 
                Area: 0.0.0.0
                Task: OSPF
                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
                AS path: I

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

10.10.80.2/32 (1 entry, 1 announced)
        State: <FlashAll>
        *LDP    Preference: 9
                Next hop type: Router
                Next-hop reference count: 3
                Next hop: 10.10.81.10 via xe-0/3/0.0, selected
                Label operation: Push 299776
                State: <Active Int>
                Local AS:   855 
                Age: 2  Metric: 1 
                Task: LDP
                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
                AS path: I

{master}
se36152 at PE1-STJHLab-re0> show ldp route logical-system PE10 10.10.80.2 extensive    
Destination         Next-hop intf/lsp                Next-hop address
 10.10.80.2/32      xe-0/3/0.0                       10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:10 ago

se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 logical-system PE10 no-resolve 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.353 ms  0.274 ms  0.279 ms
 2  10.10.80.2  0.460 ms  0.455 ms  0.437 ms

{master}
se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 logical-system PE10 no-resolve
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299776  LDP         10.10.81.10      (null)           Success           
    2        3  LDP         10.10.81.1       10.10.81.10      Egress            

  Path 1 via xe-0/3/0.0 destination 127.0.0.64
----------------------

Everything is normal. IP packets are following the OSPF shortest path per the costs I've set. The LDP LSP is following OSPF.

Now I turn on OSPF LFA "link-protection" on the links and re-run the same tests:

-----------------------
se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail                

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
        *OSPF   Preference: 10
                Next hop type: Router
                Next-hop reference count: 26
                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000   <--------- Huh???
                State: <Active Int>
                Local AS:   855 
                Age: 4  Metric: 2 
                Area: 0.0.0.0
                Task: OSPF
                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
                AS path: I

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

10.10.80.2/32 (1 entry, 1 announced)
        State: <FlashAll>
        *LDP    Preference: 9
                Next hop type: Router
                Next-hop reference count: 3
                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
                Label operation: Push 299776
                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- Huh???
                Label operation: Push 299856
                State: <Active Int>
                Local AS:   855 
                Age: 4  Metric: 1 
                Task: LDP
                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
                AS path: I

{master}
se36152 at PE1-STJHLab-re0> show ldp route logical-system PE10 10.10.80.2 extensive         
Destination         Next-hop intf/lsp                Next-hop address
 10.10.80.2/32      xe-0/3/0.0                       10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
                    ge-1/3/3.0                       10.10.81.23
   Session ID 10.10.80.10:0--10.10.80.14:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:09 ago

{master}
se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 logical-system PE10 no-resolve            
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.407 ms  0.282 ms  0.283 ms
 2  10.10.80.2  0.904 ms  1.086 ms  1.066 ms

{master}
se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 logical-system PE10 no-resolve   
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299776  LDP         10.10.81.10      (null)           Success           
    2        3  LDP         10.10.81.1       10.10.81.10      Egress            

  Path 1 via xe-0/3/0.0 destination 127.0.0.64

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299856  LDP         10.10.81.23      (null)           Success           
    2        3  LDP         10.10.81.20      10.10.81.23      Egress            

  Path 2 via ge-1/3/3.0 destination 127.0.1.64  <--- Why does this get used??
-----------------------

The path via ge-1/3/3 is a backup path chosen by OSPF LFA. As expected IP packets don't use it when I do a traceroute. The "traceroute mpls ldp" however seems to use both paths?!? Does this mean that the ingress PE could dump traffic on both LSPs? I don't want this as only 1 of the 2 is the preferred path...

Any ideas?

Thanks,
Serge



      __________________________________________________________________
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

From snar at snar.spb.ru  Tue Mar 16 08:56:03 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Tue, 16 Mar 2010 15:56:03 +0300
Subject: [j-nsp] mysterious microbursts ?
In-Reply-To: <1920897981-1268572714-cardhu_decombobulator_blackberry.rim.net-746799913-@bda069.bisx.prod.on.blackberry>
References: <20100314112549.GA76596@snar.spb.ru>
	<1920897981-1268572714-cardhu_decombobulator_blackberry.rim.net-746799913-@bda069.bisx.prod.on.blackberry>
Message-ID: <20100316125603.GA77756@snar.spb.ru>

On Sun, Mar 14, 2010 at 01:18:39PM +0000, chrisccnpspam2 at gmail.com wrote:
> One thing I would check for first is unicast flooding.  It sounds like 
> the backup router is flooding all traffic as it doesn't have any arp/mac 
> tables created for traffic that comes ingress to it. Would be hard to 
> pinpoint the issue unless you can provide some traffic flow stats. 
> 
> Unicast flooding is a common problem with active/backup switching 
> environments. If this is the case we can work on modifying the mac 
> and arp timers to resolve it. 
> 
> Hope this helps

Thanks, you described my problem mostly exactly, with the only 
difference: actually my backup router had correct arp table, with 
default arp aging-time of 20min, but mac-table-aging-time on second 
core switch was (by default) just 300sec, so in five minutes after 
backup router passive-learned some arp entry switch had to flood traffic 
in unknown-unicast mode, thus affecting only ports on "even" access-switches.

Thanks again. 

> Sent via BlackBerry by AT&T
> 
> -----Original Message-----
> From: Alexandre Snarskii <snar at snar.spb.ru>
> Date: Sun, 14 Mar 2010 14:25:49 
> To: Juniper-NSP Mailing list<juniper-nsp at puck.nether.net>
> Subject: [j-nsp] mysterious microbursts ?
> 
> 
> Hi!
> 
> During routine maintenance on my ex-3200 switches I found that 
> some devices, connected with 100mbit/full-duplex observe minor
> packet loss. Well, there is nothing too unexpected, you can 
> see it mostly every time when traffic enters switch using 1ge (2x1ge
> aggregate in my case) link and exits using 100mbit, switch ports
> just do not have enough buffer space to handle bursts well, but... 
> That's where the strangeness begins: 
> a) these 100mbit ports used to connect VoIP devices handling RTP 
> traffic, so there should be no bursts at all.
> b) there are more than 30 such devices in my network, and I see 
> that loss only on half of them - on that half that is connected 
> to even-numbered switches, there are no packet loss on devices 
> connected to odd-numbered ones.
> 
> Logical topology is just "a vlan connected to a router (two routers
> in VRRP master/slave scenario)", physical is classic ring (some rings 
> actually, each odd-numbered access switch connected to coresw1, 
> even-numbered - to coresw2): 
> 
>   router1                  router2(backup, no traffic right now)
>     |                        |
>   coresw1 ================ coresw2
>     |                        |
>     |                        |
>   accsw1 -------- x ------ accsw2
> 
> link between core switches is 10ge, links core-access and access-access
> is 2x ge aggregated ethernet, access-access links are blocked by STP. 
> Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4.
> 
> Well, these losses is about 0.1% and I can live with that, but
> I'd like to have any idea on why it happens only on half of 
> devices, and I don't have one :( 
> Any clue ? 
> 
> Example interface with errors: 
> 
> Physical interface: ge-0/0/26, Enabled, Physical link is Up
>   Interface index: 165, SNMP ifIndex: 174, Generation: 168
>   Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, MAC-REWRITE Error: None,
>   Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Disabled,
>   Remote fault: Online
>   Device flags   : Present Running
>   Interface flags: SNMP-Traps Internal: 0x0
>   Link flags     : None
>   CoS queues     : 8 supported, 8 maximum usable queues
>   Hold-times     : Up 0 ms, Down 0 ms
>   Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a
>   Last flapped   : 2010-03-05 04:36:34 PST (1w1d 22:21 ago)
>   Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago)
>   Traffic statistics:
>    Input  bytes  :          88312256790                    0 bps
>    Output bytes  :          88616684644                 5984 bps
>    Input  packets:            443797702                    0 pps
>    Output packets:            412072442                   10 pps
>    IPv6 transit statistics:
>     Input  bytes  :                   0 
>     Output bytes  :                   0
>     Input  packets:                   0
>     Output packets:                   0
>   Input errors:
>     Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0,
>     L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
>   Output errors:
>     Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0,
>     MTU errors: 0, Resource errors: 0
>   Egress queues: 8 supported, 4 in use
>   Queue counters:       Queued packets  Transmitted packets      Dropped packets
>     0 best-effort                    0            411934501               454642
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     1 assured-forw                   0                    0                    0
>     5 expedited-fo                   0                    0                    0
>     7 network-cont                   0               137336                    0
>   Active alarms  : None
>   Active defects : None
>   MAC statistics:                      Receive         Transmit
>     Total octets                   88312256790      88616684644
>     Total packets                    443797702        412072442
>     Unicast packets                  443796941        410096125
>     Broadcast packets                      761           447035
>     Multicast packets                        0          1529282
>     CRC/Align errors                         0                0
>     FIFO errors                              0                0
>     MAC control frames                       0                0
>     MAC pause frames                         0                0
>     Oversized frames                         0
>     Jabber frames                            0
>     Fragment frames                          0
>     Code violations                          0
>   Autonegotiation information:
>     Negotiation status: Incomplete
>   Packet Forwarding Engine configuration:
>     Destination slot: 0
>     Direction : Output 
>     CoS transmit queue               Bandwidth               Buffer Priority   Limit
>                               %            bps     %           usec
>     0 best-effort            95       95000000    95             NA      low    none
>     7 network-control         5        5000000     5             NA      low    none
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

From chmorl at wm.edu  Tue Mar 16 10:35:30 2010
From: chmorl at wm.edu (Clarke Morledge)
Date: Tue, 16 Mar 2010 10:35:30 -0400 (EDT)
Subject: [j-nsp] OSPF LFA and LDP LSPs
In-Reply-To: <mailman.3536.1268743924.2718.juniper-nsp@puck.nether.net>
References: <mailman.3536.1268743924.2718.juniper-nsp@puck.nether.net>
Message-ID: <Pine.SOC.4.60.1003161015080.7961@stat.wm.edu>

Serge,

Part of what you wrote included this:

> Now I turn on OSPF LFA "link-protection" on the links and re-run the same tests:
>
> -----------------------
> se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail
>
> inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
> 10.10.80.2/32 (1 entry, 1 announced)
>        *OSPF   Preference: 10
>                Next hop type: Router
>                Next-hop reference count: 26
>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000   <--------- Huh???
>                State: <Active Int>
>                Local AS:   855
>                Age: 4  Metric: 2
>                Area: 0.0.0.0
>                Task: OSPF
>                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2
>                AS path: I
>
> inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
>
> 10.10.80.2/32 (1 entry, 1 announced)
>        State: <FlashAll>
>        *LDP    Preference: 9
>                Next hop type: Router
>                Next-hop reference count: 3
>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>                Label operation: Push 299776
>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- Huh???
>                Label operation: Push 299856
>                State: <Active Int>
>                Local AS:   855
>                Age: 4  Metric: 1
>                Task: LDP
>                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
>                AS path: I

I can not speak to your traceroute issue, but my understanding is that the 
next-hop 10.10.81.23 references are the alternate paths that get put in 
your routing table by the LFA algorithm.  These routes exist but only in 
"stand-by" mode.  So if the 10.10.81.10 next-hop ever goes away, traffic 
can immediately use this "stand-by" routing entry to forward the traffic 
while OSPF is recalculating new routes under the covers.  This is loosely 
analogous to how Detours work in RSVP/MPLS Fast ReRoute -- though, 
admittedly, Fast ReRoute is much more involved.  Then, once the OSPF 
recalculations are done in LFA, the routing table is updated with a new 
primary routing entry and another "stand-by" entry.

Therefore, LFA effectively doubles the size of your routing table to 
accommodate all of the "stand-by" routes.

Unless, I'm missing something, that is at least my understanding of how 
LFA actually works --- or at least how it is supposed to work.  In other 
words, per your routing table it is working as designed.  However, this 
does not necessarily mean that OSPF LFA currently solves all of the 
problems with microloops in some topologies.  If someone has a better 
explanation, I'd like to know, too.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187

From sergevautour at yahoo.ca  Tue Mar 16 10:54:09 2010
From: sergevautour at yahoo.ca (Serge Vautour)
Date: Tue, 16 Mar 2010 07:54:09 -0700 (PDT)
Subject: [j-nsp] OSPF LFA and LDP LSPs
In-Reply-To: <Pine.SOC.4.60.1003161015080.7961@stat.wm.edu>
References: <mailman.3536.1268743924.2718.juniper-nsp@puck.nether.net>
	<Pine.SOC.4.60.1003161015080.7961@stat.wm.edu>
Message-ID: <474247.57046.qm@web53605.mail.re2.yahoo.com>

Hello,

Thanks for your comments. I agree with your theory. It's my understanding as well. What I don't get is why the "traceroute mpls ldp" command uses both paths and yet "traceroute ip" uses 1 path. It's like the backup path is being used by the LDP LSP when it shouldn't be...

Serge



----- Original Message ----
From: Clarke Morledge <chmorl at wm.edu>
To: juniper-nsp at puck.nether.net
Cc: Serge Vautour <sergevautour at yahoo.ca>
Sent: Tue, March 16, 2010 11:35:30 AM
Subject: RE: [j-nsp] OSPF LFA and LDP LSPs

Serge,

Part of what you wrote included this:

> Now I turn on OSPF LFA "link-protection" on the links and re-run the same tests:
> 
> -----------------------
> se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail
> 
> inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
> 10.10.80.2/32 (1 entry, 1 announced)
>        *OSPF   Preference: 10
>                Next hop type: Router
>                Next-hop reference count: 26
>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000   <--------- Huh???
>                State: <Active Int>
>                Local AS:   855
>                Age: 4  Metric: 2
>                Area: 0.0.0.0
>                Task: OSPF
>                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2
>                AS path: I
> 
> inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
> 
> 10.10.80.2/32 (1 entry, 1 announced)
>        State: <FlashAll>
>        *LDP    Preference: 9
>                Next hop type: Router
>                Next-hop reference count: 3
>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>                Label operation: Push 299776
>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- Huh???
>                Label operation: Push 299856
>                State: <Active Int>
>                Local AS:   855
>                Age: 4  Metric: 1
>                Task: LDP
>                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
>                AS path: I

I can not speak to your traceroute issue, but my understanding is that the next-hop 10.10.81.23 references are the alternate paths that get put in your routing table by the LFA algorithm.  These routes exist but only in "stand-by" mode.  So if the 10.10.81.10 next-hop ever goes away, traffic can immediately use this "stand-by" routing entry to forward the traffic while OSPF is recalculating new routes under the covers.  This is loosely analogous to how Detours work in RSVP/MPLS Fast ReRoute -- though, admittedly, Fast ReRoute is much more involved.  Then, once the OSPF recalculations are done in LFA, the routing table is updated with a new primary routing entry and another "stand-by" entry.

Therefore, LFA effectively doubles the size of your routing table to accommodate all of the "stand-by" routes.

Unless, I'm missing something, that is at least my understanding of how LFA actually works --- or at least how it is supposed to work.  In other words, per your routing table it is working as designed.  However, this does not necessarily mean that OSPF LFA currently solves all of the problems with microloops in some topologies.  If someone has a better explanation, I'd like to know, too.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

From chrisccnpspam2 at gmail.com  Tue Mar 16 11:02:54 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Tue, 16 Mar 2010 10:02:54 -0500
Subject: [j-nsp] RFC2544 on Juniper MX960 10G ports
In-Reply-To: <419dba611003141413k32d9f577sa531adac88cf2a65@mail.gmail.com>
References: <82e7ac35-85b4-4908-93ff-5d65c5b61742@tnib.de>
	<419dba611003141228w1901b75au5a9dab1eeb47c5c2@mail.gmail.com>
	<A0CB4A8E43FA4EADB20347B5D3DDBF84@jnpr.net>
	<419dba611003141413k32d9f577sa531adac88cf2a65@mail.gmail.com>
Message-ID: <419dba611003160802v447d62ddnbf51624621573a5c@mail.gmail.com>

Update..

JTAC came back stating they were able to get line rate @ 64bytes on a L3
config, but did get some loss on the l2 configuration. I tested with them to
show my packet loss that I was getting.. Turns out they tested on the 4 x
10Gig line module, I am testing with the combo card. They then tested with a
combo card in their lab and duplicated the results I was seeing..

So to the person asking about the combo card, there is an issue with it..
Once again, this is with 9.6R3.8

On Sun, Mar 14, 2010 at 4:13 PM, Chris Evans <chrisccnpspam2 at gmail.com>wrote:

> Alex,
>
> Thanks for you input. While what you stay is true, there are still issues
> with the MX platform. As stated in my previous postings, I can only push
> line rate or 94.78% max before drops start.. This is that % on a full duplex
> stream.. If I shutdown one of the streams I can then push 100% line rate,
> packet loss is only there when there are full duplex flows.. It's really
> either down to a bug or just the PFE cannot forward the PPS. If you take the
> frame size up to 69 bytes, you can do 100% line rate full duplex.
>
> Putting the MX into a layer2 mode (meaning setting it up as a typical
> ethernet switch) brings another issue with even much larger % of packet loss
> unfortunately.
>
> I am using an IXIA XM12 appliance and IXNetwork.
>
> On Sun, Mar 14, 2010 at 5:04 PM, Alex <alex.arseniev at gmail.com> wrote:
>
>> Chris,
>> Line rate on one 10G port could be different from line-rate on another 10G
>> port because Ethernet is not bit-synchronous.
>> LAN-PHY 10GBASE-S allowed transmitter clock tolerance is 10.3125Gbd +/1
>> 100ppm (parts per million) and LAN-PHY 10GBASE-S allowed receiver clock
>> tolerance is also 10.3125Gbd +/- 100ppm. See IEEE 802.3-2008 spec sections
>> 52.5.1 and 52.5.2.
>> So in reality the Rx on ingress port could run at 10.31353125Gbd and Tx on
>> egress port could run at 10.31146875Gbd. This 0.0020625Gbd=2.0625Mbd
>> difference causes ingress buffer to grow until there is no more room and
>> eventually an "overspill" and packet drop. Please run Your tests at 99% line
>> rate, I am sure there will be no packet loss at all.
>> Rgds
>> Alex
>>
>>
>> ----- Original Message ----- From: "Chris Evans" <
>> chrisccnpspam2 at gmail.com>
>> To: "Joerg Staedele" <js at tnib.de>
>> Cc: "juniper-nsp" <juniper-nsp at puck.nether.net>
>> Sent: Sunday, March 14, 2010 7:28 PM
>>
>> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>>
>>
>>  Joerg,
>>>
>>> The hardware we have in our lab is the 20xSFP + 2x10Gig.. JTAC says this
>>> 'should' work but obviously it doesn't.. I tested it on an EX switch and
>>> it
>>> had no issues.. In a simple L2 mode the MX lost about 47% packets at
>>> 64byte
>>> 10Gig line rates. In L3 mode is lost about 5.2%.. This is when testing
>>> full
>>> duplex flows. This was with 9.6R3.8.. There is a known PR related to this
>>> issue.
>>>
>>> Hope to have some resolution sometime this week..
>>>
>>> On Sun, Mar 14, 2010 at 3:14 PM, Joerg Staedele <js at tnib.de> wrote:
>>>
>>>  Hi,
>>>>
>>>> so this means that this Linecard is not able to do line-rate forwarding
>>>> with small frame sizes? What about other cards (20xSFP+2x10G) .. I guess
>>>> they use exactly the same PFE hardware? So they have this limitation
>>>> aswell?
>>>>
>>>> I am really confused now because in every document you read that the
>>>> DPCE's
>>>> are able to do line-rate at any frame-size?
>>>>
>>>> Regards,
>>>>  Joerg
>>>>
>>>> -----Original Message-----
>>>> From: juniper-nsp-bounces at puck.nether.net [mailto:
>>>> juniper-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Lassoff
>>>> Sent: Sunday, March 14, 2010 6:55 PM
>>>> To: Serge Vautour
>>>> Cc: juniper-nsp
>>>> Subject: Re: [j-nsp] RFC2544 on Juniper MX960 10G ports
>>>>
>>>> Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
>>>> > Hello,
>>>> >
>>>> > We recently used a traffic generator to run RFC2544 tests against a
>>>> Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame
>>>> sizes.
>>>> >
>>>> > The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to
>>>> > 25%
>>>> packets with certain small frames (ex: 70 byte frames). The packet loss
>>>> goes
>>>> away almost completely for frames larger than 100 bytes. Our SE tells us
>>>> this is normal and is due to how the MX chops the frames up into 64 byte
>>>> cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G
>>>> port)
>>>> and each of them has 10G of bandwidth. 10G of small frames essentially
>>>> creates more than 10G of traffic inside the PFE. That explanation may
>>>> not be
>>>> 100% correct but I think it paints the right picture.
>>>> >
>>>> > Now the questions. Is this a problem on production networks with real
>>>> world traffic? What about on VPN networks with alot of small frames like
>>>> VoIP? Has anyone seen this problem creep it's head in production?
>>>>
>>>> Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
>>>> Ethernet 802.3 requires this.
>>>>
>>>> Wouldn't this make the problem moot if you're just running Ethernet?
>>>>
>>>> Might be a problem with small ATM cells?
>>>>
>>>> Cheers,
>>>> jof
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>>  _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>>
>

From alex.arseniev at gmail.com  Tue Mar 16 12:44:13 2010
From: alex.arseniev at gmail.com (Alex)
Date: Tue, 16 Mar 2010 16:44:13 -0000
Subject: [j-nsp] OSPF LFA and LDP LSPs
References: <mailman.3536.1268743924.2718.juniper-nsp@puck.nether.net><Pine.SOC.4.60.1003161015080.7961@stat.wm.edu>
	<474247.57046.qm@web53605.mail.re2.yahoo.com>
Message-ID: <AD15EFFE0E6E4B1DA815BB429A40C9B0@jnpr.net>

Serge,
Do you have "track-igp-metric" configured under LDP? I am pretty sure it 
does not since your OSPF and LDP metrics are different but I'd like to 
confirm.
Please try to configure "track-igp-metric" for LDP and re-run MPLS 
traceroute.
Rgds
Alex


----- Original Message ----- 
From: "Serge Vautour" <sergevautour at yahoo.ca>
To: "Clarke Morledge" <chmorl at wm.edu>; <juniper-nsp at puck.nether.net>
Sent: Tuesday, March 16, 2010 2:54 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs


> Hello,
>
> Thanks for your comments. I agree with your theory. It's my understanding 
> as well. What I don't get is why the "traceroute mpls ldp" command uses 
> both paths and yet "traceroute ip" uses 1 path. It's like the backup path 
> is being used by the LDP LSP when it shouldn't be...
>
> Serge
>
>
>
> ----- Original Message ----
> From: Clarke Morledge <chmorl at wm.edu>
> To: juniper-nsp at puck.nether.net
> Cc: Serge Vautour <sergevautour at yahoo.ca>
> Sent: Tue, March 16, 2010 11:35:30 AM
> Subject: RE: [j-nsp] OSPF LFA and LDP LSPs
>
> Serge,
>
> Part of what you wrote included this:
>
>> Now I turn on OSPF LFA "link-protection" on the links and re-run the same 
>> tests:
>>
>> -----------------------
>> se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail
>>
>> inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
>> 10.10.80.2/32 (1 entry, 1 announced)
>>        *OSPF   Preference: 10
>>                Next hop type: Router
>>                Next-hop reference count: 26
>>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 
>> <--------- Huh???
>>                State: <Active Int>
>>                Local AS:   855
>>                Age: 4  Metric: 2
>>                Area: 0.0.0.0
>>                Task: OSPF
>>                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2
>>                AS path: I
>>
>> inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
>>
>> 10.10.80.2/32 (1 entry, 1 announced)
>>        State: <FlashAll>
>>        *LDP    Preference: 9
>>                Next hop type: Router
>>                Next-hop reference count: 3
>>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>>                Label operation: Push 299776
>>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 
>> <--------- Huh???
>>                Label operation: Push 299856
>>                State: <Active Int>
>>                Local AS:   855
>>                Age: 4  Metric: 1
>>                Task: LDP
>>                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
>>                AS path: I
>
> I can not speak to your traceroute issue, but my understanding is that the 
> next-hop 10.10.81.23 references are the alternate paths that get put in 
> your routing table by the LFA algorithm.  These routes exist but only in 
> "stand-by" mode.  So if the 10.10.81.10 next-hop ever goes away, traffic 
> can immediately use this "stand-by" routing entry to forward the traffic 
> while OSPF is recalculating new routes under the covers.  This is loosely 
> analogous to how Detours work in RSVP/MPLS Fast ReRoute -- though, 
> admittedly, Fast ReRoute is much more involved.  Then, once the OSPF 
> recalculations are done in LFA, the routing table is updated with a new 
> primary routing entry and another "stand-by" entry.
>
> Therefore, LFA effectively doubles the size of your routing table to 
> accommodate all of the "stand-by" routes.
>
> Unless, I'm missing something, that is at least my understanding of how 
> LFA actually works --- or at least how it is supposed to work.  In other 
> words, per your routing table it is working as designed.  However, this 
> does not necessarily mean that OSPF LFA currently solves all of the 
> problems with microloops in some topologies.  If someone has a better 
> explanation, I'd like to know, too.
>
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
>
>
>
>      __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From sergevautour at yahoo.ca  Tue Mar 16 14:25:38 2010
From: sergevautour at yahoo.ca (Serge Vautour)
Date: Tue, 16 Mar 2010 11:25:38 -0700 (PDT)
Subject: [j-nsp] OSPF LFA and LDP LSPs
In-Reply-To: <AD15EFFE0E6E4B1DA815BB429A40C9B0@jnpr.net>
References: <mailman.3536.1268743924.2718.juniper-nsp@puck.nether.net><Pine.SOC.4.60.1003161015080.7961@stat.wm.edu>
	<474247.57046.qm@web53605.mail.re2.yahoo.com>
	<AD15EFFE0E6E4B1DA815BB429A40C9B0@jnpr.net>
Message-ID: <57142.69691.qm@web53608.mail.re2.yahoo.com>

Hello,

Well that command explains a few things. Thanks! I do want the LDP LSPs to follow the OSPF shortest path. I had never really noticed that the inet.3 table entries had a different metric than my inet.0 entries. That helped make the metrics match however I still have the same problem.

Note the matching metrics:

---------------------
se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail 

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
        *OSPF   Preference: 10
                Next hop type: Router
                Next-hop reference count: 26
                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
                State: <Active Int>
                Local AS:   855 
                Age: 8:04       Metric: 2 
                Area: 0.0.0.0
                Task: OSPF
                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
                AS path: I

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

10.10.80.2/32 (1 entry, 1 announced)
        State: <FlashAll>
        *LDP    Preference: 9
                Next hop type: Router
                Next-hop reference count: 3
                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
                Label operation: Push 300064
                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
                Label operation: Push 300000
                State: <Active Int>
                Local AS:   855 
                Age: 8:04       Metric: 2  <------- Matches inet.0
                Task: LDP
                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
                AS path: I
---------------------

The same problem exists:

--------------------
se36152 at PE1-STJHLab-re0> show ldp route 10.10.80.2 logical-system PE10         
Destination         Next-hop intf/lsp                Next-hop address
 10.10.80.2/32      xe-0/3/0.0                       10.10.81.10
                    ge-1/3/3.0                       10.10.81.23

se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 no-resolve logical-system PE10 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.347 ms  0.268 ms  0.279 ms
 2  10.10.80.2  36.471 ms  0.480 ms  0.436 ms

se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 no-resolve logical-system PE10
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300064  LDP         10.10.81.10      (null)           Success           
    2        3  LDP         10.10.81.1       10.10.81.10      Egress            

  Path 1 via xe-0/3/0.0 destination 127.0.0.64

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300000  LDP         10.10.81.23      (null)           Success           
    2        3  LDP         10.10.81.20      10.10.81.23      Egress            

  Path 2 via ge-1/3/3.0 destination 127.0.1.64

-------------------------

Note that the LDP LSP is still taking both paths?!?

Thanks,
Serge




----- Original Message ----
From: Alex <alex.arseniev at gmail.com>
To: Serge Vautour <serge at nbnet.nb.ca>; juniper-nsp at puck.nether.net
Sent: Tue, March 16, 2010 1:44:13 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs

Serge,
Do you have "track-igp-metric" configured under LDP? I am pretty sure it does not since your OSPF and LDP metrics are different but I'd like to confirm.
Please try to configure "track-igp-metric" for LDP and re-run MPLS traceroute.
Rgds
Alex


----- Original Message ----- From: "Serge Vautour" <sergevautour at yahoo.ca>
To: "Clarke Morledge" <chmorl at wm.edu>; <juniper-nsp at puck.nether.net>
Sent: Tuesday, March 16, 2010 2:54 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs


> Hello,
> 
> Thanks for your comments. I agree with your theory. It's my understanding as well. What I don't get is why the "traceroute mpls ldp" command uses both paths and yet "traceroute ip" uses 1 path. It's like the backup path is being used by the LDP LSP when it shouldn't be...
> 
> Serge
> 
> 
> 
> ----- Original Message ----
> From: Clarke Morledge <chmorl at wm.edu>
> To: juniper-nsp at puck.nether.net
> Cc: Serge Vautour <sergevautour at yahoo.ca>
> Sent: Tue, March 16, 2010 11:35:30 AM
> Subject: RE: [j-nsp] OSPF LFA and LDP LSPs
> 
> Serge,
> 
> Part of what you wrote included this:
> 
>> Now I turn on OSPF LFA "link-protection" on the links and re-run the same tests:
>> 
>> -----------------------
>> se36152 at PE1-STJHLab-re0> show route 10.10.80.2 logical-system PE10 detail
>> 
>> inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
>> 10.10.80.2/32 (1 entry, 1 announced)
>>        *OSPF   Preference: 10
>>                Next hop type: Router
>>                Next-hop reference count: 26
>>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- Huh???
>>                State: <Active Int>
>>                Local AS:   855
>>                Age: 4  Metric: 2
>>                Area: 0.0.0.0
>>                Task: OSPF
>>                Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2
>>                AS path: I
>> 
>> inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
>> 
>> 10.10.80.2/32 (1 entry, 1 announced)
>>        State: <FlashAll>
>>        *LDP    Preference: 9
>>                Next hop type: Router
>>                Next-hop reference count: 3
>>                Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
>>                Label operation: Push 299776
>>                Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- Huh???
>>                Label operation: Push 299856
>>                State: <Active Int>
>>                Local AS:   855
>>                Age: 4  Metric: 1
>>                Task: LDP
>>                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
>>                AS path: I
> 
> I can not speak to your traceroute issue, but my understanding is that the next-hop 10.10.81.23 references are the alternate paths that get put in your routing table by the LFA algorithm.  These routes exist but only in "stand-by" mode.  So if the 10.10.81.10 next-hop ever goes away, traffic can immediately use this "stand-by" routing entry to forward the traffic while OSPF is recalculating new routes under the covers.  This is loosely analogous to how Detours work in RSVP/MPLS Fast ReRoute -- though, admittedly, Fast ReRoute is much more involved.  Then, once the OSPF recalculations are done in LFA, the routing table is updated with a new primary routing entry and another "stand-by" entry.
> 
> Therefore, LFA effectively doubles the size of your routing table to accommodate all of the "stand-by" routes.
> 
> Unless, I'm missing something, that is at least my understanding of how LFA actually works --- or at least how it is supposed to work.  In other words, per your routing table it is working as designed.  However, this does not necessarily mean that OSPF LFA currently solves all of the problems with microloops in some topologies.  If someone has a better explanation, I'd like to know, too.
> 
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> 
> 
> 
>      __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
> 
> http://www.flickr.com/gift/
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



      __________________________________________________________________
Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/

From ras at e-gerbil.net  Tue Mar 16 19:44:15 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 16 Mar 2010 18:44:15 -0500
Subject: [j-nsp] BGP Flowspec + NSR
Message-ID: <20100316234415.GY75640@gerbil.cluepon.net>

So I noticed something interesting about NSR, apparently it doesn't
support BGP sessions with flowspec SAFIs enabled. Here is a sh bgp sum
from the backup RE of a router trying to do NSR, note the number of
flaps:

ras at backupre.somerouter> show bgp summary 
Groups: 53 Peers: 74 Down peers: 24
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0            394198     250825          0          0          0          0
inetflow.0             0          0          0          0          0          0
inet6.0             3288       2418          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
x.x.x.x                xxxx          0          0       0  142650           6 Idle  
x.x.x.x                xxxx          0          0       0  137608           3 Idle  
x.x.x.x                xxxx          0          0       0  130645           5 Idle  
x.x.x.x                xxxx          0          0       0  138745           1 Idle  
etc etc etc

ras at backupre.somerouter> show bgp neighbor x.x.x.x | match "Last flap"
  Last flap event: NsrNotsupported

It just sits and spins forever trying to bring up the BGP sync session
between the master and backup RE, and turning off inetflow negotiation
makes things work properly again. This was under 9.5 and 9.6, but I
haven't seen anything in any release notes about support for it in any
later software versions. Does anybody know if this is actually on the
roadmap to get supported, or has flowspec just completely fallen off the
radar since Pedro and Raszuk left Juniper? :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From harry at juniper.net  Tue Mar 16 19:54:22 2010
From: harry at juniper.net (Harry Reynolds)
Date: Tue, 16 Mar 2010 16:54:22 -0700
Subject: [j-nsp] BGP Flowspec + NSR
In-Reply-To: <20100316234415.GY75640@gerbil.cluepon.net>
References: <20100316234415.GY75640@gerbil.cluepon.net>
Message-ID: <50B3A5560BA4D74CADEC55A48B4641B23D10A9516E@EMBX01-HQ.jnpr.net>

I can confirm that the flowspec family is one of several that are not yet nsr supported. The expected results are as you show...

There is an ER/RLI to add but this is not currently scheduled for any release.

Regards

 

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A Steenbergen
Sent: Tuesday, March 16, 2010 4:44 PM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] BGP Flowspec + NSR

So I noticed something interesting about NSR, apparently it doesn't support BGP sessions with flowspec SAFIs enabled. Here is a sh bgp sum from the backup RE of a router trying to do NSR, note the number of
flaps:

ras at backupre.somerouter> show bgp summary
Groups: 53 Peers: 74 Down peers: 24
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0            394198     250825          0          0          0          0
inetflow.0             0          0          0          0          0          0
inet6.0             3288       2418          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
x.x.x.x                xxxx          0          0       0  142650           6 Idle  
x.x.x.x                xxxx          0          0       0  137608           3 Idle  
x.x.x.x                xxxx          0          0       0  130645           5 Idle  
x.x.x.x                xxxx          0          0       0  138745           1 Idle  
etc etc etc

ras at backupre.somerouter> show bgp neighbor x.x.x.x | match "Last flap"
  Last flap event: NsrNotsupported

It just sits and spins forever trying to bring up the BGP sync session between the master and backup RE, and turning off inetflow negotiation makes things work properly again. This was under 9.5 and 9.6, but I haven't seen anything in any release notes about support for it in any later software versions. Does anybody know if this is actually on the roadmap to get supported, or has flowspec just completely fallen off the radar since Pedro and Raszuk left Juniper? :)

-- 
Richard A Steenbergen <ras at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp


From felix.schueren at hosteurope.de  Wed Mar 17 06:01:53 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Wed, 17 Mar 2010 11:01:53 +0100
Subject: [j-nsp] BGP Flowspec + NSR
In-Reply-To: <20100316234415.GY75640@gerbil.cluepon.net>
References: <20100316234415.GY75640@gerbil.cluepon.net>
Message-ID: <4BA0A891.7060209@hosteurope.de>

Richard A Steenbergen wrote:
> So I noticed something interesting about NSR, apparently it doesn't
> support BGP sessions with flowspec SAFIs enabled. Here is a sh bgp sum
> It just sits and spins forever trying to bring up the BGP sync session
> between the master and backup RE, and turning off inetflow negotiation
> makes things work properly again. This was under 9.5 and 9.6, but I
> haven't seen anything in any release notes about support for it in any
> later software versions. Does anybody know if this is actually on the
> roadmap to get supported, or has flowspec just completely fallen off the
> radar since Pedro and Raszuk left Juniper? :)
> 
confirmed and very, very annoying. I've filed this as a bug over a year 
ago when my MBGP sessions broke in NSR on the backup RE - apparently, it 
was always broken and not working properly when using flowspec, and 
incorrectly displayed everything was fine (it didn't flap the sessions 
then). Somewhere in 9.4 or 9.5 they started dropping the sessions on the 
backup re.

Now we need to run twin loopbacks with two sessions, one for the 
NSR-supported SAFIs, and another just for flowspec - otherwise NSR 
obviously fails for all SAFIs. Plus the logfiles on the backup RE get 
messed up by the constant BGP flapping :(

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen



From sean1207 at gmail.com  Wed Mar 17 09:10:59 2010
From: sean1207 at gmail.com (Sean Clarke)
Date: Wed, 17 Mar 2010 14:10:59 +0100
Subject: [j-nsp] BGP Flowspec + NSR
In-Reply-To: <4BA0A891.7060209@hosteurope.de>
References: <20100316234415.GY75640@gerbil.cluepon.net>
	<4BA0A891.7060209@hosteurope.de>
Message-ID: <4BA0D4E3.9050708@gmail.com>

On 3/17/10 11:01 AM, Felix Schueren wrote:
>>
> confirmed and very, very annoying. I've filed this as a bug over a 
> year ago when my MBGP sessions broke in NSR on the backup RE - 
> apparently, it was always broken and not working properly when using 
> flowspec,

Not really a bug - it's just never been supported.

The best workaround is what you already do .. have 2 BGP sessions, one 
for stuff that's supported, and one for stuff that isn't.
Not ideal, but it's the only way to protect your supported family's

cheers
Sean

From jmadrid2 at gmail.com  Wed Mar 17 12:27:11 2010
From: jmadrid2 at gmail.com (Jose Madrid)
Date: Wed, 17 Mar 2010 12:27:11 -0400
Subject: [j-nsp] Routing-Instance Removal Memory Savings
Message-ID: <867d5e9c1003170927k581d265w7444303af8f61c49@mail.gmail.com>

Hello everyone,

I have a customer who is using a routing-instance per provider on an
M7i.  There is no real reason for this doing this and he only has it
this way due to a previous consultant who decided that would be best.
The box is running hot and sits at 93% memory utilization.  I am
trying to calculate the memory savings from removing the
routing-instance and just incorporating the routes into the main
instance, which is being done by policy anyway.  Any idea how I can
find out a real number savings or a percentage? Here is the output of
a "show route instance".  Any help would be much appreciated.  Thank
you.

> show route instance
Instance             Type
         Primary RIB                                     Active/holddown/hidden
master               forwarding
         inet.0                                          314403/0/0
         mpls.0                                          0/0/0
         inet6.0                                         0/0/0
         l2circuit.0                                     0/0/0
__juniper_private1__ forwarding
         __juniper_private1__.inet.0                     2/0/0
         __juniper_private1__.inet6.0                    4/0/0
__juniper_private2__ forwarding
         __juniper_private2__.inet.0                     0/0/1
isp-a                 virtual-router
         ispa.inet.0                                     310054/0/0
         ispa.iso.0                                      0/0/0
         ispa.inet6.0                                    0/0/0
isp-b               virtual-router
         ispb.inet.0                                   309416/0/0
         ispb.iso.0                                    0/0/0
         ispb.inet6.0                                  0/0/0


-- 
It has to start somewhere, it has to start sometime.  What better
place than here? What better time than now?

From youssefchagh at gmail.com  Wed Mar 17 13:15:56 2010
From: youssefchagh at gmail.com (youssef chagh)
Date: Wed, 17 Mar 2010 17:15:56 +0000
Subject: [j-nsp] L2VPN/L2Circuit and Vlan transparent
Message-ID: <7ce6688e1003171015u3abd5874u7327d9a30b6e4f2@mail.gmail.com>

Hi All,


I have the following architecture :

*Switch*(Extreme)----*M7i*( GE IQ PIC, 9.6R3.8)--------MPLS--------*M20* (GE
IQ PIC, 8.5R1.13)-----*Switch*(EXtreme)


Can I connect 2 sites (cisco switches ) each one to an Extreme with a trunk
ports (many vlans on the ciscos ), and using a L2VPN/L2circuit , so that the
entire path  between the 2 Extreme will be vlan transparent (It's like the
QinQ   )?

Doses the Extreme switchs must support QinQ to achieve that ? or simply
configure the ports toward the ciscos as access ?

Sorry for all those  vendor's names, But I can consider the use of Juniper
Switchs  -)

Many thanks

From sthaug at nethelp.no  Wed Mar 17 13:54:27 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 17 Mar 2010 18:54:27 +0100 (CET)
Subject: [j-nsp] L2VPN/L2Circuit and Vlan transparent
In-Reply-To: <7ce6688e1003171015u3abd5874u7327d9a30b6e4f2@mail.gmail.com>
References: <7ce6688e1003171015u3abd5874u7327d9a30b6e4f2@mail.gmail.com>
Message-ID: <20100317.185427.74653366.sthaug@nethelp.no>

> I have the following architecture :
> 
> *Switch*(Extreme)----*M7i*( GE IQ PIC, 9.6R3.8)--------MPLS--------*M20* (GE
> IQ PIC, 8.5R1.13)-----*Switch*(EXtreme)
> 
> 
> Can I connect 2 sites (cisco switches ) each one to an Extreme with a trunk
> ports (many vlans on the ciscos ), and using a L2VPN/L2circuit , so that the
> entire path  between the 2 Extreme will be vlan transparent (It's like the
> QinQ   )?

Using l2vpn / l2circuit (Martini tunnel) in *port mode* on the Juniper
routers, you can have the circuit between the two Extreme switch ports
be completely transparent.

> Doses the Extreme switchs must support QinQ to achieve that ? or simply
> configure the ports toward the ciscos as access ?

The Extreme switches support QinQ, it is called "vman". It is not enough
to simply configure the ports towards the Cisco switches as access, you
need to explicitly create a vman. You may also want to define the vman
Ethertype (the default is *not* 0x8100).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From mtinka at globaltransit.net  Wed Mar 17 13:25:37 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 18 Mar 2010 01:25:37 +0800
Subject: [j-nsp] L2VPN/L2Circuit and Vlan transparent
In-Reply-To: <7ce6688e1003171015u3abd5874u7327d9a30b6e4f2@mail.gmail.com>
References: <7ce6688e1003171015u3abd5874u7327d9a30b6e4f2@mail.gmail.com>
Message-ID: <201003180125.42265.mtinka@globaltransit.net>

On Thursday 18 March 2010 01:15:56 am youssef chagh wrote:

> Can I connect 2 sites (cisco switches ) each one to an
>  Extreme with a trunk ports (many vlans on the ciscos ),
>  and using a L2VPN/L2circuit , so that the entire path 
>  between the 2 Extreme will be vlan transparent (It's
>  like the QinQ   )?

If you run the pw in port-based mode (which, it appears, you 
would given the PIC's you have on the M7i and M20), you 
should be able to pass Layer 2 control and data frames 
transparently between the Extreme switches, as though they 
were connected back-to-back.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100318/11fd0e94/attachment.bin>

From ras at e-gerbil.net  Wed Mar 17 14:32:40 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Wed, 17 Mar 2010 13:32:40 -0500
Subject: [j-nsp] Routing-Instance Removal Memory Savings
In-Reply-To: <867d5e9c1003170927k581d265w7444303af8f61c49@mail.gmail.com>
References: <867d5e9c1003170927k581d265w7444303af8f61c49@mail.gmail.com>
Message-ID: <20100317183240.GD75640@gerbil.cluepon.net>

On Wed, Mar 17, 2010 at 12:27:11PM -0400, Jose Madrid wrote:
> Hello everyone,
> 
> I have a customer who is using a routing-instance per provider on an
> M7i.  There is no real reason for this doing this and he only has it
> this way due to a previous consultant who decided that would be best.
> The box is running hot and sits at 93% memory utilization.  I am
> trying to calculate the memory savings from removing the
> routing-instance and just incorporating the routes into the main
> instance, which is being done by policy anyway.  Any idea how I can
> find out a real number savings or a percentage? Here is the output of
> a "show route instance".  Any help would be much appreciated.  Thank
> you.

$10 says I can guess who the consultant was. :)

There isn't exactly an easy way to calculate it, but I think you'd be
pretty safe ballparking it at "a couple hundred megs". You'd still have
the same total number of paths and adj ribs, but you'd be eliminating
two complete ribs worth of extra routes... ~200MB sounds pretty
realistic, *maybe* more depending on the number of attributes
(communities, etc) and how your multipath config works out.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From listacct at tulsaconnect.com  Wed Mar 17 14:45:44 2010
From: listacct at tulsaconnect.com (TCIS List Acct)
Date: Wed, 17 Mar 2010 13:45:44 -0500
Subject: [j-nsp] SSG140 - Configure Ethernet ports as switch ports?
Message-ID: <4BA12358.9090404@tulsaconnect.com>

Is it possible in a SSG-140 to configure a few of the Ethernet interfaces as a 
L2 segment/VLAN to emulate a switch, but also have L3 functions (firewall rules, 
MIPs, etc) work for hosts in that L2 segment? (without having the device in 
transparent mode)

TIA.

--Mike


From sfouant at shortestpathfirst.net  Wed Mar 17 15:00:35 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 17 Mar 2010 13:00:35 -0600
Subject: [j-nsp] SSG140 - Configure Ethernet ports as switch ports?
In-Reply-To: <4BA12358.9090404@tulsaconnect.com>
References: <4BA12358.9090404@tulsaconnect.com>
Message-ID: <005101cac604$2170cd50$645267f0$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of TCIS List Acct
> Sent: Wednesday, March 17, 2010 12:46 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] SSG140 - Configure Ethernet ports as switch ports?
> 
> Is it possible in a SSG-140 to configure a few of the Ethernet
> interfaces as a
> L2 segment/VLAN to emulate a switch, but also have L3 functions
> (firewall rules,
> MIPs, etc) work for hosts in that L2 segment? (without having the
> device in
> transparent mode)

Yup, it's called a bridge-group in ScreenOS terminology.  Very easy to set
up.  Simply bind your interfaces to the bridge-group interface, and then you
configure your VLANs, IP assignments, DIPs, MIPs, etc. on the bridge-group
interface.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From toasty at dragondata.com  Wed Mar 17 17:50:54 2010
From: toasty at dragondata.com (Kevin Day)
Date: Wed, 17 Mar 2010 16:50:54 -0500
Subject: [j-nsp] Content filtering/malware protection
Message-ID: <A883ADF1-EEC5-4BF3-B0DA-C94AA1A7C271@dragondata.com>


Does anyone have any experience with Juniper's inline filtering appliances? A client is looking for something to sit between their office LAN and router, to filter out employees clicking on malware, as well as logging what computer visits what sites. They're looking for something plug-and-play, auto updating, etc. Does anyone have experience with Juniper's IDP line? The online documentation is pretty light. Does it actually prevent access to the bad stuff, or just log that it happened? What's their datasource for filtering?

-- Kevin



From ObrienH at missouri.edu  Thu Mar 18 09:44:29 2010
From: ObrienH at missouri.edu (OBrien, Will)
Date: Thu, 18 Mar 2010 08:44:29 -0500
Subject: [j-nsp] SSG140 - Configure Ethernet ports as switch ports?
In-Reply-To: <4BA12358.9090404@tulsaconnect.com>
References: <4BA12358.9090404@tulsaconnect.com>
Message-ID: <620B451C-A086-42D3-ABA0-94C3B090FC6B@missouri.edu>

I don't have any 140s but usually you can create a bridge group and  
put the interfaces in it.

Will O'Brien

On Mar 17, 2010, at 12:49 PM, "TCIS List Acct" <listacct at tulsaconnect.com 
 > wrote:

> Is it possible in a SSG-140 to configure a few of the Ethernet  
> interfaces as a
> L2 segment/VLAN to emulate a switch, but also have L3 functions  
> (firewall rules,
> MIPs, etc) work for hosts in that L2 segment? (without having the  
> device in
> transparent mode)
>
> TIA.
>
> --Mike
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From jmadrid2 at gmail.com  Thu Mar 18 11:24:01 2010
From: jmadrid2 at gmail.com (Jose Madrid)
Date: Thu, 18 Mar 2010 11:24:01 -0400
Subject: [j-nsp] Routing-Instance Removal Memory Savings
In-Reply-To: <20100317183240.GD75640@gerbil.cluepon.net>
References: <867d5e9c1003170927k581d265w7444303af8f61c49@mail.gmail.com>
	<20100317183240.GD75640@gerbil.cluepon.net>
Message-ID: <867d5e9c1003180824t59c5f9dh810642ccf00c9525@mail.gmail.com>

Thank you to everyone on this list for being so helpful.

On Wed, Mar 17, 2010 at 2:32 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
> On Wed, Mar 17, 2010 at 12:27:11PM -0400, Jose Madrid wrote:
>> Hello everyone,
>>
>> I have a customer who is using a routing-instance per provider on an
>> M7i. ?There is no real reason for this doing this and he only has it
>> this way due to a previous consultant who decided that would be best.
>> The box is running hot and sits at 93% memory utilization. ?I am
>> trying to calculate the memory savings from removing the
>> routing-instance and just incorporating the routes into the main
>> instance, which is being done by policy anyway. ?Any idea how I can
>> find out a real number savings or a percentage? Here is the output of
>> a "show route instance". ?Any help would be much appreciated. ?Thank
>> you.
>
> $10 says I can guess who the consultant was. :)
>
> There isn't exactly an easy way to calculate it, but I think you'd be
> pretty safe ballparking it at "a couple hundred megs". You'd still have
> the same total number of paths and adj ribs, but you'd be eliminating
> two complete ribs worth of extra routes... ~200MB sounds pretty
> realistic, *maybe* more depending on the number of attributes
> (communities, etc) and how your multipath config works out.
>
> --
> Richard A Steenbergen <ras at e-gerbil.net> ? ? ? http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>



-- 
It has to start somewhere, it has to start sometime.  What better
place than here? What better time than now?


From adisubrata at gmail.com  Thu Mar 18 12:15:45 2010
From: adisubrata at gmail.com (Nugroho WH Adisubrata)
Date: Thu, 18 Mar 2010 23:15:45 +0700
Subject: [j-nsp] VLAN table of MX series (SNMP)
Message-ID: <9748e271003180915v3afa14a3g17b2ed1ceaecfcd4@mail.gmail.com>

Hi All,

I have a question regarding SMMP polling to get VLAN table on MX.

Is that possible to get the list of VLAN on MX?

Personally I'm not sure if this is possible since I've looking from juniper
website and found nothing.
I found SNMP oid (jnxVlanTable) is only available in EX series, thus need
some helps if anyone has similar experience.
For Cisco, I just simply using #
vtpVlanTable .1.3.6.1.4.1.9.9.46.1.3.1.1.2.1

http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-network-mgm/snmp-std-mibs-junos-nm.html
.

Appreciate for advice.

Regards,
Nugroho WH Adisubrata

From hans.kristian.eiken at gmail.com  Thu Mar 18 14:14:36 2010
From: hans.kristian.eiken at gmail.com (Hans Kristian Eiken)
Date: Thu, 18 Mar 2010 19:14:36 +0100
Subject: [j-nsp] Logging default deny traffic on SSG-550?
In-Reply-To: <4B9AA05D.2080806@tulsaconnect.com>
References: <4B9AA05D.2080806@tulsaconnect.com>
Message-ID: <f3a806561003181114l6ba9c8a2meb9284af31e4941f@mail.gmail.com>

2010/3/12 TCIS List Acct <listacct at tulsaconnect.com>

> We've got a pair of Juniper SSG-550's in HA mode running Screen OS
> 6.1.0r4.0. For the life of me I can't figure out how to enable logging for
> denied/blocked traffic for the implicit default-deny rule.  I've followed
> the instructions found in the Screen OS Cookbook with no results.
>
> Anyone have any pointers?
>

You can find this in the ScreenOS cli guide, at least in ScreenOS 6.2. The
command is "set flow log-dropped-packet". The output can be show using "get
log flow-deny", but a test shows me that it also ends up in the traffic log
as policy id 32000 (ns-5gt).

Be aware of the possible impact on the cpu on logging all denied sessions.

--
Hans Kristian Eiken

From sthaug at nethelp.no  Thu Mar 18 15:26:20 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 18 Mar 2010 20:26:20 +0100 (CET)
Subject: [j-nsp] M7i DHCP Relay
In-Reply-To: <4B3CD00C.5040706@sofnet.com>
References: <4B3CD00C.5040706@sofnet.com>
Message-ID: <20100318.202620.71112103.sthaug@nethelp.no>

> I am trying to get DHCP relay working using either [forwarding-options 
> dhcp-relay] or [forwarding-options helpers bootp] on an M7i w/IQ2 
> ethernet running 9.6R1.13.  I have several double-tagged and single 
> tagged vlans on interface ge-0/0/3 and am wanting to do relay on several 
> double-tagged units that are unnumbered to lo0.0.  The bootp helper 
> doesn't seem to forward/relay any requests if the interface is 
> unnumbered - it works fine if the interface has an IP.  DHCP-relay seems 
> to effect all of the units on ge-0/0/3 even though I only specify a 
> certain unit to operate on.

Yes. This is a serious bug which basically makes M/MX routers unusable
if you want to have DHCP relay agent functionality *on the router* at
the same time as you have other DHCP unicast traffic (for instance
generated by a Cisco CPE with "ip helper", or a client sending its
renewal request directly to the DHCP server) passing *through* the
router.

I find it absolutely incredible that Juniper with its ERX history has
managed to botch the M/MX DHCP functionality this badly.

Verified with 9.5R4.3 and 10.0R2.10.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From phil.pierotti at gmail.com  Fri Mar 19 01:49:27 2010
From: phil.pierotti at gmail.com (Phil Pierotti)
Date: Fri, 19 Mar 2010 16:49:27 +1100
Subject: [j-nsp] MX-80 rumors and heresay - any comments?
Message-ID: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>

Hi All,

Given the size/shape/ports of the soon-to-be-delivered MX-80, it's fairly
obvious that it's targeted at the 7206-G2/ASR1004/SmartEdge-400 size of the
market.

Has anyone heard any rumors (or otherwise) of there being L2TP
LAC/LNS/Tunnel-Switching functionality available on this platform (ie "in
real JunOS").

Should such a beast finally take shape it would certainly be a swift kick
where it hurts most for Cisco, Redback and friends.

Thanks,
Phil P

From jgoodwin at studio442.com.au  Fri Mar 19 01:57:25 2010
From: jgoodwin at studio442.com.au (Julien Goodwin)
Date: Fri, 19 Mar 2010 16:57:25 +1100
Subject: [j-nsp] MX-80 rumors and heresay - any comments?
In-Reply-To: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>
References: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>
Message-ID: <4BA31245.9060104@studio442.com.au>

On 19/03/10 16:49, Phil Pierotti wrote:
> Given the size/shape/ports of the soon-to-be-delivered MX-80, it's fairly
> obvious that it's targeted at the 7206-G2/ASR1004/SmartEdge-400 size of the
> market.
> 
> Has anyone heard any rumors (or otherwise) of there being L2TP
> LAC/LNS/Tunnel-Switching functionality available on this platform (ie "in
> real JunOS").

So I've yet to see a definitive statement, but I was looking at this
last night.

The MX MPC data sheet indicates L2TP support:
http://www.juniper.net/us/en/local/pdf/datasheets/1000294-en.pdf

"Inline services include...
                   Layer 2 Tunneling Protocol (L2TP), L2TP access
concentrator (LAC), and L2TP network server (LNS)."
(Page 2, "Junos Trio Chipset")

I have not seen a statement one way or the other on the MX80.

I too would love such a statement, as a potential project of mine is
contingent on that support.

Julien

-- 
Julien Goodwin
Studio442
"Blue Sky Solutioneering"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100319/574bf058/attachment.bin>

From skovlund at gmail.com  Fri Mar 19 04:55:52 2010
From: skovlund at gmail.com (=?ISO-8859-1?Q?Bj=F8rn_Skovlund?=)
Date: Fri, 19 Mar 2010 09:55:52 +0100
Subject: [j-nsp] MX-80 rumors and heresay - any comments?
In-Reply-To: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>
References: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>
Message-ID: <ba3f242f1003190155j5031d22fwf59528f9c66b9884@mail.gmail.com>

Hi,

I would be surprised if your mentioned L2TP functions isn't available
in the MX-80, if not at launch, then shortly after.

It seems clear that Juniper is currently focusing hard on making the
MX platform a subscriber termination point. We're not using any L2TP
features, but do use dynamic-profiling, VLAN auto-creation and RADIUS
authentication of subscribers on the MX platform, where we're looking
very much forward to the MX-80 due to size, price and the 64K
subscribers on the Trio chipset.

I will expect the box to be very license-based, with a low initial
price, but licensing needs for anything besides routing/switching
pretty much. I guess it makes sense, considering what possibilities
this small box brings and the broad range of markets it's advantageous
to.

I can't wait to order these :)

Cheers, Bj?rn


From mtinka at globaltransit.net  Fri Mar 19 11:45:09 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 19 Mar 2010 23:45:09 +0800
Subject: [j-nsp] MX-80 rumors and heresay - any comments?
In-Reply-To: <ba3f242f1003190155j5031d22fwf59528f9c66b9884@mail.gmail.com>
References: <5574b2241003182249m6d8ecf91wb129c651c66ee0ac@mail.gmail.com>
	<ba3f242f1003190155j5031d22fwf59528f9c66b9884@mail.gmail.com>
Message-ID: <201003192345.20047.mtinka@globaltransit.net>

On Friday 19 March 2010 04:55:52 pm Bj?rn Skovlund wrote:

> I will expect the box to be very license-based, with a
>  low initial price, but licensing needs for anything
>  besides routing/switching pretty much. I guess it makes
>  sense, considering what possibilities this small box
>  brings and the broad range of markets it's advantageous
>  to.

As a peering and high-end edge aggregation router, this box 
is pretty sweet.

But I think Juniper still need something else for Access in 
the Metro. The MX80, as small as it is, is still too large 
for this role (well, at least price-wise, anyway).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100319/bf2b2995/attachment.bin>

From matthias at z.commy.de  Fri Mar 19 19:08:42 2010
From: matthias at z.commy.de (=?windows-1252?Q?Matthias_Gelbhardt?=)
Date: Sat, 20 Mar 2010 00:08:42 +0100
Subject: [j-nsp] internal traffic forwarding between instances
Message-ID: <vmime.4ba403fa.13f0.2c3d0a935b8138e5@zarafa.gw.ms>


Hi!

?

I try to accomplish the following:

?

I have two J-Series routers in chassis cluster mode. I have two reth-interfaces, reth1 and reth2. The interfaces are connected to a switch, so I have four cables to one VLAN. I have one routing-instace instance1, which is configured, together with inet.0 running OSPF.

?

Behind the switch is a firewall, which is also running OSPF. I have configured rib-groups, so I have copied the routing tables from inet.0 to instance1.inet.0 and instance1.inet.0 to inet.0. I see all of the routes learned from OSPF. I have also copied a static default route into instance1.

?

Now I am killing all connections but one, which is configured to the instance1. In the routing table I see, that all the routes are destined to reth2, which is in instance1. But there seems to be no traffic forwarding. Am I lacking something? Do I have to configure something else to enable that? I use instance-type virtual-router. The forwarding has to be made internal without a physical interface. Is that possible?

?

Regards,

?

Matthias

From sfouant at shortestpathfirst.net  Fri Mar 19 19:54:38 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Fri, 19 Mar 2010 23:54:38 +0000
Subject: [j-nsp] internal traffic forwarding between instances
Message-ID: <1978101249-1269042900-cardhu_decombobulator_blackberry.rim.net-1121761150-@bda294.bisx.prod.on.blackberry>

What happens if you leak interface routes between instance1 and inet.0?

Stefan Fouant
------Original Message------
From: Matthias Gelbhardt
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp at puck.nether.net
ReplyTo: matthias at commy.de
Subject: [j-nsp] internal traffic forwarding between instances
Sent: Mar 19, 2010 5:08 PM


Hi!

?

I try to accomplish the following:

?

I have two J-Series routers in chassis cluster mode. I have two reth-interfaces, reth1 and reth2. The interfaces are connected to a switch, so I have four cables to one VLAN. I have one routing-instace instance1, which is configured, together with inet.0 running OSPF.

?

Behind the switch is a firewall, which is also running OSPF. I have configured rib-groups, so I have copied the routing tables from inet.0 to instance1.inet.0 and instance1.inet.0 to inet.0. I see all of the routes learned from OSPF. I have also copied a static default route into instance1.

?

Now I am killing all connections but one, which is configured to the instance1. In the routing table I see, that all the routes are destined to reth2, which is in instance1. But there seems to be no traffic forwarding. Am I lacking something? Do I have to configure something else to enable that? I use instance-type virtual-router. The forwarding has to be made internal without a physical interface. Is that possible?

?

Regards,

?

Matthias
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent from my Verizon Wireless BlackBerry


From matthias at commy.de  Fri Mar 19 20:10:55 2010
From: matthias at commy.de (Matthias Gelbhardt)
Date: Sat, 20 Mar 2010 01:10:55 +0100
Subject: [j-nsp] internal traffic forwarding between instances
In-Reply-To: <1978101249-1269042900-cardhu_decombobulator_blackberry.rim.net-1121761150-@bda294.bisx.prod.on.blackberry>
References: <1978101249-1269042900-cardhu_decombobulator_blackberry.rim.net-1121761150-@bda294.bisx.prod.on.blackberry>
Message-ID: <4BA4128F.1010509@commy.de>

Hi!

Seems to be working now. Thanks! I knew it was something small.

Matthias

Am 20.03.10 00:54, schrieb Stefan Fouant:
> What happens if you leak interface routes between instance1 and inet.0?
>
> Stefan Fouant
> ------Original Message------
> From: Matthias Gelbhardt
> Sender: juniper-nsp-bounces at puck.nether.net
> To: juniper-nsp at puck.nether.net
> ReplyTo: matthias at commy.de
> Subject: [j-nsp] internal traffic forwarding between instances
> Sent: Mar 19, 2010 5:08 PM
>
>
> Hi!
>
>   
>
> I try to accomplish the following:
>
>   
>
> I have two J-Series routers in chassis cluster mode. I have two reth-interfaces, reth1 and reth2. The interfaces are connected to a switch, so I have four cables to one VLAN. I have one routing-instace instance1, which is configured, together with inet.0 running OSPF.
>
>   
>
> Behind the switch is a firewall, which is also running OSPF. I have configured rib-groups, so I have copied the routing tables from inet.0 to instance1.inet.0 and instance1.inet.0 to inet.0. I see all of the routes learned from OSPF. I have also copied a static default route into instance1.
>
>   
>
> Now I am killing all connections but one, which is configured to the instance1. In the routing table I see, that all the routes are destined to reth2, which is in instance1. But there seems to be no traffic forwarding. Am I lacking something? Do I have to configure something else to enable that? I use instance-type virtual-router. The forwarding has to be made internal without a physical interface. Is that possible?
>
>   
>
> Regards,
>
>   
>
> Matthias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry
>    


From sfouant at shortestpathfirst.net  Fri Mar 19 20:41:50 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 20 Mar 2010 00:41:50 +0000
Subject: [j-nsp] internal traffic forwarding between instances
Message-ID: <2129190474-1269045731-cardhu_decombobulator_blackberry.rim.net-1995923037-@bda294.bisx.prod.on.blackberry>

No worries mate.  This is probably one of the most common things I see on a regular basis when dealing with routing instances.  Protocol information is leaked, but without leaking interfaces the physical next-hops for those routes can't be recursed.

Stefan Fouant
------Original Message------
From: Matthias Gelbhardt
To: sfouant at shortestpathfirst.net
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] internal traffic forwarding between instances
Sent: Mar 19, 2010 6:10 PM

Hi!

Seems to be working now. Thanks! I knew it was something small.

Matthias

Am 20.03.10 00:54, schrieb Stefan Fouant:
> What happens if you leak interface routes between instance1 and inet.0?
>
> Stefan Fouant
> ------Original Message------
> From: Matthias Gelbhardt
> Sender: juniper-nsp-bounces at puck.nether.net
> To: juniper-nsp at puck.nether.net
> ReplyTo: matthias at commy.de
> Subject: [j-nsp] internal traffic forwarding between instances
> Sent: Mar 19, 2010 5:08 PM
>
>
> Hi!
>
>   
>
> I try to accomplish the following:
>
>   
>
> I have two J-Series routers in chassis cluster mode. I have two reth-interfaces, reth1 and reth2. The interfaces are connected to a switch, so I have four cables to one VLAN. I have one routing-instace instance1, which is configured, together with inet.0 running OSPF.
>
>   
>
> Behind the switch is a firewall, which is also running OSPF. I have configured rib-groups, so I have copied the routing tables from inet.0 to instance1.inet.0 and instance1.inet.0 to inet.0. I see all of the routes learned from OSPF. I have also copied a static default route into instance1.
>
>   
>
> Now I am killing all connections but one, which is configured to the instance1. In the routing table I see, that all the routes are destined to reth2, which is in instance1. But there seems to be no traffic forwarding. Am I lacking something? Do I have to configure something else to enable that? I use instance-type virtual-router. The forwarding has to be made internal without a physical interface. Is that possible?
>
>   
>
> Regards,
>
>   
>
> Matthias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry
>    



Sent from my Verizon Wireless BlackBerry


From fahad.khan at gmail.com  Sat Mar 20 08:18:41 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Sat, 20 Mar 2010 17:18:41 +0500
Subject: [j-nsp] logical routers on M10i
Message-ID: <d0cc41791003200518x2ca7e676k29f6b000afa86c10@mail.gmail.com>

Hi Experts,

I need to know what do i require for running logical routers on M10i. I have
AS II PIC. I have configured lt interfaces, but i cant see them in "sh
interfaces terse".

please let me know about any thing else i need. Do i need to configure any
thing on PIC level???


waiting for  urgent response

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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

From fahad.khan at gmail.com  Sat Mar 20 09:45:05 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Sat, 20 Mar 2010 18:45:05 +0500
Subject: [j-nsp] Content filtering/malware protection
In-Reply-To: <A883ADF1-EEC5-4BF3-B0DA-C94AA1A7C271@dragondata.com>
References: <A883ADF1-EEC5-4BF3-B0DA-C94AA1A7C271@dragondata.com>
Message-ID: <d0cc41791003200645y54cac039jc1db225ef23fc0e6@mail.gmail.com>

Yeah IDP is great tool. You will have to manage it via NSM. The attack
database is huge. This device can run in both promiscuous  and inline mode
aslo supports HA

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Thu, Mar 18, 2010 at 2:50 AM, Kevin Day <toasty at dragondata.com> wrote:

>
> Does anyone have any experience with Juniper's inline filtering appliances?
> A client is looking for something to sit between their office LAN and
> router, to filter out employees clicking on malware, as well as logging what
> computer visits what sites. They're looking for something plug-and-play,
> auto updating, etc. Does anyone have experience with Juniper's IDP line? The
> online documentation is pretty light. Does it actually prevent access to the
> bad stuff, or just log that it happened? What's their datasource for
> filtering?
>
> -- Kevin
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From fahad.khan at gmail.com  Sat Mar 20 09:50:58 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Sat, 20 Mar 2010 18:50:58 +0500
Subject: [j-nsp] EX 8200 deployment
Message-ID: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>

Hi Folks,

Please share your experiences regarding the deployment of EX 8200, I need to
deploy two chassis in VRRP. Please let shed some light on the following
point

- Any trick in power/power requirements??
- stability
- best design( like Virtual routers are needed or not)
- possible caveats
- Best junos version

Add any trick or issue which you have found out?

waiting for ur inputs

thanks and best regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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

From ras at e-gerbil.net  Sat Mar 20 11:03:13 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 20 Mar 2010 10:03:13 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
Message-ID: <20100320150313.GT75640@gerbil.cluepon.net>

On Sat, Mar 20, 2010 at 06:50:58PM +0500, Fahad Khan wrote:
> Hi Folks,
> 
> Please share your experiences regarding the deployment of EX 8200, I need to
> deploy two chassis in VRRP. Please let shed some light on the following
> point
> 
> - Any trick in power/power requirements??
> - stability
> - best design( like Virtual routers are needed or not)
> - possible caveats
> - Best junos version
> 
> Add any trick or issue which you have found out?

We just deployed our first EX8208 a few days ago, running 10.1R1. 
Gotchas so far:

* Obviously this is a very different architecture from Juniper's normal 
boxes, so be prepared for vlan space being shared across the entire box, 
not a per-interface basis.

* In a move straight out of Foundry's playbook of how to fail at making
a useable product, EX has no packet counters (cli or snmp) available for
L3 vlan interfaces. It DOES have working counters if you do traditional 
Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123 
vlan-id 123), but it does NOT work if you have to do RVI style (vlan 
blah l3-interface vlan.123 and then put vlan blah in an ethernet 
switching interface). Subinterface style is my preference anyways, so as 
long as you only ever use vlans on point-to-point links this isn't a 
problem, but the instant you need to put a VLAN on more than one port 
you no longer get packet counters.

* Related to the issue above, you can't mix "subinterface style" and 
"RVI style" vlans on the same trunk port. The instant you need to do 
anything more than classic subinterface style vlans, you have to convert 
everything on the trunk to vlan/rvi style. For example, where I might 
otherwise be able to get away with doing interface xe-1/0/0 unit 123 
vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that 
same interface I now have to convert unit 123 to RVI style. One possible 
workaround I have yet to test is doing a CCC instead of a vlan, to keep 
the subinterface style. This would only work with 2-port member vlans 
though, and I have yet to test the implications for mixing tagged and 
untagged ports on EX, so this may not actually work for anyone at all. 

* There is a hardcoded default maximum data memory per process of 512MB
on the EX8200 series, which isn't enough memory for rpd to run any kind
of complex BGP configuration. Juniper says they tested it to 3.2 million
paths and it only used ~400MB, but I guess they found some artificially
low test scenario (I still wonder how they did this, even with no
communities and no as-path attributes it's only a ~10% memory
difference), and they didn't bother to ask the rpd developers how much
memory usage to expect, because real world usage is obviously FAR
higher. In our testing rpd coredumped at about 900k BGP paths, which is
probably a bad thing if you actually want to route on these boxes.
Juniper is working on this issue, but as a temporary workaround, edit
your /boot/loader.conf file as root, replace the kern.maxdsiz=512M with
something more sensible like 1536M, and reboot. This will of course be
blown away every time you upgrade JUNOS, so it helps to have dual REs so
you can pre-stage things. :)

* Firewall filters are still a bit of a mess. You can't count or log
anything, you can't use policers on either control plane or egress
filters (heck you can't even commit a firewall filter with a policer in
it if applied as an output filter), you can't match frags, etc, etc.
Basically if you're coming from another Juniper router, be prepared to
completely redesign all of your firewall filters across the board. For
example, you can't currently do a match like "from port 179" on EX, you
have to do "from source-port 179" and "from destination-port 179", which
means splitting what was previously a single term into two terms. This
is expected to get better with future sw, but my feeling is probably in
small increments over the next year+ or so.

* I don't know who thought 2GB of storage on an RE was sufficient, but 
it isn't. The best idea I've come up with so far is to grab some small 
USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and 
deploy them on every RE so you have a little bit of working space.

Other than that we haven't found any fundamental flaws in the box yet
(though that may change by the time MPLS features get implemented :P). 
Plenty of bugs to be sure, DOM isn't working right on any of our
interfaces, pfe statistics don't work right, monitor interface on vlans
isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried
to speak BGP flowspec to the box, etc, but we have cases open on all of
the above. IMHO it definitely has the potential to be a very good box in
the long term, but whoever didn't think to put vlan counters into the
hardware really screwed the pooch something fierce. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sfouant at shortestpathfirst.net  Sat Mar 20 14:52:06 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 20 Mar 2010 18:52:06 +0000
Subject: [j-nsp] logical routers on M10i
Message-ID: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>

Do you mean you are trying to configure a logical-tunnel interface between the logical routers?

Stefan Fouant
------Original Message------
From: Fahad Khan
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] logical routers on M10i
Sent: Mar 20, 2010 8:18 AM

Hi Experts,

I need to know what do i require for running logical routers on M10i. I have
AS II PIC. I have configured lt interfaces, but i cant see them in "sh
interfaces terse".

please let me know about any thing else i need. Do i need to configure any
thing on PIC level???


waiting for  urgent response

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent from my Verizon Wireless BlackBerry


From fahad.khan at gmail.com  Sat Mar 20 16:17:51 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Sun, 21 Mar 2010 01:17:51 +0500
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
References: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
Message-ID: <d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>

yes stefan,

but now i got it, i need tunnel PIC , but not AS PIC II

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Sat, Mar 20, 2010 at 11:52 PM, Stefan Fouant <
sfouant at shortestpathfirst.net> wrote:

> Do you mean you are trying to configure a logical-tunnel interface between
> the logical routers?
>
> Stefan Fouant
> ------Original Message------
> From: Fahad Khan
> Sender: juniper-nsp-bounces at puck.nether.net
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] logical routers on M10i
> Sent: Mar 20, 2010 8:18 AM
>
> Hi Experts,
>
> I need to know what do i require for running logical routers on M10i. I
> have
> AS II PIC. I have configured lt interfaces, but i cant see them in "sh
> interfaces terse".
>
> please let me know about any thing else i need. Do i need to configure any
> thing on PIC level???
>
>
> waiting for  urgent response
>
> regards,
>
> Muhammad Fahad Khan
> JNCIP - M/T # 834
> IT Specialist
> Global Technology Services, IBM
> fahad at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry

From sthaug at nethelp.no  Sat Mar 20 16:26:51 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sat, 20 Mar 2010 21:26:51 +0100 (CET)
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>
References: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
	<d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>
Message-ID: <20100320.212651.74703019.sthaug@nethelp.no>

> but now i got it, i need tunnel PIC , but not AS PIC II

The AS PIC should be able to do anything the tunnel PIC can do (and 
more).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From fahad.khan at gmail.com  Sat Mar 20 16:41:31 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Sun, 21 Mar 2010 01:41:31 +0500
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <20100320.212651.74703019.sthaug@nethelp.no>
References: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
	<d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>
	<20100320.212651.74703019.sthaug@nethelp.no>
Message-ID: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>

But i can not see any lt interfaces in show interfaces terse ?? why??

regards,
Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Sun, Mar 21, 2010 at 1:26 AM, <sthaug at nethelp.no> wrote:

> > but now i got it, i need tunnel PIC , but not AS PIC II
>
> The AS PIC should be able to do anything the tunnel PIC can do (and
> more).
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>

From chrisccnpspam2 at gmail.com  Sat Mar 20 17:29:40 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sat, 20 Mar 2010 17:29:40 -0400
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100320150313.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
Message-ID: <419dba611003201429i1c0e4d76nc593f261d2cc2905@mail.gmail.com>

Richard,

I agree with you with the EX platform.. It's really buggy. I personally
think that Juniper is moving too slow bringing new features and bug fixes to
the platform.. We're deploying the new Cisco Nexus platforms in our data
centers at this point. Cisco is moving at light speed with these platforms,
while Juniper is crawling to bring their aging boxes into the lime light
left by the Cisco Cat6500 days.

On another note. I know you're upset about the limit on the routing that the
EX series can do, but a better question is why are you using this box for
that high end routing solution? In my opinion, the EX's 8200's

On Sat, Mar 20, 2010 at 11:03 AM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Sat, Mar 20, 2010 at 06:50:58PM +0500, Fahad Khan wrote:
> > Hi Folks,
> >
> > Please share your experiences regarding the deployment of EX 8200, I need
> to
> > deploy two chassis in VRRP. Please let shed some light on the following
> > point
> >
> > - Any trick in power/power requirements??
> > - stability
> > - best design( like Virtual routers are needed or not)
> > - possible caveats
> > - Best junos version
> >
> > Add any trick or issue which you have found out?
>
> We just deployed our first EX8208 a few days ago, running 10.1R1.
> Gotchas so far:
>
> * Obviously this is a very different architecture from Juniper's normal
> boxes, so be prepared for vlan space being shared across the entire box,
> not a per-interface basis.
>
> * In a move straight out of Foundry's playbook of how to fail at making
> a useable product, EX has no packet counters (cli or snmp) available for
> L3 vlan interfaces. It DOES have working counters if you do traditional
> Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123
> vlan-id 123), but it does NOT work if you have to do RVI style (vlan
> blah l3-interface vlan.123 and then put vlan blah in an ethernet
> switching interface). Subinterface style is my preference anyways, so as
> long as you only ever use vlans on point-to-point links this isn't a
> problem, but the instant you need to put a VLAN on more than one port
> you no longer get packet counters.
>
> * Related to the issue above, you can't mix "subinterface style" and
> "RVI style" vlans on the same trunk port. The instant you need to do
> anything more than classic subinterface style vlans, you have to convert
> everything on the trunk to vlan/rvi style. For example, where I might
> otherwise be able to get away with doing interface xe-1/0/0 unit 123
> vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that
> same interface I now have to convert unit 123 to RVI style. One possible
> workaround I have yet to test is doing a CCC instead of a vlan, to keep
> the subinterface style. This would only work with 2-port member vlans
> though, and I have yet to test the implications for mixing tagged and
> untagged ports on EX, so this may not actually work for anyone at all.
>
> * There is a hardcoded default maximum data memory per process of 512MB
> on the EX8200 series, which isn't enough memory for rpd to run any kind
> of complex BGP configuration. Juniper says they tested it to 3.2 million
> paths and it only used ~400MB, but I guess they found some artificially
> low test scenario (I still wonder how they did this, even with no
> communities and no as-path attributes it's only a ~10% memory
> difference), and they didn't bother to ask the rpd developers how much
> memory usage to expect, because real world usage is obviously FAR
> higher. In our testing rpd coredumped at about 900k BGP paths, which is
> probably a bad thing if you actually want to route on these boxes.
> Juniper is working on this issue, but as a temporary workaround, edit
> your /boot/loader.conf file as root, replace the kern.maxdsiz=512M with
> something more sensible like 1536M, and reboot. This will of course be
> blown away every time you upgrade JUNOS, so it helps to have dual REs so
> you can pre-stage things. :)
>
> * Firewall filters are still a bit of a mess. You can't count or log
> anything, you can't use policers on either control plane or egress
> filters (heck you can't even commit a firewall filter with a policer in
> it if applied as an output filter), you can't match frags, etc, etc.
> Basically if you're coming from another Juniper router, be prepared to
> completely redesign all of your firewall filters across the board. For
> example, you can't currently do a match like "from port 179" on EX, you
> have to do "from source-port 179" and "from destination-port 179", which
> means splitting what was previously a single term into two terms. This
> is expected to get better with future sw, but my feeling is probably in
> small increments over the next year+ or so.
>
> * I don't know who thought 2GB of storage on an RE was sufficient, but
> it isn't. The best idea I've come up with so far is to grab some small
> USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and
> deploy them on every RE so you have a little bit of working space.
>
> Other than that we haven't found any fundamental flaws in the box yet
> (though that may change by the time MPLS features get implemented :P).
> Plenty of bugs to be sure, DOM isn't working right on any of our
> interfaces, pfe statistics don't work right, monitor interface on vlans
> isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried
> to speak BGP flowspec to the box, etc, but we have cases open on all of
> the above. IMHO it definitely has the potential to be a very good box in
> the long term, but whoever didn't think to put vlan counters into the
> hardware really screwed the pooch something fierce. :)
>
> --
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From chrisccnpspam2 at gmail.com  Sat Mar 20 17:31:36 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sat, 20 Mar 2010 17:31:36 -0400
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100320150313.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
Message-ID: <419dba611003201431s20a5e1f7lc9ef8ec4967a8cf9@mail.gmail.com>

Richard,

I agree with you with the EX platform.. It's really buggy. I personally
think that Juniper is moving too slow bringing new features and bug fixes to
the platform.. We're deploying the new Cisco Nexus platforms in our data
centers at this point. Cisco is moving at light speed with these platforms,
while Juniper is crawling to bring their aging boxes into the lime light
left by the Cisco Cat6500 days.

On another note. I know you're upset about the limit on the routing that the
EX series can do, but a better question is why are you using this box for
that high end routing solution? In my opinion, the EX's 8200's are a switch
built for the data center, they shouldn't require much more than a default
route and/or a few hundred routes to your core.

Discussion?

On Sat, Mar 20, 2010 at 11:03 AM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Sat, Mar 20, 2010 at 06:50:58PM +0500, Fahad Khan wrote:
> > Hi Folks,
> >
> > Please share your experiences regarding the deployment of EX 8200, I need
> to
> > deploy two chassis in VRRP. Please let shed some light on the following
> > point
> >
> > - Any trick in power/power requirements??
> > - stability
> > - best design( like Virtual routers are needed or not)
> > - possible caveats
> > - Best junos version
> >
> > Add any trick or issue which you have found out?
>
> We just deployed our first EX8208 a few days ago, running 10.1R1.
> Gotchas so far:
>
> * Obviously this is a very different architecture from Juniper's normal
> boxes, so be prepared for vlan space being shared across the entire box,
> not a per-interface basis.
>
> * In a move straight out of Foundry's playbook of how to fail at making
> a useable product, EX has no packet counters (cli or snmp) available for
> L3 vlan interfaces. It DOES have working counters if you do traditional
> Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123
> vlan-id 123), but it does NOT work if you have to do RVI style (vlan
> blah l3-interface vlan.123 and then put vlan blah in an ethernet
> switching interface). Subinterface style is my preference anyways, so as
> long as you only ever use vlans on point-to-point links this isn't a
> problem, but the instant you need to put a VLAN on more than one port
> you no longer get packet counters.
>
> * Related to the issue above, you can't mix "subinterface style" and
> "RVI style" vlans on the same trunk port. The instant you need to do
> anything more than classic subinterface style vlans, you have to convert
> everything on the trunk to vlan/rvi style. For example, where I might
> otherwise be able to get away with doing interface xe-1/0/0 unit 123
> vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that
> same interface I now have to convert unit 123 to RVI style. One possible
> workaround I have yet to test is doing a CCC instead of a vlan, to keep
> the subinterface style. This would only work with 2-port member vlans
> though, and I have yet to test the implications for mixing tagged and
> untagged ports on EX, so this may not actually work for anyone at all.
>
> * There is a hardcoded default maximum data memory per process of 512MB
> on the EX8200 series, which isn't enough memory for rpd to run any kind
> of complex BGP configuration. Juniper says they tested it to 3.2 million
> paths and it only used ~400MB, but I guess they found some artificially
> low test scenario (I still wonder how they did this, even with no
> communities and no as-path attributes it's only a ~10% memory
> difference), and they didn't bother to ask the rpd developers how much
> memory usage to expect, because real world usage is obviously FAR
> higher. In our testing rpd coredumped at about 900k BGP paths, which is
> probably a bad thing if you actually want to route on these boxes.
> Juniper is working on this issue, but as a temporary workaround, edit
> your /boot/loader.conf file as root, replace the kern.maxdsiz=512M with
> something more sensible like 1536M, and reboot. This will of course be
> blown away every time you upgrade JUNOS, so it helps to have dual REs so
> you can pre-stage things. :)
>
> * Firewall filters are still a bit of a mess. You can't count or log
> anything, you can't use policers on either control plane or egress
> filters (heck you can't even commit a firewall filter with a policer in
> it if applied as an output filter), you can't match frags, etc, etc.
> Basically if you're coming from another Juniper router, be prepared to
> completely redesign all of your firewall filters across the board. For
> example, you can't currently do a match like "from port 179" on EX, you
> have to do "from source-port 179" and "from destination-port 179", which
> means splitting what was previously a single term into two terms. This
> is expected to get better with future sw, but my feeling is probably in
> small increments over the next year+ or so.
>
> * I don't know who thought 2GB of storage on an RE was sufficient, but
> it isn't. The best idea I've come up with so far is to grab some small
> USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and
> deploy them on every RE so you have a little bit of working space.
>
> Other than that we haven't found any fundamental flaws in the box yet
> (though that may change by the time MPLS features get implemented :P).
> Plenty of bugs to be sure, DOM isn't working right on any of our
> interfaces, pfe statistics don't work right, monitor interface on vlans
> isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried
> to speak BGP flowspec to the box, etc, but we have cases open on all of
> the above. IMHO it definitely has the potential to be a very good box in
> the long term, but whoever didn't think to put vlan counters into the
> hardware really screwed the pooch something fierce. :)
>
> --
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From cordmacleod at gmail.com  Sat Mar 20 18:41:21 2010
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Sat, 20 Mar 2010 18:41:21 -0400
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <419dba611003201431s20a5e1f7lc9ef8ec4967a8cf9@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<419dba611003201431s20a5e1f7lc9ef8ec4967a8cf9@mail.gmail.com>
Message-ID: <5C2E93E0-E027-4090-B6C8-414BAD3C8222@gmail.com>


On Mar 20, 2010, at 5:31 PM, Chris Evans wrote:

> Richard,
> 
> I agree with you with the EX platform.. It's really buggy. I personally
> think that Juniper is moving too slow bringing new features and bug fixes to
> the platform.. We're deploying the new Cisco Nexus platforms in our data
> centers at this point. Cisco is moving at light speed with these platforms,
> while Juniper is crawling to bring their aging boxes into the lime light
> left by the Cisco Cat6500 days.
> 
> On another note. I know you're upset about the limit on the routing that the
> EX series can do, but a better question is why are you using this box for
> that high end routing solution? In my opinion, the EX's 8200's are a switch
> built for the data center, they shouldn't require much more than a default
> route and/or a few hundred routes to your core.
> 
> Discussion?

Agreed.  High end routing with dense port configurations is called an MX.

> 
> On Sat, Mar 20, 2010 at 11:03 AM, Richard A Steenbergen <ras at e-gerbil.net>wrote:
> 
>> On Sat, Mar 20, 2010 at 06:50:58PM +0500, Fahad Khan wrote:
>>> Hi Folks,
>>> 
>>> Please share your experiences regarding the deployment of EX 8200, I need
>> to
>>> deploy two chassis in VRRP. Please let shed some light on the following
>>> point
>>> 
>>> - Any trick in power/power requirements??
>>> - stability
>>> - best design( like Virtual routers are needed or not)
>>> - possible caveats
>>> - Best junos version
>>> 
>>> Add any trick or issue which you have found out?
>> 
>> We just deployed our first EX8208 a few days ago, running 10.1R1.
>> Gotchas so far:
>> 
>> * Obviously this is a very different architecture from Juniper's normal
>> boxes, so be prepared for vlan space being shared across the entire box,
>> not a per-interface basis.
>> 
>> * In a move straight out of Foundry's playbook of how to fail at making
>> a useable product, EX has no packet counters (cli or snmp) available for
>> L3 vlan interfaces. It DOES have working counters if you do traditional
>> Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123
>> vlan-id 123), but it does NOT work if you have to do RVI style (vlan
>> blah l3-interface vlan.123 and then put vlan blah in an ethernet
>> switching interface). Subinterface style is my preference anyways, so as
>> long as you only ever use vlans on point-to-point links this isn't a
>> problem, but the instant you need to put a VLAN on more than one port
>> you no longer get packet counters.
>> 
>> * Related to the issue above, you can't mix "subinterface style" and
>> "RVI style" vlans on the same trunk port. The instant you need to do
>> anything more than classic subinterface style vlans, you have to convert
>> everything on the trunk to vlan/rvi style. For example, where I might
>> otherwise be able to get away with doing interface xe-1/0/0 unit 123
>> vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that
>> same interface I now have to convert unit 123 to RVI style. One possible
>> workaround I have yet to test is doing a CCC instead of a vlan, to keep
>> the subinterface style. This would only work with 2-port member vlans
>> though, and I have yet to test the implications for mixing tagged and
>> untagged ports on EX, so this may not actually work for anyone at all.
>> 
>> * There is a hardcoded default maximum data memory per process of 512MB
>> on the EX8200 series, which isn't enough memory for rpd to run any kind
>> of complex BGP configuration. Juniper says they tested it to 3.2 million
>> paths and it only used ~400MB, but I guess they found some artificially
>> low test scenario (I still wonder how they did this, even with no
>> communities and no as-path attributes it's only a ~10% memory
>> difference), and they didn't bother to ask the rpd developers how much
>> memory usage to expect, because real world usage is obviously FAR
>> higher. In our testing rpd coredumped at about 900k BGP paths, which is
>> probably a bad thing if you actually want to route on these boxes.
>> Juniper is working on this issue, but as a temporary workaround, edit
>> your /boot/loader.conf file as root, replace the kern.maxdsiz=512M with
>> something more sensible like 1536M, and reboot. This will of course be
>> blown away every time you upgrade JUNOS, so it helps to have dual REs so
>> you can pre-stage things. :)
>> 
>> * Firewall filters are still a bit of a mess. You can't count or log
>> anything, you can't use policers on either control plane or egress
>> filters (heck you can't even commit a firewall filter with a policer in
>> it if applied as an output filter), you can't match frags, etc, etc.
>> Basically if you're coming from another Juniper router, be prepared to
>> completely redesign all of your firewall filters across the board. For
>> example, you can't currently do a match like "from port 179" on EX, you
>> have to do "from source-port 179" and "from destination-port 179", which
>> means splitting what was previously a single term into two terms. This
>> is expected to get better with future sw, but my feeling is probably in
>> small increments over the next year+ or so.
>> 
>> * I don't know who thought 2GB of storage on an RE was sufficient, but
>> it isn't. The best idea I've come up with so far is to grab some small
>> USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and
>> deploy them on every RE so you have a little bit of working space.
>> 
>> Other than that we haven't found any fundamental flaws in the box yet
>> (though that may change by the time MPLS features get implemented :P).
>> Plenty of bugs to be sure, DOM isn't working right on any of our
>> interfaces, pfe statistics don't work right, monitor interface on vlans
>> isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried
>> to speak BGP flowspec to the box, etc, but we have cases open on all of
>> the above. IMHO it definitely has the potential to be a very good box in
>> the long term, but whoever didn't think to put vlan counters into the
>> hardware really screwed the pooch something fierce. :)
>> 
>> --
>> Richard A Steenbergen <ras at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



From ras at e-gerbil.net  Sat Mar 20 19:51:52 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 20 Mar 2010 18:51:52 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <419dba611003201431s20a5e1f7lc9ef8ec4967a8cf9@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<419dba611003201431s20a5e1f7lc9ef8ec4967a8cf9@mail.gmail.com>
Message-ID: <20100320235152.GV75640@gerbil.cluepon.net>

On Sat, Mar 20, 2010 at 05:31:36PM -0400, Chris Evans wrote:
> Richard,
> 
> I agree with you with the EX platform.. It's really buggy. I
> personally think that Juniper is moving too slow bringing new features
> and bug fixes to the platform.. We're deploying the new Cisco Nexus
> platforms in our data centers at this point. Cisco is moving at light
> speed with these platforms, while Juniper is crawling to bring their
> aging boxes into the lime light left by the Cisco Cat6500 days.

Nexus 7000 is not a bad platform, and definitely deserves consideration 
for the same kind of role. Obviously each has its own specific 
advantages and disadvantages, but at a high level Nexus 7k an EX8200 are 
*VERY* comperable in both price and features (and even their roadmaps 
look a lot alike). Yes n7k is probably a little more mature and stable 
than EX at the moment, but there is a lot to be said for the benefits of 
working with JUNOS too. An importand consideration is not only how well 
it works today, but how well it will work in the future, and like I said 
JUNOS earns the EX a LOT of leeway (to a point :P).

> On another note. I know you're upset about the limit on the routing
> that the EX series can do, but a better question is why are you using
> this box for that high end routing solution? In my opinion, the EX's
> 8200's are a switch built for the data center, they shouldn't require
> much more than a default route and/or a few hundred routes to your
> core.

Clearly we have different definitions of a datacenter role. Let me be 
clear, EX is absolutely *NOT* a replacement for the very capable and 
mature MX platform, nor does it try to be. MX does things like MPLS, 
VPLS, large (2mil+) FIBs, large memory (4GB) for multiple RIBs, it 
supports complex vlan tag manipulation that EX will never do, it has 
unique vlan IDs per interface not shared across the box, it has large 
packet buffers, support for SONET cards, XFP support for working with 
long reach optics in a carrier ethernet role, much more robust firewall 
features, services card support, and a host of other things that EX will 
never do.

That said, EX has a role for simpler work in the datacenter where the
full functionality of an MX is simply not worth the extra money and the
features aren't necessary. EX is also (or at least is intended to be) a
competitor of datacenter boxes like 6500 and Nexus 7000, both of which
support a full routing table and multiple paths via BGP. Your datacenter
may not make use of a full BGP routing table, but mine does, and clearly
a lot of other people's do too or Cisco wouldn't be making full-table
6500s or Nexus 7000s.

Also, my use of routing on the EX was well within the intended support
of the platform, it was simply a mistake in the code that caused it to 
fail at much lower levels than they intended. My real gripe was that the 
failure should have been perfectly obvious to them, and yet it wasn't. I 
know for a fact that Juniper employs many very smart and capable people 
who would have known better, it's just that the EX guys didn't consult 
them. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sfouant at shortestpathfirst.net  Sat Mar 20 19:51:44 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 20 Mar 2010 23:51:44 +0000
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
References: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
	<d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>
	<20100320.212651.74703019.sthaug@nethelp.no><d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
Message-ID: <429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>

You have to enable tunnel services on the PIC:

chassis {
    fpc 0 {
        pic 0 {
            tunnel-services {
                bandwidth 1g;
            }
        }
    }
    network-services ip;
}

That should take care of it.

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Fahad Khan <fahad.khan at gmail.com>
Date: Sun, 21 Mar 2010 01:41:31 
To: <sthaug at nethelp.no>
Cc: <sfouant at shortestpathfirst.net>; <juniper-nsp at puck.nether.net>; <juniper-nsp-bounces at puck.nether.net>
Subject: Re: [j-nsp] logical routers on M10i

But i can not see any lt interfaces in show interfaces terse ?? why??

regards,
Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Sun, Mar 21, 2010 at 1:26 AM, <sthaug at nethelp.no> wrote:

> > but now i got it, i need tunnel PIC , but not AS PIC II
>
> The AS PIC should be able to do anything the tunnel PIC can do (and
> more).
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>


From mtinka at globaltransit.net  Sat Mar 20 15:23:41 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 21 Mar 2010 03:23:41 +0800
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100320150313.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
Message-ID: <201003210323.48005.mtinka@globaltransit.net>

On Saturday 20 March 2010 11:03:13 pm Richard A Steenbergen 
wrote:

> * Obviously this is a very different architecture from
>  Juniper's normal boxes, so be prepared for vlan space
>  being shared across the entire box, not a per-interface
>  basis.

Terrible.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100321/595ef967/attachment.bin>

From sfouant at shortestpathfirst.net  Sat Mar 20 23:27:33 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sun, 21 Mar 2010 03:27:33 +0000
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <201003210323.48005.mtinka@globaltransit.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com><20100320150313.GT75640@gerbil.cluepon.net><201003210323.48005.mtinka@globaltransit.net>
Message-ID: <97292688-1269142072-cardhu_decombobulator_blackberry.rim.net-218636369-@bda294.bisx.prod.on.blackberry>

Chassis-wide VLAN space? Great!... Juniper just managed to build a Cisco 6509 ;)

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Mark Tinka <mtinka at globaltransit.net>
Date: Sun, 21 Mar 2010 03:23:41 
To: <juniper-nsp at puck.nether.net>
Cc: Richard A Steenbergen<ras at e-gerbil.net>
Subject: Re: [j-nsp] EX 8200 deployment

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



From jgoodwin at studio442.com.au  Sun Mar 21 03:08:33 2010
From: jgoodwin at studio442.com.au (Julien Goodwin)
Date: Sun, 21 Mar 2010 18:08:33 +1100
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100320150313.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
Message-ID: <4BA5C5F1.20806@studio442.com.au>

On 21/03/10 02:03, Richard A Steenbergen wrote:
> We just deployed our first EX8208 a few days ago, running 10.1R1. 
> Gotchas so far:
> 
> * Obviously this is a very different architecture from Juniper's normal 
> boxes, so be prepared for vlan space being shared across the entire box, 
> not a per-interface basis.

So far, apart from the MX I'm not aware of any Juniper gear that does
switching with multiple VLAN spaces.

> * In a move straight out of Foundry's playbook of how to fail at making
> a useable product, EX has no packet counters (cli or snmp) available for
> L3 vlan interfaces. It DOES have working counters if you do traditional 
> Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123 
> vlan-id 123), but it does NOT work if you have to do RVI style (vlan 
> blah l3-interface vlan.123 and then put vlan blah in an ethernet 
> switching interface). Subinterface style is my preference anyways, so as 
> long as you only ever use vlans on point-to-point links this isn't a 
> problem, but the instant you need to put a VLAN on more than one port 
> you no longer get packet counters.

Thank you for doing the testing on this, I was assuming this was a bug
as I'd thought they couldn't be *that* stupid.

To make things worse counters for vlan.XXX traffic are also only the
traffic destined *to* the interface, not counting traffic routed *through*.

> * Related to the issue above, you can't mix "subinterface style" and 
> "RVI style" vlans on the same trunk port. The instant you need to do 
> anything more than classic subinterface style vlans, you have to convert 
> everything on the trunk to vlan/rvi style. For example, where I might 
> otherwise be able to get away with doing interface xe-1/0/0 unit 123 
> vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that 
> same interface I now have to convert unit 123 to RVI style. One possible 
> workaround I have yet to test is doing a CCC instead of a vlan, to keep 
> the subinterface style. This would only work with 2-port member vlans 
> though, and I have yet to test the implications for mixing tagged and 
> untagged ports on EX, so this may not actually work for anyone at all. 

Either way please post.

> * Firewall filters are still a bit of a mess. You can't count or log
> anything, you can't use policers on either control plane or egress
> filters (heck you can't even commit a firewall filter with a policer in
> it if applied as an output filter), you can't match frags, etc, etc.

Lack of outbound policers also makes it fairly useless in many roles
where enforcing max bandwidth on a WAN link is required (At least here
in Australia carriers complain if you actually dump 100Mbit of traffic
on a 100Mbit point-to-point link).

> * I don't know who thought 2GB of storage on an RE was sufficient, but 
> it isn't. The best idea I've come up with so far is to grab some small 
> USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and 
> deploy them on every RE so you have a little bit of working space.

I've only just upgraded a bunch of stuff *to* 2GB, and don't have any
real space issues. I would very much appreciate if Juniper would just
give us two, externally accessible CF slots for storage and have that be it.

> Other than that we haven't found any fundamental flaws in the box yet
> (though that may change by the time MPLS features get implemented :P). 
> Plenty of bugs to be sure, DOM isn't working right on any of our
> interfaces, pfe statistics don't work right, monitor interface on vlans
> isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried
> to speak BGP flowspec to the box, etc, but we have cases open on all of
> the above. IMHO it definitely has the potential to be a very good box in
> the long term, but whoever didn't think to put vlan counters into the
> hardware really screwed the pooch something fierce. :)

So the EX (4200) bits from my personal list:
* EX4200 - bootp relay doesn't work when configured inside a
routing-instance, works when configured at top to use an instance
* The commands in
http://kb.juniper.net/index?page=content&id=KB13206&cat=JUNOS_EX&actp=LIST
don't exist in 9.5

I'm mostly on 10.0R2.10, but all our EX's are still 9.5.

-- 
Julien Goodwin
Studio442
"Blue Sky Solutioneering"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100321/e5df125c/attachment-0001.bin>

From dale.shaw+j-nsp at gmail.com  Sun Mar 21 03:16:38 2010
From: dale.shaw+j-nsp at gmail.com (Dale Shaw)
Date: Sun, 21 Mar 2010 18:16:38 +1100
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <4BA5C5F1.20806@studio442.com.au>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<4BA5C5F1.20806@studio442.com.au>
Message-ID: <3329cbb41003210016r3ae0e6bak62bc56c083f17ab6@mail.gmail.com>

Hi,

..straying a bit off topic..

On Sun, Mar 21, 2010 at 6:08 PM, Julien Goodwin
<jgoodwin at studio442.com.au> wrote:
> So the EX (4200) bits from my personal list:
> * EX4200 - bootp relay doesn't work when configured inside a
> routing-instance, works when configured at top to use an instance

Got bitten by this one a couple of weekends ago, during a big roll-out.

Very counter-intuitive 'fix'.

We had:

set routing-instances blah-vr forwarding-options helpers bootp
interface vlan.600 server 172.13.40.9

We actually needed:

set forwarding-options helpers bootp interface vlan.600 server
172.13.40.9 routing-instance blah-vr

cheers,
Dale

From ras at e-gerbil.net  Sun Mar 21 04:22:32 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 21 Mar 2010 03:22:32 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <4BA5C5F1.20806@studio442.com.au>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<4BA5C5F1.20806@studio442.com.au>
Message-ID: <20100321082232.GW75640@gerbil.cluepon.net>

On Sun, Mar 21, 2010 at 06:08:33PM +1100, Julien Goodwin wrote:
> > * Obviously this is a very different architecture from Juniper's normal 
> > boxes, so be prepared for vlan space being shared across the entire box, 
> > not a per-interface basis.
> 
> So far, apart from the MX I'm not aware of any Juniper gear that does
> switching with multiple VLAN spaces.

That's not exactly correct. For all intents and purposes MX is a much
cheaper ethernet-optimized T640, with an extra layer of "stuff" added to
let it do ethernet switching between some interfaces. Under that layer
of stuff though, it is still the same basic architecture as a T-series,
in which every interface has its own totally unique vlan space. On a M/T
series you didn't have the "ethernet switching" component, but that has 
nothing to do with the vlan id space.

This is completely and totally different from the architecture of a
"layer 3 switch" (like a 6509, Nexus, Foundry, Force10, etc) which is at
its core a layer 2 ethernet switch, with some "stuff" glued on to make
it do routing. In a "layer 3 switch" the vlan space is shared globally
across the box just like in a layer 2 switch, and when you want to
"route" on an interface what you're actually doing is secretly stealing
one of those 4096 box-wide vlans, using some hacks to do routing on it, 
and applying it as an access mode vlan to a single interface.

The ironic part of the whole thing is that, as far as I understand at
any rate, EX isn't actually a layer 3 switch architecture like the rest
of those boxes. In Juniper's rush to get into the enterprise switch
market, it seems like they decided to copy the other enterprise-marketed
switches out there, bad designs and all. At the end of the day it
doesn't "really" matter, most of us are comparing this to similar boxes
in the market segment which have the same limitations (Nexus 7k, etc),
it's just something people coming from other Juniper products need to
know.

> Thank you for doing the testing on this, I was assuming this was a bug
> as I'd thought they couldn't be *that* stupid.
> 
> To make things worse counters for vlan.XXX traffic are also only the
> traffic destined *to* the interface, not counting traffic routed
> *through*.

Correct. I actually found some old gripes about this when I searched
j-nsp after noticing the problem, but it is a big enough issue that I 
think it needs to be repeated again (and again and again, until it gets 
fixed :P).

At one point I work working on an sflow to snmp emulator for some of my 
poor Foundry-using friends who can't bill customers landing on vlans, 
may end up having to dust that off as a workaround for the EX design 
flaw.

> Lack of outbound policers also makes it fairly useless in many roles
> where enforcing max bandwidth on a WAN link is required (At least here
> in Australia carriers complain if you actually dump 100Mbit of traffic
> on a 100Mbit point-to-point link).

I believe this is just a current limitation of the software, not a flaw 
in the design of the hardware, so it should be "coming soon". Again, 
just something people need to be aware of, since as you say it can be a 
big problem if you need those features. :)

> I've only just upgraded a bunch of stuff *to* 2GB, and don't have any
> real space issues. I would very much appreciate if Juniper would just
> give us two, externally accessible CF slots for storage and have that
> be it.

I'm talking about the EX8200 here, which has 2GB of DRAM, not a
stackable box. When the thing crashes, where do you plan to write the
kernel panic file? I wasn't even able to work with my 512mb rpd
coredump, not enough free space to uncompress the tarball. Maybe you
aren't a power user and you don't notice the issue right now, but trust
me this is a setup for a lot of problems in the future.

> So the EX (4200) bits from my personal list:
> * EX4200 - bootp relay doesn't work when configured inside a
> routing-instance, works when configured at top to use an instance
> * The commands in
> http://kb.juniper.net/index?page=content&id=KB13206&cat=JUNOS_EX&actp=LIST
> don't exist in 9.5
> 
> I'm mostly on 10.0R2.10, but all our EX's are still 9.5.

I'm more interested in the 8200 than the 4200, so we haven't done that
much interesting testing on the 4200, but what I can tell (for the sake
of the mailing list archives) you is that the 3200/4200 and 8200 are two
different revisions of the same family of ASICs, with different feature
supported by the hardware, and different levels of support in software
for those two different revisions of hardware. What 3200/4200 does is
not necessarily the same as what 8200 does.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From tore.anderson at redpill-linpro.com  Sun Mar 21 05:50:37 2010
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Sun, 21 Mar 2010 10:50:37 +0100 (CET)
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100321082232.GW75640@gerbil.cluepon.net>
Message-ID: <476710337.42460.1269165037839.JavaMail.root@claudius.linpro.no>

* Richard A Steenbergen

> Correct. I actually found some old gripes about this when I searched
> j-nsp after noticing the problem, but it is a big enough issue that I
> think it needs to be repeated again (and again and again, until it
> gets fixed :P).

I'll be happy to join the choir on this one.  I reported the problem
back in March 2009, got PR 435648 opened, but haven't heard anything
more since then.

My workaround is to terminate the customer VLANs that needs counters
for accounting purposes on the EX-es' upstream routers instead, which
are MX-es with standard vlan-tagged family inet sub-interfaces.  That
works well enough but it's not as tidy as I would have preferred.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From sthaug at nethelp.no  Sun Mar 21 06:03:27 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sun, 21 Mar 2010 11:03:27 +0100 (CET)
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <3329cbb41003210016r3ae0e6bak62bc56c083f17ab6@mail.gmail.com>
References: <20100320150313.GT75640@gerbil.cluepon.net>
	<4BA5C5F1.20806@studio442.com.au>
	<3329cbb41003210016r3ae0e6bak62bc56c083f17ab6@mail.gmail.com>
Message-ID: <20100321.110327.74687917.sthaug@nethelp.no>

> > So the EX (4200) bits from my personal list:
> > * EX4200 - bootp relay doesn't work when configured inside a
> > routing-instance, works when configured at top to use an instance
> 
> Got bitten by this one a couple of weekends ago, during a big roll-out.
> 
> Very counter-intuitive 'fix'.
> 
> We had:
> 
> set routing-instances blah-vr forwarding-options helpers bootp
> interface vlan.600 server 172.13.40.9
> 
> We actually needed:
> 
> set forwarding-options helpers bootp interface vlan.600 server
> 172.13.40.9 routing-instance blah-vr

This is *not* specific to EX, the same applies to the M series.

However, the "Extended DHCP Relay" functionality (forwarding-options
dhcp-relay) needs to be configured under the routing-instance. Isn't
consistency wonderful?

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From chrisccnpspam2 at gmail.com  Sun Mar 21 08:52:54 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Sun, 21 Mar 2010 12:52:54 +0000
Subject: [j-nsp] EX 8200 deployment
Message-ID: <492466186-1269175975-cardhu_decombobulator_blackberry.rim.net-1398409415-@bda069.bisx.prod.on.blackberry>

Everyone, you do realize that the EX switches were designed to get Juniper into the enterprise switching market (although poorly). This is what they are doing, Don't expect features of the MX to show up. 

As of the current software offering the EX 8200 isn't even up to par with a 6500 feature wise yet. While its not the best at everything, the 6500 is a swiss army knife. Its going to take quite a bit of time to be at the same level. Then also take the fact that the 6500 is dead as a strategic platform. The Nexus 7k is the new boy on the block. Juniper needs to push features and hardware faster to keep up, yet sadly I don't think they're doing it. 


------Original Message------
From: Stefan Fouant
Sender: juniper-nsp-bounces at puck.nether.net
To: mtinka at globaltransit.net
To: juniper-nsp at puck.nether.net
Cc: Richard A Steenbergen
ReplyTo: sfouant at shortestpathfirst.net
Subject: Re: [j-nsp] EX 8200 deployment
Sent: Mar 20, 2010 11:27 PM

Chassis-wide VLAN space? Great!... Juniper just managed to build a Cisco 6509 ;)

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Mark Tinka <mtinka at globaltransit.net>
Date: Sun, 21 Mar 2010 03:23:41 
To: <juniper-nsp at puck.nether.net>
Cc: Richard A Steenbergen<ras at e-gerbil.net>
Subject: Re: [j-nsp] EX 8200 deployment

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent via BlackBerry by AT&T


From chrisccnpspam2 at gmail.com  Sun Mar 21 10:48:54 2010
From: chrisccnpspam2 at gmail.com (Chris Evans)
Date: Sun, 21 Mar 2010 10:48:54 -0400
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <201003212215.33800.mtinka@globaltransit.net>
References: <492466186-1269175975-cardhu_decombobulator_blackberry.rim.net-1398409415-@bda069.bisx.prod.on.blackberry>
	<201003212215.33800.mtinka@globaltransit.net>
Message-ID: <419dba611003210748q2a71cfb6ib18790102550166@mail.gmail.com>

Yes, you are correct. The Cat6500 has some new hardware coming to it,
however it's still going to be the Cat6500 at the end of the day. Still
using IOS, still integrating with older line cards, etc.. The Cat6500 has
served my company for years, we have thousands in production ranging from
Sup1a to the Sup720 series, CatOS to IOS, etc.. While it has served us,
along with bringing many headaches, it's time to move on to the new age.

You are right though, currently we're only replacing out Cat6500's in the
data centers as we just cannot get the reliability, 10GigE density and
support for CEE/DCB (future 7K cards) that the N7K has/will bring.. The fact
that we can do ISSU is huge for us.. I believe the EX8200 is on track to
have ISSU support in 2011. However in the corp environment, we're still
using Cat6500's. I honestly would like to see us start to use stackables.
The access tier is a commodity anymore, there is no reason to have a high
dollar box.

We completed a RFP late last year and we reviewed Brocade(Foundry), Cisco
and Juniper's latest offering. We found that the EX8200 didn't have some
critical features that our 6500's have, so it was almost an immediate no. I
wish somehow Juniper would realize this and put more resources into the EX
series. It has TONS of potential, just little pushing on the product side..
Cisco is going to release the 2nd gen of Nexus 5K later this year. Cisco is
also releasing a whole new line of modules for the 7K, new fabric extenders,
etc.. That is just for the Nexus series. As you stated they're bringing new
hardware to the Cat6500 as well. Juniper doesn't have any new modules for
the EX8200 series, I've heard rumor of a high density 10Gig module, but it
seems to be vaporware. No plans (as of now) to support CEE/DCB. The EX4500
platform is barely in beta stage.. The list goes on, they're moving too
slow! Very FRUSTRATING!

Currently we only use Juniper products for SSLVPN, Internet edge and some
other minor roles, I'd like to see them have more of a play in our
environment. How can I bring another switch vendor into my environment when
the "new" box doesn't do what I have now and will be outdated in a short
time frame. It's a very hard thing to justify.



On Sun, Mar 21, 2010 at 10:15 AM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Sunday 21 March 2010 08:52:54 pm chrisccnpspam2 at gmail.com
> wrote:
>
> > Then also take the fact that the 6500 is
> >  dead as a strategic platform. The Nexus 7k is the new
> >  boy on the block.
>
> You've probably heard that the 6500 will be getting a new
> switch fabric/supervisor module which should resolve a lot
> of the hardware limitations seen in the current EARL (for
> all intents and purposes, it should be the same EARL being
> used on the Nexus 7000 series platforms).
>
> It probably makes more sense for anyone looking at a new
> 6500 to consider the Nexus 7000 for a number of reasons,
> least of which isn't the potential for future 40Gbps and
> 100Gbps Ethernet support. But Cisco will still get customers
> for the new fabric, especially existing 6500 folk.
>
> Cheers,
>
> Mark.
>

From mtinka at globaltransit.net  Sun Mar 21 10:15:33 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 21 Mar 2010 22:15:33 +0800
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <492466186-1269175975-cardhu_decombobulator_blackberry.rim.net-1398409415-@bda069.bisx.prod.on.blackberry>
References: <492466186-1269175975-cardhu_decombobulator_blackberry.rim.net-1398409415-@bda069.bisx.prod.on.blackberry>
Message-ID: <201003212215.33800.mtinka@globaltransit.net>

On Sunday 21 March 2010 08:52:54 pm chrisccnpspam2 at gmail.com 
wrote:

> Then also take the fact that the 6500 is
>  dead as a strategic platform. The Nexus 7k is the new
>  boy on the block.

You've probably heard that the 6500 will be getting a new 
switch fabric/supervisor module which should resolve a lot 
of the hardware limitations seen in the current EARL (for 
all intents and purposes, it should be the same EARL being 
used on the Nexus 7000 series platforms).

It probably makes more sense for anyone looking at a new 
6500 to consider the Nexus 7000 for a number of reasons, 
least of which isn't the potential for future 40Gbps and 
100Gbps Ethernet support. But Cisco will still get customers 
for the new fabric, especially existing 6500 folk.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100321/86ab4fa6/attachment-0001.bin>

From sronan at fattoc.com  Sun Mar 21 20:10:46 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Sun, 21 Mar 2010 19:10:46 -0500
Subject: [j-nsp] Shutting Down a Network and Selling off Assets
Message-ID: <79860B11-3CDA-4388-AADC-51F8F6AFF3CF@fattoc.com>

Hello everyone,

This might be slightly off topic, but I am shutting down a large
network, and selling off the assets.

Information is @ www.ronan-online/forsale.html

I will be adding items to the list as they come offline, as well as
the location of each asset.

Email me with any questions or offers.

Shane Ronan

From sronan at fattoc.com  Sun Mar 21 20:37:00 2010
From: sronan at fattoc.com (Shane Ronan)
Date: Sun, 21 Mar 2010 19:37:00 -0500
Subject: [j-nsp] Shutting Down a Network and Selling off Assets
In-Reply-To: <79860B11-3CDA-4388-AADC-51F8F6AFF3CF@fattoc.com>
References: <79860B11-3CDA-4388-AADC-51F8F6AFF3CF@fattoc.com>
Message-ID: <736B5AF0-7FFB-48A1-8D4B-5DEA0DACA739@fattoc.com>

>  www.ronan-online.com/forsale.html

On Mar 21, 2010, at 7:10 PM, Shane Ronan wrote:

> Hello everyone,
>
> This might be slightly off topic, but I am shutting down a large
> network, and selling off the assets.
>
> Information is @ www.ronan-online/forsale.html
>
> I will be adding items to the list as they come offline, as well as
> the location of each asset.
>
> Email me with any questions or offers.
>
> Shane Ronan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From sj_hznm at yahoo.com.cn  Mon Mar 22 10:07:44 2010
From: sj_hznm at yahoo.com.cn (Joe Shen)
Date: Mon, 22 Mar 2010 22:07:44 +0800 (CST)
Subject: [j-nsp] Quesion on E320 Radius Accouting packet
Message-ID: <681117.26648.qm@web15602.mail.cnb.yahoo.com>

hi,

Could anybody explain  Juniper E320 radius accouting packet content?

We use Juniper E320 with C2000 to provide portal based wlan access service.


subscribers --(WLAN) --- E320 ---- C2000 ----- Radius server

it is notice that  there are radius accounting packets has Acct-Output-Packets  = 0  while Acct-Input-Octets = 145428422  ( see sample radius packets caught below).

customer respond for this radius accounting packets says he only browse internet in that wlan session. it's not possible for TCP communication there is only one-way packets sent. 

Would anybody do me a favor to explain following quesions

1. Does Acct-Output-Packets  and Acct-Output-Octets  record traffic sent to customer?

   Does Acct-Input-Octets  and Acct-Input-Packets record traffic sent by customer?

   In culating customer traffic, do we need to consider Acct-Output-Gigawords  and Acct-Input-Gigawords  ?


2. Is there any traffic calculation policy set in E320 or C2000?

3.  how to calculate total amount of traffic sent or received by customers ?


regards

Joe

=== Sample radius accouting packets




Thu Mar 18 15:02:09 EAT 2010
        Acct-Status-Type = Start
        Acct-Delay-Time = 0
        User-Name = 8958060203
        NAS-Port-Id = VR_WLAN at XH-BAS-E320-3.MAN GigabitEthernet 14/0/1:1019-2550
        Framed-IP-Address = 15.194.59.94
        NAS-Port-Type = 19
        Class = internet-1M-wlan
        NAS-Identifier = 10.191.154.212
        NAS-IP-Address = 10.191.154.212
        Event-TimeStamp = 1268895730
        Acct-Session-Id = internet-1M-wlan:18958060203:1268895730697:54057
        NAS-Port-Type = 19


Thu Mar 18 15:17:10 EAT 2010
        Acct-Status-Type = Interim-Update
        Acct-Delay-Time = 0
        User-Name = 8958060203
        NAS-Port-Id = VR_WLAN at XH-BAS-E320-3.MAN GigabitEthernet 14/0/1:1019-2550
        Framed-IP-Address = 15.194.59.94
        NAS-Port-Type = 19
        Class = internet-1M-wlan
        Acct-Session-Time = 900
        Acct-Output-Packets = 0
        Acct-Output-Gigawords = 0
        Acct-Input-Gigawords = 0
        Acct-Input-Octets = 145428422
        Acct-Output-Octets = 0
        Acct-Input-Packets = 186105
        NAS-Identifier = 10.191.154.212
        NAS-IP-Address = 10.191.154.212
        Event-TimeStamp = 1268896630
        Acct-Session-Id = internet-1M-wlan:18958060203:1268895730697:54057
        NAS-Port-Type = 19

Thu Mar 18 15:32:10 EAT 2010
        Acct-Status-Type = Interim-Update
        Acct-Delay-Time = 0
        User-Name = 8958060203
        NAS-Port-Id = VR_WLAN at XH-BAS-E320-3.MAN GigabitEthernet 14/0/1:1019-2550
        Framed-IP-Address = 15.194.59.94
        NAS-Port-Type = 19
        Class = internet-1M-wlan
        Acct-Session-Time = 1800
        Acct-Output-Packets = 0
        Acct-Output-Gigawords = 0
        Acct-Input-Gigawords = 0
        Acct-Input-Octets = 320842121
        Acct-Output-Octets = 0
        Acct-Input-Packets = 389872
        NAS-Identifier = 10.191.154.212
        NAS-IP-Address = 10.191.154.212
        Event-TimeStamp = 1268897530
        Acct-Session-Id = internet-1M-wlan:18958060203:1268895730697:54057
        NAS-Port-Type = 19


Thu Mar 18 15:33:17 EAT 2010
        Acct-Status-Type = Stop
        Acct-Delay-Time = 0
        User-Name = 8958060203
        NAS-Port-Id = VR_WLAN at XH-BAS-E320-3.MAN GigabitEthernet 14/0/1:1019-2550
        Framed-IP-Address = 15.194.59.94
        NAS-Port-Type = 19
        Class = internet-1M-wlan
        Acct-Terminate-Cause = 2
        Acct-Session-Time = 1866
        Acct-Output-Packets = 0
        Acct-Output-Gigawords = 0
        Acct-Input-Gigawords = 0
        Acct-Input-Octets = 320842121
        Acct-Output-Octets = 0
        Acct-Input-Packets = 389872
        NAS-Identifier = 10.191.154.212
        NAS-IP-Address = 10.191.154.212
        Event-TimeStamp = 1268897597
        Acct-Session-Id = internet-1M-wlan:18958060203:1268895730697:54057
        NAS-Port-Type = 19



      


From snar at snar.spb.ru  Mon Mar 22 10:31:38 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Mon, 22 Mar 2010 17:31:38 +0300
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100320150313.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
Message-ID: <20100322143138.GE30843@snar.spb.ru>

On Sat, Mar 20, 2010 at 10:03:13AM -0500, Richard A Steenbergen wrote:
> 
> * In a move straight out of Foundry's playbook of how to fail at making
> a useable product, EX has no packet counters (cli or snmp) available for
> L3 vlan interfaces. It DOES have working counters if you do traditional 
> Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123 
> vlan-id 123), but it does NOT work if you have to do RVI style (vlan 
> blah l3-interface vlan.123 and then put vlan blah in an ethernet 
> switching interface). Subinterface style is my preference anyways, so as 
> long as you only ever use vlans on point-to-point links this isn't a 
> problem, but the instant you need to put a VLAN on more than one port 
> you no longer get packet counters.

I suppose you can use good old "hairpin cable" trick to have both 
egress policers (converted to ingress ones on "switched" side of 
hairpin) and counters on Vlan's (actually on subinterfaces on "routed" side). 
Not checked with ex-82xx, but it works for ex-[34]200.


From stacy at acm.org  Mon Mar 22 11:17:36 2010
From: stacy at acm.org (Stacy W. Smith)
Date: Mon, 22 Mar 2010 09:17:36 -0600
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
References: <1535844862-1269111146-cardhu_decombobulator_blackberry.rim.net-407308208-@bda294.bisx.prod.on.blackberry>
	<d0cc41791003201317j57cc8615o6e348b7b752b4c0@mail.gmail.com>
	<20100320.212651.74703019.sthaug@nethelp.no><d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
Message-ID: <F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>

I believe configuring "tunnel-services" is only applicable to MX-series DPCs. While you may be able to apply this config to an AS PIC, I don't believe it will provide you with an lt interface. On M/T-series you need a tunnel PIC to provide an lt interface.

--Stacy


On Mar 20, 2010, at 5:51 PM, Stefan Fouant wrote:

> You have to enable tunnel services on the PIC:
> 
> chassis {
>    fpc 0 {
>        pic 0 {
>            tunnel-services {
>                bandwidth 1g;
>            }
>        }
>    }
>    network-services ip;
> }
> 
> That should take care of it.
> 
> Stefan Fouant
> Sent from my Verizon Wireless BlackBerry
> 
> -----Original Message-----
> From: Fahad Khan <fahad.khan at gmail.com>
> Date: Sun, 21 Mar 2010 01:41:31 
> To: <sthaug at nethelp.no>
> Cc: <sfouant at shortestpathfirst.net>; <juniper-nsp at puck.nether.net>; <juniper-nsp-bounces at puck.nether.net>
> Subject: Re: [j-nsp] logical routers on M10i
> 
> But i can not see any lt interfaces in show interfaces terse ?? why??
> 
> regards,
> Muhammad Fahad Khan
> JNCIP - M/T # 834
> IT Specialist
> Global Technology Services, IBM
> fahad at 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
> 
> 
> On Sun, Mar 21, 2010 at 1:26 AM, <sthaug at nethelp.no> wrote:
> 
>>> but now i got it, i need tunnel PIC , but not AS PIC II
>> 
>> The AS PIC should be able to do anything the tunnel PIC can do (and
>> more).
>> 
>> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



From sthaug at nethelp.no  Mon Mar 22 12:09:39 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 22 Mar 2010 17:09:39 +0100 (CET)
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
References: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
	<F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
Message-ID: <20100322.170939.74720753.sthaug@nethelp.no>

> On M/T-series you need a tunnel PIC to provide an lt interface.

Not necessarily. From an M7i with built-in ASP (i.e. the built-in
version of the AS PIC):

FPC 1                                                    E-FPC
  PIC 2          REV 05   750-015931   PX6751            ASP - Integrated (Layer-2-3)

x at y.z> show interfaces lt-1/2/0
Physical interface: lt-1/2/0, Enabled, Physical link is Up
  Interface index: 140, SNMP ifIndex: 511
  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 800mbps
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps
  Link flags     : None
  Physical info  : 13
  Current address: 00:1f:12:a5:a4:bc, Hardware address: 00:1f:12:a5:a4:bc
  Last flapped   : 2009-11-26 01:00:02 CET (16w4d 16:06 ago)
  Input rate     : 0 bps (0 pps)
  Output rate    : 0 bps (0 pps)

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From jonlooney at gmail.com  Mon Mar 22 12:19:42 2010
From: jonlooney at gmail.com (Jonathan Looney)
Date: Mon, 22 Mar 2010 12:19:42 -0400
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <20100322.170939.74720753.sthaug@nethelp.no>
References: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
	<F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
	<20100322.170939.74720753.sthaug@nethelp.no>
Message-ID: <ba5437101003220919p7bbb96ffq255482cbb9da58f@mail.gmail.com>

The M7i is a special case.  It either comes with a built-in tunnel PIC, or a
built-in ASM.  However, the built-in ASM on the M7i retains the logical
tunnel feature you would otherwise get with the default built-in tunnel PIC.

For all other M/T platforms, I believe Stacy is correct.

-Jon

On Mon, Mar 22, 2010 at 12:09 PM, <sthaug at nethelp.no> wrote:

> > On M/T-series you need a tunnel PIC to provide an lt interface.
>
> Not necessarily. From an M7i with built-in ASP (i.e. the built-in
> version of the AS PIC):
>
> FPC 1                                                    E-FPC
>  PIC 2          REV 05   750-015931   PX6751            ASP - Integrated
> (Layer-2-3)
>
> x at y.z> show interfaces lt-1/2/0
> Physical interface: lt-1/2/0, Enabled, Physical link is Up
>  Interface index: 140, SNMP ifIndex: 511
>  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited,
> Speed: 800mbps
>  Device flags   : Present Running
>  Interface flags: Point-To-Point SNMP-Traps
>  Link flags     : None
>  Physical info  : 13
>  Current address: 00:1f:12:a5:a4:bc, Hardware address: 00:1f:12:a5:a4:bc
>  Last flapped   : 2009-11-26 01:00:02 CET (16w4d 16:06 ago)
>  Input rate     : 0 bps (0 pps)
>  Output rate    : 0 bps (0 pps)
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From eric at atlantech.net  Mon Mar 22 12:37:05 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 22 Mar 2010 12:37:05 -0400
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <ba5437101003220919p7bbb96ffq255482cbb9da58f@mail.gmail.com>
References: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
	<F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
	<20100322.170939.74720753.sthaug@nethelp.no>
	<ba5437101003220919p7bbb96ffq255482cbb9da58f@mail.gmail.com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFD85A555@exchange.aoihq.local>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Jonathan Looney
> Sent: Monday, March 22, 2010 12:20 PM
> To: sthaug at nethelp.no
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] logical routers on M10i
> 
> The M7i is a special case.  It either comes with a built-in tunnel PIC, or
> a
> built-in ASM.  However, the built-in ASM on the M7i retains the logical
> tunnel feature you would otherwise get with the default built-in tunnel
> PIC.
> 
> For all other M/T platforms, I believe Stacy is correct.
> 
> -Jon
> 

Our AS II PIC provides tunnel services, even when running in layer-2 mode:

user at router1-re0> show chassis hardware detail | match "PIC 3"  
  PIC 3          REV 03   750-012924   xxxxx         AS2 Layer-2 Services

user at router1-re0> show interfaces lt-0/2/0
Physical interface: lt-0/2/0, Enabled, Physical link is Up
...

This is in an M20 w/ FPC-E.  However, in our M10i, it doesn't work and you might have to enable 'layer-2-3' or 'layer-3' for that PIC for lt functionality (sorry, can't risk trying it myself on production equipment :-) ):

set chassis fpc X pic X adaptive-services service-package [ layer-2-3 layer-3 ]

-evt


From stacy at acm.org  Mon Mar 22 12:45:29 2010
From: stacy at acm.org (Stacy W. Smith)
Date: Mon, 22 Mar 2010 10:45:29 -0600
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFD85A555@exchange.aoihq.local>
References: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
	<F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
	<20100322.170939.74720753.sthaug@nethelp.no>
	<ba5437101003220919p7bbb96ffq255482cbb9da58f@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFD85A555@exchange.aoihq.local>
Message-ID: <3014104F-26ED-4BB1-8DDC-872ECB493767@acm.org>

On Mar 22, 2010, at 10:37 AM, Eric Van Tol wrote:
> Our AS II PIC provides tunnel services, even when running in layer-2 mode:
> 
> user at router1-re0> show chassis hardware detail | match "PIC 3"  
>  PIC 3          REV 03   750-012924   xxxxx         AS2 Layer-2 Services
> 
> user at router1-re0> show interfaces lt-0/2/0
> Physical interface: lt-0/2/0, Enabled, Physical link is Up
> ...

That doesn't look like the lt interface is being supplied by the AS PIC. You're AS PIC is in PIC slot 3 and your lt interface is in PIC slot 2.

--Stacy



From eric at atlantech.net  Mon Mar 22 12:52:44 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 22 Mar 2010 12:52:44 -0400
Subject: [j-nsp] logical routers on M10i
In-Reply-To: <3014104F-26ED-4BB1-8DDC-872ECB493767@acm.org>
References: <d0cc41791003201341s62028109rae417520b5c46584@mail.gmail.com>
	<429277123-1269129122-cardhu_decombobulator_blackberry.rim.net-1327131963-@bda294.bisx.prod.on.blackberry>
	<F09E7B98-BC30-4CAF-8B0C-425426F34244@acm.org>
	<20100322.170939.74720753.sthaug@nethelp.no>
	<ba5437101003220919p7bbb96ffq255482cbb9da58f@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFD85A555@exchange.aoihq.local>
	<3014104F-26ED-4BB1-8DDC-872ECB493767@acm.org>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFD85A557@exchange.aoihq.local>

> -----Original Message-----
> From: Stacy Smith [mailto:stacy.w.smith at gmail.com] On Behalf Of Stacy W.
> Smith
> Sent: Monday, March 22, 2010 12:45 PM
> To: Eric Van Tol
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] logical routers on M10i
> 
> On Mar 22, 2010, at 10:37 AM, Eric Van Tol wrote:
> > Our AS II PIC provides tunnel services, even when running in layer-2
> mode:
> >
> > user at router1-re0> show chassis hardware detail | match "PIC 3"
> >  PIC 3          REV 03   750-012924   xxxxx         AS2 Layer-2 Services
> >
> > user at router1-re0> show interfaces lt-0/2/0
> > Physical interface: lt-0/2/0, Enabled, Physical link is Up
> > ...
> 
> That doesn't look like the lt interface is being supplied by the AS PIC.
> You're AS PIC is in PIC slot 3 and your lt interface is in PIC slot 2.
> 
> --Stacy

Wow.  Some days I wonder how I still even have a job.  You are correct - I forgot that this router also has a tunnel PIC installed and am used to hitting TAB to complete commands. :-/

After reviewing the documentation on the service packages settings, it does not appear as though the AS II PIC supports logical tunnels at all, confirming your earlier post:

http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-services/id-10028063.htm

In fact, it seems to be the only type of tunnel that it cannot create.

Sorry for the epic fail.

-evt


From hoogen82 at gmail.com  Mon Mar 22 13:05:46 2010
From: hoogen82 at gmail.com (Hoogen)
Date: Mon, 22 Mar 2010 10:05:46 -0700
Subject: [j-nsp] SRX deployment / issues
Message-ID: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>

I think the EX thread was really good and the feedback was awesome. I would
like hear about similar experiences while deploying SRX Series gateways, I
am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would
also love to hear feedback on SRX 3000/5000 if people have been using it in
their setup, problems that their facing, improvements and general deployment
scenario that have been used.

-Hoogen

From ras at e-gerbil.net  Mon Mar 22 15:16:36 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 22 Mar 2010 14:16:36 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322143138.GE30843@snar.spb.ru>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
Message-ID: <20100322191636.GB75640@gerbil.cluepon.net>

On Mon, Mar 22, 2010 at 05:31:38PM +0300, Alexandre Snarskii wrote:
> I suppose you can use good old "hairpin cable" trick to have both
> egress policers (converted to ingress ones on "switched" side of
> hairpin) and counters on Vlan's (actually on subinterfaces on "routed"
> side).  Not checked with ex-82xx, but it works for ex-[34]200.

I'm trying to picture the exact configuration you're talking about, but
I'm not sure I get it. If you hairpined a trunk port, wouldn't you still
have to configure the layer 2 vlans on the other side to do anything
with them, and wouldn't they then be the same vlans as the originals? 

I was waiting on some more lab EX's to show up before I started playing
with this further, but I suppose I might as well ask here and see if
someone else wants to test it... What happens when you configure the
same vlan-id under two different interfaces? For example, we know that
the counters for multiple subinterfaces work correctly like this:

interface xe-1/0/0 {
    vlan-tagging;
    unit 101 {
        vlan-id 101;
        family inet {
            address 1.2.3.4/24;
        }
    }
}

But what happens when you do:

interface xe-1/0/0 {
    vlan-tagging;
    unit 101 {
        vlan-id 101;
        family inet {
            address 1.2.3.4/24;
        }
    }
}

interface xe-2/0/0 {
    vlan-tagging;
    unit 101 {
        vlan-id 101;
        family inet {
            address 2.3.4.5/24;
        }
    }
}

Commit check doesn't error on it at any rate, but does this share 
packets within a vlan 101 space automatically, or not? Or were you 
saying that when you do a subinterface style it doesn't actually use the 
vlan chassis-wide like it would if you did this subinterface style 
config on a 6509 for example, and you were proposing this:

interface xe-1/0/0 {
    vlan-tagging;
    unit 101 {
        vlan-id 101;
        family inet {
            address 1.2.3.4/24;
        }
    }
}

interface xe-2/0/0 {
    unit 0 {
        family ethernet-switching {
            port-mode trunk;
            vlan {
                members VLAN101;
            }
        }
    }
}

vlans {
    VLAN101 {
        vlan-id 101;
    }
}

With a hairpin between xe-1/0/0 and xe-2/0/0, and then you could use 
VLAN101 in whatever other configuration you wanted while still using 
xe-1/0/0.101 for the counting?

And if the above is true, can someone test as an alternative to family 
ethernet-switching:

interface xe-1/0/0 {
    vlan-tagging;
    unit 101 {
        family ccc;
    }
}

interface xe-1/0/1 {
    vlan-tagging;
    unit 101 {
        family ccc;
    }
}

protocols {
    connections {
        interface-switch test {
            interface xe-1/0/0.101;
            interface xe-1/0/1.101;
        }
    }
}

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From david.roy at orange-ftgroup.com  Mon Mar 22 15:29:39 2010
From: david.roy at orange-ftgroup.com (david.roy at orange-ftgroup.com)
Date: Mon, 22 Mar 2010 20:29:39 +0100
Subject: [j-nsp] BGP tcp-mss
In-Reply-To: <50B3A5560BA4D74CADEC55A48B4641B23D0D2FC518@EMBX01-HQ.jnpr.net>
References: <18182_1265122472_4B683CA8_18182_40163_1_153490EA03CE634EBD317768617B63104716D20DE6@PMEXCB1A.intranet-paris.francetelecom.fr>
	<50B3A5560BA4D74CADEC55A48B4641B23D0D1DCA41@EMBX01-HQ.jnpr.net>
	<8177_1265193519_4B69522F_8177_1063_1_153490EA03CE634EBD317768617B63104716D20DF4@PMEXCB1A.intranet-paris.francetelecom.fr>
	<50B3A5560BA4D74CADEC55A48B4641B23D0D2FC518@EMBX01-HQ.jnpr.net>
Message-ID: <32266_1269286180_4BA7C524_32266_186903_1_153490EA03CE634EBD317768617B6310471F613474@PMEXCB1A.intranet-paris.francetelecom.fr>

Hi,

Just for info. A new PR 514196 has been opened to track this issue.

Regards,
David
 


 
David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com
 

-----Message d'origine-----
De : Harry Reynolds [mailto:harry at juniper.net] 
Envoy? : mercredi 3 f?vrier 2010 17:10
? : ROY David DTF/DERX; juniper-nsp at puck.nether.net
Objet : RE: BGP tcp-mss

I believe so. I only scanned, but did not seem platform or pmtu related.

Regards

 

-----Original Message-----
From: david.roy at orange-ftgroup.com [mailto:david.roy at orange-ftgroup.com]
Sent: Wednesday, February 03, 2010 2:39 AM
To: Harry Reynolds; juniper-nsp at puck.nether.net
Subject: RE: BGP tcp-mss

 
Hi,

Path MTU Discovery is disabled and I have the problem with MX, T640 and T1600 platforms. 
Do you think that the PR might include my case as well ? 

Regards,
David


 
David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com
 

-----Message d'origine-----
De : Harry Reynolds [mailto:harry at juniper.net] Envoy? : mercredi 3 f?vrier 2010 02:22 ? : ROY David DTF/DERX; juniper-nsp at puck.nether.net Objet : RE: BGP tcp-mss

Sounds like case 2009-0127-0051, which seems to have been fixed via pr 390993 around 9.4.

Hths

Harry






-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of david.roy at orange-ftgroup.com
Sent: Tuesday, February 02, 2010 6:55 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] BGP tcp-mss

Hi all,

Do you why, when I set the tcp-mss to 4096 between to BGP neighbors, this one is well exchange between the TCP Connection Establishment but when I check the mss via the command "show system connection extensive" I see that the mss used is 2048 (the half).

R1 config - lo0 172.20.223.6 :

  neighbor 172.20.223.5 {
        tcp-mss 4096;
    }
R2 config - lo0 172.20.223.5

  neighbor 172.20.223.6 {
        tcp-mss 4096;
    }

One Link between R1 and R2 with MTU set to 4484.

TCPDUMP output on R2 - we see that 4096 is well exchanged :

15:49:29.681732 Out IP 172.20.223.5.55025 > 172.20.223.6.179: S 2338565447:2338565447(0) win 16384 <mss 4096,nop,wscale 0,nop,nop,timestamp 2417320394 0,sackOK,eol>
15:49:29.682439  In IP 172.20.223.6.179 > 172.20.223.5.55025: S 1139135010:1139135010(0) ack 2338565448 win 16384 <mss 4096,nop,wscale 0,nop,nop,timestamp 455578404 2417320394,sackOK,eol>
15:49:29.682455 Out IP 172.20.223.5.55025 > 172.20.223.6.179: . ack 1 win 16384 <nop,nop,timestamp 2417320394 455578404>


On R2 : show system connection extensive | find 172.20.223.6

tcp4       0      0  172.20.223.5.55025                            172.20.223.6.179                              ESTABLISHED
   sndsbcc:          0 sndsbmbcnt:          0  sndsbmbmax:     131072
sndsblowat:       2048 sndsbhiwat:      16384
   rcvsbcc:          0 rcvsbmbcnt:          0  rcvsbmbmax:     131072
rcvsblowat:          1 rcvsbhiwat:      16384
   proc id:       1131  proc name:        rpd
       iss: 2338565447      sndup: 2338567245
    snduna: 2338567245     sndnxt: 2338567245      sndwnd:      16384
    sndmax: 2338567245    sndcwnd:       4096 sndssthresh: 1073725440
       irs: 1139135010      rcvup: 1139136242
    rcvnxt: 1139136261     rcvadv: 1139152645      rcvwnd:      16384
       rtt:          0       srtt:       2230        rttv:        574
    rxtcur:       1200   rxtshift:          0       rtseq: 2338567226
    rttmin:       1000  mss:       2048


N.B: Release 9.3

Thank you
Regards,
David


David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com<mailto:david.roy at orange-ftgroup.com>



*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************



From jhanke at myclearwave.net  Mon Mar 22 16:11:20 2010
From: jhanke at myclearwave.net (Jay Hanke)
Date: Mon, 22 Mar 2010 15:11:20 -0500
Subject: [j-nsp] SRX as Little Juniper BGP Box
Message-ID: <008c01cac9fb$d6d6dc20$84849460$@net>

I?m in need of a box that will handle up to ? gig of throughput and some
very low volume BGP (about 200 routes + default) for IPv4 and IPv6 in the
next couple of months.

 

I was looking at the sheets and the SRX appears to give a little more ?bang
for buck? as compared to a j2320 or j2350. I wouldn?t be afraid of the EX
line but the cost of the AFL for BGP puts me out of the budget for the
project.

 

Has anyone used an SRX in a similar situation? Is the j-series still safer?

 

Thanks,

 

Jay


From pautore at columbus-networks.com  Mon Mar 22 15:41:05 2010
From: pautore at columbus-networks.com (Paolo Autore)
Date: Mon, 22 Mar 2010 15:41:05 -0400
Subject: [j-nsp] BGP tcp-mss
References: <18182_1265122472_4B683CA8_18182_40163_1_153490EA03CE634EBD317768617B63104716D20DE6@PMEXCB1A.intranet-paris.francetelecom.fr><50B3A5560BA4D74CADEC55A48B4641B23D0D1DCA41@EMBX01-HQ.jnpr.net><8177_1265193519_4B69522F_8177_1063_1_153490EA03CE634EBD317768617B63104716D20DF4@PMEXCB1A.intranet-paris.francetelecom.fr><50B3A5560BA4D74CADEC55A48B4641B23D0D2FC518@EMBX01-HQ.jnpr.net>
	<32266_1269286180_4BA7C524_32266_186903_1_153490EA03CE634EBD317768617B6310471F613474@PMEXCB1A.intranet-paris.francetelecom.fr>
Message-ID: <9E6682E52B89BE47B72BCE81C141CD172B1ED8B7@nwndc.nwncable.com>

Guys;
 I ran into this issue sometime ago, and basically all you can do is configured the "tcp-mss" under the bgp session or ask your transmission dept to increase their mtu on the transport side (if supported). Majority of transmission techs aren't aware of this setting so you'll have to ask them to research it with equipment manufacturer. 

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of david.roy at orange-ftgroup.com
Sent: Monday, March 22, 2010 3:30 PM
To: 'Harry Reynolds'; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] BGP tcp-mss

Hi,

Just for info. A new PR 514196 has been opened to track this issue.

Regards,
David
 


 
David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com
 

-----Message d'origine-----
De : Harry Reynolds [mailto:harry at juniper.net] 
Envoy? : mercredi 3 f?vrier 2010 17:10
? : ROY David DTF/DERX; juniper-nsp at puck.nether.net
Objet : RE: BGP tcp-mss

I believe so. I only scanned, but did not seem platform or pmtu related.

Regards

 

-----Original Message-----
From: david.roy at orange-ftgroup.com [mailto:david.roy at orange-ftgroup.com]
Sent: Wednesday, February 03, 2010 2:39 AM
To: Harry Reynolds; juniper-nsp at puck.nether.net
Subject: RE: BGP tcp-mss

 
Hi,

Path MTU Discovery is disabled and I have the problem with MX, T640 and T1600 platforms. 
Do you think that the PR might include my case as well ? 

Regards,
David


 
David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com
 

-----Message d'origine-----
De : Harry Reynolds [mailto:harry at juniper.net] Envoy? : mercredi 3 f?vrier 2010 02:22 ? : ROY David DTF/DERX; juniper-nsp at puck.nether.net Objet : RE: BGP tcp-mss

Sounds like case 2009-0127-0051, which seems to have been fixed via pr 390993 around 9.4.

Hths

Harry






-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of david.roy at orange-ftgroup.com
Sent: Tuesday, February 02, 2010 6:55 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] BGP tcp-mss

Hi all,

Do you why, when I set the tcp-mss to 4096 between to BGP neighbors, this one is well exchange between the TCP Connection Establishment but when I check the mss via the command "show system connection extensive" I see that the mss used is 2048 (the half).


R1 config - lo0 172.20.223.6 :

  neighbor 172.20.223.5 {
        tcp-mss 4096;
    }
R2 config - lo0 172.20.223.5

  neighbor 172.20.223.6 {
        tcp-mss 4096;
    }

One Link between R1 and R2 with MTU set to 4484.

TCPDUMP output on R2 - we see that 4096 is well exchanged :

15:49:29.681732 Out IP 172.20.223.5.55025 > 172.20.223.6.179: S 2338565447:2338565447(0) win 16384 <mss 4096,nop,wscale 0,nop,nop,timestamp 2417320394 0,sackOK,eol>
15:49:29.682439  In IP 172.20.223.6.179 > 172.20.223.5.55025: S 1139135010:1139135010(0) ack 2338565448 win 16384 <mss 4096,nop,wscale 0,nop,nop,timestamp 455578404 2417320394,sackOK,eol>
15:49:29.682455 Out IP 172.20.223.5.55025 > 172.20.223.6.179: . ack 1 win 16384 <nop,nop,timestamp 2417320394 455578404>


On R2 : show system connection extensive | find 172.20.223.6

tcp4       0      0  172.20.223.5.55025                            172.20.223.6.179                              ESTABLISHED
   sndsbcc:          0 sndsbmbcnt:          0  sndsbmbmax:     131072
sndsblowat:       2048 sndsbhiwat:      16384
   rcvsbcc:          0 rcvsbmbcnt:          0  rcvsbmbmax:     131072
rcvsblowat:          1 rcvsbhiwat:      16384
   proc id:       1131  proc name:        rpd
       iss: 2338565447      sndup: 2338567245
    snduna: 2338567245     sndnxt: 2338567245      sndwnd:      16384
    sndmax: 2338567245    sndcwnd:       4096 sndssthresh: 1073725440
       irs: 1139135010      rcvup: 1139136242
    rcvnxt: 1139136261     rcvadv: 1139152645      rcvwnd:      16384
       rtt:          0       srtt:       2230        rttv:        574
    rxtcur:       1200   rxtshift:          0       rtseq: 2338567226
    rttmin:       1000  mss:       2048


N.B: Release 9.3

Thank you
Regards,
David


David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange-ftgroup.com<mailto:david.roy at orange-ftgroup.com>



*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From snar at snar.spb.ru  Mon Mar 22 16:35:19 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Mon, 22 Mar 2010 23:35:19 +0300
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322191636.GB75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
Message-ID: <20100322203519.GA33868@snar.spb.ru>

On Mon, Mar 22, 2010 at 02:16:36PM -0500, Richard A Steenbergen wrote:
> On Mon, Mar 22, 2010 at 05:31:38PM +0300, Alexandre Snarskii wrote:
> > I suppose you can use good old "hairpin cable" trick to have both
> > egress policers (converted to ingress ones on "switched" side of
> > hairpin) and counters on Vlan's (actually on subinterfaces on "routed"
> > side).  Not checked with ex-82xx, but it works for ex-[34]200.
> 
> I'm trying to picture the exact configuration you're talking about, but
> I'm not sure I get it. If you hairpined a trunk port, wouldn't you still
> have to configure the layer 2 vlans on the other side to do anything
> with them, and wouldn't they then be the same vlans as the originals? 

EX-series (at least [34]200) has the same "local vlan significance" 
principle that applies, for example, to OSM-equipped 6500/Sup2: 
"you can create chassis-wide vlan, and it will be used on all LAN 
cards, but you still can reuse the same vlan id on OSM subinterface", 
and the idea is actually stolen from some old recipe on "how to run 
6500/sup2 Vlan as a part of VRF". 
In case of ex-series it's even better - there are no 'internal vlan'
allocation that happens in case of 65xx/76xx. 

> Or were you saying that when you do a subinterface style it doesn't 
> actually use the vlan chassis-wide like it would if you did this 
> subinterface style config on a 6509 for example, and you were 
> proposing this:

Yes, you got the idea. 

> interface xe-1/0/0 {
>     vlan-tagging;
>     unit 101 {
>         vlan-id 101;
>         family inet {
>             address 1.2.3.4/24;
>         }
>     }
> }
> 
> interface xe-2/0/0 {
>     unit 0 {
>         family ethernet-switching {
>             port-mode trunk;
>             vlan {
>                 members VLAN101;
>             }
>         }
>     }
> }
> 
> vlans {
>     VLAN101 {
>         vlan-id 101;
>     }
> }
> 
> With a hairpin between xe-1/0/0 and xe-2/0/0, and then you could use 
> VLAN101 in whatever other configuration you wanted while still using 
> xe-1/0/0.101 for the counting?

From ras at e-gerbil.net  Mon Mar 22 19:16:50 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 22 Mar 2010 18:16:50 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322203519.GA33868@snar.spb.ru>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<20100322203519.GA33868@snar.spb.ru>
Message-ID: <20100322231650.GH75640@gerbil.cluepon.net>

On Mon, Mar 22, 2010 at 11:35:19PM +0300, Alexandre Snarskii wrote:
> EX-series (at least [34]200) has the same "local vlan significance" 
> principle that applies, for example, to OSM-equipped 6500/Sup2: 
> "you can create chassis-wide vlan, and it will be used on all LAN 
> cards, but you still can reuse the same vlan id on OSM subinterface", 
> and the idea is actually stolen from some old recipe on "how to run 
> 6500/sup2 Vlan as a part of VRF". 
> In case of ex-series it's even better - there are no 'internal vlan'
> allocation that happens in case of 65xx/76xx. 

That is indeed a fair bit better than the 6500/7600 vlan model, I guess
EX's vlan support isn't quite as bad as I thought. I swear I tested this
on EX4200 when we first got one (2 years ago) and I have a very strong
memory of this behavior not working this way, but damned if I can find
the emails with the test results to prove it.

On 6500, when you do something like this:

interface TenGigabitEthernet1/1.101
 encapsulation dot1Q 101
 ip address 1.2.3.4 255.255.255.0

It simply creates vlan 101 as an internal vlan, which consumes vlan 101
across the entire chassis and blocks the creation of another vlan 101 
anywhere else. Of course if you didn't do a subinterface but simply 
slapped an IP directly on the physical interface, it would simply pick a 
pseudo-random vlan ID to use, like so:

crisco6509#sh vlan internal usage 

VLAN Usage
---- --------------------
901  TenGigabitEthernet8/2.901
910  TenGigabitEthernet4/2.910
1606 TenGigabitEthernet8/2.1606
2201 TenGigabitEthernet8/2.2201
4032 TenGigabitEthernet3/4
4033 TenGigabitEthernet3/3
4034 TenGigabitEthernet3/2
4035 TenGigabitEthernet3/1
...


So... I'm wondering how much of this counter issue is really a hardware 
limitation, and how much is just design limitation. For example, would 
it be possible for Juniper to implement ethernet switching as 
essentially a multi-port ccc, like so:

interfaces {
    xe-1/0/0 {
        vlan-tagging;
        unit 101 {
            family inet {
                address 1.2.3.1/24;
            }
        }
        unit 201 {
            vlan-id 201;
            family ethernet-switching;
        }
    }
    xe-2/0/0 {
        vlan-tagging;
        unit 101 {
            family inet {
                address 2.3.4.1/24;
            }
        }
        unit 201 {
            vlan-id 201;
            family ethernet-switching;
        }
    }
}
vlans {
    blah {
        interface {
            xe-1/0/0.201;
            xe-2/0/0.201;
        }
    }
}

To me this seems like a much more natural way of handling mixed L2 and 
L3 configs on a single port anyways, and it could potentially let you 
have everything on a port which could be properly counted. Extra bonus 
points if there was a way to strip the vlan tag before putting it into 
the "multi-port ccc" so you could do vlan translation, but I don't know 
if that is possible in hardware (there is certainly no input-vlan-map to 
pop the vlan like on MX/etc, but this will be a problem when they get 
around to implementing mpls l2circuits).

The funny thing about the above configuration is that it doesn't seem to
be complaining about the lack of a vlan-id under vlan "blah", only about
the mixing vlan-tagging and family ethernet-switching. :)

Now say I took the above scenario and made it:

vlans {
    blah {
        interface {
            xe-1/0/0.201;
            xe-2/0/0.201;
            ...
        }
        l3-interface vlan.201;
    }
}

Today they don't have working counters on vlan.201, and Juniper claims
it is a hardware limitation they can't solve without some hackery like
firewall filter counters applied to each interface, but... If I can get
xe-1/0/0.101 counters today, could I also get xe-1/0/0.201 counters in
the above configuration? Possibly those could be added up internally to 
make a virtual vlan.201 counter, but worst case I could definitely do 
the additionl on my side post-SNMP collection.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From sfouant at shortestpathfirst.net  Mon Mar 22 19:18:55 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 22 Mar 2010 19:18:55 -0400
Subject: [j-nsp] SRX as Little Juniper BGP Box
In-Reply-To: <008c01cac9fb$d6d6dc20$84849460$@net>
References: <008c01cac9fb$d6d6dc20$84849460$@net>
Message-ID: <003701caca16$0b683370$22389a50$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Jay Hanke
> Sent: Monday, March 22, 2010 4:11 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] SRX as Little Juniper BGP Box
> 
> I was looking at the sheets and the SRX appears to give a little more
> "bang
> for buck" as compared to a j2320 or j2350. I wouldn't be afraid of the
> EX
> line but the cost of the AFL for BGP puts me out of the budget for the
> project.

IMO, with the release of the SRX platforms I really can't see why anyone
would still be looking at the J-Series.  I expect Juniper is going to slow
down the development of these platforms in favor of the SRX.

Although there are still a fair number of bugs on the SRX, for what you want
to do I think you'd be perfectly safe running an SRX platform.  I have
worked with several customers who are using this as their
edge-router/firewall platform with a good degree of success.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From jackson.tim at gmail.com  Mon Mar 22 19:29:36 2010
From: jackson.tim at gmail.com (Tim Jackson)
Date: Mon, 22 Mar 2010 18:29:36 -0500
Subject: [j-nsp] SRX as Little Juniper BGP Box
In-Reply-To: <003701caca16$0b683370$22389a50$@net>
References: <008c01cac9fb$d6d6dc20$84849460$@net>
	<003701caca16$0b683370$22389a50$@net>
Message-ID: <4407932e1003221629g11849864r699702ade5087c87@mail.gmail.com>

I second that. Buggy still but getting better...

On Mar 22, 2010 6:24 PM, "Stefan Fouant" <sfouant at shortestpathfirst.net>
wrote:

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> boun...
IMO, with the release of the SRX platforms I really can't see why anyone
would still be looking at the J-Series.  I expect Juniper is going to slow
down the development of these platforms in favor of the SRX.

Although there are still a fair number of bugs on the SRX, for what you want
to do I think you'd be perfectly safe running an SRX platform.  I have
worked with several customers who are using this as their
edge-router/firewall platform with a good degree of success.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.ne...

From jgoodwin at studio442.com.au  Mon Mar 22 20:45:22 2010
From: jgoodwin at studio442.com.au (Julien Goodwin)
Date: Tue, 23 Mar 2010 11:45:22 +1100
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
References: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
Message-ID: <4BA80F22.70200@studio442.com.au>

On 23/03/10 04:05, Hoogen wrote:
> I think the EX thread was really good and the feedback was awesome. I would
> like hear about similar experiences while deploying SRX Series gateways, I
> am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would
> also love to hear feedback on SRX 3000/5000 if people have been using it in
> their setup, problems that their facing, improvements and general deployment
> scenario that have been used.

So the big gotcha with the SRX line is the lack of IPv6 support. I've
been assured by a Juniper tech rep that over 10.2-10.4 it should get
closer to parity.

From my big evil list:
* SRX650 allowed me to configure {{family ethernet-switching}} on the
internal ports, which isn't supported
* SRX650 only supports LACP on {{family ethernet-switching}} ports,
which excludes the internal ports, EX4200 doesn't have this problem

From the firewall section (much of these are feature reqs)
* Allow to change the default policy per {{from-zone a to-zone d}}
* Allow to do {{from-zone any ...}} or perhaps just {{from-zone [ a b c
] to-zone d}}, this would be a *major* PITA in a hosting environment
with a zone per customer.
* Allow to have {{from-zone ... to-zone ...}} with no rules, I know the
default is implied with it not there
* Allow to have {{address-set}} inside {{address-set}} (ie, group of
groups), this is a *huge* PITA for us now
* The warning on {{show}} for an undefined application is {{Warning:
application or application-set must be defined}} which sucks when
multiple apps are defined, {{commit check}} is fine
* Documentation is unclear re NAT pool IP addresses. I had to add the
pool address to a loopback to get things working, until then the route
was never offered.

-- 
Julien Goodwin
Studio442
"Blue Sky Solutioneering"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100323/c0efff2e/attachment-0001.bin>

From rubensk at gmail.com  Mon Mar 22 21:53:51 2010
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 22 Mar 2010 22:53:51 -0300
Subject: [j-nsp] SRX as Little Juniper BGP Box
In-Reply-To: <008c01cac9fb$d6d6dc20$84849460$@net>
References: <008c01cac9fb$d6d6dc20$84849460$@net>
Message-ID: <6bb5f5b11003221853h3310ff36ubcab30a30a235ff9@mail.gmail.com>

Beware of the firewall nature of the SRX in situations like
asymmetrical routing; you can make a workaround using selective
firewall filters with the packet-mode clause, as long as you don't put
traffic where the router is the destination in packet mode (this has
to use flow mode).


Rubens


On Mon, Mar 22, 2010 at 5:11 PM, Jay Hanke <jhanke at myclearwave.net> wrote:
> I?m in need of a box that will handle up to ? gig of throughput and some
> very low volume BGP (about 200 routes + default) for IPv4 and IPv6 in the
> next couple of months.
>
>
>
> I was looking at the sheets and the SRX appears to give a little more ?bang
> for buck? as compared to a j2320 or j2350. I wouldn?t be afraid of the EX
> line but the cost of the AFL for BGP puts me out of the budget for the
> project.
>
>
>
> Has anyone used an SRX in a similar situation? Is the j-series still safer?
>
>
>
> Thanks,
>
>
>
> Jay
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


From rubensk at gmail.com  Mon Mar 22 22:12:41 2010
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 22 Mar 2010 23:12:41 -0300
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <4BA80F22.70200@studio442.com.au>
References: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
	<4BA80F22.70200@studio442.com.au>
Message-ID: <6bb5f5b11003221912maf79336x33392288f5ca93a6@mail.gmail.com>

> So the big gotcha with the SRX line is the lack of IPv6 support. I've
> been assured by a Juniper tech rep that over 10.2-10.4 it should get
> closer to parity.

Do you mean lack of stateful IPv6 support ? We've a config here in the
lab with 9.x running IPv6+BGP... we hit what we think is a bug (SRX
sending the link-local address of the loopback interface in the NLRI
alongside the public address of the loopback interface), but if the
other platform accepts that (Cisco IOS is ok with it, Quagga is not),
it works.


Rubens

From fahad.khan at gmail.com  Tue Mar 23 05:04:15 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Tue, 23 Mar 2010 14:04:15 +0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322231650.GH75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<20100322203519.GA33868@snar.spb.ru>
	<20100322231650.GH75640@gerbil.cluepon.net>
Message-ID: <d0cc41791003230204q326dc6c1oa5e8ed1944ff88ee@mail.gmail.com>

I really appreciate all for their inputs. Thanks a lot.

Is there any caveat in RTG, Can we easily get rid of STP running?? do you
recommend it or not??

Is there any special socket required for powering this chassis up?? as we
need industrial sockets in case of Cisco 6500.

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Tue, Mar 23, 2010 at 4:16 AM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Mon, Mar 22, 2010 at 11:35:19PM +0300, Alexandre Snarskii wrote:
> > EX-series (at least [34]200) has the same "local vlan significance"
> > principle that applies, for example, to OSM-equipped 6500/Sup2:
> > "you can create chassis-wide vlan, and it will be used on all LAN
> > cards, but you still can reuse the same vlan id on OSM subinterface",
> > and the idea is actually stolen from some old recipe on "how to run
> > 6500/sup2 Vlan as a part of VRF".
> > In case of ex-series it's even better - there are no 'internal vlan'
> > allocation that happens in case of 65xx/76xx.
>
> That is indeed a fair bit better than the 6500/7600 vlan model, I guess
> EX's vlan support isn't quite as bad as I thought. I swear I tested this
> on EX4200 when we first got one (2 years ago) and I have a very strong
> memory of this behavior not working this way, but damned if I can find
> the emails with the test results to prove it.
>
> On 6500, when you do something like this:
>
> interface TenGigabitEthernet1/1.101
>  encapsulation dot1Q 101
>  ip address 1.2.3.4 255.255.255.0
>
> It simply creates vlan 101 as an internal vlan, which consumes vlan 101
> across the entire chassis and blocks the creation of another vlan 101
> anywhere else. Of course if you didn't do a subinterface but simply
> slapped an IP directly on the physical interface, it would simply pick a
> pseudo-random vlan ID to use, like so:
>
> crisco6509#sh vlan internal usage
>
> VLAN Usage
> ---- --------------------
> 901  TenGigabitEthernet8/2.901
> 910  TenGigabitEthernet4/2.910
> 1606 TenGigabitEthernet8/2.1606
> 2201 TenGigabitEthernet8/2.2201
> 4032 TenGigabitEthernet3/4
> 4033 TenGigabitEthernet3/3
> 4034 TenGigabitEthernet3/2
> 4035 TenGigabitEthernet3/1
> ...
>
>
> So... I'm wondering how much of this counter issue is really a hardware
> limitation, and how much is just design limitation. For example, would
> it be possible for Juniper to implement ethernet switching as
> essentially a multi-port ccc, like so:
>
> interfaces {
>     xe-1/0/0 {
>        vlan-tagging;
>        unit 101 {
>             family inet {
>                address 1.2.3.1/24;
>            }
>        }
>        unit 201 {
>            vlan-id 201;
>            family ethernet-switching;
>        }
>    }
>    xe-2/0/0 {
>        vlan-tagging;
>        unit 101 {
>            family inet {
>                address 2.3.4.1/24;
>            }
>        }
>        unit 201 {
>            vlan-id 201;
>            family ethernet-switching;
>        }
>    }
> }
> vlans {
>    blah {
>        interface {
>            xe-1/0/0.201;
>            xe-2/0/0.201;
>        }
>    }
> }
>
> To me this seems like a much more natural way of handling mixed L2 and
> L3 configs on a single port anyways, and it could potentially let you
> have everything on a port which could be properly counted. Extra bonus
> points if there was a way to strip the vlan tag before putting it into
> the "multi-port ccc" so you could do vlan translation, but I don't know
> if that is possible in hardware (there is certainly no input-vlan-map to
> pop the vlan like on MX/etc, but this will be a problem when they get
> around to implementing mpls l2circuits).
>
> The funny thing about the above configuration is that it doesn't seem to
> be complaining about the lack of a vlan-id under vlan "blah", only about
> the mixing vlan-tagging and family ethernet-switching. :)
>
> Now say I took the above scenario and made it:
>
> vlans {
>    blah {
>        interface {
>            xe-1/0/0.201;
>            xe-2/0/0.201;
>            ...
>        }
>        l3-interface vlan.201;
>    }
> }
>
> Today they don't have working counters on vlan.201, and Juniper claims
> it is a hardware limitation they can't solve without some hackery like
> firewall filter counters applied to each interface, but... If I can get
> xe-1/0/0.101 counters today, could I also get xe-1/0/0.201 counters in
> the above configuration? Possibly those could be added up internally to
> make a virtual vlan.201 counter, but worst case I could definitely do
> the additionl on my side post-SNMP collection.
>
> --
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From cian.brennan at redbrick.dcu.ie  Tue Mar 23 05:16:38 2010
From: cian.brennan at redbrick.dcu.ie (Cian Brennan)
Date: Tue, 23 Mar 2010 09:16:38 +0000
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
References: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
Message-ID: <20100323091638.GA8787@minerva.redbrick.dcu.ie>

On Mon, Mar 22, 2010 at 10:05:46AM -0700, Hoogen wrote:
> I think the EX thread was really good and the feedback was awesome. I would
> like hear about similar experiences while deploying SRX Series gateways, I
> am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would
> also love to hear feedback on SRX 3000/5000 if people have been using it in
> their setup, problems that their facing, improvements and general deployment
> scenario that have been used.
> 

We've had rather a lot of difficulty with the URL filtering/Virus scanning
causing crashes on the 210. And with the URL filtering failing to recover if
the websense server went down on the same platform.

> -Hoogen
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

-- 

-- 

From telesis at nm.ru  Tue Mar 23 03:53:14 2010
From: telesis at nm.ru (telesis at nm.ru)
Date: Tue, 23 Mar 2010 10:53:14 +0300
Subject: [j-nsp] E320 policy input on dynamic PPPoE
Message-ID: <a0306f4ca3e6f84db5b95fa0326e5f67f611edfd@mail.qip.ru>

Hello all....

 I'm trying use route-class for matching LocalNets, "destination-route-class" don't match any pakets. All traffic match on C12-213.

===show policy
#sh policy-list P02-119807

                                  Policy Table
                                  ------ -----
IP Policy P02-119807
   Administrative state: enable
   Reference count:      128
   Classifier control list: C12-214, precedence 20000
      rate-limit-profile R12-26
   Classifier control list: C12-213, precedence 21000
      rate-limit-profile R12-25
   Classifier control list: C12-212, precedence 32000
      forward

#sh classifier-list C12-214

                         Classifier Control List Table
                         ---------- ------- ---- -----
IP C12-214.1 destination-route-class 60 ip any any
IP C12-214.2 destination-route-class 50 ip any any
IP C12-214.3 destination-route-class 30 ip any any
IP C12-214.4 destination-route-class 40 ip any any
IP C12-214.5 destination-route-class 20 ip any any

#sh classifier-list C12-213

                         Classifier Control List Table
                         ---------- ------- ---- -----
IP C12-213.1 ip any any

#sh classifier-list C12-212

                         Classifier Control List Table
                         ---------- ------- ---- -----
IP C12-212.1 ip any any

==sh ip ro {LocalIP}

#sh ip route  {LocalIP} detail
Protocol/Route type codes:
  I1- ISIS level 1, I2- ISIS level2,
  I- route type intra, IA- route type inter, E- route type external,
  i- metric type internal, e- metric type external,
  P- periodic download, O- OSPF, E1- external type 1, E2- external type2,
  N1- NSSA external type1, N2- NSSA external type2
  L- MPLS label, V- VRF, *- via indirect next-hop

{LocalIP}/32 Type: O-E2 Distance: 114 Metric: 700 Tag: 240 Class: 40
NextHop: 1.1.1.1 IntfIndex 0xF Intf TenGigabitEthernet0/0/0.418}

=== sh ip int 
TenGigabitEthernet0/0/0.428.658 line protocol Ppp is up, ip is up
  Network Protocols: IP
  Unnumbered Interface on loopback0
  ( IP address  xx.xxx.xx.xxx )
  Operational MTU = 1466  Administrative MTU = 0
  Operational speed = 10000 Mbps   Administrative speed = 0
  Discontinuity Time = 221419181
  Router advertisement = disabled
  Proxy Arp = disabled
  ARP spoof checking = enabled
  Network Address Translation is disabled
  TCP MSS Adjustment = disabled
  Administrative debounce-time = disabled
  Operational debounce-time    = disabled
  Access routing = enabled: Using xxx.yyy.zzz.07
  Multipath mode = hashed
  Auto Configure = disabled
  Auto Detect = disabled
  Inactivity Timer = disabled
  Use Framed Routes = disabled
  Warm-restart initial-sequence-preference: Operational = 0 Administrative = 0

  In Received Packets 5548, Bytes 946882
    Unicast Packets 5543, Bytes 946319
    Multicast Packets 5, Bytes 563
  In Policed Packets 0, Bytes 0
  In Error Packets 0
  In Invalid Source Address Packets 0
  In Discarded Packets 0
  Out Forwarded Packets 923, Bytes 635923
    Unicast Packets 923, Bytes 635923
    Multicast Routed Packets 0, Bytes 0
  Out Scheduler Dropped Packets 0, Bytes 0
  Out Policed Packets 0, Bytes 0
  Out Discarded Packets 0

  IP policy input P02-119807
    classifier-group C12-214 entry 1
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-214 entry 2
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-214 entry 3
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-214 entry 4
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-214 entry 5
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-213 entry 1
      5541 packets, 1112173 bytes
      rate-limit-profile R12-25
        committed rate: 1024000 bps, committed burst: 128000 bytes
        excess burst: 0 bytes
        committed: 5541 packets, 1112173 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-212 entry 1
      1 packets, 78 bytes
      forward
  IP policy output P02-119808
    classifier-group C12-215 entry 1
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-215 entry 2
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-215 entry 3
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-215 entry 4
      0 packets, 0 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 0 packets, 0 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-215 entry 5
      254 packets, 197611 bytes
      rate-limit-profile R12-26
        committed rate: 4294967295 bps, committed burst: 536870912 bytes
        excess burst: 0 bytes
        committed: 254 packets, 197611 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-213 entry 1
      671 packets, 467610 bytes
      rate-limit-profile R12-25
        committed rate: 1024000 bps, committed burst: 128000 bytes
        excess burst: 0 bytes
        committed: 671 packets, 467610 bytes, action: transmit
        conformed: 0 packets, 0 bytes, action: transmit
        exceeded:  0 packets, 0 bytes, action: drop
    classifier-group C12-212 entry 1
      0 packets, 0 bytes
      filter
  queue 0: traffic class best-effort, bound to ip
TenGigabitEthernet0/0/0.428.658
    Queue length 0 bytes
    Forwarded packets 1330, bytes 685241
    Dropped committed packets 0, bytes 0
    Dropped conformed packets 0, bytes 0
    Dropped exceeded packets 0, bytes 0



From felix.schueren at hosteurope.de  Tue Mar 23 06:30:25 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Tue, 23 Mar 2010 11:30:25 +0100
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <476710337.42460.1269165037839.JavaMail.root@claudius.linpro.no>
References: <476710337.42460.1269165037839.JavaMail.root@claudius.linpro.no>
Message-ID: <4BA89841.2070201@hosteurope.de>

Tore Anderson wrote:
> * Richard A Steenbergen
> 
>> Correct. I actually found some old gripes about this when I searched
>> j-nsp after noticing the problem, but it is a big enough issue that I
>> think it needs to be repeated again (and again and again, until it
>> gets fixed :P).
> 
> I'll be happy to join the choir on this one.  I reported the problem
> back in March 2009, got PR 435648 opened, but haven't heard anything
> more since then.
> 
> My workaround is to terminate the customer VLANs that needs counters
> for accounting purposes on the EX-es' upstream routers instead, which
> are MX-es with standard vlan-tagged family inet sub-interfaces.  That
> works well enough but it's not as tidy as I would have preferred.
> 
> Best regards,
chiming in here - we need to do the same, and we also ended up 
terminating L3 on our MXes when we'd really want to do it on the 8200s, 
yet the stupid messed up RVI counters don't allow us to do so.

Oh, there's more, btw. You can't do

vlan members [ 2-2999 ]
on a trunk port if you don't use ALL of those vlans. It won't commit, 
which means you have to use "vlan members all", which in turn messes up 
your one-interface-RVIs (that you have to use because you need to trunk 
some vlans on that port in addition to the family inet RVI)...

gah. Promising boxes, but they really messed up some points by looking 
to closely at how vendors B & C are doing it. That being said, we do use 
them in the data center, but they'd better get around fixing these things.

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen



From fahad.khan at gmail.com  Tue Mar 23 07:03:54 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Tue, 23 Mar 2010 16:03:54 +0500
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <20100323091638.GA8787@minerva.redbrick.dcu.ie>
References: <dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com>
	<20100323091638.GA8787@minerva.redbrick.dcu.ie>
Message-ID: <d0cc41791003230403r5fa2df13v9e942c482496b719@mail.gmail.com>

Means UTM has issues as well ??

How about the support of multicast ?? Has any one experienced running any
multicast based application across this Firewall??

regards

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Tue, Mar 23, 2010 at 2:16 PM, Cian Brennan
<cian.brennan at redbrick.dcu.ie>wrote:

> On Mon, Mar 22, 2010 at 10:05:46AM -0700, Hoogen wrote:
> > I think the EX thread was really good and the feedback was awesome. I
> would
> > like hear about similar experiences while deploying SRX Series gateways,
> I
> > am assuming I would hear a lot on the branch boxes SRX 210,240,650 I
> would
> > also love to hear feedback on SRX 3000/5000 if people have been using it
> in
> > their setup, problems that their facing, improvements and general
> deployment
> > scenario that have been used.
> >
>
> We've had rather a lot of difficulty with the URL filtering/Virus scanning
> causing crashes on the 210. And with the URL filtering failing to recover
> if
> the websense server went down on the same platform.
>
> > -Hoogen
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> --
>
> --
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From mdale at dalegroup.net  Tue Mar 23 08:10:08 2010
From: mdale at dalegroup.net (Michael Dale)
Date: Tue, 23 Mar 2010 23:10:08 +1100
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: dffd2e731003221005l69c86910g81dab045bf6054af@mail.gmail.com
Message-ID: <20100323121008.64fda6b1@mail.lttd.net>

I've had some serious issues with both my SRX 210 and 2x240s.

The SRX210 I have here at home was having all kinds of issues reconnecting if there was an ADSL drop. A restart routing command would fix this. This issue seems to have been mostly fixed in 10.0R2 and 10.1R1.

The pair of SRX240s on the other hand are still having issues. I recently setup a cluster with 10.1R1 which was all working fine in the lab, but after 10 ours of production all traffic simply stopped. I've logged into the devices via the console and cannot find any errors. No idea what is going on here. Not to mention the issues with ethernet switching and clustering...

Oh and no support for packet based traffic in clusters, so no IPv6 at all.

The older SSG line will have to keep me going until juniper fix some of these issues!

Michael.

----- Original Message -----
From: Hoogen [mailto:hoogen82 at gmail.com]
To:
juniper-nsp at puck.nether.net
Sent: Tue, 23 Mar 2010 04:05:46 +1100
Subject:
[j-nsp] SRX deployment / issues


> I think the EX thread was really good and the feedback was awesome. I would
> like hear about similar experiences while deploying SRX Series gateways, I
> am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would
> also love to hear feedback on SRX 3000/5000 if people have been using it in
> their setup, problems that their facing, improvements and general deployment
> scenario that have been used.
> 
> -Hoogen
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From paul at paulstewart.org  Tue Mar 23 08:50:01 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 23 Mar 2010 08:50:01 -0400
Subject: [j-nsp] Speed/Duplex Issue
Message-ID: <02b101caca87$5a330810$0e991830$@org>

Hi folks...

 

We just cut in another couple of EX4200's into production overnight.  These
are the first deployments that don't have pure GigE ports - several ports
100/full.

 

When I did the configuration I set the ether-options for 100/full ... most
of the ports are facing Cisco switches.  All the ports that were hard coded
would not come up at all - the minute I removed the ether-options they came
up and appear to be ok.

 

Is this normal?  Also, I'm wondering how you verify what duplex the port is
running at?  Sorry for basic question but for the life of me I can't find
this in the output or the docs...;)

 

Paul

 

 

 


From fahad.khan at gmail.com  Tue Mar 23 09:21:05 2010
From: fahad.khan at gmail.com (Fahad Khan)
Date: Tue, 23 Mar 2010 18:21:05 +0500
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <20100323121008.64fda6b1@mail.lttd.net>
References: <20100323121008.64fda6b1@mail.lttd.net>
Message-ID: <d0cc41791003230621v7c6e83dbiec4d0aaee9a40bcf@mail.gmail.com>

Seems to be looking some thing wrong with session table??

any one faced same thing with SRX650??

regards,
Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at 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


On Tue, Mar 23, 2010 at 5:10 PM, Michael Dale <mdale at dalegroup.net> wrote:

> I've had some serious issues with both my SRX 210 and 2x240s.
>
> The SRX210 I have here at home was having all kinds of issues reconnecting
> if there was an ADSL drop. A restart routing command would fix this. This
> issue seems to have been mostly fixed in 10.0R2 and 10.1R1.
>
> The pair of SRX240s on the other hand are still having issues. I recently
> setup a cluster with 10.1R1 which was all working fine in the lab, but after
> 10 ours of production all traffic simply stopped. I've logged into the
> devices via the console and cannot find any errors. No idea what is going on
> here. Not to mention the issues with ethernet switching and clustering...
>
> Oh and no support for packet based traffic in clusters, so no IPv6 at all.
>
> The older SSG line will have to keep me going until juniper fix some of
> these issues!
>
> Michael.
>
> ----- Original Message -----
> From: Hoogen [mailto:hoogen82 at gmail.com]
> To:
> juniper-nsp at puck.nether.net
> Sent: Tue, 23 Mar 2010 04:05:46 +1100
> Subject:
> [j-nsp] SRX deployment / issues
>
>
> > I think the EX thread was really good and the feedback was awesome. I
> would
> > like hear about similar experiences while deploying SRX Series gateways,
> I
> > am assuming I would hear a lot on the branch boxes SRX 210,240,650 I
> would
> > also love to hear feedback on SRX 3000/5000 if people have been using it
> in
> > their setup, problems that their facing, improvements and general
> deployment
> > scenario that have been used.
> >
> > -Hoogen
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From xmin0s at gmail.com  Tue Mar 23 09:27:53 2010
From: xmin0s at gmail.com (Tim Eberhard)
Date: Tue, 23 Mar 2010 07:27:53 -0600
Subject: [j-nsp] SRX deployment / issues
In-Reply-To: <d0cc41791003230621v7c6e83dbiec4d0aaee9a40bcf@mail.gmail.com>
References: <20100323121008.64fda6b1@mail.lttd.net>
	<d0cc41791003230621v7c6e83dbiec4d0aaee9a40bcf@mail.gmail.com>
Message-ID: <2c52b84e1003230627q419b4beek5281db04bec4d500@mail.gmail.com>

I know there was/is an issue on the older code versions of sessions being
built with the incorrect time out (if I recall correctly it was 48 hours).

It's easy to see though all one would have to do is look at a type of
session that you know would have a short duration time (such as ICMP or UDP)
and if you see a extremely large number then you've got an issue.

In the past on the netscreen platform I've seen various issues with the
NATAGER process (the process responsible for session table clean up) but so
far at least in my experience I haven't ran into an like that on the SRX
platform.

-Tim Eberhard

On Tue, Mar 23, 2010 at 7:21 AM, Fahad Khan <fahad.khan at gmail.com> wrote:

> Seems to be looking some thing wrong with session table??
>
> any one faced same thing with SRX650??
>
> regards,
> Muhammad Fahad Khan
> JNCIP - M/T # 834
> IT Specialist
> Global Technology Services, IBM
> fahad at 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
>
>
> On Tue, Mar 23, 2010 at 5:10 PM, Michael Dale <mdale at dalegroup.net> wrote:
>
> > I've had some serious issues with both my SRX 210 and 2x240s.
> >
> > The SRX210 I have here at home was having all kinds of issues
> reconnecting
> > if there was an ADSL drop. A restart routing command would fix this. This
> > issue seems to have been mostly fixed in 10.0R2 and 10.1R1.
> >
> > The pair of SRX240s on the other hand are still having issues. I recently
> > setup a cluster with 10.1R1 which was all working fine in the lab, but
> after
> > 10 ours of production all traffic simply stopped. I've logged into the
> > devices via the console and cannot find any errors. No idea what is going
> on
> > here. Not to mention the issues with ethernet switching and clustering...
> >
> > Oh and no support for packet based traffic in clusters, so no IPv6 at
> all.
> >
> > The older SSG line will have to keep me going until juniper fix some of
> > these issues!
> >
> > Michael.
> >
> > ----- Original Message -----
> > From: Hoogen [mailto:hoogen82 at gmail.com]
> > To:
> > juniper-nsp at puck.nether.net
> > Sent: Tue, 23 Mar 2010 04:05:46 +1100
> > Subject:
> > [j-nsp] SRX deployment / issues
> >
> >
> > > I think the EX thread was really good and the feedback was awesome. I
> > would
> > > like hear about similar experiences while deploying SRX Series
> gateways,
> > I
> > > am assuming I would hear a lot on the branch boxes SRX 210,240,650 I
> > would
> > > also love to hear feedback on SRX 3000/5000 if people have been using
> it
> > in
> > > their setup, problems that their facing, improvements and general
> > deployment
> > > scenario that have been used.
> > >
> > > -Hoogen
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From paul at paulstewart.org  Tue Mar 23 10:21:19 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 23 Mar 2010 10:21:19 -0400
Subject: [j-nsp] BPDU Question
Message-ID: <02d201caca94$1ba21ca0$52e655e0$@org>

Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol

 

I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out.  In the Cisco world we would setup a port
just like this:

 

interface GigabitEthernet3/2

 description xxxxxxxxxxx

 switchport

 switchport access vlan 66

 switchport mode access

 switchport nonegotiate

 no ip address

 no cdp enable

 no mop enabled

 spanning-tree bpdufilter enable

 

 

What is the equivalent to this in Juniper?  I tried setting up "bpdu
protect" one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...

 

Thanks ;)

 

Paul

 


From chrisccnpspam2 at gmail.com  Tue Mar 23 10:30:15 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Tue, 23 Mar 2010 14:30:15 +0000
Subject: [j-nsp] BPDU Question
Message-ID: <170941496-1269354619-cardhu_decombobulator_blackberry.rim.net-1220271027-@bda069.bisx.prod.on.blackberry>

What is the answer? :) 
------Original Message------
From: Paul Stewart
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] BPDU Question
Sent: Mar 23, 2010 10:21 AM

Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol

 

I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out.  In the Cisco world we would setup a port
just like this:

 

interface GigabitEthernet3/2

 description xxxxxxxxxxx

 switchport

 switchport access vlan 66

 switchport mode access

 switchport nonegotiate

 no ip address

 no cdp enable

 no mop enabled

 spanning-tree bpdufilter enable

 

 

What is the equivalent to this in Juniper?  I tried setting up "bpdu
protect" one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...

 

Thanks ;)

 

Paul

 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent via BlackBerry by AT&T


From paul at paulstewart.org  Tue Mar 23 10:34:25 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 23 Mar 2010 10:34:25 -0400
Subject: [j-nsp] BPDU Question
In-Reply-To: <170941496-1269354619-cardhu_decombobulator_blackberry.rim.net-1220271027-@bda069.bisx.prod.on.blackberry>
References: <170941496-1269354619-cardhu_decombobulator_blackberry.rim.net-1220271027-@bda069.bisx.prod.on.blackberry>
Message-ID: <02dd01caca95$efc82690$cf5873b0$@org>

Oh sorry, so the "show interface ge0/0/0 extensive" does show the actual
speed/duplex

My problem was around auto-neg and I though by specifying the speed and
duplex that this would disable auto-neg but you have to actually turn it off
in ether-options....

Paul


-----Original Message-----
From: chrisccnpspam2 at gmail.com [mailto:chrisccnpspam2 at gmail.com] 
Sent: March-23-10 10:30 AM
To: Paul Stewart; juniper-nsp-bounces at puck.nether.net;
juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] BPDU Question

What is the answer? :) 
------Original Message------
From: Paul Stewart
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] BPDU Question
Sent: Mar 23, 2010 10:21 AM

Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol

 

I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out.  In the Cisco world we would setup a port
just like this:

 

interface GigabitEthernet3/2

 description xxxxxxxxxxx

 switchport

 switchport access vlan 66

 switchport mode access

 switchport nonegotiate

 no ip address

 no cdp enable

 no mop enabled

 spanning-tree bpdufilter enable

 

 

What is the equivalent to this in Juniper?  I tried setting up "bpdu
protect" one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...

 

Thanks ;)

 

Paul

 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent via BlackBerry by AT&T



From N.Ardts at intermax.nl  Tue Mar 23 10:36:51 2010
From: N.Ardts at intermax.nl (Niels Ardts)
Date: Tue, 23 Mar 2010 15:36:51 +0100
Subject: [j-nsp] BPDU Question
In-Reply-To: <02d201caca94$1ba21ca0$52e655e0$@org>
References: <02d201caca94$1ba21ca0$52e655e0$@org>
Message-ID: <A797DC7AEC9C9D4BB50BAA40AF4896EF0143B59B43@EX01.intermax.local>

Hi Paul,

We've faced the same problem in the past and we created a firewall filter which does what you want:

{master:0}[edit firewall family ethernet-switching filter BPDU_FILTER]

term 1 {
    from {
        destination-mac-address {
            01:80:c2:00:00:00;
        }
    }
    then {
        discard;
        count BPDU_FILTER;
    }
}
term 2 {
    then accept;
}

This is applied to the interface input filter.

Additionally, we disable the port in MSTP like  'prototocols mstp interface XXX disable' so it does not send BPDU's to the customer.

I think with the newer JunOS versions there might be a better/smarter option though.. :)

Regards,
Niels




-----Oorspronkelijk bericht-----
Van: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] Namens Paul Stewart
Verzonden: dinsdag 23 maart 2010 15:21
Aan: juniper-nsp at puck.nether.net
Onderwerp: [j-nsp] BPDU Question

Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol



I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out.  In the Cisco world we would setup a port
just like this:



interface GigabitEthernet3/2

 description xxxxxxxxxxx

 switchport

 switchport access vlan 66

 switchport mode access

 switchport nonegotiate

 no ip address

 no cdp enable

 no mop enabled

 spanning-tree bpdufilter enable





What is the equivalent to this in Juniper?  I tried setting up "bpdu
protect" one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...



Thanks ;)



Paul



_______________________________________________
juniper-nsp mailing list juniper-nsp at 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.



From Wouter.vandenBergh at imtech.nl  Tue Mar 23 10:48:21 2010
From: Wouter.vandenBergh at imtech.nl (Wouter van den Bergh)
Date: Tue, 23 Mar 2010 15:48:21 +0100
Subject: [j-nsp] Low power warning
In-Reply-To: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
References: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
Message-ID: <7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>

Hi,

I am running into these errors on a virtual-chassis with 2 EX4200's:

Mar 22 16:14:20  chas[796]:  link 1 SFP receive power low  warning set
Mar 22 16:14:40  chas[796]:  link 1 SFP receive power low  warning cleared

Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles.

Regards,

Wouter


From cra at WPI.EDU  Tue Mar 23 11:27:22 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 23 Mar 2010 11:27:22 -0400
Subject: [j-nsp] Low power warning
In-Reply-To: <7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>
References: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
	<7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>
Message-ID: <20100323152722.GD6065@angus.ind.WPI.EDU>

On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh wrote:
> Mar 22 16:14:20  chas[796]:  link 1 SFP receive power low  warning set
> Mar 22 16:14:40  chas[796]:  link 1 SFP receive power low  warning cleared
> 
> Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles.

try:

show interfaces diagnostics optics ge-x/y/z

where x/y/z is where you have SFP interfaces, and look for low values 
in the "Receiver signal average optical power" field.  Unfortunately, 
you can't run the command without specifying each specific interface, 
one at a time--oh wait!  That now works in 10.1R1!

show interfaces diagnostics optics

shows output for each of the interfaces that has DOM capabilities.

Not sure when they enhanced that, but it didn't do that in 9.5R2.

From charlie at playlouder.com  Tue Mar 23 14:10:45 2010
From: charlie at playlouder.com (Charlie Allom)
Date: Tue, 23 Mar 2010 18:10:45 +0000
Subject: [j-nsp] EX4200 firewall only filters on physical ingress/egress?
In-Reply-To: <20100311012524.GA14727@spodder.com>
References: <20100311012524.GA14727@spodder.com>
Message-ID: <20100323181045.GE22218@spodder.com>

JTAC have confirmed that the port has to be crossed to have the filter
come into effect.

Hence why L2 vlan filters (VACLs) have their input/output meaning
reversed.

Not sure if my previous email makes sense, but thought I would update
here anyway.

Regards,
  C.

On Thu, Mar 11, 2010 at 01:25:27AM +0000, Charlie Allom wrote:
> Hello,
> 
> has anyone come up against this with the EX4200's? That a firewall
> filter will only affect a packet traversing a physical interface..
> 
> ==trunk==>[port A] (RVI A)..(RVI B) [port B]--access-->
>                                ^
>    filter applied here --------|
> 
> I was expecting the filter on 'input' on RVI B to block traffic, but it
> only works entirely when you filter on its 'output'.
> 
> Else the host behind [port B] gets the SYN, SYNACKs back, and /then/ it
> is blocked by the ethernet-switching or inet filter.
> 
> The docs don't mention this, except they never give an example of
> filtering on an RVI, just physical routed interfaces. But they DO say
> you can do it.. page 1368 of the "Software Guide for EX Series Ethernet
> Switches, Release 10.0".
> 
> What gives? (I have a case open with JTAC but it's hopeless trying to
> convince them to grasp and replicate, so far)
> 
> 
>   C.
> -- 
>  020 7729 4797
>  http://blog.playlouder.com/
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
 020 7729 4797
 http://blog.playlouder.com/

From ras at e-gerbil.net  Tue Mar 23 14:36:19 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 23 Mar 2010 13:36:19 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322191636.GB75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
Message-ID: <20100323183619.GJ75640@gerbil.cluepon.net>

On Mon, Mar 22, 2010 at 02:16:36PM -0500, Richard A Steenbergen wrote:
> protocols {
>     connections {
>         interface-switch test {
>             interface xe-1/0/0.101;
>             interface xe-1/0/1.101;
>         }
>     }
> }

Well for everyone woh asked, I tried the following on an EX8208 under
10.1R1, and it didn't work:

interfaces {
    ae0 {
        vlan-tagging;
        mtu 9216;
        ...
        unit 69 {
            vlan-id 69;
            family ccc;
        }
    }
    ae2 {
        vlan-tagging;
        mtu 9216;
        ...
        unit 69 {
            vlan-id 69;
            family ccc;
        }
    }
}

protocols {
    connections {
        interface-switch test {
            interface ae0.69;
            interface ae2.69;
        }
    }
}

Which of course errors because MPLS is still required to use CCC (who
knows why that has never been fixed :P):

ras at router# commit check 
re1: 
[edit protocols connections]
  'interface-switch test'
    CCC: Connection test error MPLS must be enabled to use CCC
error: configuration check-out failed

So turn on something in protocol MPLS to shut it up, which of course
turns on the log-filling no license nag (even though I do have an
advanced feature license, and the documentation says MPLS is included in
the AFL, go figure):

Mar 23 18:27:42.298  re1.router alarmd[734]: %DAEMON-4: Alarm cleared: 
License color=YELLOW, class=CHASSIS, reason=Multi Protocol Label 
Switching usage requires a license

And now the ccc looks like it should be up:

Connection/Circuit                Type        St      Time last up     # Up trans
test                              if-sw       Up      Mar 23 18:18:55           
1
  ae0.69                            intf  Up
  ae2.69                            intf  Up
                                                                   # Paths
  Time             Event                Interface/Label            Rcv Xmt
  Mar 23 18:18:56  CCC status update  
  Mar 23 18:18:55  Interface up         ae2.69                  
  Mar 23 18:18:55  Interface up         ae0.69                  
  Mar 23 18:18:55  CCC status update  
  Mar 23 18:18:55  Interface up         ae2.69                  
  Mar 23 18:18:55  Interface up         ae0.69                  

But no packets are passed through it, and the interface counters for
both sides show 0 packets received. Of course the correct way to
configure this on every other platform would be vlan-ccc rather than
just ccc, but on EX there is no vlan-ccc option and the ccc config
commits without error.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ras at e-gerbil.net  Tue Mar 23 15:02:22 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 23 Mar 2010 14:02:22 -0500
Subject: [j-nsp] Low power warning
In-Reply-To: <20100323152722.GD6065@angus.ind.WPI.EDU>
References: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
	<7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>
	<20100323152722.GD6065@angus.ind.WPI.EDU>
Message-ID: <20100323190222.GK75640@gerbil.cluepon.net>

On Tue, Mar 23, 2010 at 11:27:22AM -0400, Chuck Anderson wrote:
> On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh wrote:
> > Mar 22 16:14:20  chas[796]:  link 1 SFP receive power low  warning set
> > Mar 22 16:14:40  chas[796]:  link 1 SFP receive power low  warning cleared
> > 
> > Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles.
> 
> try:
> 
> show interfaces diagnostics optics ge-x/y/z
> 
> where x/y/z is where you have SFP interfaces, and look for low values 
> in the "Receiver signal average optical power" field.  Unfortunately, 
> you can't run the command without specifying each specific interface, 
> one at a time--oh wait!  That now works in 10.1R1!
> 
> show interfaces diagnostics optics
> 
> shows output for each of the interfaces that has DOM capabilities.
> 
> Not sure when they enhanced that, but it didn't do that in 9.5R2.

Hrm... The lack of ability to do "show interfaces diagnostic optics" and
see all interfaces has been on my bitch-list for the last 3+ years. I
had just given up hope that they were ever going to do anything to fix
it (or support the reverse order "show interface xe-0/0/0 diagnostics
optics" for that matter), so I had stopped even checking... But after 
reading this email I just went back and checked a bunch of boxes, and it 
actually IS working on MX on every version of code we're running (9.4R3 
being the oldest). Guess they slipped it in when we weren't looking.

I also just checked our lab EX4200 for the accuracy of the DOM readings
(currently running 10.1R1), and the news there is... less good. Both of
the interfaces are perfectly good working LR XFPs that work just fine in 
MX:

Physical interface: xe-0/1/0
    Laser bias current                        :  35.138 mA
    Laser output power                        :  0.5540 mW / -2.56 dBm
    Module temperature                        :  32 degrees C / 90 degrees F
    Laser rx power                            :  0.5460 mW / -2.63 dBm
    ...
    Laser output power high alarm             :  Off
    Laser output power low alarm              :  On
    Laser output power high warning           :  Off
    Laser output power low warning            :  On
    ...
    Tx data not ready alarm                   :  Off
    Tx not ready alarm                        :  Off
    Tx laser fault alarm                      :  Off
    Tx CDR loss of lock alarm                 :  On
    Rx not ready alarm                        :  On
    Rx loss of signal alarm                   :  On
    Rx CDR loss of lock alarm                 :  On

Apparently my transmit power of -2.56dBm (perfectly normal and in spec)
is setting off the low power alarm low, and even though I have link and
am passing packets, I have complete loss of signal too. The next one is
even worse:

Physical interface: xe-0/1/1
    Laser bias current                        :  42.375 mA
    Laser output power                        :  0.4670 mW / -3.31 dBm
    Module temperature                        :  37 degrees C / 99 degrees F
    Laser rx power                            :  0.0016 mW / -27.96 dBm

-27.96dBm is absurdly out of spec for LR, there is no possible way this 
link could be up if it was within even 10dB of being that low.

But that is still better than our EX8200 DOM under 10.1R1:

Physical interface: xe-0/0/0
    Laser bias current                        :  0.000 mA
    Laser output power                        :  0.0000
    Module temperature                        :  0 degrees C / 32 degrees F
    Module voltage                            :  0.0000 V
    Receiver signal average optical power     :  0.0000
    etc etc etc all 0's for everything...

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ras at e-gerbil.net  Tue Mar 23 15:13:11 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 23 Mar 2010 14:13:11 -0500
Subject: [j-nsp] JUNOS 9.6R3.8 on MX
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863BFC46CB24@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B863BFC46CB24@exchange.aoihq.local>
Message-ID: <20100323191311.GL75640@gerbil.cluepon.net>

On Mon, Mar 15, 2010 at 02:21:57PM -0400, Eric Van Tol wrote:
> Hi all,
> Any experiences with 9.6R3.8 on MX?  I have 9.5R4.3 installed on some
> newly acquired MX boxes, per the advice of this list.  However, I

Oh btw, a word a warning about 9.5R4 after everyone has hyped it up on
this list as the most stable code available for MX. I recently
discovered a nasty little bug where having bgp "accept-remote-nexthop"
turned on causes rpd to crash if the interface your eBGP neighbor is
connected to flaps (PR 500062). Unfortunately Juniper is refusing to
build a fix for 9.5 because 9.5 has reached the end of engineering
support. The funny part is that technically 9.5 reached the end of
engineering support (on 2/15/2010), 4 days before 9.5R4 was even
released (on 2/19/2010). I guess technically that means 9.5R4 was never 
supported at all. Great job guys, really. :)

FYI as a workaround turning off accept-remote-nexthop keeps rpd from
crashing (oh and btw when it does crash, it somehow wipes out a bunch of
directly connected interface routes from the krt in the process,
requiring you to manually remove and re-add the interface configs to
restore normal routing on them).

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From mtinka at globaltransit.net  Wed Mar 24 00:36:36 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 24 Mar 2010 12:36:36 +0800
Subject: [j-nsp] Speed/Duplex Issue
In-Reply-To: <02b101caca87$5a330810$0e991830$@org>
References: <02b101caca87$5a330810$0e991830$@org>
Message-ID: <201003241236.37778.mtinka@globaltransit.net>

On Tuesday 23 March 2010 08:50:01 pm Paul Stewart wrote:

> When I did the configuration I set the ether-options for
>  100/full ... most of the ports are facing Cisco
>  switches.  All the ports that were hard coded would not
>  come up at all - the minute I removed the ether-options
>  they came up and appear to be ok.

Did you hard-code the speed/duplex setting on both the Juniper 
and Cisco switches, or just the Juniper's?

We've been happy with auto-nego'ing all connections, including 
with upstreams. Life has been much easier going that route. I can't 
remember the last time anything good came out of hard-coding these 
settings, or when we last did that, for that matter.

> Is this normal?  Also, I'm wondering how you verify what
>  duplex the port is running at?  Sorry for basic question
>  but for the life of me I can't find this in the output
>  or the docs...;)

[edit]
test at lab# run show interfaces ge-0/1/3 | match Duplex 
  Link-level type: Ethernet, MTU: 9014, Speed: 1000mbps, Duplex: Full-Duplex, MAC-REWRITE Error: None, Loopback: Disabled, Source 
filtering: Disabled, Flow control: Enabled               ^^^^^^^^^^^^^^^^^^^^
						         ^^^^^^^^^^^^^^^^^^^^
[edit]
test at lab#

The above is taken off an EX3200.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100324/70c8843f/attachment.bin>

From paul at paulstewart.org  Wed Mar 24 05:55:32 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 24 Mar 2010 05:55:32 -0400
Subject: [j-nsp] Speed/Duplex Issue
In-Reply-To: <201003241236.37778.mtinka@globaltransit.net>
References: <02b101caca87$5a330810$0e991830$@org>
	<201003241236.37778.mtinka@globaltransit.net>
Message-ID: <039701cacb38$24bec690$6e3c53b0$@org>

> Did you hard-code the speed/duplex setting on both the Juniper and Cisco
switches, or just the Juniper's?

> We've been happy with auto-nego'ing all connections, including with
upstreams. Life has been much easier going that route. I can't remember the
last time anything good came out of hard-coding these settings, or when we
last did that, for that matter.

The Cisco's (customer equipment) were already hard coded as per our
instructions at the time.  Coming from the Cisco world we had a lot of
issues with auto-neg towards various makes/models of switch vendors.

Anyways, we're fixed now after understanding Juniper's approach to auto-neg
... thanks...;)

Paul




From ibariouen.khalid at ericsson.com  Wed Mar 24 05:55:12 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Wed, 24 Mar 2010 10:55:12 +0100
Subject: [j-nsp] question NAT - ISG2000
In-Reply-To: <201003241236.37778.mtinka@globaltransit.net>
References: <02b101caca87$5a330810$0e991830$@org>
	<201003241236.37778.mtinka@globaltransit.net>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA26692B36@ESESSCMS0364.eemea.ericsson.se>


Hi all

Actually we are Nating around 11500 active internet users by a ISG-2000 with 4 public Ip addresses

As my understanding the NAT is done per session not per user.
Can you please tell me how to check if those ip addresses are enough or not ?

BR/




From Wouter.vandenBergh at imtech.nl  Wed Mar 24 05:24:45 2010
From: Wouter.vandenBergh at imtech.nl (Wouter van den Bergh)
Date: Wed, 24 Mar 2010 10:24:45 +0100
Subject: [j-nsp] Low power warning
In-Reply-To: <20100323190222.GK75640@gerbil.cluepon.net>
References: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
	<7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>
	<20100323152722.GD6065@angus.ind.WPI.EDU>
	<20100323190222.GK75640@gerbil.cluepon.net>
Message-ID: <7393DD5B69CCB64D8F90EAB9808281499F23A94DDC@exb01.cs.imtechict.local>

Richard, Chuck,

Thanks for your replies. I should be able to work with those commands!

Cheers,

Wouter

-----Oorspronkelijk bericht-----
Van: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] Namens Richard A Steenbergen
Verzonden: dinsdag 23 maart 2010 20:02
Aan: juniper-nsp at puck.nether.net
Onderwerp: Re: [j-nsp] Low power warning

On Tue, Mar 23, 2010 at 11:27:22AM -0400, Chuck Anderson wrote:
> On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh wrote:
> > Mar 22 16:14:20  chas[796]:  link 1 SFP receive power low  warning set
> > Mar 22 16:14:40  chas[796]:  link 1 SFP receive power low  warning cleared
> > 
> > Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles.
> 
> try:
> 
> show interfaces diagnostics optics ge-x/y/z
> 
> where x/y/z is where you have SFP interfaces, and look for low values 
> in the "Receiver signal average optical power" field.  Unfortunately, 
> you can't run the command without specifying each specific interface, 
> one at a time--oh wait!  That now works in 10.1R1!
> 
> show interfaces diagnostics optics
> 
> shows output for each of the interfaces that has DOM capabilities.
> 
> Not sure when they enhanced that, but it didn't do that in 9.5R2.

Hrm... The lack of ability to do "show interfaces diagnostic optics" and
see all interfaces has been on my bitch-list for the last 3+ years. I
had just given up hope that they were ever going to do anything to fix
it (or support the reverse order "show interface xe-0/0/0 diagnostics
optics" for that matter), so I had stopped even checking... But after 
reading this email I just went back and checked a bunch of boxes, and it 
actually IS working on MX on every version of code we're running (9.4R3 
being the oldest). Guess they slipped it in when we weren't looking.

I also just checked our lab EX4200 for the accuracy of the DOM readings
(currently running 10.1R1), and the news there is... less good. Both of
the interfaces are perfectly good working LR XFPs that work just fine in 
MX:

Physical interface: xe-0/1/0
    Laser bias current                        :  35.138 mA
    Laser output power                        :  0.5540 mW / -2.56 dBm
    Module temperature                        :  32 degrees C / 90 degrees F
    Laser rx power                            :  0.5460 mW / -2.63 dBm
    ...
    Laser output power high alarm             :  Off
    Laser output power low alarm              :  On
    Laser output power high warning           :  Off
    Laser output power low warning            :  On
    ...
    Tx data not ready alarm                   :  Off
    Tx not ready alarm                        :  Off
    Tx laser fault alarm                      :  Off
    Tx CDR loss of lock alarm                 :  On
    Rx not ready alarm                        :  On
    Rx loss of signal alarm                   :  On
    Rx CDR loss of lock alarm                 :  On

Apparently my transmit power of -2.56dBm (perfectly normal and in spec)
is setting off the low power alarm low, and even though I have link and
am passing packets, I have complete loss of signal too. The next one is
even worse:

Physical interface: xe-0/1/1
    Laser bias current                        :  42.375 mA
    Laser output power                        :  0.4670 mW / -3.31 dBm
    Module temperature                        :  37 degrees C / 99 degrees F
    Laser rx power                            :  0.0016 mW / -27.96 dBm

-27.96dBm is absurdly out of spec for LR, there is no possible way this 
link could be up if it was within even 10dB of being that low.

But that is still better than our EX8200 DOM under 10.1R1:

Physical interface: xe-0/0/0
    Laser bias current                        :  0.000 mA
    Laser output power                        :  0.0000
    Module temperature                        :  0 degrees C / 32 degrees F
    Module voltage                            :  0.0000 V
    Receiver signal average optical power     :  0.0000
    etc etc etc all 0's for everything...

-- 
Richard A Steenbergen <ras at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From eric at atlantech.net  Wed Mar 24 06:59:01 2010
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 24 Mar 2010 06:59:01 -0400
Subject: [j-nsp] Strange IS-IS Problem
In-Reply-To: <66A8D063-2044-4465-ACF8-23E694BF6B92@fattoc.com>
References: <1903757449-1267967121-cardhu_decombobulator_blackberry.rim.net-70976675-@bda294.bisx.prod.on.blackberry>
	<ba5437101003080757m68269b24u30c61b46f994e2f5@mail.gmail.com>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C92D@exchange.aoihq.local>
	<2C05E949E19A9146AF7BDF9D44085B863BFC46C938@exchange.aoihq.local>
	<20100308185446.GF12615@angus.ind.WPI.EDU>
	<66A8D063-2044-4465-ACF8-23E694BF6B92@fattoc.com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863BFD85A5D2@exchange.aoihq.local>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Shane Ronan
> Sent: Tuesday, March 09, 2010 8:46 AM
> To: Chuck Anderson
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Strange IS-IS Problem
> 
> 
> On Mar 8, 2010, at 1:54 PM, Chuck Anderson wrote:
> 
> > I wonder if that is because the IS-IS Hello PDUs are being sent
> > as Ethernet Multicast frames
> 
> 
> This had been my suspicion as well. Is it possible to disable igmp-
> snooping on the EX2500's?
> 
> -Shane

As a follow-up to this problem, the above is exactly what was happening and the switch was dropping them.  The only workaround was to configure point-to-point.  That said, this problem is going to be fixed in the next version of BladeOS.  I have a pre-release version installed at the moment and it seems to work fine.

-evt


From ibariouen.khalid at ericsson.com  Wed Mar 24 09:39:35 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Wed, 24 Mar 2010 14:39:35 +0100
Subject: [j-nsp] sessions ISG 2000
In-Reply-To: <SNT105-DS8BC7AD8A0A5408A5AA2D88D250@phx.gbl>
References: <7B520BC9477F5B45B50F8A193CDD55DA26692ACD@ESESSCMS0364.eemea.ericsson.se>
	<SNT105-DS8BC7AD8A0A5408A5AA2D88D250@phx.gbl>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA26692C18@ESESSCMS0364.eemea.ericsson.se>

Hi all
Can someone tell me what's the meaning of the following output ?

Is it the number of sessions ??



GURGiFW:GURGiFW01(M)-> get performance session detail
Last 60 seconds:
 0:      818  1:      711  2:      723  3:      753  4:      697  5:      712
 6:      703  7:      720  8:      706  9:      722 10:      754 11:      737
12:      810 13:      717 14:      818 15:      794 16:      711 17:      732
18:      739 19:      789 20:      712 21:      756 22:      633 23:      687
24:      704 25:      776 26:      714 27:      649 28:      720 29:      635
30:      682 31:      748 32:      773 33:      723 34:      678 35:      836
36:      760 37:      752 38:      754 39:      748 40:      829 41:      709
42:      745 43:      720 44:      624 45:      689 46:      767 47:      748
48:      703 49:      687 50:      683 51:      723 52:      758 53:      753
54:      781 55:      753 56:      748 57:      796 58:      759 59:      719

Last 60 minutes:
 0:    43182  1:    43062  2:    42270  3:    42092  4:    42182  5:    41452
 6:    43388  7:    42766  8:    41878  9:    43618 10:    41223 11:    43629
12:    43512 13:    42015 14:    41240 15:    41713 16:    42376 17:    41089
18:    40845 19:    41254 20:    41706 21:    43379 22:    44066 23:    42946
24:    41307 25:    40752 26:    42202 27:    42116 28:    42065 29:    42664
30:    42105 31:    41580 32:    40966 33:    42879 34:    41547 35:    41210
36:    41028 37:    42219 38:    42228 39:    39627 40:    39858 41:    40927
42:    39653 43:    39048 44:    38701 45:    40059 46:    39197 47:    38769
48:    37620 49:    40328 50:    41233 51:    42655 52:    40946 53:    41503
54:    40446 55:    38491 56:    39515 57:    39991 58:    39151 59:    39603

Last 24 hours:
 0:  1477066  1:  2344774  2:  2073201  3:  1925822  4:  1787530  5:  1609260
 6:  1383548  7:  1040609  8:   809206  9:   696466 10:   671836 11:   845894
12:  1267113 13:  1939370 14:  2627395 15:  3258609 16:  3606961 17:  3573903
18:  3318069 19:  3093698 20:  2457813 21:  2331525 22:  2296393 23:  2455807

From xmin0s at gmail.com  Wed Mar 24 09:50:35 2010
From: xmin0s at gmail.com (Tim Eberhard)
Date: Wed, 24 Mar 2010 07:50:35 -0600
Subject: [j-nsp] sessions ISG 2000
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA26692C18@ESESSCMS0364.eemea.ericsson.se>
References: <7B520BC9477F5B45B50F8A193CDD55DA26692ACD@ESESSCMS0364.eemea.ericsson.se>
	<SNT105-DS8BC7AD8A0A5408A5AA2D88D250@phx.gbl>
	<7B520BC9477F5B45B50F8A193CDD55DA26692C18@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <2c52b84e1003240650g79e63434o9b18e8672ed35411@mail.gmail.com>

That is the number of sessions built per second, minute and then hour.

Starting off..
Last 60 seconds:
 0:      818  1:      711  2:      723  3:      753  4:      697  5:
 712

That is the last 60 seconds, so 818 sessions were built 1 second ago.

Last 24 hours:
 0:  1477066

1477066 were built in the last hour.


These are permitted connections.

Hope this helps,
-Tim Eberhard

On Wed, Mar 24, 2010 at 7:39 AM, Ibariouen Khalid <
ibariouen.khalid at ericsson.com> wrote:

> Hi all
> Can someone tell me what's the meaning of the following output ?
>
> Is it the number of sessions ??
>
>
>
> GURGiFW:GURGiFW01(M)-> get performance session detail
> Last 60 seconds:
>  0:      818  1:      711  2:      723  3:      753  4:      697  5:
>  712
>  6:      703  7:      720  8:      706  9:      722 10:      754 11:
>  737
> 12:      810 13:      717 14:      818 15:      794 16:      711 17:
>  732
> 18:      739 19:      789 20:      712 21:      756 22:      633 23:
>  687
> 24:      704 25:      776 26:      714 27:      649 28:      720 29:
>  635
> 30:      682 31:      748 32:      773 33:      723 34:      678 35:
>  836
> 36:      760 37:      752 38:      754 39:      748 40:      829 41:
>  709
> 42:      745 43:      720 44:      624 45:      689 46:      767 47:
>  748
> 48:      703 49:      687 50:      683 51:      723 52:      758 53:
>  753
> 54:      781 55:      753 56:      748 57:      796 58:      759 59:
>  719
>
> Last 60 minutes:
>  0:    43182  1:    43062  2:    42270  3:    42092  4:    42182  5:
>  41452
>  6:    43388  7:    42766  8:    41878  9:    43618 10:    41223 11:
>  43629
> 12:    43512 13:    42015 14:    41240 15:    41713 16:    42376 17:
>  41089
> 18:    40845 19:    41254 20:    41706 21:    43379 22:    44066 23:
>  42946
> 24:    41307 25:    40752 26:    42202 27:    42116 28:    42065 29:
>  42664
> 30:    42105 31:    41580 32:    40966 33:    42879 34:    41547 35:
>  41210
> 36:    41028 37:    42219 38:    42228 39:    39627 40:    39858 41:
>  40927
> 42:    39653 43:    39048 44:    38701 45:    40059 46:    39197 47:
>  38769
> 48:    37620 49:    40328 50:    41233 51:    42655 52:    40946 53:
>  41503
> 54:    40446 55:    38491 56:    39515 57:    39991 58:    39151 59:
>  39603
>
> Last 24 hours:
>  0:  1477066  1:  2344774  2:  2073201  3:  1925822  4:  1787530  5:
>  1609260
>  6:  1383548  7:  1040609  8:   809206  9:   696466 10:   671836 11:
> 845894
> 12:  1267113 13:  1939370 14:  2627395 15:  3258609 16:  3606961 17:
>  3573903
> 18:  3318069 19:  3093698 20:  2457813 21:  2331525 22:  2296393 23:
>  2455807
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From ibariouen.khalid at ericsson.com  Wed Mar 24 09:53:17 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Wed, 24 Mar 2010 14:53:17 +0100
Subject: [j-nsp] sessions ISG 2000
In-Reply-To: <2c52b84e1003240650g79e63434o9b18e8672ed35411@mail.gmail.com>
References: <7B520BC9477F5B45B50F8A193CDD55DA26692ACD@ESESSCMS0364.eemea.ericsson.se>
	<SNT105-DS8BC7AD8A0A5408A5AA2D88D250@phx.gbl>
	<7B520BC9477F5B45B50F8A193CDD55DA26692C18@ESESSCMS0364.eemea.ericsson.se>
	<2c52b84e1003240650g79e63434o9b18e8672ed35411@mail.gmail.com>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA26692C27@ESESSCMS0364.eemea.ericsson.se>

Thanks for ure feed-back
But how comes that I have 1477066 were built in the last hour and the license is limited to 500064 sessions ?
Waiting for your feed-back.
BR/

________________________________
From: Tim Eberhard [mailto:xmin0s at gmail.com]
Sent: mercredi 24 mars 2010 15:51
To: Ibariouen Khalid
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] sessions ISG 2000

That is the number of sessions built per second, minute and then hour.

Starting off..
Last 60 seconds:
 0:      818  1:      711  2:      723  3:      753  4:      697  5:      712

That is the last 60 seconds, so 818 sessions were built 1 second ago.

Last 24 hours:
 0:  1477066

1477066 were built in the last hour.


These are permitted connections.

Hope this helps,
-Tim Eberhard
On Wed, Mar 24, 2010 at 7:39 AM, Ibariouen Khalid <ibariouen.khalid at ericsson.com<mailto:ibariouen.khalid at ericsson.com>> wrote:
Hi all
Can someone tell me what's the meaning of the following output ?

Is it the number of sessions ??



GURGiFW:GURGiFW01(M)-> get performance session detail
Last 60 seconds:
 0:      818  1:      711  2:      723  3:      753  4:      697  5:      712
 6:      703  7:      720  8:      706  9:      722 10:      754 11:      737
12:      810 13:      717 14:      818 15:      794 16:      711 17:      732
18:      739 19:      789 20:      712 21:      756 22:      633 23:      687
24:      704 25:      776 26:      714 27:      649 28:      720 29:      635
30:      682 31:      748 32:      773 33:      723 34:      678 35:      836
36:      760 37:      752 38:      754 39:      748 40:      829 41:      709
42:      745 43:      720 44:      624 45:      689 46:      767 47:      748
48:      703 49:      687 50:      683 51:      723 52:      758 53:      753
54:      781 55:      753 56:      748 57:      796 58:      759 59:      719

Last 60 minutes:
 0:    43182  1:    43062  2:    42270  3:    42092  4:    42182  5:    41452
 6:    43388  7:    42766  8:    41878  9:    43618 10:    41223 11:    43629
12:    43512 13:    42015 14:    41240 15:    41713 16:    42376 17:    41089
18:    40845 19:    41254 20:    41706 21:    43379 22:    44066 23:    42946
24:    41307 25:    40752 26:    42202 27:    42116 28:    42065 29:    42664
30:    42105 31:    41580 32:    40966 33:    42879 34:    41547 35:    41210
36:    41028 37:    42219 38:    42228 39:    39627 40:    39858 41:    40927
42:    39653 43:    39048 44:    38701 45:    40059 46:    39197 47:    38769
48:    37620 49:    40328 50:    41233 51:    42655 52:    40946 53:    41503
54:    40446 55:    38491 56:    39515 57:    39991 58:    39151 59:    39603

Last 24 hours:
 0:  1477066  1:  2344774  2:  2073201  3:  1925822  4:  1787530  5:  1609260
 6:  1383548  7:  1040609  8:   809206  9:   696466 10:   671836 11:   845894
12:  1267113 13:  1939370 14:  2627395 15:  3258609 16:  3606961 17:  3573903
18:  3318069 19:  3093698 20:  2457813 21:  2331525 22:  2296393 23:  2455807
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp


From xmin0s at gmail.com  Wed Mar 24 10:00:44 2010
From: xmin0s at gmail.com (Tim Eberhard)
Date: Wed, 24 Mar 2010 08:00:44 -0600
Subject: [j-nsp] sessions ISG 2000
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA26692C27@ESESSCMS0364.eemea.ericsson.se>
References: <7B520BC9477F5B45B50F8A193CDD55DA26692ACD@ESESSCMS0364.eemea.ericsson.se>
	<SNT105-DS8BC7AD8A0A5408A5AA2D88D250@phx.gbl>
	<7B520BC9477F5B45B50F8A193CDD55DA26692C18@ESESSCMS0364.eemea.ericsson.se>
	<2c52b84e1003240650g79e63434o9b18e8672ed35411@mail.gmail.com>
	<7B520BC9477F5B45B50F8A193CDD55DA26692C27@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <2c52b84e1003240700p38a7bbd2l173997528ced95c@mail.gmail.com>

Those are the number of sessions built, not the number of co-current
sessions.

To see the total number of co-current sessions you can do a "get session
info".

How is it possible that 1477066 sessions were built in an hour? Sessions are
often built and torn down very quickly, case in point DNS or HTTP. A session
is built as the initial DNS request is sent, after a reply is seen the
session is torn down. The total duration is very very quick and the session
doesn't stay in the session table very long.

Without knowing your traffic type I cannot tell you if this is normal or
high. You can use a tool to analyze your session table that I wrote that
will tell you what kind of traffic you have passing through your firewall.
The tool is called NSSA (Netscreen Session Analyzer).

Hope this clears things up,
-Tim Eberhard

On Wed, Mar 24, 2010 at 7:53 AM, Ibariouen Khalid <
ibariouen.khalid at ericsson.com> wrote:

>  Thanks for ure feed-back
>
> But how comes that I have 1477066 were built in the last hour and the
> license is limited to 500064 sessions ?
>
> Waiting for your feed-back.
>
> BR/
>
>
>  ------------------------------
>
> *From:* Tim Eberhard [mailto:xmin0s at gmail.com]
> *Sent:* mercredi 24 mars 2010 15:51
> *To:* Ibariouen Khalid
> *Cc:* juniper-nsp at puck.nether.net
> *Subject:* Re: [j-nsp] sessions ISG 2000
>
>
>
> That is the number of sessions built per second, minute and then hour.
>
> Starting off..
> Last 60 seconds:
>  0:      818  1:      711  2:      723  3:      753  4:      697  5:
>  712
>
> That is the last 60 seconds, so 818 sessions were built 1 second ago.
>
> Last 24 hours:
>  0:  1477066
>
> 1477066 were built in the last hour.
>
>
> These are permitted connections.
>
> Hope this helps,
> -Tim Eberhard
>
> On Wed, Mar 24, 2010 at 7:39 AM, Ibariouen Khalid <
> ibariouen.khalid at ericsson.com> wrote:
>
> Hi all
> Can someone tell me what's the meaning of the following output ?
>
> Is it the number of sessions ??
>
>
>
> GURGiFW:GURGiFW01(M)-> get performance session detail
> Last 60 seconds:
>  0:      818  1:      711  2:      723  3:      753  4:      697  5:
>  712
>  6:      703  7:      720  8:      706  9:      722 10:      754 11:
>  737
> 12:      810 13:      717 14:      818 15:      794 16:      711 17:
>  732
> 18:      739 19:      789 20:      712 21:      756 22:      633 23:
>  687
> 24:      704 25:      776 26:      714 27:      649 28:      720 29:
>  635
> 30:      682 31:      748 32:      773 33:      723 34:      678 35:
>  836
> 36:      760 37:      752 38:      754 39:      748 40:      829 41:
>  709
> 42:      745 43:      720 44:      624 45:      689 46:      767 47:
>  748
> 48:      703 49:      687 50:      683 51:      723 52:      758 53:
>  753
> 54:      781 55:      753 56:      748 57:      796 58:      759 59:
>  719
>
> Last 60 minutes:
>  0:    43182  1:    43062  2:    42270  3:    42092  4:    42182  5:
>  41452
>  6:    43388  7:    42766  8:    41878  9:    43618 10:    41223 11:
>  43629
> 12:    43512 13:    42015 14:    41240 15:    41713 16:    42376 17:
>  41089
> 18:    40845 19:    41254 20:    41706 21:    43379 22:    44066 23:
>  42946
> 24:    41307 25:    40752 26:    42202 27:    42116 28:    42065 29:
>  42664
> 30:    42105 31:    41580 32:    40966 33:    42879 34:    41547 35:
>  41210
> 36:    41028 37:    42219 38:    42228 39:    39627 40:    39858 41:
>  40927
> 42:    39653 43:    39048 44:    38701 45:    40059 46:    39197 47:
>  38769
> 48:    37620 49:    40328 50:    41233 51:    42655 52:    40946 53:
>  41503
> 54:    40446 55:    38491 56:    39515 57:    39991 58:    39151 59:
>  39603
>
> Last 24 hours:
>  0:  1477066  1:  2344774  2:  2073201  3:  1925822  4:  1787530  5:
>  1609260
>  6:  1383548  7:  1040609  8:   809206  9:   696466 10:   671836 11:
> 845894
> 12:  1267113 13:  1939370 14:  2627395 15:  3258609 16:  3606961 17:
>  3573903
> 18:  3318069 19:  3093698 20:  2457813 21:  2331525 22:  2296393 23:
>  2455807
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>

From plunin at senetsy.ru  Wed Mar 24 17:06:15 2010
From: plunin at senetsy.ru (Pavel Lunin)
Date: Thu, 25 Mar 2010 00:06:15 +0300
Subject: [j-nsp] question NAT - ISG2000
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA26692B36@ESESSCMS0364.eemea.ericsson.se>
References: <02b101caca87$5a330810$0e991830$@org>
	<201003241236.37778.mtinka@globaltransit.net> 
	<7B520BC9477F5B45B50F8A193CDD55DA26692B36@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <77c10e261003241406v349e9ea7pa93d6b63f334d9a6@mail.gmail.com>

Hi Ibariouen,

Enough in this case can mean different things. Enough for what?

Usually not enough means that each external IP ?generate? too many
simultaneous and new (per second) sessions. This can trigger an attack
defence mechanisms on popular sites, etc.

But ?too many? is also quite not clear definition, but it is harder to
justify.

You can check how many sessions has each IP as a source with ?get session
info? command. You see total sessions and dividing them by the number of IPs
you can get the number of sessions per external IP. The same with new
sessions: issue ?get perf session detail?.

There is one tricky thing here. The values you get dividing the total
numbers of [new] sessions by the number of external IP, can be either exact
or average.

If you do not use dip stickiness (by default it is off), the sessions are
distributed uniformly over the pool?each new session is translated to the
next IP on round-robin basis. If you do, than there is a dispersion due to
each internal IP is always hardly mapped to an external one while it has
active sessions. In most situations people switch the stickiness on to get
multisession services (like IKE without ALG or even FTP) work properly.

You can check if the stickness is on with ?get dip? command. If you see
?Port-xlated dip stickness on? in its output, then the numbers of sessions
per IP are average, not exact. In this case you have to keep in mind that
the actual maximum of sessions per IP can be much higher that the average
since there are more and less active users. The numbers of sessions
generated by them can differ tenfold and more.

I believe in your particular case you will receive tens of thousands of
simultaneous and at least early thousands of new sessions per external IP.
Believe me, it s TOO many. ICQ and others should definitely block your
users.

--
Regards,
Pavel

2010/3/24 Ibariouen Khalid <ibariouen.khalid at ericsson.com>

>
> Hi all
>
> Actually we are Nating around 11500 active internet users by a ISG-2000
> with 4 public Ip addresses
>
> As my understanding the NAT is done per session not per user.
> Can you please tell me how to check if those ip addresses are enough or not
> ?
>
> BR/
>
>

From plunin at senetsy.ru  Wed Mar 24 17:31:15 2010
From: plunin at senetsy.ru (Pavel Lunin)
Date: Thu, 25 Mar 2010 00:31:15 +0300
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100322191636.GB75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com> 
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru> 
	<20100322191636.GB75640@gerbil.cluepon.net>
Message-ID: <77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>

2010/3/22 Richard A Steenbergen <ras at e-gerbil.net>

> But what happens when you do:
>
> interface xe-1/0/0 {
>    vlan-tagging;
>    unit 101 {
>        vlan-id 101;
>        family inet {
>            address 1.2.3.4/24;
>        }
>    }
> }
>
> interface xe-2/0/0 {
>    vlan-tagging;
>    unit 101 {
>        vlan-id 101;
>        family inet {
>            address 2.3.4.5/24;
>        }
>    }
> }
>
> Commit check doesn't error on it at any rate, but does this share
> packets within a vlan 101 space automatically, or not?


The outgoing iface for this piece of config will be chosen using the dst mac
address of the next hop, which is behind a particular interface. There is no
L2 switching here at all. I can confirm EX3/4200 allow to do so.

The main difference of EXs is that they only can do one lookup. E. g. either
L3 or L2, not both. So you can not mix families for units on the same
physical port.

However if you do inet on the port, you don't need to care if any other
ports do ether-switching for the same vlan or something. That said, it seems
like you don't need to be aware of all that VLAN significance cauchemar as
poor CCIE candidates :)

A good workaround (not counting doubled port consumption, delay and the
cable and SFPs cost) you can split the L2 and L3 lookups into two steps with
a hairpin as Alexandre proposed. It is also a way to convert input policiers
to output (thanks, Alexandre!).

But I am not sure about counters. No way if you want to count packets routed
through RVI on a VLAN sprung across multiple trunk ports.

Richard, one more thing. What do you do with the crash dumps untarzipping
them on the router/switch itself? I have never done anything with them but
sending to JTA. I believe it can have a lot of sense to pick them and
discover yourself (though I've never tried), but why on the switch itself?
Am I missing something important?

--
Kind regards,
Pavel

From cra at WPI.EDU  Wed Mar 24 18:37:58 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 24 Mar 2010 18:37:58 -0400
Subject: [j-nsp] EX4200 egress analyzer (mirror) bogus 802.1Q tags
Message-ID: <20100324223758.GV12189@angus.ind.WPI.EDU>

EX4200
JUNOS 10.1R1.8

Anyone else notice that packets captured by an egress analyzer have 
bogus 802.1Q tags?  Originally I thought that egress mirroring was 
broken because I saw no output when filtering on what I thought was 
the correct VLAN ID like this:

tcpdump -i eth1 -n -s0 -e -v vlan 123

but in fact after trying every combination and doing no filtering:

tcpdump -i eth1 -n -s0 -e -v -w test.pcap

and looking in Wireshark, I have verified that ingress/egress works 
using individual input interfaces, multiple input interfaces, all 
input interfaces, ae0 input interface, ingress only, egress only, 
both, etc. but it is just that any packets that are captured in the 
egress direction have bogus 802.1Q tags.  Ingress packets are always 
fine.  Untagged packets are always fine too (of course there is no tag 
to mess up).

foo at bar> show configuration ethernet-switching-options analyzer uplink
input {
    ingress {
        interface ae0.0;
        inactive: interface ge-1/1/0.0;
        inactive: interface ge-2/1/0.0;
        inactive: interface all;
    }
    egress {
        interface ae0.0;
        inactive: interface ge-1/1/0.0;
        inactive: interface ge-2/1/0.0;
        inactive: interface all;
    }
}
output {
    interface {
        ge-0/0/47.0;
    }
}

And it isn't just "bit-flipped" or soemthing similar.  The values 
change, but not completely randomly.  I haven't figured out the 
pattern yet...

From ras at e-gerbil.net  Wed Mar 24 19:21:31 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Wed, 24 Mar 2010 18:21:31 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
Message-ID: <20100324232131.GT75640@gerbil.cluepon.net>

On Thu, Mar 25, 2010 at 12:31:15AM +0300, Pavel Lunin wrote:
> Richard, one more thing. What do you do with the crash dumps
> untarzipping them on the router/switch itself? I have never done
> anything with them but sending to JTA. I believe it can have a lot of
> sense to pick them and discover yourself (though I've never tried),
> but why on the switch itself? Am I missing something important?

You can run gdb on the coredump files locally and get a pretty good idea
of what blew up and where, which is often quite helpful in working
around the original problem. Also, JTAC is far too often surprisingly
bad at working with coredumps, and without the ability to independently
verify things myself and tell them they were confused I've had some
cases which would probably never have been solved.

The story that was explained to me was that JTAC has some point and
click tool that they load the core into, which parses it and searches
their PR database to find matching backtraces. The problem is I'm
convinced at this point nobody in JTAC actually knows what a backtrace
is or how to read it, they just match it to whatever their tool tells
them, and surprisingly often their tool is very very wrong.

The other big problem of course is file size and compression. Apparently
their tool only works with .zip files not .tgz files (which is a small
bit of a problem, seeing as how the router only has gzip :P), so they
have to uncompress it locally first before they can load it. I've had
JTAC not know what a .tgz file was, I've had Advanced JTAC spend days
trying to figure out why they couldn't get any data out of a coredump
when the problem turned out to be their local filesystem quota wasn't
big enough to work with a large core file, etc, etc. Even when things
work "right" it seems to take them 12-72 hours to parse a coredump even
on a p1 case, and a healthy percentage of the time their analysis is
just flat out wrong. Without the ability to look at the dump yourself, 
you'd never know they were barking up the wrong tree.

Because EX uses PowerPC, it isn't even particularly easy to find a
FreeBSD ppc box where you can actually do any useful analysis of the
coredumps. That assumes of course that you have working connectivity on 
the box in question and can quickly copy the sometimes very large files 
off, which due to the original problem that caused the crash is often 
times not the case. And where do they plan on writing a 2GB core dump 
when there is an EX kernel panic and you only have 600MB of free space 
on an "empty" box? You can bet there will be, I run into them at least 
2 or 3 times a year on MX easily, it's just a fact of life. I mean 
seriously what does 32GB of flash cost, $100? Think about the amount of 
grief that will be caused by this in comparison, and tell me it was a 
smart move on their part. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From chrisccnpspam2 at gmail.com  Wed Mar 24 19:39:51 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Wed, 24 Mar 2010 23:39:51 +0000
Subject: [j-nsp] EX4200 egress analyzer (mirror) bogus 802.1Q tags
In-Reply-To: <20100324223758.GV12189@angus.ind.WPI.EDU>
References: <20100324223758.GV12189@angus.ind.WPI.EDU>
Message-ID: <1815314073-1269473993-cardhu_decombobulator_blackberry.rim.net-400059311-@bda069.bisx.prod.on.blackberry>

Open a jtac case? Need to get identified as a bug. 
Sent via BlackBerry by AT&T

-----Original Message-----
From: Chuck Anderson <cra at wpi.edu>
Date: Wed, 24 Mar 2010 18:37:58 
To: <juniper-nsp at puck.nether.net>
Subject: [j-nsp] EX4200 egress analyzer (mirror) bogus 802.1Q tags

EX4200
JUNOS 10.1R1.8

Anyone else notice that packets captured by an egress analyzer have 
bogus 802.1Q tags?  Originally I thought that egress mirroring was 
broken because I saw no output when filtering on what I thought was 
the correct VLAN ID like this:

tcpdump -i eth1 -n -s0 -e -v vlan 123

but in fact after trying every combination and doing no filtering:

tcpdump -i eth1 -n -s0 -e -v -w test.pcap

and looking in Wireshark, I have verified that ingress/egress works 
using individual input interfaces, multiple input interfaces, all 
input interfaces, ae0 input interface, ingress only, egress only, 
both, etc. but it is just that any packets that are captured in the 
egress direction have bogus 802.1Q tags.  Ingress packets are always 
fine.  Untagged packets are always fine too (of course there is no tag 
to mess up).

foo at bar> show configuration ethernet-switching-options analyzer uplink
input {
    ingress {
        interface ae0.0;
        inactive: interface ge-1/1/0.0;
        inactive: interface ge-2/1/0.0;
        inactive: interface all;
    }
    egress {
        interface ae0.0;
        inactive: interface ge-1/1/0.0;
        inactive: interface ge-2/1/0.0;
        inactive: interface all;
    }
}
output {
    interface {
        ge-0/0/47.0;
    }
}

And it isn't just "bit-flipped" or soemthing similar.  The values 
change, but not completely randomly.  I haven't figured out the 
pattern yet...
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From hoogen82 at gmail.com  Thu Mar 25 01:45:07 2010
From: hoogen82 at gmail.com (Hoogen)
Date: Wed, 24 Mar 2010 22:45:07 -0700
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100324232131.GT75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
Message-ID: <dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>

I think flash isn't going to be considered... It has a finite erase/write
cycles.. yeah but 8200 could have had more storage..

-Hoogen

On Wed, Mar 24, 2010 at 4:21 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Thu, Mar 25, 2010 at 12:31:15AM +0300, Pavel Lunin wrote:
> > Richard, one more thing. What do you do with the crash dumps
> > untarzipping them on the router/switch itself? I have never done
> > anything with them but sending to JTA. I believe it can have a lot of
> > sense to pick them and discover yourself (though I've never tried),
> > but why on the switch itself? Am I missing something important?
>
> You can run gdb on the coredump files locally and get a pretty good idea
> of what blew up and where, which is often quite helpful in working
> around the original problem. Also, JTAC is far too often surprisingly
> bad at working with coredumps, and without the ability to independently
> verify things myself and tell them they were confused I've had some
> cases which would probably never have been solved.
>
> The story that was explained to me was that JTAC has some point and
> click tool that they load the core into, which parses it and searches
> their PR database to find matching backtraces. The problem is I'm
> convinced at this point nobody in JTAC actually knows what a backtrace
> is or how to read it, they just match it to whatever their tool tells
> them, and surprisingly often their tool is very very wrong.
>
> The other big problem of course is file size and compression. Apparently
> their tool only works with .zip files not .tgz files (which is a small
> bit of a problem, seeing as how the router only has gzip :P), so they
> have to uncompress it locally first before they can load it. I've had
> JTAC not know what a .tgz file was, I've had Advanced JTAC spend days
> trying to figure out why they couldn't get any data out of a coredump
> when the problem turned out to be their local filesystem quota wasn't
> big enough to work with a large core file, etc, etc. Even when things
> work "right" it seems to take them 12-72 hours to parse a coredump even
> on a p1 case, and a healthy percentage of the time their analysis is
> just flat out wrong. Without the ability to look at the dump yourself,
> you'd never know they were barking up the wrong tree.
>
> Because EX uses PowerPC, it isn't even particularly easy to find a
> FreeBSD ppc box where you can actually do any useful analysis of the
> coredumps. That assumes of course that you have working connectivity on
> the box in question and can quickly copy the sometimes very large files
> off, which due to the original problem that caused the crash is often
> times not the case. And where do they plan on writing a 2GB core dump
> when there is an EX kernel panic and you only have 600MB of free space
> on an "empty" box? You can bet there will be, I run into them at least
> 2 or 3 times a year on MX easily, it's just a fact of life. I mean
> seriously what does 32GB of flash cost, $100? Think about the amount of
> grief that will be caused by this in comparison, and tell me it was a
> smart move on their part. :)
>
> --
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From ras at e-gerbil.net  Thu Mar 25 02:54:48 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 25 Mar 2010 01:54:48 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
Message-ID: <20100325065448.GX75640@gerbil.cluepon.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? :) 

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From snar at snar.spb.ru  Thu Mar 25 04:35:39 2010
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Thu, 25 Mar 2010 11:35:39 +0300
Subject: [j-nsp] EX4200 egress analyzer (mirror) bogus 802.1Q tags
In-Reply-To: <20100324223758.GV12189@angus.ind.WPI.EDU>
References: <20100324223758.GV12189@angus.ind.WPI.EDU>
Message-ID: <20100325083539.GA14333@snar.spb.ru>

On Wed, Mar 24, 2010 at 06:37:58PM -0400, Chuck Anderson wrote:
> EX4200
> JUNOS 10.1R1.8
> 
> Anyone else notice that packets captured by an egress analyzer have 
> bogus 802.1Q tags?  Originally I thought that egress mirroring was 

http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/release-notes/10.1/topic-42111.html#rn-junos-ex-limitations

On EX3200 and EX4200 switches, when port mirroring is configured on any 
interface, the mirrored packets leaving a tagged interface might contain 
an incorrect VLAN ID. 


> broken because I saw no output when filtering on what I thought was 
> the correct VLAN ID like this:
> 
> tcpdump -i eth1 -n -s0 -e -v vlan 123
> 
> but in fact after trying every combination and doing no filtering:
> 
> tcpdump -i eth1 -n -s0 -e -v -w test.pcap
> 
> and looking in Wireshark, I have verified that ingress/egress works 
> using individual input interfaces, multiple input interfaces, all 
> input interfaces, ae0 input interface, ingress only, egress only, 
> both, etc. but it is just that any packets that are captured in the 
> egress direction have bogus 802.1Q tags.  Ingress packets are always 
> fine.  Untagged packets are always fine too (of course there is no tag 
> to mess up).
> 
> foo at bar> show configuration ethernet-switching-options analyzer uplink
> input {
>     ingress {
>         interface ae0.0;
>         inactive: interface ge-1/1/0.0;
>         inactive: interface ge-2/1/0.0;
>         inactive: interface all;
>     }
>     egress {
>         interface ae0.0;
>         inactive: interface ge-1/1/0.0;
>         inactive: interface ge-2/1/0.0;
>         inactive: interface all;
>     }
> }
> output {
>     interface {
>         ge-0/0/47.0;
>     }
> }
> 
> And it isn't just "bit-flipped" or soemthing similar.  The values 
> change, but not completely randomly.  I haven't figured out the 
> pattern yet...
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

From martin.levin at molndal.se  Thu Mar 25 07:30:53 2010
From: martin.levin at molndal.se (Martin Levin)
Date: Thu, 25 Mar 2010 12:30:53 +0100
Subject: [j-nsp] Low power warning
In-Reply-To: <20100323190222.GK75640@gerbil.cluepon.net>
References: <mailman.3516.1265316008.2122.juniper-nsp@puck.nether.net>
	<7393DD5B69CCB64D8F90EAB9808281499F23A94BBE@exb01.cs.imtechict.local>
	<20100323152722.GD6065@angus.ind.WPI.EDU>
	<20100323190222.GK75640@gerbil.cluepon.net>
Message-ID: <4BAB577D020000D40001165F@gw.molndal.se>

Yes, I have the same problem here on EX[4,3]200 with XFP. SFPs seems to
work OK however.
 
Are these original Juniper XFPs? Because mine are not and if it's a
problem with Juniper original we'll have to wait until Juniper fixes
it... otherwise it might be a problem with the actual XFP.
 
---
Martin Levin
IT-strategy & planning
M?lndals stad


>>> 


Fr?n:Richard A Steenbergen <ras at e-gerbil.net>
Till:"juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Datum:2010-03-23 20:07
?rende:Re: [j-nsp] Low power warning
On Tue, Mar 23, 2010 at 11:27:22AM -0400, Chuck Anderson wrote:
> On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh
wrote:
> > Mar 22 16:14:20  chas[796]:  link 1 SFP receive power low  warning
set
> > Mar 22 16:14:40  chas[796]:  link 1 SFP receive power low  warning
cleared
> > 
> > Does anyone know how I can link this to the interface these
messages come from? It doesn't seem to appear anywhere in the logfiles.
> 
> try:
> 
> show interfaces diagnostics optics ge-x/y/z
> 
> where x/y/z is where you have SFP interfaces, and look for low values

> in the "Receiver signal average optical power" field.  Unfortunately,

> you can't run the command without specifying each specific interface,

> one at a time--oh wait!  That now works in 10.1R1!
> 
> show interfaces diagnostics optics
> 
> shows output for each of the interfaces that has DOM capabilities.
> 
> Not sure when they enhanced that, but it didn't do that in 9.5R2.

Hrm... The lack of ability to do "show interfaces diagnostic optics"
and
see all interfaces has been on my bitch-list for the last 3+ years. I
had just given up hope that they were ever going to do anything to fix
it (or support the reverse order "show interface xe-0/0/0 diagnostics
optics" for that matter), so I had stopped even checking... But after 
reading this email I just went back and checked a bunch of boxes, and
it 
actually IS working on MX on every version of code we're running (9.4R3

being the oldest). Guess they slipped it in when we weren't looking.

I also just checked our lab EX4200 for the accuracy of the DOM
readings
(currently running 10.1R1), and the news there is... less good. Both
of
the interfaces are perfectly good working LR XFPs that work just fine
in 
MX:

Physical interface: xe-0/1/0
    Laser bias current                        :  35.138 mA
    Laser output power                        :  0.5540 mW / -2.56 dBm
    Module temperature                        :  32 degrees C / 90
degrees F
    Laser rx power                            :  0.5460 mW / -2.63 dBm
    ...
    Laser output power high alarm             :  Off
    Laser output power low alarm              :  On
    Laser output power high warning           :  Off
    Laser output power low warning            :  On
    ...
    Tx data not ready alarm                   :  Off
    Tx not ready alarm                        :  Off
    Tx laser fault alarm                      :  Off
    Tx CDR loss of lock alarm                 :  On
    Rx not ready alarm                        :  On
    Rx loss of signal alarm                   :  On
    Rx CDR loss of lock alarm                 :  On

Apparently my transmit power of -2.56dBm (perfectly normal and in
spec)
is setting off the low power alarm low, and even though I have link
and
am passing packets, I have complete loss of signal too. The next one
is
even worse:

Physical interface: xe-0/1/1
    Laser bias current                        :  42.375 mA
    Laser output power                        :  0.4670 mW / -3.31 dBm
    Module temperature                        :  37 degrees C / 99
degrees F
    Laser rx power                            :  0.0016 mW / -27.96
dBm

-27.96dBm is absurdly out of spec for LR, there is no possible way this

link could be up if it was within even 10dB of being that low.

But that is still better than our EX8200 DOM under 10.1R1:

Physical interface: xe-0/0/0
    Laser bias current                        :  0.000 mA
    Laser output power                        :  0.0000
    Module temperature                        :  0 degrees C / 32
degrees F
    Module voltage                            :  0.0000 V
    Receiver signal average optical power     :  0.0000
    etc etc etc all 0's for everything...

-- 
Richard A Steenbergen <ras at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

From cra at WPI.EDU  Thu Mar 25 08:32:01 2010
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 25 Mar 2010 08:32:01 -0400
Subject: [j-nsp] EX4200 egress analyzer (mirror) bogus 802.1Q tags
In-Reply-To: <20100325083539.GA14333@snar.spb.ru>
References: <20100324223758.GV12189@angus.ind.WPI.EDU>
	<20100325083539.GA14333@snar.spb.ru>
Message-ID: <20100325123201.GA7939@angus.ind.WPI.EDU>

On Thu, Mar 25, 2010 at 11:35:39AM +0300, Alexandre Snarskii wrote:
> On Wed, Mar 24, 2010 at 06:37:58PM -0400, Chuck Anderson wrote:
> > EX4200
> > JUNOS 10.1R1.8
> > 
> > Anyone else notice that packets captured by an egress analyzer have 
> > bogus 802.1Q tags?  Originally I thought that egress mirroring was 
> 
> http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/release-notes/10.1/topic-42111.html#rn-junos-ex-limitations
> 
> On EX3200 and EX4200 switches, when port mirroring is configured on any 
> interface, the mirrored packets leaving a tagged interface might contain 
> an incorrect VLAN ID. 

Thanks.

You know, I had read that two weeks ago and had a feeling of deja vu 
when I actally ran into the problem last night, but for some reason 
didn't remember nor go back to check the obvious place.  Why is it 
that Release Notes don't seem to apply to your situation until you 
actually hit the problem?  Oh well.

Anyway, becase this is in the Limitations section, not the Outstanding 
Issues section, does that mean it won't/can't be fixed?

From danno at appliedi.net  Thu Mar 25 12:13:59 2010
From: danno at appliedi.net (Dan Farrell)
Date: Thu, 25 Mar 2010 09:13:59 -0700
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100325065448.GX75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
Message-ID: <06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>

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.
danno at 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



From jof at thejof.com  Thu Mar 25 12:51:20 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 25 Mar 2010 09:51:20 -0700
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
Message-ID: <1269534839-sup-3870@sfo.thejof.com>

Excerpts from Dan Farrell's message of Thu Mar 25 09:13:59 -0700 2010:
> 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.

I've definitely observed wearing out older multi-layer flash chips, but
every modern (in the last several years) flash device I've run across
implements some sort of damaged cell management on the chips controller.

If you're careful about how you access the device (mounting filesystems
with no atime, no heavy logging, etc.), I'm convinced that modern flash
works just fine in an embedded application like this.

That being said, I think Richard is right regarding adding expandable
flash. 
Flash is so cheap and constantly developing, it seems like a no
brainer to just eat the cost of adding a small controller-on-a-chip,
some discrete components, and a CF slot to future-proof the storage.

In looking at the EX platforms though, this doesn't seem in line with
Juniper's design goals though (not that I actually know what they
planned). It seems like most of the hardware ('cept the EX-8200) comes
in a fixed configuration -- stuff that's just supposed to "work", and
not to worry the manuf. with compatibility concerns.


If you're feeling gutsy and want to void any warranties, you might try
de-soldering and replacing the internal flash :)

Cheers,
jof

From ahabib at asacogroup.com  Thu Mar 25 12:55:56 2010
From: ahabib at asacogroup.com (adnan)
Date: Thu, 25 Mar 2010 19:55:56 +0300
Subject: [j-nsp] JNCIE-ER
In-Reply-To: <06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>	<20100320150313.GT75640@gerbil.cluepon.net>	<20100322143138.GE30843@snar.spb.ru>	<20100322191636.GB75640@gerbil.cluepon.net>	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>	<20100324232131.GT75640@gerbil.cluepon.net>	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>	<20100325065448.GX75640@gerbil.cluepon.net>
	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
Message-ID: <000001cacc3c$108cafc0$31a60f40$@com>

Dear All


I am preparing my JNCIE-ER . if anyone is also preparing contact me  so we
can share the material .



Best regard  



From chrisccnpspam2 at gmail.com  Thu Mar 25 13:42:07 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Thu, 25 Mar 2010 17:42:07 +0000
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <1269534839-sup-3870@sfo.thejof.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com><20100320150313.GT75640@gerbil.cluepon.net><20100322143138.GE30843@snar.spb.ru><20100322191636.GB75640@gerbil.cluepon.net><77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com><20100324232131.GT75640@gerbil.cluepon.net><dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com><20100325065448.GX75640@gerbil.cluepon.net><06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local><1269534839-sup-3870@sfo.thejof.com>
Message-ID: <1043294041-1269538929-cardhu_decombobulator_blackberry.rim.net-1407675542-@bda069.bisx.prod.on.blackberry>

My opinion.  As long as I get a decent lifetime out of it who cares. This is what managements systems are for, to backup my devices. Service contracts take care of the rest. 

Hardware fails, just the nature of the game. 
Sent via BlackBerry by AT&T

-----Original Message-----
From: Jonathan Lassoff <jof at thejof.com>
Date: Thu, 25 Mar 2010 09:51:20 
To: Dan Farrell<danno at appliedi.net>
Cc: juniper-nsp at puck.nether.net<juniper-nsp at puck.nether.net>; Richard A Steenbergen<ras at e-gerbil.net>
Subject: Re: [j-nsp] EX 8200 deployment

Excerpts from Dan Farrell's message of Thu Mar 25 09:13:59 -0700 2010:
> 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.

I've definitely observed wearing out older multi-layer flash chips, but
every modern (in the last several years) flash device I've run across
implements some sort of damaged cell management on the chips controller.

If you're careful about how you access the device (mounting filesystems
with no atime, no heavy logging, etc.), I'm convinced that modern flash
works just fine in an embedded application like this.

That being said, I think Richard is right regarding adding expandable
flash. 
Flash is so cheap and constantly developing, it seems like a no
brainer to just eat the cost of adding a small controller-on-a-chip,
some discrete components, and a CF slot to future-proof the storage.

In looking at the EX platforms though, this doesn't seem in line with
Juniper's design goals though (not that I actually know what they
planned). It seems like most of the hardware ('cept the EX-8200) comes
in a fixed configuration -- stuff that's just supposed to "work", and
not to worry the manuf. with compatibility concerns.


If you're feeling gutsy and want to void any warranties, you might try
de-soldering and replacing the internal flash :)

Cheers,
jof
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From palanchi at rutgers.edu  Thu Mar 25 12:50:28 2010
From: palanchi at rutgers.edu (Philip Palanchi)
Date: Thu, 25 Mar 2010 12:50:28 -0400 (EDT)
Subject: [j-nsp] LLDP between cisco and juniper
Message-ID: <469221143.184530.1269535828700.JavaMail.root@zimmbox12.rutgers.edu>

I have enabled LLDP between several mx240's JUNOS 9.6R1.13 with DPCE-R-20GE-2XGE and several cisco 6506's.  LLDP works fine in both directions for anything connected by a 10G interface.  None of the mx240's sees the cisco LLDP neighbor connected by 1GE interface.  However, the cisco's see the mx240's.  All I see are errors as below.  Has anyone else had this problem?

me at mx240> show lldp statistics    
Interface  Received  Unknown TLVs  With Errors  Discarded TLVs  Transmitted  Untransmitted
ge-2/0/0   0         0             43589        43589           43375        0       
ge-2/1/0   0         0             45611        45611           45386        0       
xe-2/2/0   43898     0             0            0               43900        572     
xe-2/3/0   45611     0             0            0               45386        0

Thanks,
Phil

From chrisccnpspam2 at gmail.com  Thu Mar 25 13:53:17 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Thu, 25 Mar 2010 17:53:17 +0000
Subject: [j-nsp] LLDP between cisco and juniper
Message-ID: <1705208913-1269539599-cardhu_decombobulator_blackberry.rim.net-1571525203-@bda069.bisx.prod.on.blackberry>

Ived tested this with a 3750 in my lab connected to a MX480 and an EX4200.   From what I remember it functions both ways. I am used gige. I will very and get back to you. 

I am testing 9.6R3.8 on both Juniper and 12.2(50)SE3 on the 3750. 

Im
------Original Message------
From: Philip Palanchi
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp
Subject: [j-nsp] LLDP between cisco and juniper
Sent: Mar 25, 2010 12:50 PM

I have enabled LLDP between several mx240's JUNOS 9.6R1.13 with DPCE-R-20GE-2XGE and several cisco 6506's.  LLDP works fine in both directions for anything connected by a 10G interface.  None of the mx240's sees the cisco LLDP neighbor connected by 1GE interface.  However, the cisco's see the mx240's.  All I see are errors as below.  Has anyone else had this problem?

me at mx240> show lldp statistics    
Interface  Received  Unknown TLVs  With Errors  Discarded TLVs  Transmitted  Untransmitted
ge-2/0/0   0         0             43589        43589           43375        0       
ge-2/1/0   0         0             45611        45611           45386        0       
xe-2/2/0   43898     0             0            0               43900        572     
xe-2/3/0   45611     0             0            0               45386        0

Thanks,
Phil
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent via BlackBerry by AT&T


From fitzgeraldb at camosun.bc.ca  Thu Mar 25 13:58:22 2010
From: fitzgeraldb at camosun.bc.ca (Brian Fitzgerald)
Date: Thu, 25 Mar 2010 10:58:22 -0700
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <1269534839-sup-3870@sfo.thejof.com>
Message-ID: <C7D0F24E.6652%fitzgeraldb@camosun.bc.ca>




On 10-03-25 9:51 AM, "Jonathan Lassoff" <jof at thejof.com> wrote:

> Excerpts from Dan Farrell's message of Thu Mar 25 09:13:59 -0700 2010:
>> 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.
...
> 
> In looking at the EX platforms though, this doesn't seem in line with
> Juniper's design goals though (not that I actually know what they
> planned). It seems like most of the hardware ('cept the EX-8200) comes
> in a fixed configuration -- stuff that's just supposed to "work", and
> not to worry the manuf. with compatibility concerns.
> 

They do allow the mounting of a USB flash device.  Of course, the usual
admonishment about using Juniper USB devices, but you can mount a fat32
formatted USB key:

* Enter the shell as root:
user at switch> start shell user root
Password:
root at switch%

* Mount USB to /mnt
root at switch% mount_msdosfs /dev/da1s1 /mnt

* Check the contents in USB?disk
root at switch% ls /mnt
juniper.conf.1.gz?????? juniper.conf.3.gz?????? rescue.conf.gz
juniper.conf.2.gz?????? juniper.conf.gz

* Unmount usb disk and then pull it out.
user at switch% umount /mnt

http://kb.juniper.net/KB12880
http://kb.juniper.net/KB12022

USB keys are cheap too - cheap enough to replace as part of yearly
maintenance.

As usual, YMMV - some USB keys are better than others, and I haven't tried
any larger than 4G.

> 
> If you're feeling gutsy and want to void any warranties, you might try
> de-soldering and replacing the internal flash :)
> 

Heh.  Sounds like fun - maybe with a unit once it gets older/off
warranty/maintenance.

Take care

Brian Fitzgerald



From paul at paulstewart.org  Thu Mar 25 15:13:31 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 25 Mar 2010 15:13:31 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
Message-ID: <00a801cacc4f$41ee4f20$c5caed60$@org>

Hi there.

 

We're originally a Cisco shop slowly converting to Juniper .

 

I'm looking for feedback from folks on the list who are service providers
and connect to peering exchange points (IE. PAIX, Equinix, LINX etc).   I'm
looking for recommended configuration for layer2 connectivity via an EX
switch towards one of these exchange points - we have been doing in Cisco so
long that I'm missing some obvious config in the Juniper's we just moved to
;)

 

Perhaps I should explain a bit better. in the Cisco world, we configure the
physical port like this:

 

interface GigabitEthernet3/3

 description xxxxx

 switchport

 switchport access vlan 61

 switchport mode access

 no ip address

 speed 100

 duplex full

 no cdp enable

 no mop enabled

 spanning-tree bpdufilter enable

 

Juniper port we migrated to:

 

ether-options {

    no-auto-negotiation;

    link-mode full-duplex;

    speed {

        100m;

    }

}

unit 0 {

    family ethernet-switching {

        port-mode access;

        vlan {

            members Peering-xxxxx;

        }

    }

}

 

protocols {

    rstp {

        interface ge-0/0/3.0 {

            disable;

        }

}

 

Then from the Juniper switch (or the Cisco that we had in place) the traffic
is trunked via a couple of other switches back to a Cisco 7600 for layer3
traffic (which hasn't changed at all):

 

interface Vlan61

 description Peering:xxxxxx

 ip address xx.xx.xxx.34 255.255.255.0

 ip access-group 199 out

 no ip redirects

 no ip proxy-arp

 ip flow ingress

 ipv6 address xx:xx:xx::34/64

 ipv6 nd ra suppress

 no ipv6 mld router

 no ipv6 redirects

 no ipv6 pim

 no mop enabled

end

 

 

The problem I'm facing we're tripping the port security on the exchange
switch:

 

Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
violation occurred, caused by MAC address 000b.45b6.f500 on port
FastEthernet0/1.

 

It is obviously seeing several MAC addresses and doesn't like this.  so I'm
trying to adapt a "best practice" here based on what other folks have
encountered along the way as we're trying our best to learn Juniper better
;)

 

Thanks,

 

Paul

 


From jof at thejof.com  Thu Mar 25 16:02:51 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 25 Mar 2010 13:02:51 -0700
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <00a801cacc4f$41ee4f20$c5caed60$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
Message-ID: <1269547147-sup-1236@sfo.thejof.com>

Excerpts from Paul Stewart's message of Thu Mar 25 12:13:31 -0700 2010:
> I'm looking for feedback from folks on the list who are service providers
> and connect to peering exchange points (IE. PAIX, Equinix, LINX etc).   I'm
> looking for recommended configuration for layer2 connectivity via an EX
> switch towards one of these exchange points - we have been doing in Cisco so
> long that I'm missing some obvious config in the Juniper's we just moved to
> ;)

AMS-IX has a nice guide and some useful suggestions over here:
http://www.ams-ix.net/config-guide/#10


> The problem I'm facing we're tripping the port security on the exchange
> switch:
> 
>  
> 
> Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> violation occurred, caused by MAC address 000b.45b6.f500 on port
> FastEthernet0/1.
> 
> It is obviously seeing several MAC addresses and doesn't like this.  so I'm
> trying to adapt a "best practice" here based on what other folks have
> encountered along the way as we're trying our best to learn Juniper better
> ;)

Doh!

If your platform supports it, implement a packet filter that blocks all
traffic except for the single MAC that you think should be on that port.

Maybe IGMP is leaking out?

Also, depending on your platform, tcpdump (probably not much help on an
L2 switch configuration) or a passive tap could provide some indication
as to what traffic is causing port security to trip on the far side.

Is 00:0b:45:b6:f5:00 the Ethernet MAC you expect to be seeing?

Cheers,
jof

From paul at paulstewart.org  Thu Mar 25 16:09:51 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 25 Mar 2010 16:09:51 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <1269547147-sup-1236@sfo.thejof.com>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<1269547147-sup-1236@sfo.thejof.com>
Message-ID: <00ad01cacc57$20a7cf50$61f76df0$@org>

Thanks very much for the reply...

The AMS-IX guide I've been through but their Juniper section isn't nearly as
detailed as the Cisco side... good guide for sure. ;)

The MAC shown in my example below is actually the correct MAC for the layer3
facing interface ... so you're suggesting to create a filter to only allow
that MAC to be 'sent out' to the peering switch?  We never had to do this in
the Cisco world using the configurations I sent in my original post hence
some of my confusion...

Appreciate it,

Paul


-----Original Message-----
From: Jonathan Lassoff [mailto:jof at thejof.com] 
Sent: Thursday, March 25, 2010 4:03 PM
To: Paul Stewart
Cc: jnsp
Subject: Re: [j-nsp] EX Switches - Internet Exchange Points

Excerpts from Paul Stewart's message of Thu Mar 25 12:13:31 -0700 2010:
> I'm looking for feedback from folks on the list who are service providers
> and connect to peering exchange points (IE. PAIX, Equinix, LINX etc).
I'm
> looking for recommended configuration for layer2 connectivity via an EX
> switch towards one of these exchange points - we have been doing in Cisco
so
> long that I'm missing some obvious config in the Juniper's we just moved
to
> ;)

AMS-IX has a nice guide and some useful suggestions over here:
http://www.ams-ix.net/config-guide/#10


> The problem I'm facing we're tripping the port security on the exchange
> switch:
> 
>  
> 
> Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> violation occurred, caused by MAC address 000b.45b6.f500 on port
> FastEthernet0/1.
> 
> It is obviously seeing several MAC addresses and doesn't like this.  so
I'm
> trying to adapt a "best practice" here based on what other folks have
> encountered along the way as we're trying our best to learn Juniper better
> ;)

Doh!

If your platform supports it, implement a packet filter that blocks all
traffic except for the single MAC that you think should be on that port.

Maybe IGMP is leaking out?

Also, depending on your platform, tcpdump (probably not much help on an
L2 switch configuration) or a passive tap could provide some indication
as to what traffic is causing port security to trip on the far side.

Is 00:0b:45:b6:f5:00 the Ethernet MAC you expect to be seeing?

Cheers,
jof


From jof at thejof.com  Thu Mar 25 16:26:48 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 25 Mar 2010 13:26:48 -0700
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <00ad01cacc57$20a7cf50$61f76df0$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<1269547147-sup-1236@sfo.thejof.com>
	<00ad01cacc57$20a7cf50$61f76df0$@org>
Message-ID: <1269548501-sup-852@sfo.thejof.com>

Excerpts from Paul Stewart's message of Thu Mar 25 13:09:51 -0700 2010:
> Thanks very much for the reply...
> 
> The AMS-IX guide I've been through but their Juniper section isn't nearly as
> detailed as the Cisco side... good guide for sure. ;)
> 
> The MAC shown in my example below is actually the correct MAC for the layer3
> facing interface ... so you're suggesting to create a filter to only allow
> that MAC to be 'sent out' to the peering switch?  We never had to do this in
> the Cisco world using the configurations I sent in my original post hence
> some of my confusion...

Indeed, Cisco is a big global player in the switching market, so many
guides and experience are with Cisco gear.

There's probably some other protocol running that's causing frames from
other source MACs to be sent out of your port facing the peering switch,
either from your Juniper or your Cisco interface.

Maybe implement port security on your downstream interfaces that are on
your peering VLAN/bridge..

If you can track down that protocol and disable it out of the interface
in question, all the better.

I was suggesting an L2 filter since if it's supported, it should give
you the effect you want for the least amount of effort (no packet
tracing, taps, etc.), but it comes at the cost of having to go back and
change the filter if you want to change routers.

Cheers,
jof

From jof at thejof.com  Thu Mar 25 16:39:15 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 25 Mar 2010 13:39:15 -0700
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <00ad01cacc57$20a7cf50$61f76df0$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<1269547147-sup-1236@sfo.thejof.com>
	<00ad01cacc57$20a7cf50$61f76df0$@org>
Message-ID: <1269549372-sup-7642@sfo.thejof.com>

Excerpts from Paul Stewart's message of Thu Mar 25 13:09:51 -0700 2010:
> Thanks very much for the reply...
> 
> The AMS-IX guide I've been through but their Juniper section isn't nearly as
> detailed as the Cisco side... good guide for sure. ;)
> 
> The MAC shown in my example below is actually the correct MAC for the layer3
> facing interface ... so you're suggesting to create a filter to only allow
> that MAC to be 'sent out' to the peering switch?  We never had to do this in
> the Cisco world using the configurations I sent in my original post hence
> some of my confusion...

Ok, I checked this out on a spare EX-3200.

Maybe some configuration like:

firewall {
    family ethernet-switching {
        filter XXX-IX_Peering_Filter {
            term expected_mac_address {
                from {
                    source-mac-address {
                        00:0b:45:b6:f5:00;
                    }
                }
                then accept;
            }
            term block {
                then discard;
            }
        }
    }
}

interfaces {
 ge-x/x/x {
  unit 0 {
   family ethernet-switching {
    filter {
     output XXX-IX_Peering_Filter
    }
   }
  }
 }
}

Would accomplish what you want.

Cheers,
jof

From paul at paulstewart.org  Thu Mar 25 16:45:10 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 25 Mar 2010 16:45:10 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <1269549372-sup-7642@sfo.thejof.com>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<1269547147-sup-1236@sfo.thejof.com>
	<00ad01cacc57$20a7cf50$61f76df0$@org>
	<1269549372-sup-7642@sfo.thejof.com>
Message-ID: <00b401cacc5c$0f923ca0$2eb6b5e0$@org>

Thanks again - we have some Ex4200's in our lab currently so will test this
out... again, appreciate the fast response times..;)

Paul


-----Original Message-----
From: Jonathan Lassoff [mailto:jof at thejof.com] 
Sent: Thursday, March 25, 2010 4:39 PM
To: Paul Stewart
Cc: jnsp
Subject: RE: [j-nsp] EX Switches - Internet Exchange Points

Excerpts from Paul Stewart's message of Thu Mar 25 13:09:51 -0700 2010:
> Thanks very much for the reply...
> 
> The AMS-IX guide I've been through but their Juniper section isn't nearly
as
> detailed as the Cisco side... good guide for sure. ;)
> 
> The MAC shown in my example below is actually the correct MAC for the
layer3
> facing interface ... so you're suggesting to create a filter to only allow
> that MAC to be 'sent out' to the peering switch?  We never had to do this
in
> the Cisco world using the configurations I sent in my original post hence
> some of my confusion...

Ok, I checked this out on a spare EX-3200.

Maybe some configuration like:

firewall {
    family ethernet-switching {
        filter XXX-IX_Peering_Filter {
            term expected_mac_address {
                from {
                    source-mac-address {
                        00:0b:45:b6:f5:00;
                    }
                }
                then accept;
            }
            term block {
                then discard;
            }
        }
    }
}

interfaces {
 ge-x/x/x {
  unit 0 {
   family ethernet-switching {
    filter {
     output XXX-IX_Peering_Filter
    }
   }
  }
 }
}

Would accomplish what you want.

Cheers,
jof


From hoogen82 at gmail.com  Thu Mar 25 18:26:11 2010
From: hoogen82 at gmail.com (Hoogen)
Date: Thu, 25 Mar 2010 15:26:11 -0700
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <20100325065448.GX75640@gerbil.cluepon.net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
Message-ID: <dffd2e731003251526y4398ccefy2d8ab6c4ecc33f7d@mail.gmail.com>

Didn't word it right.. I meant shouldn't ...

I was taking some example out from SRX.. where customers choose to
log ?session-init? and ?session-close?, it could generates high rate of IO
activity to /var/log/rtlogd. Though its not a problem logging all these; but
on a compact flash when we have a life cycle of about 100k it might become
an issue very soon. Do note that this may effect only event mode logs not
the stream mode.

-Hoogen


On Wed, Mar 24, 2010 at 11:54 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> 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? :)
>
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>

From ras at e-gerbil.net  Thu Mar 25 19:36:09 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 25 Mar 2010 18:36:09 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
Message-ID: <20100325233609.GB75640@gerbil.cluepon.net>

On Thu, Mar 25, 2010 at 09:13:59AM -0700, Dan Farrell wrote:

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

I've seen dozens of old RE-2.0s with CFs that have died over time, but 
I'm 99% certain there was no effort made to do wear leveling or bad 
block detection and avoidance on those things. :) The ironiy is that 
they were really put in as "backup" because nobody trusted spinning 
media in a router, go figure.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ras at e-gerbil.net  Thu Mar 25 19:44:15 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 25 Mar 2010 18:44:15 -0500
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <1269534839-sup-3870@sfo.thejof.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
	<1269534839-sup-3870@sfo.thejof.com>
Message-ID: <20100325234415.GC75640@gerbil.cluepon.net>

On Thu, Mar 25, 2010 at 09:51:20AM -0700, Jonathan Lassoff wrote:
> In looking at the EX platforms though, this doesn't seem in line with
> Juniper's design goals though (not that I actually know what they
> planned). It seems like most of the hardware ('cept the EX-8200) comes
> in a fixed configuration -- stuff that's just supposed to "work", and
> not to worry the manuf. with compatibility concerns.
> 
> If you're feeling gutsy and want to void any warranties, you might try
> de-soldering and replacing the internal flash :)

8200 is fixed configuration too. 

da0 at umass-sim0 bus 0 target 0 lun 0
da0: <ST ST72682 2.10> Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 2000MB (4096000 512 byte sectors: 255H 63S/T 254C)

Same device as on EX3200/4200, just bigger.

Looks to be an embedded USB->Flash controller with non-modular flash.

http://www.st.com/stonline/books/pdf/docs/12029.pdf

I've taken a soldering iron to many a router and switch in my day to
"correct" design flaws, but I don't think that will work out here. Those
5mm USB flash units stuffed into the usb port on the front seem to be
the best option for making something that at least won't get bumped or
stolen in the datacenter, but I can't find them shipping yet either.

http://www.engadget.com/2009/06/24/buffalos-16gb-5mm-usb-thumbkey-its-really-small/

Then again, I have some promotional Cisco USB drives that might look 
good sticking out of the box like a giant wart too. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ras at e-gerbil.net  Thu Mar 25 19:52:15 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 25 Mar 2010 18:52:15 -0500
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <00a801cacc4f$41ee4f20$c5caed60$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
Message-ID: <20100325235215.GD75640@gerbil.cluepon.net>

On Thu, Mar 25, 2010 at 03:13:31PM -0400, Paul Stewart wrote:
> The problem I'm facing we're tripping the port security on the exchange
> switch:
> 
> Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> violation occurred, caused by MAC address 000b.45b6.f500 on port
> FastEthernet0/1.
> 
> It is obviously seeing several MAC addresses and doesn't like this.  so I'm
> trying to adapt a "best practice" here based on what other folks have
> encountered along the way as we're trying our best to learn Juniper better
> ;)

The MAC address vendor database says 000b45 is Cisco, so either you have
a misconfiguration or your Juniper is leaking something it shouldn't be,
but at least is isn't generating something on its own. I'd recommend you
track down that MAC address on your network and figure out how it is
getting to the exchange, since if the Juniper is leaking things outside
of its configured vlan it is a Big Problem (tm) which needs to be fixed.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From jof at thejof.com  Thu Mar 25 20:00:29 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 25 Mar 2010 17:00:29 -0700
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <20100325235215.GD75640@gerbil.cluepon.net>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
Message-ID: <1269561580-sup-8639@sfo.thejof.com>

Excerpts from Richard A Steenbergen's message of Thu Mar 25 16:52:15 -0700 2010:
> On Thu, Mar 25, 2010 at 03:13:31PM -0400, Paul Stewart wrote:
> > The problem I'm facing we're tripping the port security on the exchange
> > switch:
> > 
> > Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> > violation occurred, caused by MAC address 000b.45b6.f500 on port
> > FastEthernet0/1.
> > 
> > It is obviously seeing several MAC addresses and doesn't like this.  so I'm
> > trying to adapt a "best practice" here based on what other folks have
> > encountered along the way as we're trying our best to learn Juniper better
> > ;)
> 
> The MAC address vendor database says 000b45 is Cisco, so either you have
> a misconfiguration or your Juniper is leaking something it shouldn't be,
> but at least is isn't generating something on its own. I'd recommend you
> track down that MAC address on your network and figure out how it is
> getting to the exchange, since if the Juniper is leaking things outside
> of its configured vlan it is a Big Problem (tm) which needs to be fixed.

>From the original post, it sounds like Paul was using a Cisco as the
router and just using his EX switch as an L2 device to connect the two,
in which case, the Cisco OUI seems expected.

--j

From paul at paulstewart.org  Thu Mar 25 20:01:36 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 25 Mar 2010 20:01:36 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <20100325235215.GD75640@gerbil.cluepon.net>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
Message-ID: <046601cacc77$80cc07f0$826417d0$@org>

Thanks Richard...

The MAC filtering idea proposed earlier by another friendly person was quite
helpful and solved the issue.  That Cisco MAC is actually what we wanted to
see however other MAC's were showing up from the intermediary switches along
the path (Cisco 7600 - EX4200 - EX4200 - EX4200 in this particular case)....

Solved now thankfully - we like to be friendly to our peers at exchange
points and I was getting worried ;)

Take care,

Paul


-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: March-25-10 7:52 PM
To: Paul Stewart
Cc: 'jnsp'
Subject: Re: [j-nsp] EX Switches - Internet Exchange Points

On Thu, Mar 25, 2010 at 03:13:31PM -0400, Paul Stewart wrote:
> The problem I'm facing we're tripping the port security on the exchange
> switch:
> 
> Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> violation occurred, caused by MAC address 000b.45b6.f500 on port
> FastEthernet0/1.
> 
> It is obviously seeing several MAC addresses and doesn't like this.  so
I'm
> trying to adapt a "best practice" here based on what other folks have
> encountered along the way as we're trying our best to learn Juniper better
> ;)

The MAC address vendor database says 000b45 is Cisco, so either you have
a misconfiguration or your Juniper is leaking something it shouldn't be,
but at least is isn't generating something on its own. I'd recommend you
track down that MAC address on your network and figure out how it is
getting to the exchange, since if the Juniper is leaking things outside
of its configured vlan it is a Big Problem (tm) which needs to be fixed.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From ras at e-gerbil.net  Thu Mar 25 20:40:55 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 25 Mar 2010 19:40:55 -0500
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <046601cacc77$80cc07f0$826417d0$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
	<046601cacc77$80cc07f0$826417d0$@org>
Message-ID: <20100326004055.GE75640@gerbil.cluepon.net>

On Thu, Mar 25, 2010 at 08:01:36PM -0400, Paul Stewart wrote:
> Thanks Richard...
> 
> The MAC filtering idea proposed earlier by another friendly person was
> quite helpful and solved the issue.  That Cisco MAC is actually what
> we wanted to see however other MAC's were showing up from the
> intermediary switches along the path (Cisco 7600 - EX4200 - EX4200 -
> EX4200 in this particular case)....
> 
> Solved now thankfully - we like to be friendly to our peers at
> exchange points and I was getting worried ;)

What were the other MACs that you didn't want leaked? The MAC filter is 
a fine workaround, but if your EX's are leaking things they shouldn't be 
I'd like to see that get addressed too. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From mailers at oranged.to  Fri Mar 26 00:32:25 2010
From: mailers at oranged.to (Jimmy Stewpot)
Date: Fri, 26 Mar 2010 04:32:25 +0000 (UTC)
Subject: [j-nsp] JunOS temperature readings
In-Reply-To: <1939253344.703.1269577849104.JavaMail.root@poops.oranged.to>
Message-ID: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>

Hello,

I am currently looking into an issue where we are getting temperature alerts on a variety of different JunOS devices within one of our facilities. Unfortunately when I go to track down the changes all the switches are running at under 40c which is within the thresholds yet we still get alerts. 

jstewpot at JunOS Switch> show chassis temperature-thresholds 
                           Fan speed        Yellow alarm         Red alarm
Item                     Normal   High    Normal   Bad fan    Normal   Bad fan
FPC 0 CPU                    60     70        80        70        95        85
FPC 0 EX-PFE1                60     70        80        70        95        85
FPC 0 EX-PFE2                60     70        80        70        95        85
FPC 0 EX-PFE3                60     70        80        70        95        85
FPC 0 GEPHY Front Left       60     70        80        70        95        85
FPC 0 GEPHY Front Middle     60     70        80        70        95        85
FPC 0 GEPHY Front Right      60     70        80        70        95        85
FPC 0 Uplink Conn            60     70        80        70        95        85

{master:0}
jstewpot at JunOS Switch> show chassis environment 
Class Item                           Status     Measurement
Power FPC 0 Power Supply 0           OK        
      FPC 0 Power Supply 1           OK        
Temp  FPC 0 CPU                      OK         38 degrees C / 100 degrees F
      FPC 0 EX-PFE1                  OK         39 degrees C / 102 degrees F
      FPC 0 EX-PFE2                  OK         50 degrees C / 122 degrees F
      FPC 0 EX-PFE3                  OK         45 degrees C / 113 degrees F
      FPC 0 GEPHY Front Left         OK         20 degrees C / 68 degrees F
      FPC 0 GEPHY Front Middle       OK         27 degrees C / 80 degrees F
      FPC 0 GEPHY Front Right        OK         29 degrees C / 84 degrees F
      FPC 0 Uplink Conn              OK         28 degrees C / 82 degrees F
Fans  FPC 0 Fan 1                    OK         Spinning at normal speed
      FPC 0 Fan 2                    OK         Spinning at normal speed
      FPC 0 Fan 3                    OK         Spinning at normal speed

{master:0}

jstewpot at JunOS Switch> show chassis alarms 
No alarms currently active

I am interested to know if anyone has anything similar? Also is it possible to set the thresholds?

Regards,

Jimmy Stewpot

From plunin at senetsy.ru  Fri Mar 26 03:37:08 2010
From: plunin at senetsy.ru (Pavel Lunin)
Date: Fri, 26 Mar 2010 10:37:08 +0300
Subject: [j-nsp] EX 8200 deployment
In-Reply-To: <dffd2e731003251526y4398ccefy2d8ab6c4ecc33f7d@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com> 
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru> 
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com> 
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com> 
	<20100325065448.GX75640@gerbil.cluepon.net>
	<dffd2e731003251526y4398ccefy2d8ab6c4ecc33f7d@mail.gmail.com>
Message-ID: <77c10e261003260037o7dd9f518ha829bdb3c2f4c72f@mail.gmail.com>

Hi Hoogen,

I think this is just another story.

SRX should have also had some more storage capacity to store IDP base and
all the same things as Richard wrote about. But session logging can cause
another problem ? increased process switching or something like (if we talk
about Branch SRX), because the session data is collected by fwdd_octeon
(software forwarding and SPU daemon) when log processing an storing is done
by control plane. Moreover control plane on branch SRX is run on a separate
processor and is known to be ?not that fast? due to this.

SRX 3/5k can not store session logs to flash drive at all since it can cause
RE link overloading. You must use syslog exporting for this, which is done
directly by SPU and does not consume RE resources.

--
Regards,
Pavel

2010/3/26 Hoogen <hoogen82 at gmail.com>

> Didn't word it right.. I meant shouldn't ...
>
> I was taking some example out from SRX.. where customers choose to
> log ?session-init? and ?session-close?, it could generates high rate of IO
> activity to /var/log/rtlogd. Though its not a problem logging all these; but
> on a compact flash when we have a life cycle of about 100k it might become
> an issue very soon. Do note that this may effect only event mode logs not
> the stream mode.
>
> -Hoogen
>
>

From paul at paulstewart.org  Fri Mar 26 07:17:15 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 26 Mar 2010 07:17:15 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <20100326004055.GE75640@gerbil.cluepon.net>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
	<046601cacc77$80cc07f0$826417d0$@org>
	<20100326004055.GE75640@gerbil.cluepon.net>
Message-ID: <04b501caccd5$e3e35fb0$abaa1f10$@org>

Richard,

You have a very valid point and to be honest we never found out - ironically
this morning we lost a transit connection which is on a different EX4200
switch and I'm investigating a potentially similar MAC issue.  I'm not sure
yet but I've asked the upstream for detailed MAC information to see if it
could be related.

If I find something concrete I'll be happy to share this back with the list
- was hoping to find someone who had already deployed EX4200's towards
exchange points possibly ... so I could see if they ran into any of this
(which we're presuming most of it is just us learning more about Juniper) 

:)

Paul


-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: March-25-10 8:41 PM
To: Paul Stewart
Cc: 'jnsp'
Subject: Re: [j-nsp] EX Switches - Internet Exchange Points

On Thu, Mar 25, 2010 at 08:01:36PM -0400, Paul Stewart wrote:
> Thanks Richard...
> 
> The MAC filtering idea proposed earlier by another friendly person was
> quite helpful and solved the issue.  That Cisco MAC is actually what
> we wanted to see however other MAC's were showing up from the
> intermediary switches along the path (Cisco 7600 - EX4200 - EX4200 -
> EX4200 in this particular case)....
> 
> Solved now thankfully - we like to be friendly to our peers at
> exchange points and I was getting worried ;)

What were the other MACs that you didn't want leaked? The MAC filter is 
a fine workaround, but if your EX's are leaking things they shouldn't be 
I'd like to see that get addressed too. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From paul at paulstewart.org  Fri Mar 26 09:10:47 2010
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 26 Mar 2010 09:10:47 -0400
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <20100326004055.GE75640@gerbil.cluepon.net>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
	<046601cacc77$80cc07f0$826417d0$@org>
	<20100326004055.GE75640@gerbil.cluepon.net>
Message-ID: <00c401cacce5$c067ddd0$41379970$@org>

Hi there..

I just wanted to follow up on this - I'd open a case at JTAC but honestly
have no idea where to get started with them yet...;)

So, the MAC filtering worked for one of the exchange points yesterday ...
then late last night one of our upstream providers dropped off.  With the
upstream provider I've asked them for port security logs so I can start
hunting for MAC's they are seeing .... this will hopefully provide a clue.

Is there a way in a filter to log denied MAC addresses?  Snippet looks like
this:

family ethernet-switching {
    filter core2_peering_filter {
        term expected_mac_address {
            from {
                source-mac-address {
                    00:0b:45:b6:f5:00;
                }
            }
            then accept;
        }
        term block {
            then discard;
        }
    }

I tried to add "then discard log" to the term block but I get:

  'filter'
    Referenced filter 'core1_peering_filter' can not be used as log not
supported on egress
error: configuration check-out failed


Thanks,

Paul


-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Thursday, March 25, 2010 8:41 PM
To: Paul Stewart
Cc: 'jnsp'
Subject: Re: [j-nsp] EX Switches - Internet Exchange Points

On Thu, Mar 25, 2010 at 08:01:36PM -0400, Paul Stewart wrote:
> Thanks Richard...
> 
> The MAC filtering idea proposed earlier by another friendly person was
> quite helpful and solved the issue.  That Cisco MAC is actually what
> we wanted to see however other MAC's were showing up from the
> intermediary switches along the path (Cisco 7600 - EX4200 - EX4200 -
> EX4200 in this particular case)....
> 
> Solved now thankfully - we like to be friendly to our peers at
> exchange points and I was getting worried ;)

What were the other MACs that you didn't want leaked? The MAC filter is 
a fine workaround, but if your EX's are leaking things they shouldn't be 
I'd like to see that get addressed too. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From dilipjetking at gmail.com  Fri Mar 26 09:25:31 2010
From: dilipjetking at gmail.com (Dilip Srivastava)
Date: Fri, 26 Mar 2010 18:55:31 +0530
Subject: [j-nsp] JNCIE-ER
In-Reply-To: <000001cacc3c$108cafc0$31a60f40$@com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>
	<20100320150313.GT75640@gerbil.cluepon.net>
	<20100322143138.GE30843@snar.spb.ru>
	<20100322191636.GB75640@gerbil.cluepon.net>
	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>
	<20100324232131.GT75640@gerbil.cluepon.net>
	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>
	<20100325065448.GX75640@gerbil.cluepon.net>
	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>
	<000001cacc3c$108cafc0$31a60f40$@com>
Message-ID: <114441731003260625y631b3213hc4e4f13a53e36f0c@mail.gmail.com>

Dear All,


I am also looking for JNCIE-ER please share the documents or study material


regards
dilip
9313537122


On Thu, Mar 25, 2010 at 10:25 PM, adnan <ahabib at asacogroup.com> wrote:

> Dear All
>
>
> I am preparing my JNCIE-ER . if anyone is also preparing contact me  so we
> can share the material .
>
>
>
> Best regard
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Thanks & Regards

Dilip Kumar Srivastava
Engineer Wipro
9650410022

From jof at thejof.com  Fri Mar 26 14:11:57 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Fri, 26 Mar 2010 11:11:57 -0700
Subject: [j-nsp] EX Switches - Internet Exchange Points
In-Reply-To: <00c401cacce5$c067ddd0$41379970$@org>
References: <00a801cacc4f$41ee4f20$c5caed60$@org>
	<20100325235215.GD75640@gerbil.cluepon.net>
	<046601cacc77$80cc07f0$826417d0$@org>
	<20100326004055.GE75640@gerbil.cluepon.net>
	<00c401cacce5$c067ddd0$41379970$@org>
Message-ID: <1269626502-sup-4474@sfo.thejof.com>

Excerpts from Paul Stewart's message of Fri Mar 26 06:10:47 -0700 2010:
> Hi there..
> 
> I just wanted to follow up on this - I'd open a case at JTAC but honestly
> have no idea where to get started with them yet...;)
> 
> So, the MAC filtering worked for one of the exchange points yesterday ...
> then late last night one of our upstream providers dropped off.  With the
> upstream provider I've asked them for port security logs so I can start
> hunting for MAC's they are seeing .... this will hopefully provide a clue.

Oh no! Hopefully you're multihomed :)

It's strange that a transit provider would drop a connection because of
layer 2 traffic it doesn't like. Perhaps the outage was unrelated?

Every transit I've dealt with delivers service over a point-to-point
link (an Ethernet segment with just two routers on it), with no port
security or spanning tree.

IXes on the other hand seem to regularly implement port security as a
way of preventing loops in a switched environment without spanning tree
running. It's a hassle to deal with spanning tree across administrative
boundaries.


If you're still trying to track down traffic that's appearing without
explaination, and have a free PC with a GigE NIC, attach it to an
analyzer port and just start capturing.
 
> Is there a way in a filter to log denied MAC addresses?  Snippet looks like
> this:
> 
> family ethernet-switching {
>     filter core2_peering_filter {
>         term expected_mac_address {
>             from {
>                 source-mac-address {
>                     00:0b:45:b6:f5:00;
>                 }
>             }
>             then accept;
>         }
>         term block {
>             then discard;
>         }
>     }
> 
> I tried to add "then discard log" to the term block but I get:
> 
>   'filter'
>     Referenced filter 'core1_peering_filter' can not be used as log not
> supported on egress
> error: configuration check-out failed

Looks like it's not supported on egress then. This has the potential to
log a LOT.

--j

From alex.arseniev at gmail.com  Fri Mar 26 15:12:27 2010
From: alex.arseniev at gmail.com (Alex)
Date: Fri, 26 Mar 2010 19:12:27 -0000
Subject: [j-nsp] JunOS temperature readings
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>
Message-ID: <6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>

Hello there,
Are you using SMARTS?
If yes please check the thresholds set in SMARTS itself, it may be too low. 
I saw them set at 37 deg C which is "mild fever" in human terms but hardly 
alarming for modern hardware.
If it not possible to set the temp thresholds in JUNOS.
Regards
Alex

----- Original Message ----- 
From: "Jimmy Stewpot" <mailers at oranged.to>
To: <juniper-nsp at puck.nether.net>
Sent: Friday, March 26, 2010 4:32 AM
Subject: [j-nsp] JunOS temperature readings


> Hello,
>
> I am currently looking into an issue where we are getting temperature 
> alerts on a variety of different JunOS devices within one of our 
> facilities. Unfortunately when I go to track down the changes all the 
> switches are running at under 40c which is within the thresholds yet we 
> still get alerts.
>
> jstewpot at JunOS Switch> show chassis temperature-thresholds
>                           Fan speed        Yellow alarm         Red alarm
> Item                     Normal   High    Normal   Bad fan    Normal   Bad 
> fan
> FPC 0 CPU                    60     70        80        70        95 
> 85
> FPC 0 EX-PFE1                60     70        80        70        95 
> 85
> FPC 0 EX-PFE2                60     70        80        70        95 
> 85
> FPC 0 EX-PFE3                60     70        80        70        95 
> 85
> FPC 0 GEPHY Front Left       60     70        80        70        95 
> 85
> FPC 0 GEPHY Front Middle     60     70        80        70        95 
> 85
> FPC 0 GEPHY Front Right      60     70        80        70        95 
> 85
> FPC 0 Uplink Conn            60     70        80        70        95 
> 85
>
> {master:0}
> jstewpot at JunOS Switch> show chassis environment
> Class Item                           Status     Measurement
> Power FPC 0 Power Supply 0           OK
>      FPC 0 Power Supply 1           OK
> Temp  FPC 0 CPU                      OK         38 degrees C / 100 degrees 
> F
>      FPC 0 EX-PFE1                  OK         39 degrees C / 102 degrees 
> F
>      FPC 0 EX-PFE2                  OK         50 degrees C / 122 degrees 
> F
>      FPC 0 EX-PFE3                  OK         45 degrees C / 113 degrees 
> F
>      FPC 0 GEPHY Front Left         OK         20 degrees C / 68 degrees F
>      FPC 0 GEPHY Front Middle       OK         27 degrees C / 80 degrees F
>      FPC 0 GEPHY Front Right        OK         29 degrees C / 84 degrees F
>      FPC 0 Uplink Conn              OK         28 degrees C / 82 degrees F
> Fans  FPC 0 Fan 1                    OK         Spinning at normal speed
>      FPC 0 Fan 2                    OK         Spinning at normal speed
>      FPC 0 Fan 3                    OK         Spinning at normal speed
>
> {master:0}
>
> jstewpot at JunOS Switch> show chassis alarms
> No alarms currently active
>
> I am interested to know if anyone has anything similar? Also is it 
> possible to set the thresholds?
>
> Regards,
>
> Jimmy Stewpot
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


From ibariouen.khalid at ericsson.com  Fri Mar 26 17:36:39 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Fri, 26 Mar 2010 22:36:39 +0100
Subject: [j-nsp]  NAT
In-Reply-To: <6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>
	<6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>

Hi all
Can someone tell me what does "no nat vector means" exactelly :


GFW01(M)-> get counter statistics interface ethernet1/3
Hardware counters for interface ethernet1/3:
in bytes       201903417 | out bytes     2103176764 | early frame            0
in packets    2949387186 | out packets   2468188341 | late frame             0
in no buffer           0 | out no buffer          0 | re-xmt limit           0
in overrun            63 | out underrun           0 | drop vlan              0
address spoof          0 | in icmp        164486382 | no nat vector       1977


in some document No nat vector Indicates the number of packets dropped because the Network Address Translation (NAT) connection was unavailable for the gate.


But it's not clear for me ?
4 Public ip addresses are enought for 61973 sessions .


[X]


From adisubrata at gmail.com  Fri Mar 26 19:57:58 2010
From: adisubrata at gmail.com (Nugroho WH Adisubrata)
Date: Sat, 27 Mar 2010 06:57:58 +0700
Subject: [j-nsp] Logical Routers QoS
In-Reply-To: <E2C120A806ED3349A9F9E9913E0C8C1F5E7BA5@bmcserver.bmc.com.sa>
References: <E2C120A806ED3349A9F9E9913E0C8C1F5E7BA5@bmcserver.bmc.com.sa>
Message-ID: <9748e271003261657o26f383ewd3f2ab18fc526713@mail.gmail.com>

Hi Abdel,

Well it depends on what PIC you have in your router.
per unit schedule only available on IQ PIC.
(I assume you are using logical interface to connect the logical routers).

Rgrds,


On Sat, Mar 13, 2010 at 6:41 PM, Walaa Abdel razzak <walaaez at bmc.com.sa>wrote:

> Hi Experts
>
>
>
> I tried configuring QoS on logical routers on M7i router (JUNOS 9.2R3.5)
> but it's not applicable, the problem I have faced is that the CoS can be
> configured only on the physical router, then when assigning the CoS
> components to the interfaces, it's not applicable as the interfaces are
> belonging to the logical routers, there is no way to assign the CoS
> components to the logical routers interfaces. Any suggestions?
>
>
>
>  BR,
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From sfouant at shortestpathfirst.net  Sat Mar 27 19:34:56 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 27 Mar 2010 19:34:56 -0400
Subject: [j-nsp] JNCIE-ER
In-Reply-To: <114441731003260625y631b3213hc4e4f13a53e36f0c@mail.gmail.com>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>	<20100320150313.GT75640@gerbil.cluepon.net>	<20100322143138.GE30843@snar.spb.ru>	<20100322191636.GB75640@gerbil.cluepon.net>	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>	<20100324232131.GT75640@gerbil.cluepon.net>	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>	<20100325065448.GX75640@gerbil.cluepon.net>	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>	<000001cacc3c$108cafc0$31a60f40$@com>
	<114441731003260625y631b3213hc4e4f13a53e36f0c@mail.gmail.com>
Message-ID: <006101cace06$1d0a9980$571fcc80$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Dilip Srivastava
> Sent: Friday, March 26, 2010 9:26 AM
> To: adnan
> Cc: Richard A Steenbergen; juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] JNCIE-ER
> 
> I am also looking for JNCIE-ER please share the documents or study
> material
> 
> regards
> dilip
> 
> On Thu, Mar 25, 2010 at 10:25 PM, adnan <ahabib at asacogroup.com> wrote:
> 
> > Dear All
> >
> > I am preparing my JNCIE-ER . if anyone is also preparing contact me
> so we
> > can share the material .

Well I just took the exam yesterday and I don't want to count my chickens
before they hatch, but I feel that I did pretty good so here is a quick
synopsis of what I used for the exam:

- 'JUNOS Enterprise Routing' by Harry Reynolds and Doug Marschke.  Read it
twice if you can :)
- 'Advanced Juniper Networks Routing in the Enterprise' courseware and labs
which can be found on the Juniper FastTrack site.  I definitely recommend
going through the labs because they are extremely representative of the
types of things that you are likely to see on the exam.
- 'Adaptive Services' chapter in the JUNOS 'Services Interfaces
Configuration Guide' - its 500 pages but will definitely school you on all
the variants of JUNOS Services
- The 'JNCIP-M Study Guide' by Harry Reynolds is another really useful
addition if you can go through that book and do the labs this will really
help with routing policy and configuration of OSPF, RIP, and BGP.
- In addition to reading the above and getting a good strong foundational
level of understanding, I would say the *single* most useful preparation tip
I can give to anyone is to take the JNCIE-ER Bootcamp and/or the Remote
Proctored lab exams offered by Proteus Networks.  I haven't personally taken
the bootcamp, but I did see the materials from a colleague who sat through
it and after sitting the exam I can tell you that Bootcamp is spot on.  I
did however take their Remote Proctored exams and once again I am not
disappointed with my experience with them.  Rick Schenderlein was my proctor
with Proteus and he really took the time to help me understand the areas
that I could use improvement on.  Their products are truly a notch above and
will more than prepare you to sit the exam.  These are the guys who "wrote
the book" in more ways than one with the JNCIE-ER... their offerings should
be considered insurance... you're already shelling out some pretty big bucks
to sit the exam, why not do yourself the favor and take a look at what they
have to offer - http://www.proteus.net

All in all, I didn't think the exam was that tough, but I also have 12+
years of experience working with JUNOS and I also have a JNCIE-M.  I
actually finished the exam in a little over 5 hours and spent another 1-2
hours going over everything just to make sure I had it right.  I've heard
that most people going in are pretty much down to the wire with time so I'm
not sure what happened in my case but I hope I can attribute it to just
being over-prepared.

Oh one other tip, thanks Addy for passing this on to me - make sure you read
the full exam in its entirety before starting a single configuration
element.  This is truly an expert level exam, one which requires you to
think through your design decisions.  There are often things later on in the
exam that might require you to go back and reconfigure something you've set
up in an earlier section.  Reading ahead will allow you to save yourself
some time when you've thought your design through fully in advance.

I'll let you know in a few days when I receive my pass/fail status...

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From sfouant at shortestpathfirst.net  Sat Mar 27 19:42:31 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sat, 27 Mar 2010 19:42:31 -0400
Subject: [j-nsp] NAT
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>	<6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <006201cace07$2bda7330$838f5990$@net>

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Ibariouen Khalid
> Sent: Friday, March 26, 2010 5:37 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] NAT
> 
> Hi all
> Can someone tell me what does "no nat vector means" exactelly :
> 
> 
> GFW01(M)-> get counter statistics interface ethernet1/3
> Hardware counters for interface ethernet1/3:
> in bytes       201903417 | out bytes     2103176764 | early frame
> 0
> in packets    2949387186 | out packets   2468188341 | late frame
> 0
> in no buffer           0 | out no buffer          0 | re-xmt limit
> 0
> in overrun            63 | out underrun           0 | drop vlan
> 0
> address spoof          0 | in icmp        164486382 | no nat vector
> 1977
> 
> 
> in some document No nat vector Indicates the number of packets dropped
> because the Network Address Translation (NAT) connection was
> unavailable for the gate.
> 
> 
> But it's not clear for me ?
> 4 Public ip addresses are enought for 61973 sessions .

If I recall correctly, that means that there aren't enough addresses in the
NAT pool available for connections at the time a given connection is made.
You might have 4 public addresses but do you have PAT enabled?  Can you
describe your setup in more detail?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From oberman at es.net  Sat Mar 27 21:57:56 2010
From: oberman at es.net (Kevin Oberman)
Date: Sat, 27 Mar 2010 18:57:56 -0700
Subject: [j-nsp] NAT
In-Reply-To: Your message of "Fri, 26 Mar 2010 22:36:39 BST."
	<7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <20100328015756.520221CC34@ptavv.es.net>

> From: Ibariouen Khalid <ibariouen.khalid at ericsson.com>
> Date: Fri, 26 Mar 2010 22:36:39 +0100
> Sender: juniper-nsp-bounces at puck.nether.net
> 
> Hi all
> Can someone tell me what does "no nat vector means" exactelly :
> 
> 
> GFW01(M)-> get counter statistics interface ethernet1/3
> Hardware counters for interface ethernet1/3:
> in bytes       201903417 | out bytes     2103176764 | early frame           0
> in packets    2949387186 | out packets   2468188341 | late frame            0
> in no buffer           0 | out no buffer          0 | re-xmt limit          0
> in overrun            63 | out underrun           0 | drop vlan             0
> address spoof          0 | in icmp        164486382 | no nat vector      1977
> 
> 
> in some document No nat vector Indicates the number of packets dropped
> because the Network Address Translation (NAT) connection was
> unavailable for the gate.
> 
> 
> But it's not clear for me ?  4 Public ip addresses are enought for
> 61973 sessions .

I believe it may be a count of packets received for which the router has
no NAT translation. I believe that this is a packet that the router
has no NAT translation to send it to. E.g. A packet arrives from a
when no outgoing traffic has established a destination nor is there a
pre-configured destination, The router has no place to forward the
packet, do it is counted and dropped.

A wide assortment of common network scans would result in this event.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

From alf at all.de  Sat Mar 27 22:07:54 2010
From: alf at all.de (Alfred Schweder)
Date: Sun, 28 Mar 2010 04:07:54 +0200
Subject: [j-nsp] (M7i RE5.0) memory usage
Message-ID: <20100328020754.GT25496@all.de>

Hello

/kernel: CPU: Intel Celeron (397.95-MHz 686-class CPU)
/kernel:   Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
/kernel:   Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
/kernel: real memory  = 805306368 (768 MB)
/kernel: avail memory = 775344128 (739 MB)

If I look in the system summary, all memory seems to be in use:

alf at M7i.ffm> show system processes summary 
last pid: 37152;  load averages:  0.15,  0.09,  0.08  up 67+03:19:19    03:56:10
125 processes: 4 running, 105 sleeping, 16 waiting
Mem: 486M Active, 70M Inact, 147M Wired, 24M Cache, 69M Buf, 14M Free
Swap: 1536M Total, 79M Used, 1457M Free, 5% Inuse

and the system seems to swap, cause less memory. The reaction of the
cli has often a slow start which is likely for swapping ...

If I look deeper:
alf at M7i.ls> show task memory detail
...
    Dynamically allocated memory:  335396864      Maximum: 366436352
         Program data+BSS memory:    4349952      Maximum:   4349952
              Page data overhead:    2154496      Maximum:   2154496
             Page directory size:     360448      Maximum:    360448
                                  ----------
              Total bytes in use:  342261760 (55% of available memory)

all seems to be fine and much memory is waiting for more ...
Can someone give my some light in the darkness ?

Thanks and regards, ALF


From ras at e-gerbil.net  Sat Mar 27 23:28:23 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 27 Mar 2010 22:28:23 -0500
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328020754.GT25496@all.de>
References: <20100328020754.GT25496@all.de>
Message-ID: <20100328032823.GI75640@gerbil.cluepon.net>

On Sun, Mar 28, 2010 at 04:07:54AM +0200, Alfred Schweder wrote:
> Hello
> 
> /kernel: CPU: Intel Celeron (397.95-MHz 686-class CPU)
> /kernel:   Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
> /kernel:   Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
> /kernel: real memory  = 805306368 (768 MB)
> /kernel: avail memory = 775344128 (739 MB)
> 
> If I look in the system summary, all memory seems to be in use:
> 
> alf at M7i.ffm> show system processes summary 
> last pid: 37152;  load averages:  0.15,  0.09,  0.08  up 67+03:19:19    03:56:10
> 125 processes: 4 running, 105 sleeping, 16 waiting
> Mem: 486M Active, 70M Inact, 147M Wired, 24M Cache, 69M Buf, 14M Free
> Swap: 1536M Total, 79M Used, 1457M Free, 5% Inuse
> 
> and the system seems to swap, cause less memory. The reaction of the
> cli has often a slow start which is likely for swapping ...
> 
> If I look deeper:
> alf at M7i.ls> show task memory detail
> ...
>     Dynamically allocated memory:  335396864      Maximum: 366436352
>          Program data+BSS memory:    4349952      Maximum:   4349952
>               Page data overhead:    2154496      Maximum:   2154496
>              Page directory size:     360448      Maximum:    360448
>                                   ----------
>               Total bytes in use:  342261760 (55% of available memory)
> 
> all seems to be fine and much memory is waiting for more ...
> Can someone give my some light in the darkness ?

The first command is accurate for the entire system, the second is only 
showing stats on some specific junos processes. You're definitely 
(almost) out of memory, the 70M inactive + 14M free is available for 
use, but you're clearly facing pressure since you've already swapped on 
79M of inactive pages.

Run top from shell, hit o, and sort by "res" to see what else is 
consuming memory on the box.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ibariouen.khalid at ericsson.com  Sun Mar 28 02:55:54 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Sun, 28 Mar 2010 08:55:54 +0200
Subject: [j-nsp] NAT
In-Reply-To: <006201cace07$2bda7330$838f5990$@net>
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>
	<6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
	<006201cace07$2bda7330$838f5990$@net>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA266C77D6@ESESSCMS0364.eemea.ericsson.se>


Hi stefan
Yes , I have PAT enabled .





This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
-----Original Message-----
From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] 
Sent: dimanche 28 mars 2010 02:43
To: Ibariouen Khalid; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] NAT

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Ibariouen Khalid
> Sent: Friday, March 26, 2010 5:37 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] NAT
> 
> Hi all
> Can someone tell me what does "no nat vector means" exactelly :
> 
> 
> GFW01(M)-> get counter statistics interface ethernet1/3
> Hardware counters for interface ethernet1/3:
> in bytes       201903417 | out bytes     2103176764 | early frame
> 0
> in packets    2949387186 | out packets   2468188341 | late frame
> 0
> in no buffer           0 | out no buffer          0 | re-xmt limit
> 0
> in overrun            63 | out underrun           0 | drop vlan
> 0
> address spoof          0 | in icmp        164486382 | no nat vector
> 1977
> 
> 
> in some document No nat vector Indicates the number of packets dropped
> because the Network Address Translation (NAT) connection was
> unavailable for the gate.
> 
> 
> But it's not clear for me ?
> 4 Public ip addresses are enought for 61973 sessions .

If I recall correctly, that means that there aren't enough addresses in the
NAT pool available for connections at the time a given connection is made.
You might have 4 public addresses but do you have PAT enabled?  Can you
describe your setup in more detail?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D



From singh.taqdir at gmail.com  Sun Mar 28 03:32:59 2010
From: singh.taqdir at gmail.com (Taqdir Singh)
Date: Sun, 28 Mar 2010 13:02:59 +0530
Subject: [j-nsp] vrrp advertise and hold time
Message-ID: <88ec2aaf1003280032v51d45402o18cb8e8548852387@mail.gmail.com>

Hi all,

       I have read that in juniper vrrp has advertise time of 1 sec and
holdtime of 0 sec by default ?

So could you confirm ........is advertise-time = hello time in cisco ?

if this is so... and if we are taking hold time of 0 sec... in that case
backup router will never wait for even one sec and there will always be
state change in backup and master ?

could you please clear this concept ?

-- 
TAQDIR SINGH
+91 -9911709496
+91 -8010415988

-An expert is a man who has made all the mistakes which can be made

From felix.schueren at hosteurope.de  Sun Mar 28 04:15:06 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Sun, 28 Mar 2010 10:15:06 +0200
Subject: [j-nsp] vrrp advertise and hold time
In-Reply-To: <88ec2aaf1003280032v51d45402o18cb8e8548852387@mail.gmail.com>
References: <88ec2aaf1003280032v51d45402o18cb8e8548852387@mail.gmail.com>
Message-ID: <4BAF100A.7090900@hosteurope.de>

Taqdir Singh wrote:
> Hi all,
> 
>        I have read that in juniper vrrp has advertise time of 1 sec and
> holdtime of 0 sec by default ?
generally, VRRP waits for (3 * advertise time) (as per the RFC). I never 
checked if the Skew_Time (lower priority makes you wait longer) is 
implemented in Juniper, but they definitively wait for 3*advertise time. 
This is true for normal as well as the fast-interval sub-second stuff.

> 
> So could you confirm ........is advertise-time = hello time in cisco ?
supposedly. I've never used vrrp on cisco.

> 
> if this is so... and if we are taking hold time of 0 sec... in that case
> backup router will never wait for even one sec and there will always be
> state change in backup and master ?
> 
If there was a 0 hold time, yes. But at least on my routers, I have 
never seen a hold-time setting for vrrp.
In Juniper, hold-time normally is a property of the physical interface 
that delays a "link down" or "link up" notification to the rest of 
router for a short time (and will not send any at all if the link is 
restored to it's previous state quickly enough, so if you have 
"hold-time up 2000ms" and plug in a link, then unplug it a second later, 
it will never fire the "link up" event).

Where did you get the "holdtime 0" from?

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen

From singh.taqdir at gmail.com  Sun Mar 28 04:33:42 2010
From: singh.taqdir at gmail.com (Taqdir Singh)
Date: Sun, 28 Mar 2010 14:03:42 +0530
Subject: [j-nsp] vrrp advertise and hold time
In-Reply-To: <4BAF100A.7090900@hosteurope.de>
References: <88ec2aaf1003280032v51d45402o18cb8e8548852387@mail.gmail.com>
	<4BAF100A.7090900@hosteurope.de>
Message-ID: <88ec2aaf1003280133g7caae67ah30b850ad83fd7f92@mail.gmail.com>

hi Felix,

here is the link where its mentioned hold time by default is 0

http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary148.html

On Sun, Mar 28, 2010 at 1:45 PM, Felix Schueren <
felix.schueren at hosteurope.de> wrote:

> Taqdir Singh wrote:
>
>> Hi all,
>>
>>       I have read that in juniper vrrp has advertise time of 1 sec and
>> holdtime of 0 sec by default ?
>>
> generally, VRRP waits for (3 * advertise time) (as per the RFC). I never
> checked if the Skew_Time (lower priority makes you wait longer) is
> implemented in Juniper, but they definitively wait for 3*advertise time.
> This is true for normal as well as the fast-interval sub-second stuff.
>
>
>
>> So could you confirm ........is advertise-time = hello time in cisco ?
>>
> supposedly. I've never used vrrp on cisco.
>
>
>
>> if this is so... and if we are taking hold time of 0 sec... in that case
>> backup router will never wait for even one sec and there will always be
>> state change in backup and master ?
>>
>>  If there was a 0 hold time, yes. But at least on my routers, I have never
> seen a hold-time setting for vrrp.
> In Juniper, hold-time normally is a property of the physical interface that
> delays a "link down" or "link up" notification to the rest of router for a
> short time (and will not send any at all if the link is restored to it's
> previous state quickly enough, so if you have "hold-time up 2000ms" and plug
> in a link, then unplug it a second later, it will never fire the "link up"
> event).
>
> Where did you get the "holdtime 0" from?
>
> 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; maximal 0,42 EUR/Min. aus
> den dt. Mobilfunknetzen
>



-- 
TAQDIR SINGH
+91 -9911709496
+91 -8010415988

-An expert is a man who has made all the mistakes which can be made

From felix.schueren at hosteurope.de  Sun Mar 28 04:45:50 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Sun, 28 Mar 2010 10:45:50 +0200
Subject: [j-nsp] vrrp advertise and hold time
In-Reply-To: <88ec2aaf1003280133g7caae67ah30b850ad83fd7f92@mail.gmail.com>
References: <88ec2aaf1003280032v51d45402o18cb8e8548852387@mail.gmail.com>	
	<4BAF100A.7090900@hosteurope.de>
	<88ec2aaf1003280133g7caae67ah30b850ad83fd7f92@mail.gmail.com>
Message-ID: <4BAF173E.7050209@hosteurope.de>

Taqdir Singh wrote:
> hi Felix,
> 
> here is the link where its mentioned hold time by default is 0
> 
Ah, that's hold-time for preemption. When a former vrrp master router 
rejoins the network after a reboot, for example, if preemption is 
enabled (default) then it immediately takes over, regardless of it's IGP 
or BGP state. With preemption hold-time you can tell the restarting 
router to wait a couple of minutes to let IGP & BGP stabilize before it 
preempts the current vrrp router.

This has nothing to do with the actual normal vrrp operation and does 
not affect failover times for vrrp.

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen

From alf at all.de  Sun Mar 28 05:14:51 2010
From: alf at all.de (Alfred Schweder)
Date: Sun, 28 Mar 2010 11:14:51 +0200
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328032823.GI75640@gerbil.cluepon.net>
References: <20100328020754.GT25496@all.de>
	<20100328032823.GI75640@gerbil.cluepon.net>
Message-ID: <20100328091451.GV25496@all.de>

Hello

> > and the system seems to swap, cause less memory. The reaction of the
> > cli has often a slow start which is likely for swapping ...
> > If I look deeper:
> > alf at M7i.ls> show task memory detail
> >     Dynamically allocated memory:  335396864      Maximum: 366436352
> >          Program data+BSS memory:    4349952      Maximum:   4349952
> >               Page data overhead:    2154496      Maximum:   2154496
> >              Page directory size:     360448      Maximum:    360448
> >                                   ----------
> >               Total bytes in use:  342261760 (55% of available memory)
> The first command is accurate for the entire system, the second is only 
> showing stats on some specific junos processes. You're definitely 
> (almost) out of memory, the 70M inactive + 14M free is available for 
> use, but you're clearly facing pressure since you've already swapped on 
> 79M of inactive pages.
> Run top from shell, hit o, and sort by "res" to see what else is 
> consuming memory on the box.

So I see in "task memory" was is going on inside the rpd and with
"sysem proc sum" I see the system over all ?

Im wondering, where I waste memory, cause there are many posts which state
that 512MB would be fine for 4 full tables. Ive only three and the 768MB are
full. 

Are there are some knobs to reduce the memory consumption like not to use
"softreconfiguration" at cisco boxes ?

last pid: 37745;  load averages:  0.01,  0.06,  0.07
68 processes:  1 running, 67 sleeping
CPU states: 16.3% user,  2.4% nice,  6.0% system,  0.8% interrupt, 74.5% idle
Mem: 509M Active, 56M Inact, 148M Wired, 24M Cache, 69M Buf, 4412K Free
Swap: 1536M Total, 118M Used, 1418M Free, 7% Inuse

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
 1219 root        1   4    0   408M   389M kqread 653:16  1.56% rpd
 1222 root        1 111   15 43100K 40116K select  12:52  0.59% sampled
 5188 root        1  96    0 34420K 13016K select   1:40  0.00% mgd
 5187 alf         1   8    0 15264K  9760K wait     5:00  0.00% cli
13189 root        1   4    0 29680K  8980K kqread  10:45  0.00% rpd
16931 root        1   4    0 29680K  8964K kqread   6:56  0.00% rpd
 1212 root        1   4    0 29444K  7848K kqread  10:29  0.00% rpd
 1235 root        1  96    0 22408K  7056K select 104:56  0.29% snmpd
 1234 root        1  96    0 14836K  6352K select  33:56  0.00% mib2d
 1174 root        1  96    0 43204K  6300K select  39.2H  1.17% chassisd
 6007 bg          1  96    0 15188K  4800K select   0:52  0.00% cli
 1821 alf         1  96    0 15200K  4684K select   0:52  0.00% cli
 1342 alf         1  96    0 15188K  4584K select   0:55  0.00% cli

-- 
Mit freundlichen Gruessen
Dipl. Ing. A. Schweder
Gutachten & Consulting
Mobil +49.177.2194627 (+49.160.97639300)


From sthaug at nethelp.no  Sun Mar 28 05:36:40 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sun, 28 Mar 2010 11:36:40 +0200 (CEST)
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328091451.GV25496@all.de>
References: <20100328020754.GT25496@all.de>
	<20100328032823.GI75640@gerbil.cluepon.net>
	<20100328091451.GV25496@all.de>
Message-ID: <20100328.113640.74695689.sthaug@nethelp.no>

> Im wondering, where I waste memory, cause there are many posts which state
> that 512MB would be fine for 4 full tables. Ive only three and the 768MB are
> full. 

The size of JunOS itself has grown quite a bit lately - note that
I'm talking about running code here, not just the jinstall images.

We concluded some months ago that it was no longes feasible to run
RE-5.0 with a full Internet routing table - at least not if you're
going to have room for some L3VPNs and similar stuff.

So if I were you I'd look really hard at the possibility of running
your RE-5.0 boxes with a reduced Internet routing table.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From alf at all.de  Sun Mar 28 05:49:53 2010
From: alf at all.de (Alfred Schweder)
Date: Sun, 28 Mar 2010 11:49:53 +0200
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328.113640.74695689.sthaug@nethelp.no>
References: <20100328020754.GT25496@all.de>
	<20100328032823.GI75640@gerbil.cluepon.net>
	<20100328091451.GV25496@all.de>
	<20100328.113640.74695689.sthaug@nethelp.no>
Message-ID: <20100328094949.GW25496@all.de>

Hello

> > Im wondering, where I waste memory, cause there are many posts which state
> > that 512MB would be fine for 4 full tables. Ive only three and the 768MB are
> > full. 
> The size of JunOS itself has grown quite a bit lately - note that
> I'm talking about running code here, not just the jinstall images.

I use 10.0.
 
> We concluded some months ago that it was no longes feasible to run
> RE-5.0 with a full Internet routing table - at least not if you're
> going to have room for some L3VPNs and similar stuff.
> So if I were you I'd look really hard at the possibility of running
> your RE-5.0 boxes with a reduced Internet routing table.

I made some tests. I filter eg. all prefixes which more than 3 ASN,
but all other are still there as hidden information and so I dosnt
use less memory. Is there a special way of filtering ?

-- 
Mit freundlichen Gruessen
Dipl. Ing. A. Schweder
Gutachten & Consulting
Mobil +49.177.2194627 (+49.160.97639300)


From sfouant at shortestpathfirst.net  Sun Mar 28 10:57:22 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sun, 28 Mar 2010 10:57:22 -0400
Subject: [j-nsp] NAT
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA266C77D6@ESESSCMS0364.eemea.ericsson.se>
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>	<6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
	<006201cace07$2bda7330$838f5990$@net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C77D6@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <006c01cace86$f9f87670$ede96350$@net>

> -----Original Message-----
> From: Ibariouen Khalid [mailto:ibariouen.khalid at ericsson.com]
> Sent: Sunday, March 28, 2010 2:56 AM
> To: Stefan Fouant; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] NAT
> 
> 
> Hi stefan
> Yes , I have PAT enabled .

Interface-based PAT or policy-based? Have you modified the session timeouts
for any protocols you are allowing through?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From ibariouen.khalid at ericsson.com  Sun Mar 28 10:59:40 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Sun, 28 Mar 2010 16:59:40 +0200
Subject: [j-nsp] NAT
In-Reply-To: <006c01cace86$f9f87670$ede96350$@net>
References: <2125093778.705.1269577945325.JavaMail.root@poops.oranged.to>
	<6B84E5035DFA4BF5BB4B4F2BEA7D0B88@jnpr.net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C776C@ESESSCMS0364.eemea.ericsson.se>
	<006201cace07$2bda7330$838f5990$@net>
	<7B520BC9477F5B45B50F8A193CDD55DA266C77D6@ESESSCMS0364.eemea.ericsson.se>
	<006c01cace86$f9f87670$ede96350$@net>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA266C7826@ESESSCMS0364.eemea.ericsson.se>


Hi
It's policy based;
No session timeouts is configured.
BR/

-----Original Message-----
From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] 
Sent: dimanche 28 mars 2010 16:57
To: Ibariouen Khalid; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] NAT

> -----Original Message-----
> From: Ibariouen Khalid [mailto:ibariouen.khalid at ericsson.com]
> Sent: Sunday, March 28, 2010 2:56 AM
> To: Stefan Fouant; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] NAT
> 
> 
> Hi stefan
> Yes , I have PAT enabled .

Interface-based PAT or policy-based? Have you modified the session timeouts
for any protocols you are allowing through?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D



From sfouant at shortestpathfirst.net  Sun Mar 28 11:49:25 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sun, 28 Mar 2010 15:49:25 +0000
Subject: [j-nsp] NAT
Message-ID: <1544494647-1269791365-cardhu_decombobulator_blackberry.rim.net-2027558459-@bda294.bisx.prod.on.blackberry>

I take it that interface is your untrust interface?

Just out of curiousity, how long had those statistics been running when you pulled them up (i.e. When was the last time you cleared stats or rebooted the box)?  I would suggest clearing interface stats and letting it run for a few days to observe how much that counter increments, or just take a look at the delta between now and the last time you ran that command.  Has it gone up much or at all?

Stefan Fouant
------Original Message------
From: Ibariouen Khalid
To: Stefan Fouant
To: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp]  NAT
Sent: Mar 28, 2010 10:59 AM


Hi
It's policy based;
No session timeouts is configured.
BR/

-----Original Message-----
From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] 
Sent: dimanche 28 mars 2010 16:57
To: Ibariouen Khalid; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] NAT

> -----Original Message-----
> From: Ibariouen Khalid [mailto:ibariouen.khalid at ericsson.com]
> Sent: Sunday, March 28, 2010 2:56 AM
> To: Stefan Fouant; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] NAT
> 
> 
> Hi stefan
> Yes , I have PAT enabled .

Interface-based PAT or policy-based? Have you modified the session timeouts
for any protocols you are allowing through?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D



Sent from my Verizon Wireless BlackBerry


From ibariouen.khalid at ericsson.com  Sun Mar 28 14:45:17 2010
From: ibariouen.khalid at ericsson.com (Ibariouen Khalid)
Date: Sun, 28 Mar 2010 20:45:17 +0200
Subject: [j-nsp] NAT
In-Reply-To: <1544494647-1269791365-cardhu_decombobulator_blackberry.rim.net-2027558459-@bda294.bisx.prod.on.blackberry>
References: <1544494647-1269791365-cardhu_decombobulator_blackberry.rim.net-2027558459-@bda294.bisx.prod.on.blackberry>
Message-ID: <7B520BC9477F5B45B50F8A193CDD55DA266C7837@ESESSCMS0364.eemea.ericsson.se>


Hi again 
Yes it's untrust interface ;
I'm taking stats every morning and do clear stats;
This mean that during 24 hours I got around 1977 not nat vector. And it's confusing me


BR/

-----Original Message-----
From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] 
Sent: dimanche 28 mars 2010 17:49
To: Ibariouen Khalid; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] NAT

I take it that interface is your untrust interface?

Just out of curiousity, how long had those statistics been running when you pulled them up (i.e. When was the last time you cleared stats or rebooted the box)?  I would suggest clearing interface stats and letting it run for a few days to observe how much that counter increments, or just take a look at the delta between now and the last time you ran that command.  Has it gone up much or at all?

Stefan Fouant
------Original Message------
From: Ibariouen Khalid
To: Stefan Fouant
To: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp]  NAT
Sent: Mar 28, 2010 10:59 AM


Hi
It's policy based;
No session timeouts is configured.
BR/

-----Original Message-----
From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] 
Sent: dimanche 28 mars 2010 16:57
To: Ibariouen Khalid; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] NAT

> -----Original Message-----
> From: Ibariouen Khalid [mailto:ibariouen.khalid at ericsson.com]
> Sent: Sunday, March 28, 2010 2:56 AM
> To: Stefan Fouant; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] NAT
> 
> 
> Hi stefan
> Yes , I have PAT enabled .

Interface-based PAT or policy-based? Have you modified the session timeouts
for any protocols you are allowing through?

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D



Sent from my Verizon Wireless BlackBerry


From ras at e-gerbil.net  Sun Mar 28 17:39:32 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 28 Mar 2010 16:39:32 -0500
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328091451.GV25496@all.de>
References: <20100328020754.GT25496@all.de>
	<20100328032823.GI75640@gerbil.cluepon.net>
	<20100328091451.GV25496@all.de>
Message-ID: <20100328213932.GJ75640@gerbil.cluepon.net>

On Sun, Mar 28, 2010 at 11:14:51AM +0200, Alfred Schweder wrote:
> So I see in "task memory" was is going on inside the rpd and with
> "sysem proc sum" I see the system over all ?

Correct.

> Im wondering, where I waste memory, cause there are many posts which
> state that 512MB would be fine for 4 full tables. Ive only three and
> the 768MB are full. 

There is a big difference between paths and routes. When people say "4
full tables", they usually mean 4 full table FEEDS going into a single
table. This results in 310k routes, and 310k * 4 paths, which consumes a
lot less memory than if there were really 1240k routes. Based on the 
results below it looks like yo may have some independent routing 
configurations going on (4 seperate rpd processes at any rate), which is 
going to incur a lot of extra overhead.

But if you strictly look at what memory is absolutely needed to
function, you're doing pretty well (especially if that is 4 full feeds
in that main rpd process). The amount of memory in "wired" (basically,
being used by the kernel or mlocked) is a little excessive, that's
probably attributable to feature bloat on modern code more than anything
else. You might be a lot better off running some older code if you're 
going to keep trying to run the old RE too. :)

> Are there are some knobs to reduce the memory consumption like not to use
> "softreconfiguration" at cisco boxes ?

Yes, you can configure "keep none" under protocols bgp (or group or
neighbor levels) to do sortof the same thing. It doesn't completely 
eliminate the adj rib in (which is a good thing), it just doesn't retain 
a copy of any route you explicitly reject in your policies. I don't 
think this is going to be a huge savings for you unless you are 
receiving and rejecting a lot of routes, and FYI it will flap your bgp 
sessions when you configure it.

> last pid: 37745;  load averages:  0.01,  0.06,  0.07
> 68 processes:  1 running, 67 sleeping
> CPU states: 16.3% user,  2.4% nice,  6.0% system,  0.8% interrupt, 74.5% idle
> Mem: 509M Active, 56M Inact, 148M Wired, 24M Cache, 69M Buf, 4412K Free
> Swap: 1536M Total, 118M Used, 1418M Free, 7% Inuse
> 
>   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
>  1219 root        1   4    0   408M   389M kqread 653:16  1.56% rpd
>  1222 root        1 111   15 43100K 40116K select  12:52  0.59% sampled

If you aren't using netflow, you can disable your sampled process which
is sucking down a decent amount of ram. The problem is that the routing 
table data is copied from rpd to sampled just so you can populate the 
"asn" field of netflow, and there is no way to disable this behavior if 
you don't care about that field. Unfortunately the only solution is to 
kill sampled completely, if you aren't using netflow of course.

I'm not sure if it will automatically disable things if you don't have 
sampling configured, but you can forcably disable things by configuring 
"system processes sampling disable".

>  5188 root        1  96    0 34420K 13016K select   1:40  0.00% mgd
>  5187 alf         1   8    0 15264K  9760K wait     5:00  0.00% cli
> 13189 root        1   4    0 29680K  8980K kqread  10:45  0.00% rpd
> 16931 root        1   4    0 29680K  8964K kqread   6:56  0.00% rpd
>  1212 root        1   4    0 29444K  7848K kqread  10:29  0.00% rpd
>  1235 root        1  96    0 22408K  7056K select 104:56  0.29% snmpd
>  1234 root        1  96    0 14836K  6352K select  33:56  0.00% mib2d
>  1174 root        1  96    0 43204K  6300K select  39.2H  1.17% chassisd
>  6007 bg          1  96    0 15188K  4800K select   0:52  0.00% cli
>  1821 alf         1  96    0 15200K  4684K select   0:52  0.00% cli
>  1342 alf         1  96    0 15188K  4584K select   0:55  0.00% cli

4.5MB+ for each of those cli processes is probably going to add up too, 
but realistically there are a lot of pages you just don't need in real 
time, and the vm system is doing the right thing by swapping them out. 
You can probably run "just fine" with a decent amount of memory used in 
swap.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From mohan.nanduri at gmail.com  Sun Mar 28 18:14:50 2010
From: mohan.nanduri at gmail.com (mail-list)
Date: Sun, 28 Mar 2010 18:14:50 -0400
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100328213932.GJ75640@gerbil.cluepon.net>
References: <20100328020754.GT25496@all.de>
	<20100328032823.GI75640@gerbil.cluepon.net>
	<20100328091451.GV25496@all.de>
	<20100328213932.GJ75640@gerbil.cluepon.net>
Message-ID: <b12b40d91003281514u1411bc38x55043fb24965ac22@mail.gmail.com>

We just reduced our paths from 5 M to 1.5 M but still see high memory usage
values. Does Junos reclaim memory without a reboot?



On Sun, Mar 28, 2010 at 5:39 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Sun, Mar 28, 2010 at 11:14:51AM +0200, Alfred Schweder wrote:
> > So I see in "task memory" was is going on inside the rpd and with
> > "sysem proc sum" I see the system over all ?
>
> Correct.
>
> > Im wondering, where I waste memory, cause there are many posts which
> > state that 512MB would be fine for 4 full tables. Ive only three and
> > the 768MB are full.
>
> There is a big difference between paths and routes. When people say "4
> full tables", they usually mean 4 full table FEEDS going into a single
> table. This results in 310k routes, and 310k * 4 paths, which consumes a
> lot less memory than if there were really 1240k routes. Based on the
> results below it looks like yo may have some independent routing
> configurations going on (4 seperate rpd processes at any rate), which is
> going to incur a lot of extra overhead.
>
> But if you strictly look at what memory is absolutely needed to
> function, you're doing pretty well (especially if that is 4 full feeds
> in that main rpd process). The amount of memory in "wired" (basically,
> being used by the kernel or mlocked) is a little excessive, that's
> probably attributable to feature bloat on modern code more than anything
> else. You might be a lot better off running some older code if you're
> going to keep trying to run the old RE too. :)
>
> > Are there are some knobs to reduce the memory consumption like not to use
> > "softreconfiguration" at cisco boxes ?
>
> Yes, you can configure "keep none" under protocols bgp (or group or
> neighbor levels) to do sortof the same thing. It doesn't completely
> eliminate the adj rib in (which is a good thing), it just doesn't retain
> a copy of any route you explicitly reject in your policies. I don't
> think this is going to be a huge savings for you unless you are
> receiving and rejecting a lot of routes, and FYI it will flap your bgp
> sessions when you configure it.
>
> > last pid: 37745;  load averages:  0.01,  0.06,  0.07
> > 68 processes:  1 running, 67 sleeping
> > CPU states: 16.3% user,  2.4% nice,  6.0% system,  0.8% interrupt, 74.5%
> idle
> > Mem: 509M Active, 56M Inact, 148M Wired, 24M Cache, 69M Buf, 4412K Free
> > Swap: 1536M Total, 118M Used, 1418M Free, 7% Inuse
> >
> >   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
> >  1219 root        1   4    0   408M   389M kqread 653:16  1.56% rpd
> >  1222 root        1 111   15 43100K 40116K select  12:52  0.59% sampled
>
> If you aren't using netflow, you can disable your sampled process which
> is sucking down a decent amount of ram. The problem is that the routing
> table data is copied from rpd to sampled just so you can populate the
> "asn" field of netflow, and there is no way to disable this behavior if
> you don't care about that field. Unfortunately the only solution is to
> kill sampled completely, if you aren't using netflow of course.
>
> I'm not sure if it will automatically disable things if you don't have
> sampling configured, but you can forcably disable things by configuring
> "system processes sampling disable".
>
> >  5188 root        1  96    0 34420K 13016K select   1:40  0.00% mgd
> >  5187 alf         1   8    0 15264K  9760K wait     5:00  0.00% cli
> > 13189 root        1   4    0 29680K  8980K kqread  10:45  0.00% rpd
> > 16931 root        1   4    0 29680K  8964K kqread   6:56  0.00% rpd
> >  1212 root        1   4    0 29444K  7848K kqread  10:29  0.00% rpd
> >  1235 root        1  96    0 22408K  7056K select 104:56  0.29% snmpd
> >  1234 root        1  96    0 14836K  6352K select  33:56  0.00% mib2d
> >  1174 root        1  96    0 43204K  6300K select  39.2H  1.17% chassisd
> >  6007 bg          1  96    0 15188K  4800K select   0:52  0.00% cli
> >  1821 alf         1  96    0 15200K  4684K select   0:52  0.00% cli
> >  1342 alf         1  96    0 15188K  4584K select   0:55  0.00% cli
>
> 4.5MB+ for each of those cli processes is probably going to add up too,
> but realistically there are a lot of pages you just don't need in real
> time, and the vm system is doing the right thing by swapping them out.
> You can probably run "just fine" with a decent amount of memory used in
> swap.
>
> --
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From sthaug at nethelp.no  Mon Mar 29 03:17:18 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 29 Mar 2010 09:17:18 +0200 (CEST)
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <b12b40d91003281514u1411bc38x55043fb24965ac22@mail.gmail.com>
References: <20100328091451.GV25496@all.de>
	<20100328213932.GJ75640@gerbil.cluepon.net>
	<b12b40d91003281514u1411bc38x55043fb24965ac22@mail.gmail.com>
Message-ID: <20100329.091718.74660725.sthaug@nethelp.no>

> We just reduced our paths from 5 M to 1.5 M but still see high memory usage
> values. Does Junos reclaim memory without a reboot?

Our experience is that this memory won't be reclaimed without restarting
the rpd process. You can restart rpd, without rebooting the whole box,
with "restart routing" - but note that this will flap most stuff (it is
still faster than rebooting the box).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From mohan.nanduri at gmail.com  Mon Mar 29 07:02:53 2010
From: mohan.nanduri at gmail.com (mail-list)
Date: Mon, 29 Mar 2010 07:02:53 -0400
Subject: [j-nsp] (M7i RE5.0) memory usage
In-Reply-To: <20100329.091718.74660725.sthaug@nethelp.no>
References: <20100328091451.GV25496@all.de>
	<20100328213932.GJ75640@gerbil.cluepon.net>
	<b12b40d91003281514u1411bc38x55043fb24965ac22@mail.gmail.com>
	<20100329.091718.74660725.sthaug@nethelp.no>
Message-ID: <b12b40d91003290402mb227e3bjc4f4d43199b0e445@mail.gmail.com>

Thanks for the confirmation, that was my experience pre 8.1 but was not too
sure if they made any changes in recent code versions.


On Mon, Mar 29, 2010 at 3:17 AM, <sthaug at nethelp.no> wrote:

> > We just reduced our paths from 5 M to 1.5 M but still see high memory
> usage
> > values. Does Junos reclaim memory without a reboot?
>
> Our experience is that this memory won't be reclaimed without restarting
> the rpd process. You can restart rpd, without rebooting the whole box,
> with "restart routing" - but note that this will flap most stuff (it is
> still faster than rebooting the box).
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>

From shekar1975 at gmail.com  Mon Mar 29 08:30:35 2010
From: shekar1975 at gmail.com (chandrasekaran iyer)
Date: Mon, 29 Mar 2010 18:00:35 +0530
Subject: [j-nsp] ISSU
Message-ID: <e5cda7a31003290530l120b0c5bk4e79eda668510c65@mail.gmail.com>

hi,

   how to do iSSU in junos? Can anybody provide me the steps.

-- 
Thanks with regards

Shekar.B
--

From charlie at playlouder.com  Mon Mar 29 10:10:28 2010
From: charlie at playlouder.com (Charlie Allom)
Date: Mon, 29 Mar 2010 15:10:28 +0100
Subject: [j-nsp] pfem gets stuck at 100% CPU after commit
Message-ID: <20100329141028.GB2995@spodder.com>

Hello,

can someone explain why the pfem process will peg the CPU after
firewall-related commits?

This is an EX4200 stack. The CPU drops back to idle after a few minutes.

I only noticed this because snmpd's counters reset when there is little
CPU to go around, and my 64bit RRD graphs suddenly have peaks of
30Gbps... :P


charlie at sw0.cll# run show system processes summary    
last pid: 64064;  load averages:  1.12,  0.68,  0.34  up 39+19:28:23    15:01:59
108 processes: 5 running, 83 sleeping, 20 waiting

Mem: 182M Active, 19M Inact, 86M Wired, 62M Cache, 110M Buf, 634M Free
Swap:


  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  890 root        1 132    0 81544K 26972K RUN     41.4H 97.02% pfem


-- 
 020 7729 4797
 http://blog.playlouder.com/

From andy at shady.org  Mon Mar 29 09:34:30 2010
From: andy at shady.org (andy)
Date: Mon, 29 Mar 2010 14:34:30 +0100
Subject: [j-nsp] ISSU
In-Reply-To: <e5cda7a31003290530l120b0c5bk4e79eda668510c65@mail.gmail.com>
References: <e5cda7a31003290530l120b0c5bk4e79eda668510c65@mail.gmail.com>
Message-ID: <20100329133430.GF65510@shady.org>

On Mon, Mar 29, 2010 at 06:00:35PM +0530, chandrasekaran iyer wrote:
> hi,
> 
>    how to do iSSU in junos? Can anybody provide me the steps.
> 

A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different JUNOS software releases with no disruption on the control plane and with 
minimal disruption of traffic. Unified ISSU is only supported on dual Routing Engine platforms. In addition, the graceful Routing Engine switchover (GRES) and nonstop 
active routing (NSR) must be enabled.

To do this you need:

[edit system]
+   commit synchronize;
[edit chassis]
+   redundancy {
+       graceful-switchover;
+   }
[edit routing-options]
+  nonstop-routing;

Then....

1.	Verify that both routing engines are running the same version of software code. Use the ?show version invoke-on all-routing-engines? command.
2.	Enable Graceful Routing Engine switchover and non-stop active routing. Verify that the Routing Engines and protocols are synchronized. 
	On the backup Routing Engine (re1) run the ?show system switchover? command.
3.	To verify non-stop active routing is configured. On the master Routing Engine (re0) run the ?show task replication? command.
4.	Issue the request system software in-service-upgrade command on the master Routing Engine. Run the ?request system software in-service-upgrade <path-to-image> reboot? 
	command. Make sure you replace the "<path-to-image>" with the correct image version to be used in the upgrade.
5.	The upgrade will take place for both routing-engines whilst in service.


Cheers

-- 
andy    andy at shady.org
-----------------------------------------------
Never argue with an idiot. They drag you down 
to their level, then beat you with experience.

CCIP, JNCIP #959
----------------------------------------------- 

From davidtball at gmail.com  Mon Mar 29 10:31:53 2010
From: davidtball at gmail.com (David Ball)
Date: Mon, 29 Mar 2010 08:31:53 -0600
Subject: [j-nsp] ISSU
In-Reply-To: <e5cda7a31003290530l120b0c5bk4e79eda668510c65@mail.gmail.com>
References: <e5cda7a31003290530l120b0c5bk4e79eda668510c65@mail.gmail.com>
Message-ID: <8d4861b01003290731n2eadff32iff203188a1a7c5f6@mail.gmail.com>

Step 1:  Read the docs regarding ISSU at:

http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/swconfig-high-availability/frameset.html

Step 2:  Post any remaining questions here.

DB


On 29 March 2010 06:30, chandrasekaran iyer <shekar1975 at gmail.com> wrote:
> hi,
>
>   how to do iSSU in junos? Can anybody provide me the steps.
>
> --
> Thanks with regards
>
> Shekar.B
> --
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From charlie at playlouder.com  Mon Mar 29 10:50:17 2010
From: charlie at playlouder.com (Charlie Allom)
Date: Mon, 29 Mar 2010 15:50:17 +0100
Subject: [j-nsp] pfem gets stuck at 100% CPU after commit
In-Reply-To: <20100329141028.GB2995@spodder.com>
References: <20100329141028.GB2995@spodder.com>
Message-ID: <20100329145017.GC2995@spodder.com>

I've graphed my cpu samples from the CLI.

http://capslock.playlouder.com/pfem.png

It looks like a loop that gets killed to me. This is 10.0R2.10 with only
a few firewall terms:

{master:0}[edit firewall]
charlie at sw0.cll# sh|match term|count 
Count: 125 lines

{master:0}[edit firewall]
charlie at sw0.cll# 


-- 
 020 7729 4797
 http://blog.playlouder.com/

From sfouant at shortestpathfirst.net  Mon Mar 29 12:11:37 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 29 Mar 2010 12:11:37 -0400
Subject: [j-nsp] NAT
In-Reply-To: <7B520BC9477F5B45B50F8A193CDD55DA266C7837@ESESSCMS0364.eemea.ericsson.se>
References: <1544494647-1269791365-cardhu_decombobulator_blackberry.rim.net-2027558459-@bda294.bisx.prod.on.blackberry>
	<7B520BC9477F5B45B50F8A193CDD55DA266C7837@ESESSCMS0364.eemea.ericsson.se>
Message-ID: <007b01cacf5a$8349d260$89dd7720$@net>

> -----Original Message-----
> From: Ibariouen Khalid [mailto:ibariouen.khalid at ericsson.com]
> Sent: Sunday, March 28, 2010 2:45 PM
> To: sfouant at shortestpathfirst.net; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] NAT
> 
> 
> Hi again
> Yes it's untrust interface ;
> I'm taking stats every morning and do clear stats;
> This mean that during 24 hours I got around 1977 not nat vector. And
> it's confusing me

Do a 'get interface ethernet1/3 dip detail' and take a look at what your NAT
values are.  Is the status listed as Free?

Also, I would suggest ratcheting down the timers for your more commonly used
protocols (if you've got NSM you can run a report on 'Top FW/VPN Rules' -
you might want to try to identify which rules are being used the most and
check the applications which are being allowed.  Are the timeouts for those
applications set at the default?  Have they been adjusted?  I would suggest
lowering them as it sounds like you have sessions which are remaining open
and holding on to NAT/PAT allocations without releasing them.  

Finally, do you have ALGs enabled?  Take a look at 'get xlate' and try to
identify if there is an issue with failed allocations in an ALG.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


From buraglio at illinois.edu  Mon Mar 29 12:27:17 2010
From: buraglio at illinois.edu (Buraglio, Nicholas D)
Date: Mon, 29 Mar 2010 11:27:17 -0500
Subject: [j-nsp] SRX as Little Juniper BGP Box
In-Reply-To: <6bb5f5b11003221853h3310ff36ubcab30a30a235ff9@mail.gmail.com>
References: <008c01cac9fb$d6d6dc20$84849460$@net>
	<6bb5f5b11003221853h3310ff36ubcab30a30a235ff9@mail.gmail.com>
Message-ID: <A069AAA0-8232-4082-8762-0F457C4B6D7F@illinois.edu>

We're using the SRX platform in a similar fashion without much issue.  The SRX series are a decent bang-for-your-buck box but it does have some gotchas, especially if you're using their clustering abilities on the smaller boxes (the larger chassis boxes work really well in every test and odd situation we've put them through).  As stated before, the SRX is really a firewall that can do routing in a logical, sane way.  It's not a router that can firewall, so all the normal caveats apply with as with a firewall device.  That said, I really like the SRX as a routing platform as well.  
I believe the IPv6 protocol is still a bit raw on the SRX, IIRC May should bring much better support for v6 with 10.2, I'm not even attempting v6 on them until I see a decent 10.2 release since we do a bit more than just route with them.

nb  



---
Nick Buraglio   
Network Engineer, CITES, University of Illinois / ICCN
GPG key 0x2E5B44F4
Phone: 217.244.6428
buraglio at illinois.edu

On Mar 22, 2010, at 8:53 PM, Rubens Kuhl wrote:

> Beware of the firewall nature of the SRX in situations like
> asymmetrical routing; you can make a workaround using selective
> firewall filters with the packet-mode clause, as long as you don't put
> traffic where the router is the destination in packet mode (this has
> to use flow mode).
> 
> 
> Rubens
> 
> 
> On Mon, Mar 22, 2010 at 5:11 PM, Jay Hanke <jhanke at myclearwave.net> wrote:
>> I?m in need of a box that will handle up to ? gig of throughput and some
>> very low volume BGP (about 200 routes + default) for IPv4 and IPv6 in the
>> next couple of months.
>> 
>> 
>> 
>> I was looking at the sheets and the SRX appears to give a little more ?bang
>> for buck? as compared to a j2320 or j2350. I wouldn?t be afraid of the EX
>> line but the cost of the AFL for BGP puts me out of the budget for the
>> project.
>> 
>> 
>> 
>> Has anyone used an SRX in a similar situation? Is the j-series still safer?
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> Jay
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 



From shekar1975 at gmail.com  Mon Mar 29 21:09:14 2010
From: shekar1975 at gmail.com (chandrasekaran iyer)
Date: Tue, 30 Mar 2010 06:39:14 +0530
Subject: [j-nsp] Memory leak
Message-ID: <e5cda7a31003291809n43e67affu29f808ce2807a908@mail.gmail.com>

Hi,

  How do we check, memory leak in junos?  I tried few things like show
task memory.
  Where exactly do we look?

-- 
Thanks with regards

Shekar.B
--

From vvasilev at vvasilev.net  Tue Mar 30 07:37:46 2010
From: vvasilev at vvasilev.net (Vladislav Vasilev)
Date: Tue, 30 Mar 2010 12:37:46 +0100
Subject: [j-nsp] Using fxp0 as a routed interface
Message-ID: <353e59af1003300437k1cf047f9vd5e7b3e8f9587497@mail.gmail.com>

Hello!

I know I can use fxp0 as a routed interface on M7i by setting:

sysctl -w net.pfe.transit_re=1

but this seems to be not possible for M160? Has anyone been able to do
to it on it?

P.S. It is for training purposes, so the CPU will be OK


Regards,
V.Vasilev

From meryem_z at hotmail.com  Tue Mar 30 08:19:49 2010
From: meryem_z at hotmail.com (meryem Z)
Date: Tue, 30 Mar 2010 12:19:49 +0000
Subject: [j-nsp] Cos model for l2vpn
In-Reply-To: <353e59af1003300437k1cf047f9vd5e7b3e8f9587497@mail.gmail.com>
References: <353e59af1003300437k1cf047f9vd5e7b3e8f9587497@mail.gmail.com>
Message-ID: <BLU113-W1D3B821FC7A6A749220FBE11F0@phx.gbl>


hello Community,


Can anyone suggest a Cos model related to L2VPNs ? Also what are the limitations for this type of VPNs?

Thanks in advance.


Regards.




 		 	   		  
_________________________________________________________________
Hotmail : une messagerie performante et gratuite avec une s?curit? sign?e Microsoft
https://signup.live.com/signup.aspx?id=60969

From ben.kessler at zenetra.com  Tue Mar 30 08:52:23 2010
From: ben.kessler at zenetra.com (Kessler, Ben)
Date: Tue, 30 Mar 2010 08:52:23 -0400
Subject: [j-nsp] Troubleshooting J6350 Boot
Message-ID: <86793c501003300552s469c2942w285a0e05fbdc372c@mail.gmail.com>

Hello -

I'm in the process of upgrading a lot of J6350 routers and have one that is
failing on boot after the upgrade.  I'm getting the following messages on
the console when the router tries to boot:

 OK reboot
Rebooting...
elf32_loadfile: can't load module before kernel

elf32_loadfile: can't load module before kernel

elf32_loadfile: can't load module before kernel

Unable to load a kernel!

\

elf32_loadfile: can't load module before kernel

can't load '/kernel'

elf32_loadfile: can't load module before kernel

can't load '/kernel.old'


I have a case open with JTAC but they're a bit slow to respond.

Any suggestions would be appreciated.

Thanks,

Ben

From felix.schueren at hosteurope.de  Tue Mar 30 09:02:54 2010
From: felix.schueren at hosteurope.de (Felix Schueren)
Date: Tue, 30 Mar 2010 15:02:54 +0200
Subject: [j-nsp] Troubleshooting J6350 Boot
In-Reply-To: <86793c501003300552s469c2942w285a0e05fbdc372c@mail.gmail.com>
References: <86793c501003300552s469c2942w285a0e05fbdc372c@mail.gmail.com>
Message-ID: <4BB1F67E.5090109@hosteurope.de>

Kessler, Ben wrote:
> Hello -
> 
> I'm in the process of upgrading a lot of J6350 routers and have one that is
> failing on boot after the upgrade.  I'm getting the following messages on
> the console when the router tries to boot:
> 
>  OK reboot
> Rebooting...
> elf32_loadfile: can't load module before kernel
> 
> elf32_loadfile: can't load module before kernel
> 
> elf32_loadfile: can't load module before kernel
> 
> Unable to load a kernel!
> 
> \
> 
> elf32_loadfile: can't load module before kernel
> 
> can't load '/kernel'
> 
> elf32_loadfile: can't load module before kernel
> 
> can't load '/kernel.old'
> 
> 
> I have a case open with JTAC but they're a bit slow to respond.
> 
> Any suggestions would be appreciated.
> 
I suspect you'll have to boot from install media and try a 
reinstallation - something appears to have broken during the upgrade. 
Worst case, the internal flash is damaged.

We've had that happen every once in a while, and a boot & reinstall from 
install media usually fixed it.

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; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen



From rrye at norgetek.com  Tue Mar 30 09:07:38 2010
From: rrye at norgetek.com (Ralph R. Rye)
Date: Tue, 30 Mar 2010 13:07:38 +0000
Subject: [j-nsp] JUNOS - TACACS - Cisco ACS Allowed Commands
In-Reply-To: <e5cda7a31003291809n43e67affu29f808ce2807a908@mail.gmail.com>
References: <e5cda7a31003291809n43e67affu29f808ce2807a908@mail.gmail.com>
Message-ID: <46267986548D574CA44D697C680D6D3105E1CB71@mbx021-w2-ca-6.exch021.domain.local>

Hello,


I have been trying to get a few Juniper EX4200 switches working with Cisco ACS through TACACS+ utilizing "allowed commands".  I have followed the example doc on Cisco site here:

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_configuration_example09186a0080af7d1d.shtml

Which didn't work at all until I added the "remote" user on the EX 4200, but then it would only allow access and the user would be mapped to the "remote" username which had "read-only" access.


I have tried different combinations of syntax on the Cisco ACS in terms of the "local-username" and "allowed-commands" with no success ( I also added the "set" keyword in front of the commands as some examples demonstrated).  I believe I almost have it configured but I missing some simple thing.  I searched the forum but all the past posts have made mention of things I have already tried.

Anyone have any suggestions?


Config on the EX4200 (JUNOS version 10.0S1.1):

system {
	authentication-order [ tacplus password ];
	tacplus-server {
		1.2.3.4 {
			secret "stuff; ## SECRET-DATA
		timeout 5;
		source-address 5.5.5.5.;
		}
	}
}
class LIMITED {
permissions all;
}
user LIMITED-USER {
uid 2002;
class LIMITED;
}
user remote {
uid 2001;
class read-only;
}

ACS Config (version 4.2):

Setup per the link above with the following attributes in the "custom attributes" box:

local-user-name = LIMITED-USER
allow-commands = "monitor | help | show | ping | traceroute"


Thanks,

Ralph






From martin.levin at molndal.se  Tue Mar 30 09:53:13 2010
From: martin.levin at molndal.se (Martin Levin)
Date: Tue, 30 Mar 2010 15:53:13 +0200
Subject: [j-nsp] High memory usage on EX4200 stack
Message-ID: <4BB21E69020000D4000117A4@gw.molndal.se>

Hi!
 
We have 3 EX4200 virtual chassis all running 10.0S1.1, one consisting
of 4 EX4200 and the other two och two switches each.
 
The problem below only affects the two stacks with two switches each,
the 2 switch stack does not se this.
 
The problem we're seeing is that member 0, regardless of wether its the
master routing engine or not sees very high memory usage (89%) and the
boxes then become very slow. These switches operate on layer 2 only.
 
If I try to do "request session member 0" i get "could not create child
process" as an error and I can't login to that member. Traffic seems to
flow without problem however.
 
Any thoughts?
 
 
 
---
Martin Levin
IT-strategy & planning
M?lndals stad

From Wouter.vandenBergh at imtech.nl  Tue Mar 30 10:16:21 2010
From: Wouter.vandenBergh at imtech.nl (Wouter van den Bergh)
Date: Tue, 30 Mar 2010 16:16:21 +0200
Subject: [j-nsp] High memory usage on EX4200 stack
In-Reply-To: <4BB21E69020000D4000117A4@gw.molndal.se>
References: <4BB21E69020000D4000117A4@gw.molndal.se>
Message-ID: <7393DD5B69CCB64D8F90EAB980828149B198BAED84@exb01.cs.imtechict.local>

Matrin,

We have been experiencing kernel memory leaks on a EX4200 virtual chassis containing 2 devices after we upgraded to a 10 release. We were supplied version 10.0S3.1 to fix these problems. You might want to give that version a try and see if our problems were related.

Regards,

Wouter

-----Oorspronkelijk bericht-----
Van: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] Namens Martin Levin
Verzonden: dinsdag 30 maart 2010 15:53
Aan: juniper-nsp at puck.nether.net
Onderwerp: [j-nsp] High memory usage on EX4200 stack

Hi!
 
We have 3 EX4200 virtual chassis all running 10.0S1.1, one consisting
of 4 EX4200 and the other two och two switches each.
 
The problem below only affects the two stacks with two switches each,
the 2 switch stack does not se this.
 
The problem we're seeing is that member 0, regardless of wether its the
master routing engine or not sees very high memory usage (89%) and the
boxes then become very slow. These switches operate on layer 2 only.
 
If I try to do "request session member 0" i get "could not create child
process" as an error and I can't login to that member. Traffic seems to
flow without problem however.
 
Any thoughts?
 
 
 
---
Martin Levin
IT-strategy & planning
M?lndals stad
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From kworm at sofnet.com  Tue Mar 30 10:49:10 2010
From: kworm at sofnet.com (Kevin Wormington)
Date: Tue, 30 Mar 2010 09:49:10 -0500
Subject: [j-nsp] Remove EX-4200 stack member
Message-ID: <4BB20F66.20604@sofnet.com>

I'm running a production stack of 3 EX-4200s using the stacking ports on 
9.6R1.3.  I would like to remove the 3rd member (no ports in use or 
configured) which is just in line-card mode without effecting the other 
two.  The units were all pre-provisioned.  I'm curious if anyone has 
attempted this and if they just pulled the stacking cables first and 
then made software changes or made software changes and then pulled the 
cables?

Thanks,

Kevin

From jonlooney at gmail.com  Tue Mar 30 11:41:26 2010
From: jonlooney at gmail.com (Jonathan Looney)
Date: Tue, 30 Mar 2010 11:41:26 -0400
Subject: [j-nsp] Remove EX-4200 stack member
In-Reply-To: <4BB20F66.20604@sofnet.com>
References: <4BB20F66.20604@sofnet.com>
Message-ID: <ba5437101003300841n9436bfbma0321abb6cec02f3@mail.gmail.com>

Personally, I would halt the third member ("request system halt member 3"),
then pull the cables, and then change the VC configuration.  But, that is
just my preferred way of doing it.

-Jon

On Tue, Mar 30, 2010 at 10:49 AM, Kevin Wormington <kworm at sofnet.com> wrote:

> I'm running a production stack of 3 EX-4200s using the stacking ports on
> 9.6R1.3.  I would like to remove the 3rd member (no ports in use or
> configured) which is just in line-card mode without effecting the other two.
>  The units were all pre-provisioned.  I'm curious if anyone has attempted
> this and if they just pulled the stacking cables first and then made
> software changes or made software changes and then pulled the cables?
>
> Thanks,
>
> Kevin
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From joe at proteus.net  Tue Mar 30 19:54:29 2010
From: joe at proteus.net (Joseph Soricelli)
Date: Tue, 30 Mar 2010 19:54:29 -0400
Subject: [j-nsp] JNCIE-ER
In-Reply-To: <006101cace06$1d0a9980$571fcc80$@net>
References: <d0cc41791003200650i4f03f78fqf558a66030df35e1@mail.gmail.com>	<20100320150313.GT75640@gerbil.cluepon.net>	<20100322143138.GE30843@snar.spb.ru>	<20100322191636.GB75640@gerbil.cluepon.net>	<77c10e261003241431s603379e6td7a7f246cc364a67@mail.gmail.com>	<20100324232131.GT75640@gerbil.cluepon.net>	<dffd2e731003242245u6a8badf4p7fc5f12ae3ca9c36@mail.gmail.com>	<20100325065448.GX75640@gerbil.cluepon.net>	<06275CB4814DA94AB880409FDD8D779C148F208C07@EXMBXCLUS01.citservers.local>	<000001cacc3c$108cafc0$31a60f40$@com>
	<114441731003260625y631b3213hc4e4f13a53e36f0c@mail.gmail.com>
	<006101cace06$1d0a9980$571fcc80$@net>
Message-ID: <6C56AF24-0642-4989-81ED-8E91E91C4C74@proteus.net>

Stefan-

Thank you very much for the kind words. I'm sure you did well and  
passed your exam!

Regards,
Joe

Joseph Soricelli
CEO
Proteus Networks

703-980-3999
joe at proteus.net
www.proteus.net
Twitter - @proteusnetworks

On Mar 27, 2010, at 7:34 PM, Stefan Fouant wrote:

>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Dilip Srivastava
>> Sent: Friday, March 26, 2010 9:26 AM
>> To: adnan
>> Cc: Richard A Steenbergen; juniper-nsp at puck.nether.net
>> Subject: Re: [j-nsp] JNCIE-ER
>>
>> I am also looking for JNCIE-ER please share the documents or study
>> material
>>
>> regards
>> dilip
>>
>> On Thu, Mar 25, 2010 at 10:25 PM, adnan <ahabib at asacogroup.com>  
>> wrote:
>>
>>> Dear All
>>>
>>> I am preparing my JNCIE-ER . if anyone is also preparing contact me
>> so we
>>> can share the material .
>
> Well I just took the exam yesterday and I don't want to count my  
> chickens
> before they hatch, but I feel that I did pretty good so here is a  
> quick
> synopsis of what I used for the exam:
>
> - 'JUNOS Enterprise Routing' by Harry Reynolds and Doug Marschke.   
> Read it
> twice if you can :)
> - 'Advanced Juniper Networks Routing in the Enterprise' courseware  
> and labs
> which can be found on the Juniper FastTrack site.  I definitely  
> recommend
> going through the labs because they are extremely representative of  
> the
> types of things that you are likely to see on the exam.
> - 'Adaptive Services' chapter in the JUNOS 'Services Interfaces
> Configuration Guide' - its 500 pages but will definitely school you  
> on all
> the variants of JUNOS Services
> - The 'JNCIP-M Study Guide' by Harry Reynolds is another really useful
> addition if you can go through that book and do the labs this will  
> really
> help with routing policy and configuration of OSPF, RIP, and BGP.
> - In addition to reading the above and getting a good strong  
> foundational
> level of understanding, I would say the *single* most useful  
> preparation tip
> I can give to anyone is to take the JNCIE-ER Bootcamp and/or the  
> Remote
> Proctored lab exams offered by Proteus Networks.  I haven't  
> personally taken
> the bootcamp, but I did see the materials from a colleague who sat  
> through
> it and after sitting the exam I can tell you that Bootcamp is spot  
> on.  I
> did however take their Remote Proctored exams and once again I am not
> disappointed with my experience with them.  Rick Schenderlein was my  
> proctor
> with Proteus and he really took the time to help me understand the  
> areas
> that I could use improvement on.  Their products are truly a notch  
> above and
> will more than prepare you to sit the exam.  These are the guys who  
> "wrote
> the book" in more ways than one with the JNCIE-ER... their offerings  
> should
> be considered insurance... you're already shelling out some pretty  
> big bucks
> to sit the exam, why not do yourself the favor and take a look at  
> what they
> have to offer - http://www.proteus.net
>
> All in all, I didn't think the exam was that tough, but I also have  
> 12+
> years of experience working with JUNOS and I also have a JNCIE-M.  I
> actually finished the exam in a little over 5 hours and spent  
> another 1-2
> hours going over everything just to make sure I had it right.  I've  
> heard
> that most people going in are pretty much down to the wire with time  
> so I'm
> not sure what happened in my case but I hope I can attribute it to  
> just
> being over-prepared.
>
> Oh one other tip, thanks Addy for passing this on to me - make sure  
> you read
> the full exam in its entirety before starting a single configuration
> element.  This is truly an expert level exam, one which requires you  
> to
> think through your design decisions.  There are often things later  
> on in the
> exam that might require you to go back and reconfigure something  
> you've set
> up in an earlier section.  Reading ahead will allow you to save  
> yourself
> some time when you've thought your design through fully in advance.
>
> I'll let you know in a few days when I receive my pass/fail status...
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From mailers at oranged.to  Tue Mar 30 22:12:32 2010
From: mailers at oranged.to (Jimmy Stewpot)
Date: Wed, 31 Mar 2010 02:12:32 +0000 (UTC)
Subject: [j-nsp] SSG 140 Software
Message-ID: <152201108.784.1270001552511.JavaMail.root@poops.oranged.to>

Hi All,

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

Regards,

Jimmy.

From admin at toph.ca  Tue Mar 30 22:21:14 2010
From: admin at toph.ca (Christoph Blecker)
Date: Tue, 30 Mar 2010 19:21:14 -0700
Subject: [j-nsp] SSG 140 Software
In-Reply-To: <152201108.784.1270001552511.JavaMail.root@poops.oranged.to>
References: <152201108.784.1270001552511.JavaMail.root@poops.oranged.to>
Message-ID: <4BB2B19A.70506@toph.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jimmy,
The latest release version of ScreenOS for the SSG-140 series is
6.3.0r2. However, Juniper also has a knowledge base document
[https://www.juniper.net/customers/csc/software/netscreen_versions.jsp]
showing the latest *recommended* ScreenOS version. This version is
usually much more stable than the maintenance releases.

Cheers,
/toph


Jimmy Stewpot wrote:
> Hi All,
> 
> I am interested to know if anyone can provide me with what the latest version of software is for the SSG140?
> 
> Regards,
> 
> Jimmy.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuysZoACgkQg4DtNh1wGhoTGwCePzgwCd1FjeNNqBAPSsFNg+Q6
KQ4AoILWwk7oV+9dgyXq7ghPh/lEgw20
=qc0r
-----END PGP SIGNATURE-----

From rameshkarki at gmail.com  Wed Mar 31 03:20:28 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Wed, 31 Mar 2010 13:05:28 +0545
Subject: [j-nsp] ipv6 routing
Message-ID: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>

Hello all,

Can someone help me why my ipv6 routes is not  activating on intet6.0 table
?

Scenario :

 C720x -----L2-Sw----M10i

 Static route from Cisco to M10i Lo0 ip is okay. but static route from M10i
to 720x Lo0 is not showing on routing table and it is not working. There is
no problem between p2p connection.

M10i is running with JunOS 9.2.

thank you

From sean1207 at gmail.com  Wed Mar 31 03:38:51 2010
From: sean1207 at gmail.com (Sean Clarke)
Date: Wed, 31 Mar 2010 09:38:51 +0200
Subject: [j-nsp] ipv6 routing
In-Reply-To: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
Message-ID: <4BB2FC0B.5010504@gmail.com>


What is your config ?
Are you sure you are setting it right, i.e. check the rib

 >set routing-options rib inet6.0 static route 49::/64 discard


 >show route table inet6
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

49::/64            *[Static/5] 00:00:07
                       Discard

[edit]
On 3/31/10 9:20 AM, Ramesh Karki wrote:
> Hello all,
>
> Can someone help me why my ipv6 routes is not  activating on intet6.0 table
> ?
>
> Scenario :
>
>   C720x -----L2-Sw----M10i
>
>   Static route from Cisco to M10i Lo0 ip is okay. but static route from M10i
> to 720x Lo0 is not showing on routing table and it is not working. There is
> no problem between p2p connection.
>
> M10i is running with JunOS 9.2.
>
> thank you
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>    





From rameshkarki at gmail.com  Wed Mar 31 04:06:55 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Wed, 31 Mar 2010 13:51:55 +0545
Subject: [j-nsp] ipv6 routing
In-Reply-To: <201003311552.00629.mtinka@globaltransit.net>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
Message-ID: <j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>

Hi,

here is my config :

sh conf int ge-0/0/0
description " ";
unit 0 {
    family inet {
                address x.x.193.65/26;
    }
    family inet6 {
        address abcd:3800:1:1::1/64;
    }
}

sh conf int lo0
unit 0 {
    family inet {
                }
        address x.x.192.1/32;
    }
    family inet6 {
        address abcd:3800::1/128;
    }
}

rib inet6.0 {
    static {
        route abcd:3800::2/128 next-hop abcd:3800:1:1::2;
        route abcd:3800::4/128 next-hop abcd:3800:2:1::2;

here, abcd:3800:1:1::2 is neighbor (P2P) ip of 72xx router and
abcd:3800::2/128 is lo0 ip.

The command > show route table inet6.0  only shows the direct and connected
route.

thank you,


On Wed, Mar 31, 2010 at 1:36 PM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Wednesday 31 March 2010 03:20:28 pm Ramesh Karki wrote:
>
> >  Static route from Cisco to M10i Lo0 ip is okay. but
> >  static route from M10i to 720x Lo0 is not showing on
> >  routing table and it is not working. There is no problem
> >  between p2p connection.
>
> Can we take a quick peek at your static routing
> configuration?
>
> Cheers,
>
> Mark.
>

From mtinka at globaltransit.net  Wed Mar 31 03:51:56 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 31 Mar 2010 15:51:56 +0800
Subject: [j-nsp] ipv6 routing
In-Reply-To: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
Message-ID: <201003311552.00629.mtinka@globaltransit.net>

On Wednesday 31 March 2010 03:20:28 pm Ramesh Karki wrote:

>  Static route from Cisco to M10i Lo0 ip is okay. but
>  static route from M10i to 720x Lo0 is not showing on
>  routing table and it is not working. There is no problem
>  between p2p connection.

Can we take a quick peek at your static routing 
configuration?

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100331/0a2927ac/attachment.bin>

From rameshkarki at gmail.com  Wed Mar 31 09:38:39 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Wed, 31 Mar 2010 19:23:39 +0545
Subject: [j-nsp] ipv6 routing
In-Reply-To: <j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
Message-ID: <t2gbb76118f1003310638u244dd26ep92cd8267e28b45b6@mail.gmail.com>

hello,

I am still waiting the response ..is there anyone have faced the same
problem ??

Thank you,


On Wed, Mar 31, 2010 at 1:51 PM, Ramesh Karki <rameshkarki at gmail.com> wrote:

> Hi,
>
> here is my config :
>
> sh conf int ge-0/0/0
> description " ";
> unit 0 {
>     family inet {
>                 address x.x.193.65/26;
>     }
>     family inet6 {
>         address abcd:3800:1:1::1/64;
>     }
> }
>
> sh conf int lo0
> unit 0 {
>     family inet {
>                 }
>         address x.x.192.1/32;
>     }
>     family inet6 {
>         address abcd:3800::1/128;
>     }
> }
>
> rib inet6.0 {
>     static {
>         route abcd:3800::2/128 next-hop abcd:3800:1:1::2;
>         route abcd:3800::4/128 next-hop abcd:3800:2:1::2;
>
> here, abcd:3800:1:1::2 is neighbor (P2P) ip of 72xx router and
> abcd:3800::2/128 is lo0 ip.
>
> The command > show route table inet6.0  only shows the direct and connected
> route.
>
> thank you,
>
>
> On Wed, Mar 31, 2010 at 1:36 PM, Mark Tinka <mtinka at globaltransit.net>wrote:
>
>> On Wednesday 31 March 2010 03:20:28 pm Ramesh Karki wrote:
>>
>> >  Static route from Cisco to M10i Lo0 ip is okay. but
>> >  static route from M10i to 720x Lo0 is not showing on
>> >  routing table and it is not working. There is no problem
>> >  between p2p connection.
>>
>> Can we take a quick peek at your static routing
>> configuration?
>>
>> Cheers,
>>
>> Mark.
>>
>
>

From cgrundemann at gmail.com  Wed Mar 31 10:33:17 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 31 Mar 2010 08:33:17 -0600
Subject: [j-nsp] ipv6 routing
In-Reply-To: <t2gbb76118f1003310638u244dd26ep92cd8267e28b45b6@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<t2gbb76118f1003310638u244dd26ep92cd8267e28b45b6@mail.gmail.com>
Message-ID: <t2t443de7ad1003310733o433c021dx2dc6f69f67087ed3@mail.gmail.com>

Are there any hidden routes in inet6.0? Is there a route for
abcd:3800:1:1::2, can you ping it?

For more help, please paste in the output from "show route table inet6.0".

~Chris


On Wed, Mar 31, 2010 at 07:38, Ramesh Karki <rameshkarki at gmail.com> wrote:

> hello,
>
> I am still waiting the response ..is there anyone have faced the same
> problem ??
>
> Thank you,
>
>
> On Wed, Mar 31, 2010 at 1:51 PM, Ramesh Karki <rameshkarki at gmail.com>
> wrote:
>
> > Hi,
> >
> > here is my config :
> >
> > sh conf int ge-0/0/0
> > description " ";
> > unit 0 {
> >     family inet {
> >                 address x.x.193.65/26;
> >     }
> >     family inet6 {
> >         address abcd:3800:1:1::1/64;
> >     }
> > }
> >
> > sh conf int lo0
> > unit 0 {
> >     family inet {
> >                 }
> >         address x.x.192.1/32;
> >     }
> >     family inet6 {
> >         address abcd:3800::1/128;
> >     }
> > }
> >
> > rib inet6.0 {
> >     static {
> >         route abcd:3800::2/128 next-hop abcd:3800:1:1::2;
> >         route abcd:3800::4/128 next-hop abcd:3800:2:1::2;
> >
> > here, abcd:3800:1:1::2 is neighbor (P2P) ip of 72xx router and
> > abcd:3800::2/128 is lo0 ip.
> >
> > The command > show route table inet6.0  only shows the direct and
> connected
> > route.
> >
> > thank you,
> >
> >
> > On Wed, Mar 31, 2010 at 1:36 PM, Mark Tinka <mtinka at globaltransit.net
> >wrote:
> >
> >> On Wednesday 31 March 2010 03:20:28 pm Ramesh Karki wrote:
> >>
> >> >  Static route from Cisco to M10i Lo0 ip is okay. but
> >> >  static route from M10i to 720x Lo0 is not showing on
> >> >  routing table and it is not working. There is no problem
> >> >  between p2p connection.
> >>
> >> Can we take a quick peek at your static routing
> >> configuration?
> >>
> >> Cheers,
> >>
> >> Mark.
> >>
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org

From mtinka at globaltransit.net  Wed Mar 31 10:53:48 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 31 Mar 2010 22:53:48 +0800
Subject: [j-nsp] ipv6 routing
In-Reply-To: <j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
Message-ID: <201003312253.49770.mtinka@globaltransit.net>

On Wednesday 31 March 2010 04:06:55 pm Ramesh Karki wrote:

> Hi,
> 
> here is my config :

Can we take a look at your v6 routing table (I'm guessing 
it's small enough).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100331/2ba98287/attachment.bin>

From rameshkarki at gmail.com  Wed Mar 31 14:58:20 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Thu, 1 Apr 2010 00:43:20 +0545
Subject: [j-nsp] ipv6 routing
In-Reply-To: <201003312253.49770.mtinka@globaltransit.net>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
Message-ID: <l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>

Hi,

yes, I can ping my neighbor or next-hop ip adddress, and also there is no
any hidden routes on table inet6.0.

> show route table inet6.0
inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

abcd:3800::1/128   *[Direct/0] 1d 04:55:09
                    > via lo0.0
abcd:3800:1:1::/64 *[Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
abcd:3800:1:1::1/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
abcd:3800:2:1::/126*[Direct/0] 13:48:59
                    > via fe-0/1/0.0
abcd:3800:2:1::1/128
                   *[Local/0] 13:48:59
                      Local via fe-0/1/0.0
abcd:3800:4::/48   *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
abcd:3800:4::1/128 *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::/64          *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
                    [Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
                    [Direct/0] 14:05:12
                    > via fe-0/1/0.0
fe80::217:cbff:fe77:0/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
fe80::217:cbff:fe77:1f/128
                   *[Local/0] 14:05:12
                      Local via fe-0/1/0.0
fe80::217:cbff:fe77:5e/128
                   *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::2a0:a5ff:fe62:57c7/128
                   *[Direct/0] 1d 04:55:09
                    > via lo0.0

I have tried run ospf3 but no luck, the command > show ospf3 interface
ge-0/0/0.0 says
?OSPF instance is not running?



On Wed, Mar 31, 2010 at 8:38 PM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Wednesday 31 March 2010 04:06:55 pm Ramesh Karki wrote:
>
> > Hi,
> >
> > here is my config :
>
> Can we take a look at your v6 routing table (I'm guessing
> it's small enough).
>
> Cheers,
>
> Mark.
>

From rameshkarki at gmail.com  Wed Mar 31 15:08:15 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Thu, 1 Apr 2010 00:53:15 +0545
Subject: [j-nsp] ipv6 routing
In-Reply-To: <l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
	<l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
Message-ID: <m2nbb76118f1003311208x9e8ae3cfre5d23274660fddbb@mail.gmail.com>

Hi,

yes, I can ping my neighbor or next-hop ip adddress, and also there is no
any hidden routes on table inet6.0.

> show route table inet6.0
inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

abcd:3800::1/128   *[Direct/0] 1d 04:55:09
                    > via lo0.0
abcd:3800:1:1::/64 *[Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
abcd:3800:1:1::1/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
abcd:3800:2:1::/126*[Direct/0] 13:48:59
                    > via fe-0/1/0.0
abcd:3800:2:1::1/128
                   *[Local/0] 13:48:59
                      Local via fe-0/1/0.0
abcd:3800:4::/48   *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
abcd:3800:4::1/128 *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::/64          *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
                    [Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
                    [Direct/0] 14:05:12
                    > via fe-0/1/0.0
fe80::217:cbff:fe77:0/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
fe80::217:cbff:fe77:1f/128
                   *[Local/0] 14:05:12
                      Local via fe-0/1/0.0
fe80::217:cbff:fe77:5e/128
                   *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::2a0:a5ff:fe62:57c7/128
                   *[Direct/0] 1d 04:55:09
                    > via lo0.0

I have also tried to run ospf3 but no luck, the command > show ospf3
interface ge-0/0/0.0 says
?OSPF instance is not running?

Thank you,
Ramesh

On Thu, Apr 1, 2010 at 12:43 AM, Ramesh Karki <rameshkarki at gmail.com> wrote:

> Hi,
>
> yes, I can ping my neighbor or next-hop ip adddress, and also there is no
> any hidden routes on table inet6.0.
>
> > show route table inet6.0
> inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> abcd:3800::1/128   *[Direct/0] 1d 04:55:09
>                     > via lo0.0
> abcd:3800:1:1::/64 *[Direct/0] 1d 04:41:21
>                     > via ge-0/0/0.0
> abcd:3800:1:1::1/128
>                    *[Local/0] 1d 04:41:21
>                       Local via ge-0/0/0.0
> abcd:3800:2:1::/126*[Direct/0] 13:48:59
>                     > via fe-0/1/0.0
> abcd:3800:2:1::1/128
>                    *[Local/0] 13:48:59
>                       Local via fe-0/1/0.0
> abcd:3800:4::/48   *[Direct/0] 1d 04:47:20
>                     > via fe-0/3/1.0
> abcd:3800:4::1/128 *[Local/0] 1d 04:47:20
>                       Local via fe-0/3/1.0
> fe80::/64          *[Direct/0] 1d 04:47:20
>                     > via fe-0/3/1.0
>                     [Direct/0] 1d 04:41:21
>                     > via ge-0/0/0.0
>                     [Direct/0] 14:05:12
>                     > via fe-0/1/0.0
> fe80::217:cbff:fe77:0/128
>                    *[Local/0] 1d 04:41:21
>                       Local via ge-0/0/0.0
> fe80::217:cbff:fe77:1f/128
>                    *[Local/0] 14:05:12
>                       Local via fe-0/1/0.0
> fe80::217:cbff:fe77:5e/128
>                    *[Local/0] 1d 04:47:20
>                       Local via fe-0/3/1.0
> fe80::2a0:a5ff:fe62:57c7/128
>                    *[Direct/0] 1d 04:55:09
>                     > via lo0.0
>
> I have tried run ospf3 but no luck, the command > show ospf3 interface
> ge-0/0/0.0 says
> ?OSPF instance is not running?
>
>
>
> On Wed, Mar 31, 2010 at 8:38 PM, Mark Tinka <mtinka at globaltransit.net>wrote:
>
>> On Wednesday 31 March 2010 04:06:55 pm Ramesh Karki wrote:
>>
>> > Hi,
>> >
>> > here is my config :
>>
>> Can we take a look at your v6 routing table (I'm guessing
>> it's small enough).
>>
>> Cheers,
>>
>> Mark.
>>
>
>

From chrisccnpspam2 at gmail.com  Wed Mar 31 15:13:14 2010
From: chrisccnpspam2 at gmail.com (chrisccnpspam2 at gmail.com)
Date: Wed, 31 Mar 2010 19:13:14 +0000
Subject: [j-nsp] ipv6 routing
In-Reply-To: <l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com><201003311552.00629.mtinka@globaltransit.net><j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com><201003312253.49770.mtinka@globaltransit.net><l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
Message-ID: <888416260-1270062798-cardhu_decombobulator_blackberry.rim.net-2100515589-@bda069.bisx.prod.on.blackberry>

Forgive me for not fully remembering as its been a while since I muddled with v6.  But for some reason I believe you have to do the static route to a link local address, not to the address you configure under the interface. This would be the address starting with "fe80"

Can anyone validate my vague memory?

Sent via BlackBerry by AT&T

-----Original Message-----
From: Ramesh Karki <rameshkarki at gmail.com>
Date: Thu, 1 Apr 2010 00:43:20 
To: <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] ipv6 routing

Hi,

yes, I can ping my neighbor or next-hop ip adddress, and also there is no
any hidden routes on table inet6.0.

> show route table inet6.0
inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

abcd:3800::1/128   *[Direct/0] 1d 04:55:09
                    > via lo0.0
abcd:3800:1:1::/64 *[Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
abcd:3800:1:1::1/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
abcd:3800:2:1::/126*[Direct/0] 13:48:59
                    > via fe-0/1/0.0
abcd:3800:2:1::1/128
                   *[Local/0] 13:48:59
                      Local via fe-0/1/0.0
abcd:3800:4::/48   *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
abcd:3800:4::1/128 *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::/64          *[Direct/0] 1d 04:47:20
                    > via fe-0/3/1.0
                    [Direct/0] 1d 04:41:21
                    > via ge-0/0/0.0
                    [Direct/0] 14:05:12
                    > via fe-0/1/0.0
fe80::217:cbff:fe77:0/128
                   *[Local/0] 1d 04:41:21
                      Local via ge-0/0/0.0
fe80::217:cbff:fe77:1f/128
                   *[Local/0] 14:05:12
                      Local via fe-0/1/0.0
fe80::217:cbff:fe77:5e/128
                   *[Local/0] 1d 04:47:20
                      Local via fe-0/3/1.0
fe80::2a0:a5ff:fe62:57c7/128
                   *[Direct/0] 1d 04:55:09
                    > via lo0.0

I have tried run ospf3 but no luck, the command > show ospf3 interface
ge-0/0/0.0 says
?OSPF instance is not running?



On Wed, Mar 31, 2010 at 8:38 PM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Wednesday 31 March 2010 04:06:55 pm Ramesh Karki wrote:
>
> > Hi,
> >
> > here is my config :
>
> Can we take a look at your v6 routing table (I'm guessing
> it's small enough).
>
> Cheers,
>
> Mark.
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


From tony at lava.net  Wed Mar 31 15:18:32 2010
From: tony at lava.net (Antonio Querubin)
Date: Wed, 31 Mar 2010 09:18:32 -1000 (HST)
Subject: [j-nsp] ipv6 routing
In-Reply-To: <j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1003310913210.199@cust11794.lava.net>

On Wednesday 31 March 2010 03:20:28 pm Ramesh Karki wrote:

>  Static route from Cisco to M10i Lo0 ip is okay. but
>  static route from M10i to 720x Lo0 is not showing on
>  routing table and it is not working. There is no problem
>  between p2p connection.

Are you sure the Cisco is announcing the loopback address to the M10? 
You may want try adding 'redistribute connected' in the appropriate IGP 
part of your Cisco config.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net

From tony at lava.net  Wed Mar 31 15:27:40 2010
From: tony at lava.net (Antonio Querubin)
Date: Wed, 31 Mar 2010 09:27:40 -1000 (HST)
Subject: [j-nsp] ipv6 routing
In-Reply-To: <m2nbb76118f1003311208x9e8ae3cfre5d23274660fddbb@mail.gmail.com>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
	<l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
	<m2nbb76118f1003311208x9e8ae3cfre5d23274660fddbb@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1003310923240.199@cust11794.lava.net>

On Thu, 1 Apr 2010, Ramesh Karki wrote:

> I have also tried to run ospf3 but no luck, the command > show ospf3
> interface ge-0/0/0.0 says
> ?OSPF instance is not running?

>> I have tried run ospf3 but no luck, the command > show ospf3 interface
>> ge-0/0/0.0 says
>> ?OSPF instance is not running?

What does your ospf3 config look like on the M10?  What does it look like 
on the Cisco?

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net

From jof at thejof.com  Wed Mar 31 15:31:06 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 31 Mar 2010 12:31:06 -0700
Subject: [j-nsp] ipv6 routing
In-Reply-To: <888416260-1270062798-cardhu_decombobulator_blackberry.rim.net-2100515589-@bda069.bisx.prod.on.blackberry>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
	<l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
	<888416260-1270062798-cardhu_decombobulator_blackberry.rim.net-2100515589-@bda069.bisx.prod.on.blackberry>
Message-ID: <1270063556-sup-1483@sfo.thejof.com>

Excerpts from chrisccnpspam2's message of Wed Mar 31 12:13:14 -0700 2010:
> Forgive me for not fully remembering as its been a while since I muddled with v6.  But for some reason I believe you have to do the static route to a link local address, not to the address you configure under the interface. This would be the address starting with "fe80"
> 
> Can anyone validate my vague memory?

I'm not so sure about the applicability of this under JunOS, as most of
my work with it has been for IPv4/inet installations.

Protocol-wise though, I can't think it should matter. A next-hop via a
link-local address or one addressed out of the global unicast pool
should resolve all the same (i.e.. they'll both result in ICMPv6
Neighbor Solicitations)

Cheers,
jof

From cgrundemann at gmail.com  Wed Mar 31 15:49:32 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 31 Mar 2010 13:49:32 -0600
Subject: [j-nsp] ipv6 routing
In-Reply-To: <888416260-1270062798-cardhu_decombobulator_blackberry.rim.net-2100515589-@bda069.bisx.prod.on.blackberry>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
	<l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
	<888416260-1270062798-cardhu_decombobulator_blackberry.rim.net-2100515589-@bda069.bisx.prod.on.blackberry>
Message-ID: <w2s443de7ad1003311249kfc60f8acy5c264565ac2da2f7@mail.gmail.com>

On Wed, Mar 31, 2010 at 13:13, <chrisccnpspam2 at gmail.com> wrote:

> Forgive me for not fully remembering as its been a while since I muddled
> with v6.  But for some reason I believe you have to do the static route to a
> link local address, not to the address you configure under the interface.
> This would be the address starting with "fe80"
>
> Can anyone validate my vague memory?
>

Any valid next hop address is acceptable (it does not have to be a link
local address).


>
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: Ramesh Karki <rameshkarki at gmail.com>
> Date: Thu, 1 Apr 2010 00:43:20
> To: <juniper-nsp at puck.nether.net>
> Subject: Re: [j-nsp] ipv6 routing
>
> Hi,
>
> yes, I can ping my neighbor or next-hop ip adddress, and also there is no
> any hidden routes on table inet6.0.
>
> > show route table inet6.0
> inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> abcd:3800::1/128   *[Direct/0] 1d 04:55:09
>                    > via lo0.0
> abcd:3800:1:1::/64 *[Direct/0] 1d 04:41:21
>                    > via ge-0/0/0.0
> abcd:3800:1:1::1/128
>                   *[Local/0] 1d 04:41:21
>                      Local via ge-0/0/0.0
> abcd:3800:2:1::/126*[Direct/0] 13:48:59
>                    > via fe-0/1/0.0
> abcd:3800:2:1::1/128
>                   *[Local/0] 13:48:59
>                      Local via fe-0/1/0.0
> abcd:3800:4::/48   *[Direct/0] 1d 04:47:20
>                    > via fe-0/3/1.0
> abcd:3800:4::1/128 *[Local/0] 1d 04:47:20
>                      Local via fe-0/3/1.0
> fe80::/64          *[Direct/0] 1d 04:47:20
>                    > via fe-0/3/1.0
>                    [Direct/0] 1d 04:41:21
>                    > via ge-0/0/0.0
>                    [Direct/0] 14:05:12
>                    > via fe-0/1/0.0
> fe80::217:cbff:fe77:0/128
>                   *[Local/0] 1d 04:41:21
>                      Local via ge-0/0/0.0
> fe80::217:cbff:fe77:1f/128
>                   *[Local/0] 14:05:12
>                      Local via fe-0/1/0.0
> fe80::217:cbff:fe77:5e/128
>                   *[Local/0] 1d 04:47:20
>                      Local via fe-0/3/1.0
> fe80::2a0:a5ff:fe62:57c7/128
>                   *[Direct/0] 1d 04:55:09
>                    > via lo0.0
>
> I have tried run ospf3 but no luck, the command > show ospf3 interface
> ge-0/0/0.0 says
> ?OSPF instance is not running?
>
>
>
> On Wed, Mar 31, 2010 at 8:38 PM, Mark Tinka <mtinka at globaltransit.net
> >wrote:
>
> > On Wednesday 31 March 2010 04:06:55 pm Ramesh Karki wrote:
> >
> > > Hi,
> > >
> > > here is my config :
> >
> > Can we take a look at your v6 routing table (I'm guessing
> > it's small enough).
> >
> > Cheers,
> >
> > Mark.
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org

From rameshkarki at gmail.com  Wed Mar 31 15:54:29 2010
From: rameshkarki at gmail.com (Ramesh Karki)
Date: Thu, 1 Apr 2010 01:39:29 +0545
Subject: [j-nsp] ipv6 routing
In-Reply-To: <alpine.OSX.2.00.1003310923240.199@cust11794.lava.net>
References: <z2tbb76118f1003310020l794eede9w6eff2d069a2c46f8@mail.gmail.com>
	<201003311552.00629.mtinka@globaltransit.net>
	<j2wbb76118f1003310106qa9ec46d4lc9aea38e96c3e557@mail.gmail.com>
	<201003312253.49770.mtinka@globaltransit.net>
	<l2nbb76118f1003311158r63b4289dzbb0474191623abbd@mail.gmail.com>
	<m2nbb76118f1003311208x9e8ae3cfre5d23274660fddbb@mail.gmail.com>
	<alpine.OSX.2.00.1003310923240.199@cust11794.lava.net>
Message-ID: <t2gbb76118f1003311254u5c53436cr42c66c4b63836e5@mail.gmail.com>

Hi,
Similar ospf config between cisco to cisco is okay there is not any issue.
 But between cisco to M10i is not working.
Here, I have listed my JunOS ospf config :
run show configuration protocols ospf3
preference 10;
area 0.0.0.10 {
    interface lo0.0 {
        passive;
    }
    interface ge-0/0/0.0 {
        metric 10;

am I missing anything ??

My curiosity : when I execute the command > run show ospf3 interface
ge-0/0/0.0 it says -
 ?OSPF instance is not running? ??

Thank you,


On Thu, Apr 1, 2010 at 1:12 AM, Antonio Querubin <tony at lava.net> wrote:

> On Thu, 1 Apr 2010, Ramesh Karki wrote:
>
>  I have also tried to run ospf3 but no luck, the command > show ospf3
>> interface ge-0/0/0.0 says
>> ?OSPF instance is not running?
>>
>
>  I have tried run ospf3 but no luck, the command > show ospf3 interface
>>> ge-0/0/0.0 says
>>> ?OSPF instance is not running?
>>>
>>
> What does your ospf3 config look like on the M10?  What does it look like
> on the Cisco?
>
>
> Antonio Querubin
> 808-545-5282 x3003
> e-mail/xmpp:  tony at lava.net
>

From gabrielfarias03 at gmail.com  Wed Mar 31 16:23:36 2010
From: gabrielfarias03 at gmail.com (Gabriel Farias)
Date: Wed, 31 Mar 2010 17:23:36 -0300
Subject: [j-nsp] Load Balance in VRF by Junos
Message-ID: <i2ra729c7e1003311323r19c691a9k2b81783d0dfc6201@mail.gmail.com>

Hi members,


How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco 6509
(CE) Switch, which are connected via ethernet aggregated?



I used the setup below and did not work the Juniper continues with the
output unbalanced traffic.



configuration forwarding-options

load-balance {
    indexed-next-hop;
}
hash-key {
    family inet {
        layer-3;
        layer-4;
    }
}


Thanks,

Gabriel Farias

From sfouant at shortestpathfirst.net  Wed Mar 31 16:48:32 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 31 Mar 2010 20:48:32 +0000
Subject: [j-nsp] Load Balance in VRF by Junos
Message-ID: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry>

You need the following:

'set routing-option forwarding-table export load-balance'

and

'set policy-options policy-statement load-balance then load-balance per-packet'

Sorry for the top-post, I'm on my Blackberry.

HTHs.

Stefan Fouant
------Original Message------
From: Gabriel Farias
Sender: juniper-nsp-bounces at puck.nether.net
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Load Balance in VRF by Junos
Sent: Mar 31, 2010 4:23 PM

Hi members,


How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco 6509
(CE) Switch, which are connected via ethernet aggregated?



I used the setup below and did not work the Juniper continues with the
output unbalanced traffic.



configuration forwarding-options

load-balance {
    indexed-next-hop;
}
hash-key {
    family inet {
        layer-3;
        layer-4;
    }
}


Thanks,

Gabriel Farias
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Sent from my Verizon Wireless BlackBerry


From gabrielfarias03 at gmail.com  Wed Mar 31 17:32:18 2010
From: gabrielfarias03 at gmail.com (Gabriel Farias)
Date: Wed, 31 Mar 2010 18:32:18 -0300
Subject: [j-nsp] Load Balance in VRF by Junos
In-Reply-To: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry>
References: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry>
Message-ID: <m2pa729c7e1003311432q73aeb75dn92f561241f68eb86@mail.gmail.com>

I have a section between EBGP VRF PE x CE via two physical connections
(aggregate ethernet) and see the traffic unbalanced because the Junos uses
the default flow.

I need the traffic between the PE x CE is symmetrically balanced way, the
previous setting and did not work, and within the configuration
routing-instance <name> not have all the options.

Thanks
Gabriel Farias

2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>

> You need the following:
>
> 'set routing-option forwarding-table export load-balance'
>
> and
>
> 'set policy-options policy-statement load-balance then load-balance
> per-packet'
>
> Sorry for the top-post, I'm on my Blackberry.
>
> HTHs.
>
> Stefan Fouant
> ------Original Message------
> From: Gabriel Farias
> Sender: juniper-nsp-bounces at puck.nether.net
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] Load Balance in VRF by Junos
> Sent: Mar 31, 2010 4:23 PM
>
> Hi members,
>
>
> How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco
> 6509
> (CE) Switch, which are connected via ethernet aggregated?
>
>
>
> I used the setup below and did not work the Juniper continues with the
> output unbalanced traffic.
>
>
>
> configuration forwarding-options
>
> load-balance {
>    indexed-next-hop;
> }
> hash-key {
>    family inet {
>        layer-3;
>        layer-4;
>    }
> }
>
>
> Thanks,
>
> Gabriel Farias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry

From sfouant at shortestpathfirst.net  Wed Mar 31 17:42:10 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 31 Mar 2010 21:42:10 +0000
Subject: [j-nsp] Load Balance in VRF by Junos
In-Reply-To: <m2pa729c7e1003311432q73aeb75dn92f561241f68eb86@mail.gmail.com>
References: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry><m2pa729c7e1003311432q73aeb75dn92f561241f68eb86@mail.gmail.com>
Message-ID: <1685615706-1270071720-cardhu_decombobulator_blackberry.rim.net-46611921-@bda294.bisx.prod.on.blackberry>

Do you have multi-path enabled on your EBGP sessions?

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Gabriel Farias <gabrielfarias03 at gmail.com>
Date: Wed, 31 Mar 2010 18:32:18 
To: <sfouant at shortestpathfirst.net>
Cc: <juniper-nsp-bounces at puck.nether.net>; <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Load Balance in VRF by Junos

I have a section between EBGP VRF PE x CE via two physical connections
(aggregate ethernet) and see the traffic unbalanced because the Junos uses
the default flow.

I need the traffic between the PE x CE is symmetrically balanced way, the
previous setting and did not work, and within the configuration
routing-instance <name> not have all the options.

Thanks
Gabriel Farias

2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>

> You need the following:
>
> 'set routing-option forwarding-table export load-balance'
>
> and
>
> 'set policy-options policy-statement load-balance then load-balance
> per-packet'
>
> Sorry for the top-post, I'm on my Blackberry.
>
> HTHs.
>
> Stefan Fouant
> ------Original Message------
> From: Gabriel Farias
> Sender: juniper-nsp-bounces at puck.nether.net
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] Load Balance in VRF by Junos
> Sent: Mar 31, 2010 4:23 PM
>
> Hi members,
>
>
> How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco
> 6509
> (CE) Switch, which are connected via ethernet aggregated?
>
>
>
> I used the setup below and did not work the Juniper continues with the
> output unbalanced traffic.
>
>
>
> configuration forwarding-options
>
> load-balance {
>    indexed-next-hop;
> }
> hash-key {
>    family inet {
>        layer-3;
>        layer-4;
>    }
> }
>
>
> Thanks,
>
> Gabriel Farias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry


From gabrielfarias03 at gmail.com  Wed Mar 31 17:51:04 2010
From: gabrielfarias03 at gmail.com (Gabriel Farias)
Date: Wed, 31 Mar 2010 18:51:04 -0300
Subject: [j-nsp] Load Balance in VRF by Junos
In-Reply-To: <1685615706-1270071720-cardhu_decombobulator_blackberry.rim.net-46611921-@bda294.bisx.prod.on.blackberry>
References: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry>
	<m2pa729c7e1003311432q73aeb75dn92f561241f68eb86@mail.gmail.com>
	<1685615706-1270071720-cardhu_decombobulator_blackberry.rim.net-46611921-@bda294.bisx.prod.on.blackberry>
Message-ID: <v2ya729c7e1003311451x95b6b16i382c33b67fd83b0f@mail.gmail.com>

I'm not using EBGP external type in PE (M120)

Reagards,
Gabriel Farias

2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>

> Do you have multi-path enabled on your EBGP sessions?
>
> Stefan Fouant
>
> Sent from my Verizon Wireless BlackBerry
> ------------------------------
> *From: * Gabriel Farias <gabrielfarias03 at gmail.com>
> *Date: *Wed, 31 Mar 2010 18:32:18 -0300
> *To: *<sfouant at shortestpathfirst.net>
> *Cc: *<juniper-nsp-bounces at puck.nether.net>; <juniper-nsp at puck.nether.net>
> *Subject: *Re: [j-nsp] Load Balance in VRF by Junos
>
> I have a section between EBGP VRF PE x CE via two physical connections
> (aggregate ethernet) and see the traffic unbalanced because the Junos uses
> the default flow.
>
> I need the traffic between the PE x CE is symmetrically balanced way, the
> previous setting and did not work, and within the configuration
> routing-instance <name> not have all the options.
>
> Thanks
> Gabriel Farias
>
> 2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>
>
>> You need the following:
>>
>> 'set routing-option forwarding-table export load-balance'
>>
>> and
>>
>> 'set policy-options policy-statement load-balance then load-balance
>> per-packet'
>>
>> Sorry for the top-post, I'm on my Blackberry.
>>
>> HTHs.
>>
>> Stefan Fouant
>> ------Original Message------
>> From: Gabriel Farias
>> Sender: juniper-nsp-bounces at puck.nether.net
>> To: juniper-nsp at puck.nether.net
>> Subject: [j-nsp] Load Balance in VRF by Junos
>> Sent: Mar 31, 2010 4:23 PM
>>
>> Hi members,
>>
>>
>> How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco
>> 6509
>> (CE) Switch, which are connected via ethernet aggregated?
>>
>>
>>
>> I used the setup below and did not work the Juniper continues with the
>> output unbalanced traffic.
>>
>>
>>
>> configuration forwarding-options
>>
>> load-balance {
>>    indexed-next-hop;
>> }
>> hash-key {
>>    family inet {
>>        layer-3;
>>        layer-4;
>>    }
>> }
>>
>>
>> Thanks,
>>
>> Gabriel Farias
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> Sent from my Verizon Wireless BlackBerry
>
>
>

From wallerp_7 at hotmail.com  Wed Mar 31 18:13:29 2010
From: wallerp_7 at hotmail.com (Paul Waller)
Date: Thu, 1 Apr 2010 08:13:29 +1000
Subject: [j-nsp] High memory usage on EX4200 stack
In-Reply-To: <7393DD5B69CCB64D8F90EAB980828149B198BAED84@exb01.cs.imtechict.local>
References: <4BB21E69020000D4000117A4@gw.molndal.se>,
	<7393DD5B69CCB64D8F90EAB980828149B198BAED84@exb01.cs.imtechict.local>
Message-ID: <BAY133-W51B40DFF243C8C090A888D61E0@phx.gbl>


Hi Wouter,

 

We have a couple of stacked EX4200's in our network that we're just going to upgrade to 10.0S1.1.  My question is if Juniper supplied you with release 10.0S3.1 then have they acknowledge there is a problem & opened a PR ?

 

I'd be interested to know if anyone else has seen this ?  as it could be triggered with a certain configuration. 

Regards
Paul



 
> From: Wouter.vandenBergh at imtech.nl
> To: juniper-nsp at puck.nether.net
> Date: Tue, 30 Mar 2010 16:16:21 +0200
> Subject: Re: [j-nsp] High memory usage on EX4200 stack
> 
> Matrin,
> 
> We have been experiencing kernel memory leaks on a EX4200 virtual chassis containing 2 devices after we upgraded to a 10 release. We were supplied version 10.0S3.1 to fix these problems. You might want to give that version a try and see if our problems were related.
> 
> Regards,
> 
> Wouter
> 
> -----Oorspronkelijk bericht-----
> Van: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] Namens Martin Levin
> Verzonden: dinsdag 30 maart 2010 15:53
> Aan: juniper-nsp at puck.nether.net
> Onderwerp: [j-nsp] High memory usage on EX4200 stack
> 
> Hi!
> 
> We have 3 EX4200 virtual chassis all running 10.0S1.1, one consisting
> of 4 EX4200 and the other two och two switches each.
> 
> The problem below only affects the two stacks with two switches each,
> the 2 switch stack does not se this.
> 
> The problem we're seeing is that member 0, regardless of wether its the
> master routing engine or not sees very high memory usage (89%) and the
> boxes then become very slow. These switches operate on layer 2 only.
> 
> If I try to do "request session member 0" i get "could not create child
> process" as an error and I can't login to that member. Traffic seems to
> flow without problem however.
> 
> Any thoughts?
> 
> 
> 
> ---
> Martin Levin
> IT-strategy & planning
> M?lndals stad
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
 		 	   		  
_________________________________________________________________
Browse profiles for FREE! Meet local singles online.
http://clk.atdmt.com/NMN/go/150855801/direct/01/

From wallerp_7 at hotmail.com  Wed Mar 31 18:14:00 2010
From: wallerp_7 at hotmail.com (Paul Waller)
Date: Thu, 1 Apr 2010 08:14:00 +1000
Subject: [j-nsp] High memory usage on EX4200 stack
In-Reply-To: <7393DD5B69CCB64D8F90EAB980828149B198BAED84@exb01.cs.imtechict.local>
References: <4BB21E69020000D4000117A4@gw.molndal.se>,
	<7393DD5B69CCB64D8F90EAB980828149B198BAED84@exb01.cs.imtechict.local>
Message-ID: <BAY133-W28BF42DAB132FC9C1DB86ED61E0@phx.gbl>


Hi Wouter,

 

We have a couple of stacked EX4200's in our network that we're just going to upgrade to 10.0S1.1.  My question is if Juniper supplied you with release 10.0S3.1 then have they acknowledge there is a problem & opened a PR ?

 

I'd be interested to know if anyone else has seen this ?  as it could be triggered with a certain configuration. 

Regards
Paul



 
> From: Wouter.vandenBergh at imtech.nl
> To: juniper-nsp at puck.nether.net
> Date: Tue, 30 Mar 2010 16:16:21 +0200
> Subject: Re: [j-nsp] High memory usage on EX4200 stack
> 
> Matrin,
> 
> We have been experiencing kernel memory leaks on a EX4200 virtual chassis containing 2 devices after we upgraded to a 10 release. We were supplied version 10.0S3.1 to fix these problems. You might want to give that version a try and see if our problems were related.
> 
> Regards,
> 
> Wouter
> 
> -----Oorspronkelijk bericht-----
> Van: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] Namens Martin Levin
> Verzonden: dinsdag 30 maart 2010 15:53
> Aan: juniper-nsp at puck.nether.net
> Onderwerp: [j-nsp] High memory usage on EX4200 stack
> 
> Hi!
> 
> We have 3 EX4200 virtual chassis all running 10.0S1.1, one consisting
> of 4 EX4200 and the other two och two switches each.
> 
> The problem below only affects the two stacks with two switches each,
> the 2 switch stack does not se this.
> 
> The problem we're seeing is that member 0, regardless of wether its the
> master routing engine or not sees very high memory usage (89%) and the
> boxes then become very slow. These switches operate on layer 2 only.
> 
> If I try to do "request session member 0" i get "could not create child
> process" as an error and I can't login to that member. Traffic seems to
> flow without problem however.
> 
> Any thoughts?
> 
> 
> 
> ---
> Martin Levin
> IT-strategy & planning
> M?lndals stad
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
 		 	   		  
_________________________________________________________________
Looking for a new home? With all the latest places, searching has never been easier.
http://clk.atdmt.com/NMN/go/157631292/direct/01/

From sfouant at shortestpathfirst.net  Wed Mar 31 18:24:23 2010
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 31 Mar 2010 22:24:23 +0000
Subject: [j-nsp] Load Balance in VRF by Junos
In-Reply-To: <v2ya729c7e1003311451x95b6b16i382c33b67fd83b0f@mail.gmail.com>
References: <750571275-1270068503-cardhu_decombobulator_blackberry.rim.net-1706142866-@bda294.bisx.prod.on.blackberry>
	<m2pa729c7e1003311432q73aeb75dn92f561241f68eb86@mail.gmail.com>
	<1685615706-1270071720-cardhu_decombobulator_blackberry.rim.net-46611921-@bda294.bisx.prod.on.blackberry><v2ya729c7e1003311451x95b6b16i382c33b67fd83b0f@mail.gmail.com>
Message-ID: <726687785-1270074254-cardhu_decombobulator_blackberry.rim.net-2143512915-@bda294.bisx.prod.on.blackberry>

I'm sorry, your request is getting lost in translation.  Why don't you just show us your configs and do a 'show route x.x.x.x' and 'show route forwarding-table destination x.x.x.x' for the route you are trying to load-balance.

Thanks,

Stefan Fouant
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Gabriel Farias <gabrielfarias03 at gmail.com>
Date: Wed, 31 Mar 2010 18:51:04 
To: <sfouant at shortestpathfirst.net>
Cc: <juniper-nsp-bounces at puck.nether.net>; <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Load Balance in VRF by Junos

I'm not using EBGP external type in PE (M120)

Reagards,
Gabriel Farias

2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>

> Do you have multi-path enabled on your EBGP sessions?
>
> Stefan Fouant
>
> Sent from my Verizon Wireless BlackBerry
> ------------------------------
> *From: * Gabriel Farias <gabrielfarias03 at gmail.com>
> *Date: *Wed, 31 Mar 2010 18:32:18 -0300
> *To: *<sfouant at shortestpathfirst.net>
> *Cc: *<juniper-nsp-bounces at puck.nether.net>; <juniper-nsp at puck.nether.net>
> *Subject: *Re: [j-nsp] Load Balance in VRF by Junos
>
> I have a section between EBGP VRF PE x CE via two physical connections
> (aggregate ethernet) and see the traffic unbalanced because the Junos uses
> the default flow.
>
> I need the traffic between the PE x CE is symmetrically balanced way, the
> previous setting and did not work, and within the configuration
> routing-instance <name> not have all the options.
>
> Thanks
> Gabriel Farias
>
> 2010/3/31 Stefan Fouant <sfouant at shortestpathfirst.net>
>
>> You need the following:
>>
>> 'set routing-option forwarding-table export load-balance'
>>
>> and
>>
>> 'set policy-options policy-statement load-balance then load-balance
>> per-packet'
>>
>> Sorry for the top-post, I'm on my Blackberry.
>>
>> HTHs.
>>
>> Stefan Fouant
>> ------Original Message------
>> From: Gabriel Farias
>> Sender: juniper-nsp-bounces at puck.nether.net
>> To: juniper-nsp at puck.nether.net
>> Subject: [j-nsp] Load Balance in VRF by Junos
>> Sent: Mar 31, 2010 4:23 PM
>>
>> Hi members,
>>
>>
>> How to balance traffic between EBGP equipment Juniper M120 (PE) x Cisco
>> 6509
>> (CE) Switch, which are connected via ethernet aggregated?
>>
>>
>>
>> I used the setup below and did not work the Juniper continues with the
>> output unbalanced traffic.
>>
>>
>>
>> configuration forwarding-options
>>
>> load-balance {
>>    indexed-next-hop;
>> }
>> hash-key {
>>    family inet {
>>        layer-3;
>>        layer-4;
>>    }
>> }
>>
>>
>> Thanks,
>>
>> Gabriel Farias
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> Sent from my Verizon Wireless BlackBerry
>
>
>


From aalejandro at worldnetpr.com  Wed Mar 31 21:59:08 2010
From: aalejandro at worldnetpr.com (Abel Alejandro)
Date: Wed, 31 Mar 2010 21:59:08 -0400
Subject: [j-nsp] EX4200 sFlow on cluster
Message-ID: <79BBBA445314D14C927525E537E6036307B4A9@wnetexchg01.worldnetpr.com>

Hello,

I am running 4 x EX4200 in a virtual chassis configuration. I configured
sFlow but I can not get it to work.
Basically the configuration is accepted and no errors are given but no
flows are sent to the collector.

I tried placing the collecting within the same subnet as the vme 0
management interface and also moving it to a physical port.

According the EX4200 the flows are being sent but I am running a tcpdump
on the collector and nothing is coming from the EX4200.

aalejandro at mop-ex4200> show sflow collector    
Collector         Udp-port    No. of samples
 address
10.255.253.10     9998        25067         

{master:0}
aalejandro at mop-ex4200>

I am running JunOS 10.0S1.1.

Regards,
Abel.


From jof at thejof.com  Wed Mar 31 22:32:15 2010
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 31 Mar 2010 19:32:15 -0700
Subject: [j-nsp] EX4200 sFlow on cluster
In-Reply-To: <79BBBA445314D14C927525E537E6036307B4A9@wnetexchg01.worldnetpr.com>
References: <79BBBA445314D14C927525E537E6036307B4A9@wnetexchg01.worldnetpr.com>
Message-ID: <1270089028-sup-2116@sfo.thejof.com>

Excerpts from Abel Alejandro's message of Wed Mar 31 18:59:08 -0700 2010:
> Hello,
> 
> I am running 4 x EX4200 in a virtual chassis configuration. I configured
> sFlow but I can not get it to work.
> Basically the configuration is accepted and no errors are given but no
> flows are sent to the collector.
> 
> I tried placing the collecting within the same subnet as the vme 0
> management interface and also moving it to a physical port.
> 
> According the EX4200 the flows are being sent but I am running a tcpdump
> on the collector and nothing is coming from the EX4200.

Could a ACL be blocking the exports?

--j

From aalejandro at worldnetpr.com  Wed Mar 31 23:04:15 2010
From: aalejandro at worldnetpr.com (Abel Alejandro)
Date: Wed, 31 Mar 2010 23:04:15 -0400
Subject: [j-nsp] EX4200 sFlow on cluster
In-Reply-To: <1270089028-sup-2116@sfo.thejof.com>
References: <79BBBA445314D14C927525E537E6036307B4A9@wnetexchg01.worldnetpr.com>
	<1270089028-sup-2116@sfo.thejof.com>
Message-ID: <79BBBA445314D14C927525E537E6036307B4AA@wnetexchg01.worldnetpr.com>

On Wed, Mar 31, 2010 at 23:32:15, Jonathan Lassoff wrote:
> Subject: Re: [j-nsp] EX4200 sFlow on cluster
> 
> Excerpts from Abel Alejandro's message of Wed Mar 31 18:59:08 -0700
> 2010:
> > Hello,
> >
> > I am running 4 x EX4200 in a virtual chassis configuration. I 
> > configured sFlow but I can not get it to work.
> > Basically the configuration is accepted and no errors are given but
> no
> > flows are sent to the collector.
> >
> > I tried placing the collecting within the same subnet as the vme 0 
> > management interface and also moving it to a physical port.
> >
> > According the EX4200 the flows are being sent but I am running a 
> > tcpdump on the collector and nothing is coming from the EX4200.
> 
> Could a ACL be blocking the exports?
> 

The firewall section of the firewall is empty and iptables is turned off
in the collector.





From Keegan.Holley at sungard.com  Mon Mar  8 16:54:17 2010
From: Keegan.Holley at sungard.com (Keegan.Holley at sungard.com)
Date: Mon, 08 Mar 2010 21:54:17 -0000
Subject: [j-nsp] Class E IP addresses
In-Reply-To: <20100308210826.GK12615@angus.ind.WPI.EDU>
References: <20100308210826.GK12615@angus.ind.WPI.EDU>
Message-ID: <OF1D473963.29B73118-ON852576E0.00783D1F-852576E0.00783D1F@sungard.com>

An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100308/5b589c34/attachment-0001.html>

From juniper at iber-x.com  Thu Mar 25 12:00:55 2010
From: juniper at iber-x.com (iber-x)
Date: Thu, 25 Mar 2010 16:00:55 -0000
Subject: [j-nsp] Lost adjacency in IS-IS
Message-ID: <4BAB7FD2.10907@iber-x.com>

An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100325/00cfddc4/attachment-0001.html>