Re: [j-nsp] QinQ

2014-03-06 Thread Atif Saleem
I think Dave Bell is right as on switch it is as follows:

"set vlans v305 dot1q-tunneling *customer-vlans 105"*

 So the inner vlan must be 104 and outer vlan must be 305 but on MX it is
as below.

"
set bridge-domains VLAN-305 vlan-tags outer 105

set bridge-domains VLAN-305 vlan-tags inner 305
"

Instead it should be as below because on MX the inner-vlan is 305, not 105.

"
set bridge-domains VLAN-305 vlan-tags *outer 305*

set bridge-domains VLAN-305 vlan-tags *inner 105*
*"*

Best,
Atif


On Thu, Mar 6, 2014 at 3:54 PM, Rodrigo Augusto wrote:

> You have to change mtu parameters to enable q-inq ?
>
> Rodrigo Augusto
> Gestor de T.I. Grupo Connectoway
> http://www.connectoway.com.br 
> http://www.1telecom.com.br 
> * rodr...@connectoway.com.br
> ( (81) 3366-7376
> ( (81) 8184-3646
> ( INOC-DBA 52965*100
>
>
>
>
> On 06/03/14 06:23, "Mohammad Khalil"  wrote:
>
> >Hi guys , can anyone assist with the above configuration ?
> >I have tried the same with EX4200 and MX480 and did not work as well
> >
> >BR,
> >Mohammad
> >
> >
> >On Wed, Jun 26, 2013 at 11:20 AM, Mohammad Khalil
> >wrote:
> >
> >> Hi and sorry for the late reply
> >> Please find the configuration I did
> >>
> >> ex3200:
> >>
> >> --
> >>
> >>
> >>
> >> set interfaces ge-0/0/23.0 family ethernet-switching vlan members v305
> >>
> >> set vlans v305 vlan-id 305
> >>
> >> set vlans v305 interface ge-0/0/23.0
> >>
> >> set vlans v305 dot1q-tunneling customer-vlans 105
> >>
> >>
> >>
> >> MX480:
> >>
> >> ---
> >>
> >> set interfaces ge-5/0/8 unit 0 family bridge vlan-id-list 305
> >>
> >> set bridge-domains VLAN-305 domain-type bridge
> >>
> >> set bridge-domains VLAN-305 vlan-tags outer 105
> >>
> >> set bridge-domains VLAN-305 vlan-tags inner 305
> >>
> >> set bridge-domains VLAN-305 routing-interface irb.305
> >> BR,
> >> Mohammad
> >>
> >>
> >> On Tue, Jun 18, 2013 at 4:17 PM, Jared Gull  wrote:
> >>
> >>> Hi Mohammad,
> >>>
> >>> Can you share your current configurations and the topology details?
> >>>Also,
> >>> please explain how you're testing this and what you're seeing or not
> >>>seeing.
> >>>
> >>> -Thanks,
> >>>
> >>> Jared
> >>>
> >>>  --
> >>>  *From:* Mohammad Khalil 
> >>> *To:* "juniper-nsp@puck.nether.net" 
> >>> *Sent:* Tuesday, June 18, 2013 1:49 AM
> >>> *Subject:* [j-nsp] QinQ
> >>>
> >>> Hi all , i am trying to implement QinQ between mx480 and ex4200 , does
> >>> anyone have previous experience with that ?
> >>>
> >>> Thanks
> >>> ___
> >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>>
> >>>
> >>>
> >>
> >___
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



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


Re: [j-nsp] QinQ

2014-03-06 Thread Atif Saleem
Sorry, has some typo in the previous email.

I think Dave Bell is right as on switch it is as follows:

"set vlans v305 dot1q-tunneling *customer-vlans 105"*

 So, the inner vlan must be 105 and outer vlan must be 305, but on MX it is
as below.

"
set bridge-domains VLAN-305 vlan-tags outer 105

set bridge-domains VLAN-305 vlan-tags inner 305
"

Instead it should be as below on MX.

"
set bridge-domains VLAN-305 vlan-tags *outer 305*

set bridge-domains VLAN-305 vlan-tags *inner 105*
*"*

Best,
Atif


On Thu, Mar 6, 2014 at 4:54 PM, Atif Saleem wrote:

> I think Dave Bell is right as on switch it is as follows:
>
> "set vlans v305 dot1q-tunneling *customer-vlans 105"*
>
>  So the inner vlan must be 104 and outer vlan must be 305 but on MX it is
> as below.
>
> "
> set bridge-domains VLAN-305 vlan-tags outer 105
>
> set bridge-domains VLAN-305 vlan-tags inner 305
> "
>
> Instead it should be as below because on MX the inner-vlan is 305, not
> 105.
>
> "
> set bridge-domains VLAN-305 vlan-tags *outer 305*
>
> set bridge-domains VLAN-305 vlan-tags *inner 105*
> *"*
>
> Best,
> Atif
>
>
> On Thu, Mar 6, 2014 at 3:54 PM, Rodrigo Augusto 
> wrote:
>
>> You have to change mtu parameters to enable q-inq ?
>>
>> Rodrigo Augusto
>> Gestor de T.I. Grupo Connectoway
>> http://www.connectoway.com.br <http://www.connectoway.com.br/>
>> http://www.1telecom.com.br <http://www.1telecom.com.br/>
>> * rodr...@connectoway.com.br
>> ( (81) 3366-7376
>> ( (81) 8184-3646
>> ( INOC-DBA 52965*100
>>
>>
>>
>>
>> On 06/03/14 06:23, "Mohammad Khalil"  wrote:
>>
>> >Hi guys , can anyone assist with the above configuration ?
>> >I have tried the same with EX4200 and MX480 and did not work as well
>> >
>> >BR,
>> >Mohammad
>> >
>> >
>> >On Wed, Jun 26, 2013 at 11:20 AM, Mohammad Khalil
>> >wrote:
>> >
>> >> Hi and sorry for the late reply
>> >> Please find the configuration I did
>> >>
>> >> ex3200:
>> >>
>> >> --
>> >>
>> >>
>> >>
>> >> set interfaces ge-0/0/23.0 family ethernet-switching vlan members v305
>> >>
>> >> set vlans v305 vlan-id 305
>> >>
>> >> set vlans v305 interface ge-0/0/23.0
>> >>
>> >> set vlans v305 dot1q-tunneling customer-vlans 105
>> >>
>> >>
>> >>
>> >> MX480:
>> >>
>> >> ---
>> >>
>> >> set interfaces ge-5/0/8 unit 0 family bridge vlan-id-list 305
>> >>
>> >> set bridge-domains VLAN-305 domain-type bridge
>> >>
>> >> set bridge-domains VLAN-305 vlan-tags outer 105
>> >>
>> >> set bridge-domains VLAN-305 vlan-tags inner 305
>> >>
>> >> set bridge-domains VLAN-305 routing-interface irb.305
>> >> BR,
>> >> Mohammad
>> >>
>> >>
>> >> On Tue, Jun 18, 2013 at 4:17 PM, Jared Gull  wrote:
>> >>
>> >>> Hi Mohammad,
>> >>>
>> >>> Can you share your current configurations and the topology details?
>> >>>Also,
>> >>> please explain how you're testing this and what you're seeing or not
>> >>>seeing.
>> >>>
>> >>> -Thanks,
>> >>>
>> >>> Jared
>> >>>
>> >>>  --
>> >>>  *From:* Mohammad Khalil 
>> >>> *To:* "juniper-nsp@puck.nether.net" 
>> >>> *Sent:* Tuesday, June 18, 2013 1:49 AM
>> >>> *Subject:* [j-nsp] QinQ
>> >>>
>> >>> Hi all , i am trying to implement QinQ between mx480 and ex4200 , does
>> >>> anyone have previous experience with that ?
>> >>>
>> >>> Thanks
>> >>> ___
>> >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>>
>> >>>
>> >>>
>> >>
>> >___
>> >juniper-nsp mailing list juniper-nsp@puck.nether.net
>> >https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>>
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> Atif
>



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


Re: [j-nsp] About Juniper IDP 8200 OS update

2012-09-30 Thread Atif Saleem
Hi Jahangir,
 I recently up-graded the IDP OS to *5.1r3* and it did up-grade without any
problem. But I used the OS file with shell script (.sh file) as shown below
instead of .iso file. You can download it from Juniper website (I suppose
you are Juniper partner or customer and have access to download as well as
to KB) as it is easy and recommended.
*
sensor_5_1r3.sh *

You need to make sure that you transfer the above file to "*/tmp*" of the
IDP after doing cheksum and by using either WinScp or FTP in binary mode or
file gets corrupted while copying and gives error while up-grading. You can
google how to transfer/copy files using WinScp/FTP in binary mode.

After up-grade to 5.1r3 it looked like below.

*IDP01 ~]# scio getsystem**
Product Name:  NS-IDP-8200
Serial Number:  xx
Software Version:  5.1.139197
IDP Mode:  transparent
HA Mode:  Enabled
Detector Version:  5.1.110110809
Software License:   Permanent
Software Expiration Date:   never*


Let me give you the steps to up-grade as well, just as a reference.

1. When you transfer the *.sh* file to the IDP via WinScp make sure that in
TRANSFER SETTING you make it BINARY.

We were facing the error of md5 checksum. We resolved it by the following
KB.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB22668&actp=search&viewlocale=en_US&searchid=1346704354266

2. Open the CLI either SSH (the device may lose connection during the
reboot) or Console access (console is much better option).

3. Run the command

*# sh sensor_5_1r3.sh*



This starts the upgrade process after which it would be rebooted and may
take up to 30 minutes. In case you are have opened an SSH connection, you
may initiate a continuous ping to the device so as to when the device comes
up.



4. After the upgrade, open the ACM and then click on ACM--> View/Apply
Current configuration and apply these changes.

To run the ACM do "https" access to the device.



On the ACM, click save and apply configuration.

 Refer to release notes of 5.1R3

 <
http://www.juniper.net/techpubs/en_US/idp5.1/information-products/topic-collections/idp-5-1-r3-release-notes.pdf
>

4. Open up the NSM right-click the device and Adjust OS version
If you are using NSM and managing the IDP from NSM then NSM version needs
to be compatible with *5.1R3*.

Also, if you are using a very old detector engine version then you may need
to update the detector engine. Please refer to KB9773 How to update the
detector version on IDP. The link for the same is as follows:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB9773&actp=search&viewlocale=en_US&searchid=1336101017378

Best of luck!

Atif



On Sun, Sep 30, 2012 at 5:52 PM, Md. Jahangir Hossain 
wrote:
> Dear friend;
>
>
> Wishes all are fine.
>
> I need your suggestion about update of  Juniper IDP 8200 OS.
>
> My current sensor versions is :
>
> [root@localhost ~]# cat /usr/idp/device/doc/VERSION
> 4.2.112811
>
> And want to update sensor_5_1r3.iso
>
> I burn this iso into usb or cdrom and try to install then get a message
> as like “unable to find Kicstart file “
>
>
> Can anyone inform or suggest me what is reason for this or this and how
> I can resolve this problem?
>
>
>
>
> Thanks
>
> jahangir
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] How to see contatining section ?

2012-09-20 Thread Atif Saleem
Just my 2cents. You can also do the following.

show configuration | match super-user | display inheritance | except ##

or

show configuration | match super-user | display set

or just


show configuration | match "user marge" | display set

show configuration | match "user marge" | display inheritance | except ##

Best

On Thu, Sep 20, 2012 at 5:40 PM, Per Granath  wrote:
> I would typically do:
>
> show | display set | match super-user
>
> Which would give you:
>
> set system login user marge class super-user
>
> Then I would copy/paste part of that line, and do:
>
> show system login user marge
>
>
> Perhaps there's a smarter way, or perhaps someone has written an op-script 
> for it
> BTW, the '| display set' is typed with 3 keys only '|ds', and command 
> completion does the rest...
>
>
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
>> boun...@puck.nether.net] On Behalf Of Bala Subrahmanyam Venkata
>> Sent: Thursday, September 20, 2012 3:21 PM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] How to see contatining section ?
>>
>> Novice Junos CLI query:
>>
>> How can I find a section of config given a line which is 'inside' the 
>> section. For
>> instance given the following
>>
>>
>> user marge {
>> uid 2012;
>> class super-user;
>> authentication {
>> encrypted-password
>> "$1$Q5wrLnUs$zwwewew30U6/O1sWMP0yziY.ysh1"; ## SECRET-DATA
>> }
>> }
>>
>> I'd like to do something like the below but see the whole "user" section.
>> Here "find" finds the line and prints all after it. Is there somethign like 
>> "find
>> and print containing section" ?
>>
>>
>> test# show | find super-user
>> class super-user;
>> authentication {
>> encrypted-password
>> "$1$Q5wrLnUs$zwwewew30U6/O1sWMP0yziY.ysh1"; ## SECRET-DATA
>> }
>> }
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] Config help with an SRX110 & ADSL

