[j-nsp] Juniper MX supports other variants of j-Flow except IPFIX
Hi Juniper NSP, Would like to know whether Juniper MX series router support other variants of jflow except IP FIX. Flow collector that i m evaluating does not support IPFIX v10 (inline-jflow) which MX supports. So just wanted to check what other variants of jflow that can be supported. thanks Arun ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex vstp and cisco pvst
Hi, There could be an guide for this: http://www.google.sk/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CCoQFjAA; url=http%3A%2F%2Fwww.juniper.net%2Fus%2Fen%2Flocal%2Fpdf%2Fimplementation-gu ides%2F8010002-en.pdfei=ajyFT4aeNcfk4QTu8PXFBwusg=AFQjCNFYjlui3rxm97ebrago mLGvG8UNWgsig2=NS2-vPa6wlGM5ze6sncdBA --- Ing. Jozef Klačko Network Administrator JNCIA-JUNOS, JNCIS-ENT, JNCIS-SEC, JNCIS-SSL KOREX networks, s.r.o. Dolné Rudiny 1/A, 010 01 Žilina Slovak republic cell: +421 917 575 004, tel: +421 41 234, fax: +421 41 218 e-mail: jozef.kla...@korex.sk, web: http://www.korex.sk/ Internet Zilina a okolie : hotl...@korex.sk Financne oddelenie : ser...@korex.sk -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Misha Gzirishvili Sent: Wednesday, April 11, 2012 1:18 AM To: Mohammad Cc: man...@gmail.com; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] ex vstp and cisco pvst Hi there, If I remember correctly, vlan1 do not works well between C and J. due to mac address mismatches in BPDU. Use edge ports on acess ports to prevent unwanted calculations, Use spanning tree pathcost method long on cisco to adjust costs. And use rapid pvst on Cisco. HTH. Regards, Misha On Apr 10, 2012 9:51 PM, Mohammad masal...@gmail.com wrote: Hi All We have a layer 2 ring consists of 7 cisco 3750 ME switches terminated on two juniper EX4200 switches (EX-Primary) and (EX-Backup); the backhaul from EX-Primary to our HQ is fiber, while we are using a backup microwave link from EX-Backup to HQ. we have configured vstp on both EX switches and we have increased the link costs on the backup EX in order to block the port on the backup EX so that the traffic goes to primary EX and then through the fiber link to HQ. we have checked the that ports are blocked from the backup EX,,and everything is working as it should be. The problem is once we configure vstp on the EX switches we see the cpu utilization reached 100% for a short period of time and then every things goes fine, another thing we've noticed suddenly when there is a topology change in the network the EX malfunction for a short period of time and then gets back to normal operation We are using pvst on the cisco switches.switch port trunk allowed vlan 11,12,13 , etc. is configured on the cisco trunk port Vlan 1 is not configured on the juniper switches.vstp vlan all is configured on the juniper switch The question is: Shall we configure vlan1 on the juniper switches and put it as a native vlan on the trunk port facing the cisco switches and also on the trunk port connecting the two juniper switches? Shall we configure rapid pvst on the cisco switches instead of normal pvst? Any better ideas? Thank you in advance. Mohammad Salbad ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX
Netflow v5 exports off the RE are supported, just make sure you don't over tax the RE with the sampling rate. Sent from my iPhone On Apr 11, 2012, at 3:32, Arun Kumar narain.a...@gmail.com wrote: Hi Juniper NSP, Would like to know whether Juniper MX series router support other variants of jflow except IP FIX. Flow collector that i m evaluating does not support IPFIX v10 (inline-jflow) which MX supports. So just wanted to check what other variants of jflow that can be supported. thanks Arun ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Layer 2 feature on srx
10.04.2012 20:13, Michael Still wrote: OP wanted to use the IRB ints as next hop for their respective networks. This is apparently not supported on the SRX platform in transparent mode: Yeah, I mentioned this as well. In my post I just wanted to explain why these (MX-style L2) commands were successfully committed by SRX (which is really not obvious and I even think, someone who decided to reuse this part config for this purpose on SRX needed to think twice or at least document it more clearly. This is not the first time I see such a confusion). In this release, the IRB interface on the SRX Series device does not support traffic forwarding or routing. In transparent mode, packets arriving on a Layer 2 interface that are destined for the device’s MAC address are classified as Layer 3 traffic while packets that are not destined for the device’s MAC address are classified as Layer 2 traffic. Packets destined for the device’s MAC address are sent to the IRB interface. Packets from the device’s routing engine are sent out the IRB interface. So in transparent / IRB mode the IRB int can only be used as a management interface. OP needs to do is MX testing using an MX device. IICR, by now they can't even terminate IPSec on IRB. An interesting question here is whether they are going to make IRBs to be real L3 ifaces. What a mess it would be :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX
v5 certainly. Keep in mind that sampling depends on your hardware configuration (MS-DPC, etc) On Apr 11, 2012, at 2:32 AM, Arun Kumar wrote: Hi Juniper NSP, Would like to know whether Juniper MX series router support other variants of jflow except IP FIX. Flow collector that i m evaluating does not support IPFIX v10 (inline-jflow) which MX supports. So just wanted to check what other variants of jflow that can be supported. thanks Arun ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Woot. Updated MX software recommendation
I got on TAC about the fact that they were recommending 10.4 code for the MX when it doesn't support the Enhanced SCB at all. I don't know if it was my case or just enough people giving them a hard time, but they notified me that they've updated KB21476. There is now an entry for the MX series and the MX series with the Enhanced SCB. (11.2R5.4 at this time.) Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Woot. Updated MX software recommendation
On Wed, Apr 11, 2012 at 02:05:52PM +, OBrien, Will wrote: I got on TAC about the fact that they were recommending 10.4 code for the MX when it doesn't support the Enhanced SCB at all. I don't know if it was my case or just enough people giving them a hard time, but they notified me that they've updated KB21476. There is now an entry for the MX series and the MX series with the Enhanced SCB. (11.2R5.4 at this time.) 11.4R2.14 this article says to me :) PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse than in 11.4R1. Looks like the same PR/731833, http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Woot. Updated MX software recommendation
On 04/11/2012 12:09 PM, Alexandre Snarskii wrote: PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse than in 11.4R1. Looks like the same PR/731833, http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html counting is hard... let's go shopping?? wtf? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX
v5: either RE-based or Service PIC|MSDPC-based v8: either RE-based or Service PIC|MSDPC-based v9: only Service PIC|MSDPC-based. I repeat: v9 is _only_ Service PIC|MSDPC-based. No chance of v9 flow sampling/exporting on Routing Engine. HTH Rgds Alex - Original Message - From: Arun Kumar narain.a...@gmail.com To: juniper-nsp@puck.nether.net Sent: Wednesday, April 11, 2012 8:32 AM Subject: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX Hi Juniper NSP, Would like to know whether Juniper MX series router support other variants of jflow except IP FIX. Flow collector that i m evaluating does not support IPFIX v10 (inline-jflow) which MX supports. So just wanted to check what other variants of jflow that can be supported. thanks Arun ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RE : Woot. Updated MX software recommendation
Hi all, I do not encounter SNMP issue anymore since the upgrade in 11.4R2.14. Same test like in 11.4R1 Strange ? Best regards David De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] de la part de Alexandre Snarskii [s...@snar.spb.ru] Date d'envoi : mercredi 11 avril 2012 18:09 À : OBrien, Will Cc : juniper-nsp Objet : Re: [j-nsp] Woot. Updated MX software recommendation On Wed, Apr 11, 2012 at 02:05:52PM +, OBrien, Will wrote: I got on TAC about the fact that they were recommending 10.4 code for the MX when it doesn't support the Enhanced SCB at all. I don't know if it was my case or just enough people giving them a hard time, but they notified me that they've updated KB21476. There is now an entry for the MX series and the MX series with the Enhanced SCB. (11.2R5.4 at this time.) 11.4R2.14 this article says to me :) PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse than in 11.4R1. Looks like the same PR/731833, http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Woot. Updated MX software recommendation
On Wed, Apr 11, 2012 at 01:19:01PM -0400, Chris Morrow wrote: counting is hard... let's go shopping?? wtf? Yeah, it's not like we need to bill customers with these routers or anything. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Woot. Updated MX software recommendation
That's what net flow is for! Wait... doh! Richard A Steenbergen r...@e-gerbil.net wrote: On Wed, Apr 11, 2012 at 01:19:01PM -0400, Chris Morrow wrote: counting is hard... let's go shopping?? wtf? Yeah, it's not like we need to bill customers with these routers or anything. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Packet mode mpls (was Layer 2 feature on srx)
Here is some explanation.
Branch SrX Series Services Gateways process packets using flow-based
forwarding by default. For the next several releases, the flow module will
support only IP traffic. When MPLS is configured, there is no way of
knowing if an IP packet entering the services gateway will require MPLS
encapsulation until the packet is processed, so enabling MPLS can be used
to force an SrX Series or J Series device to forward all IPv4 traffic in
packet mode.
security {
}
forwarding-options {
family {
mpls {
mode packet-based;
}
} }
On Tue, Apr 10, 2012 at 5:37 PM, Pavel Lunin plu...@senetsy.ru wrote:
Phil Mayers wrote:
On 04/10/2012 06:17 AM, Doug Hanks wrote:
In the context of packet-mode, the family mpls is analogous to inet.
This
is correct.
Not sure I understand this.
analogous implies what, here? That enabling packet-mode for MPLS
implicitly enables it for IPv4?
Yep. Same for ISO.
If that's the case, why is there also a family inet option?
Looks like first they meant to have different options for different
families allowing to simultaneously have some in flow and some in packet
mode. But it's already about… 4 years passed, I think, and it's still this
way. Any family turned into packet mode turns the whole box. Sort of the
same stuff as 'say per-packet mean per-flow' LB.
There might be a difference for inet6 (I am not sure) since some version,
in which the stateful processing for IPv6 was added. I just remember I
needed to explicitly set the packet mode for it playing around something
implied IPv6, otherwise it didn't work (or rather worked in flow-mode but I
had no zones/policies). Must repeat, I'm not sure.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Packet mode mpls (was Layer 2 feature on srx)
Hello ,
I would like to change the mail address to amolmde...@rediffmail.com , Please
confirm how I can change it
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ashish verma
Sent: Thursday, April 12, 2012 7:27 AM
To: Pavel Lunin
Cc: juniper-nsp
Subject: Re: [j-nsp] Packet mode mpls (was Layer 2 feature on srx)
Here is some explanation.
Branch SrX Series Services Gateways process packets using flow-based forwarding
by default. For the next several releases, the flow module will support only IP
traffic. When MPLS is configured, there is no way of knowing if an IP packet
entering the services gateway will require MPLS encapsulation until the packet
is processed, so enabling MPLS can be used to force an SrX Series or J Series
device to forward all IPv4 traffic in packet mode.
security {
}
forwarding-options {
family {
mpls {
mode packet-based;
}
} }
On Tue, Apr 10, 2012 at 5:37 PM, Pavel Lunin plu...@senetsy.ru wrote:
Phil Mayers wrote:
On 04/10/2012 06:17 AM, Doug Hanks wrote:
In the context of packet-mode, the family mpls is analogous to inet.
This
is correct.
Not sure I understand this.
analogous implies what, here? That enabling packet-mode for MPLS
implicitly enables it for IPv4?
Yep. Same for ISO.
If that's the case, why is there also a family inet option?
Looks like first they meant to have different options for different
families allowing to simultaneously have some in flow and some in
packet mode. But it's already about... 4 years passed, I think, and it's
still this way. Any family turned into packet mode turns the whole
box. Sort of the same stuff as 'say per-packet mean per-flow' LB.
There might be a difference for inet6 (I am not sure) since some
version, in which the stateful processing for IPv6 was added. I just
remember I needed to explicitly set the packet mode for it playing
around something implied IPv6, otherwise it didn't work (or rather
worked in flow-mode but I had no zones/policies). Must repeat, I'm not sure.
___
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