2012-08-28 Thread Atif Saleem
It would be nice to share the configuration stanza after the fix or
doing the correction from Josh.

Atif

On Wed, Aug 29, 2012 at 2:06 AM, Josh Farrelly  wrote:
> Thanks Dale/Stefan, that's fixed it. Much appreciated.
>
> Regards,
>
> Josh Farrelly
> Senior Project Engineer
>
> P +64 9 630 4095
> M +64 21 919 885
> E j...@base-2.co.nz
>
> PO Box 24666, Royal Oak, Auckland 1345.
> 126 Valley Rd, Mt Eden, Auckland 1024.
>
> www.base-2.co.nz
>
>
>
> -Original Message-
> From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net]
> Sent: Wednesday, 29 August 2012 01:13
> To: Dale Shaw
> Cc: Josh Farrelly; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Config help with an SRX110 & ADSL
>
> Also, your DHCP propagate setting is referencing fe-0/0/0.0 whereas is should 
> be referencing vlan.0, vlan.1 and vlan.2. Per the docs, the propagate option 
> applies to the logical interface which will receive TCP/IP settings from the 
> external network for propagation to the DHCP pool running on the device.  
> Currently, fe-0/0/0.0 isn't a routing interface and it isn't part of any 
> assigned zone.
>
> HTHs.
>
> Stefan Fouant
> JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI
> Technical Trainer, Juniper Networks
>
> Follow us on Twitter @JuniperEducate
>
> Sent from my iPad
>
> On Aug 28, 2012, at 7:41 AM, Dale Shaw  wrote:
>
>> [Apologies for top post]
>>
>> There are a few problems with the config (once you get basic comms up
>> you'll need to look at your IPsec settings) but I suspect the main
>> problem is that interface at-1/0/0.0 isn't assigned to a security zone 
>> (untrust).
>>
>> Cheers,
>> Dale
>>
>> On Aug 28, 2012 8:10 PM, "Josh Farrelly"  wrote:
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
Atif

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


Re: [j-nsp] what is differnet between bridge and ethernet-switching ?

2012-08-14 Thread Atif Saleem
Well using the one word for both of them as bridging sounds good as it
actually is using "bridging protocol" for learn, forwarding, flooding,
filtering, and aging which is what is being done in case of
"ethernet-switching" too. Whether bridging Interfaces or Vlans :).

Atif Saleem

On Wed, Aug 15, 2012 at 10:38 AM, Xu Hu  wrote:
> Sound like a good news, let's wait for juniper rocking.
>
> 2012/8/15 Mike Devlin 
>
>> Juniper is moving to a single standard in future release to remove this
>> confusion (from what i have been told)
>>
>> It will be bridge across all platforms.
>>
>>
>>
>>
>> On Mon, Aug 13, 2012 at 11:44 AM, Xu Hu  wrote:
>>
>>> Bridge is using in router, Ethernet-switching is called in switched.
>>>
>>> Thanks and regards,
>>> Xu Hu
>>>
>>> On 13 Aug, 2012, at 21:00, "Stefan Fouant" 
>>> wrote:
>>>
>>> > There is no difference between the two.
>>> >
>>> > Sent from my HTC on the Now Network from Sprint!
>>> >
>>> > - Reply message -
>>> > From: "bruno.juniper" 
>>> > Date: Mon, Aug 13, 2012 4:01 am
>>> > Subject: [j-nsp] what is differnet between bridge and
>>> ethernet-switching ?
>>> > To: "juniper-nsp" 
>>> >
>>> > what is differnet between bridge and ethernet-switching ? i am
>>> always confused .  as i know ,when i configure mx ,we use bridge . when i
>>> configure ex ,we use ethernet-switching.
>>> >
>>> >
>>> > root@test# set interfaces fe-0/0/0 unit 0 family ?
>>> > Possible completions:
>>> > + apply-groups Groups from which to inherit configuration data
>>> > + apply-groups-except  Don't inherit configuration data from these
>>> groups
>>> >> bridge   Layer-2 bridging parameters
>>> >> ccc  Circuit cross-connect parameters
>>> >> ethernet-switching   Ethernet switching parameters
>>> >> inet IPv4 parameters
>>> >> inet6IPv6 protocol parameters
>>> >> iso  OSI ISO protocol parameters
>>> >> mlfr-end-to-end  Multilink Frame Relay end-to-end protocol
>>> parameters
>>> >> mlfr-uni-nni Multilink Frame Relay UNI NNI protoc
>>> >
>>> > --
>>> > Best Regards,
>>> > Bruno
>>> > ___
>>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> > ___
>>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] Any interest in my script that auto generate nagios configs for juniper devices polled via SNMP?

2012-07-21 Thread Atif Saleem
Hi Morgan,
 Very much interested. Having all this on a blog would be rather much
more interested and useful. I would like to get the hold of the Script
as well as the MoP to get all the SNMP traps on Nagios/Cacti.

Best,
Atif Saleem

On Fri, Jul 20, 2012 at 11:53 PM, Dana Konkin  wrote:
> Hi Morgan,
> It's possible that many will be interested. Go for it! Put it on a blog and
> see what happens.
> Good luck,
> Dana
> On Jul 20, 2012 7:39 PM, "Morgan McLean"  wrote:
>
>> I have a script that I've developed which when given a list of hosts will
>> poll via snmp and gather:
>>
>> Interface details
>> BGP peers
>> OSPF neighbors
>> Hardware information
>>
>> It then has some default behavior and intelligently builds a working nagios
>> configuration for the devices, all by itself. There are some configuration
>> flags, but the default behavior does quite a lot.
>>
>> My implementation auto generates around 17,500 checks for 38 devices before
>> ignoring access interfaces etc, things I don't care as much about. I'm able
>> to generate all of this via my script in under five minutes. I'm assuming
>> once I configure the interfaces I want to ignore (a lot) that amount of
>> checks would come down significantly.
>>
>> Some network admins don't know unix or nagios very well. If there is enough
>> interest I will put up a page with details on how to setup a quick nagios
>> installation, and include details about how to use the script (its very
>> easy). I'll probably start maintaining publicly it if there is enough
>> interest.
>>
>> I run an all juniper network at work, so this script is really only
>> designed for juniper shops. These files can also augment existing nagios
>> configurations, a stand alone installation isn't needed.
>>
>> Let me know, either publicly or directly please. I've included a few screen
>> shots.
>>
>> http://i.imgur.com/kfh2z.png
>>
>> http://i.imgur.com/IkVLo.png
>>
>> http://i.imgur.com/xrSUh.png
>>
>> Thanks!
>> Morgan
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] MX80 poor monitoring, packet loss to RE, SNMP not responding

2012-07-19 Thread Atif Saleem
Hi David,
Do you have any firewall filter to protect RE or doing any policing of
the traffic destined to RE? If, you have the filter, is it applied to
loopback interface lo0.0? You need to check whether it is configured
properly or applied properly or not.

Best,
Atif Saleem

On Fri, Jul 20, 2012 at 3:54 AM, David Miller  wrote:
> On 7/19/2012 5:56 PM, Morgan McLean wrote:
>> So I actually don't use the FXP interface. I basically have four OSPF
>> connections coming into my edge firewall srx cluster, and I use the
>> loopback address advertised over OSPF to manage all of my devices. The
>> MX80's are the only ones that seem to have a problem...am I S.O.L if I'm
>> not using the FXP interface?
>>
>> Morgan
>
> Not at all.  Management and monitoring over the loopback (in-band) is a
> perfectly valid and workable configuration.
>
> Knowing nothing at all about the config on your gear, I would think that
> the first places to look for the source of intermittent failures would
> be route stability and RE firewalls/policers.
>
> You said that you get intermittent ping failures to the box.  Can you
> ssh into the box reliably?  Can you ping from the box reliably to the
> destination that has issues pinging to the box? ...and so on...
>
> -DMM
>
>>
>> On Wed, Jul 18, 2012 at 9:14 AM, Xu Hu  wrote:
>>
>>> Does the Juniper RE not the same as Cisco RSP. I think the control plane
>>> information all need to go to the RE, if RE had any issue, why the traffic
>>> don't have any issue?
>>>
>>> Thanks and regards,
>>> Xu Hu
>>>
>>> On 18 Jul, 2012, at 22:32, "OBrien, Will"  wrote:
>>>
>>>> Check your fxp0 configuration. You may be shipping return traffic out
>>> random interfaces...
>>>> We are leaning toward putting all production traffic inside a virtual
>>> routing instance/chassis and using the main routing instance just for
>>> management.
>>>> 
>>>> From: juniper-nsp-boun...@puck.nether.net [
>>> juniper-nsp-boun...@puck.nether.net] on behalf of Morgan McLean [
>>> wrx...@gmail.com]
>>>> Sent: Wednesday, July 18, 2012 1:34 AM
>>>> To: juniper-nsp@puck.nether.net
>>>> Subject: [j-nsp] MX80 poor monitoring, packet loss to RE, SNMP not
>>> responding
>>>> I have a pair of MX80's that both are very unreliable in terms of trying
>>> to
>>>> monitor them. Any traffic destined to the RE, be it ICMP or SNMP seems to
>>>> be very hit or miss. Sometimes SNMP won't respond, pinging it gives me
>>>> maybe 50% loss on average, but it passes traffic fine.
>>>>
>>>> This causes issues with monitoring, false alerts, etc. I realize the
>>>> traffic destined for the RE is not as important, but the box is hardly
>>>> loaded and among maybe 50 other juniper devices I have, EX, SRX, only
>>> these
>>>> are giving me issues.
>>>>
>>>> Can anybody give me any insight?
>>>>
>>>> Thanks,
>>>> Morgan
>>>> ___
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>> ___
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] juniper-nsp Digest, Vol 115, Issue 22

2012-06-19 Thread Atif Saleem
show route advertising-protocol bgp y.y.y.y (to see the routes being
advertised on local router by BGP)
show route receiving-protocol bgp x.x.x.x (to see the received routes
on remote peer by BGP)

x.x.x.x & y.y.y.y = IP address of the neighbor

Cheers

On Tue, Jun 19, 2012 at 7:11 PM, Per Granath  wrote:
>> So I can't remember the command to show the BGP output being sent to a
>> peer. Such as routes and details I am drawing a blank today.
>> Thank you for the little things in advance.
>>
>
> show route advertising-protocol bgp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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


Re: [j-nsp] Problem to ping a node on internet

2012-06-12 Thread Atif Saleem
Just wondering, you don't have any "host-outbound-traffic" on any of
the zones (maybe needed on OUTSIDE). Experts can confirm what exactly
is needed.

Best,
Atif Saleem

On Mon, Jun 11, 2012 at 10:55 PM, roland DROUAL
 wrote:
> Hello the List,
>
> I have a problem to ping a node on internet.
> From INSIDE network, I can ping a node on DMZ network.
> From DMZ     network, I can ping a node on INSIDE network
> From the SRX650 ,      I can ping a node on INSIDE network, and a node on
> DMZ network.
> From the SRX650 ,      I can ping a node on internet, via OUTSIDE interface.
> For example, I can ping 23.45.160.170
> (PS: 23.45.160.170 = www.cisco.com     :-)    I'm a little nostalgic )
>
> But 
> From a node on INSIDE network, or a node from DMZ network, I can't ping a
> node on internet; I can ping the OUTSIDE interface on SRX650
> (195.221.125.206), but I can't ping the next-hop (195.221.125.205) for the
> default route.
>
> Can you help me ?
> Thanks for your help
>
> Roland DROUAL
>
> This is my config:
> ===
> toto@AS-SRX650-01# run show configuration
>
> ...
>
>    reth0 {
>        description "TRUNK vers INTER-SITES et OUTSIDE";
>        vlan-tagging;
>        redundant-ether-options {
>            redundancy-group 1;
>        }
>        unit 201 {
>            vlan-id 201;
>            family inet {
>                address 10.1.3.1/29;
>            }
>        }
>        unit 955 {
>            vlan-id 955;
>            family inet {
>                address 195.221.125.206/30;
>            }
>        }
>    }
>    reth1 {
>        description "vers INSIDE";
>        vlan-tagging;
>        redundant-ether-options {
>            redundancy-group 1;
>        }
>        unit 100 {
>            vlan-id 100;
>            family inet {
>                address 10.1.4.2/29;
>            }
>        }
>    }
>    reth2 {
>        description "802.1Q vers DMZ1";
>        vlan-tagging;
>        redundant-ether-options {
>            redundancy-group 1;
>        }
>        unit 10 {
>            vlan-id 10;
>            family inet {
>                address 193.48.41.193/29;
>            }
>        }
>    }
> }
> routing-options {
>    static {
>        route 10.96.0.0/11 next-hop 10.1.4.1;
>        route 10.192.0.0/11 next-hop 10.1.3.2;
>        route 0.0.0.0/0 next-hop 195.221.125.205;
>    }
> }
> security {
>    nat {
>        source {
>            address-persistent;
>        }
>    }
>    policies {
>        from-zone OUTSIDE to-zone DMZ {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>                    permit;
>                }
>            }
>        }
>        from-zone DMZ to-zone OUTSIDE {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>                    permit;
>                }
>            }
>        }
>        from-zone INSIDE to-zone DMZ {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>                    permit;
>                }
>            }
>        }
>        from-zone DMZ to-zone INSIDE {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>                    permit;
>                }
>            }
>        }
>        from-zone INSIDE to-zone OUTSIDE {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>                    permit;
>                }
>            }
>        }
>        from-zone OUTSIDE to-zone INSIDE {
>            policy allow-test {
>                match {
>                    source-address any;
>                    destination-address any;
>                    application any;
>                }
>                then {
>