Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:31, Mark Tinka a écrit : On 11/May/15 11:11, Raphael Mazelier wrote: We have seen this on our EX4550 switches. The uplink toward the upstream routers is an 802.1Q LAG, where the aeX interface graphs actual traffic, but the aeX.Y interface just graphs control traffic. Yes this is the case with subif, vlan (irb like) if, etc... It never occurred to me that this was an issue since we do not use the EX switches for routing. But I can see how this could be a problem for you if you are offering services directly off the EX switch. That was the plan yes. If I had correclty evaluate/made more test, I have done this differently, and just use EX for what they are made (switching). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
* Raphael Mazelier r...@futomaki.net Have you notive/hit some performance problems with this config ? No. Tore ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:27, Tore Anderson a écrit : It's quite annoying indeed. I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. The way I do it is to create input and output firewall filters for each configured family on the interface with a single term, which just does count and accept. Then I poll those firewall counters. Tore Yes I've read that it could be a solution. Have you notive/hit some performance problems with this config ? Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
On 11/May/15 11:38, Raphael Mazelier wrote: That was the plan yes. If I had correclty evaluate/made more test, I have done this differently, and just use EX for what they are made (switching). I know this does not help you now, but in general, switches are very bad at being routers. The closest they came was the Cisco 6500 (I say closest because unless you had the high end ES+ line cards from Cisco, you came up against several limitations with the regular so-called LAN cards on that platform). The SUP-2T and its host of line cards promised good things, but I've never tested those. We worked very closely with Cisco when they were building the ME3600X/3800X switches back in 2009. The platform is called a switch, but really, it is a router, and does routing as well as a Cisco router does. This is not a regular thing, and I dare see is an advantage Cisco have enjoyed. Brocade's NetIron switches are decent routers the last time I tested. Juniper have never really had a proper router that comes in a switch form-factor. We are evaluating the ACX5000 platform for this, and it looks very promising; but its use of off-the-shelf silicon is getting in the way. The EX (certainly the 1U switches) are terrible routers; I can't speak to the capability of the big EX chassis', never tested them. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Counter on subinterface on EX
I've just realized there is another pretting annoying problem with EX series. It seems that is was not possible to count passing in subinterface (or vlan interface) on EX. Quoting the documentation : Note: For logical interfaces on EX Series switches, the traffic statistics fields in show interfaces commands show only control traffic; the traffic statistics do not include data traffic. This make me in real trouble for billing, as I mixed customers vlan(s) on physical ports in my architecture... I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
On 11/May/15 11:11, Raphael Mazelier wrote: I've just realized there is another pretting annoying problem with EX series. It seems that is was not possible to count passing in subinterface (or vlan interface) on EX. Quoting the documentation : Note: For logical interfaces on EX Series switches, the traffic statistics fields in show interfaces commands show only control traffic; the traffic statistics do not include data traffic. This make me in real trouble for billing, as I mixed customers vlan(s) on physical ports in my architecture... I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. We have seen this on our EX4550 switches. The uplink toward the upstream routers is an 802.1Q LAG, where the aeX interface graphs actual traffic, but the aeX.Y interface just graphs control traffic. It never occurred to me that this was an issue since we do not use the EX switches for routing. But I can see how this could be a problem for you if you are offering services directly off the EX switch. FWIW, SVI interfaces on Cisco switches work the same way. One would have to track traffic hitting the interface that the SVI is attached to, and not the SVI itself. On platforms such as the ME3600X/3800X and ASR920, Cisco use EVC (which can be considered sub-interfaces called EFP's), but these come with special SNMP counting capability that treats them as physical interfaces which will count actual customer traffic. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
On 11/May/15 12:07, Raphael Mazelier wrote: Speaking about EX4550 I think they are OK for basic routing. In my use case (l3vpn, and customers demarcation) results are mixed. They worked, they are stable but : Remaining problems are : - l2vpn mess (I ve found a working config, but what a pain) - no-auto export, local leaking not working - and no statistics for subif That say, despite theirs limitations, I think they have a really good value for money. I just not correctly identify them when I bought them... We think they are awesome value for money - ports that support both 1Gbps and 10Gbps is definite value for money. But we use them purely for Layer 2 aggregation. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:49, Mark Tinka a écrit : Juniper have never really had a proper router that comes in a switch form-factor. We are evaluating the ACX5000 platform for this, and it looks very promising; but its use of off-the-shelf silicon is getting in the way. The EX (certainly the 1U switches) are terrible routers; I can't speak to the capability of the big EX chassis', never tested them. Speaking about EX4550 I think they are OK for basic routing. In my use case (l3vpn, and customers demarcation) results are mixed. They worked, they are stable but : Remaining problems are : - l2vpn mess (I ve found a working config, but what a pain) - no-auto export, local leaking not working - and no statistics for subif That say, despite theirs limitations, I think they have a really good value for money. I just not correctly identify them when I bought them... (if only I had a better budget and more time :) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
* Raphael Mazelier r...@futomaki.net I've just realized there is another pretting annoying problem with EX series. It seems that is was not possible to count passing in subinterface (or vlan interface) on EX. It's quite annoying indeed. I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. The way I do it is to create input and output firewall filters for each configured family on the interface with a single term, which just does count and accept. Then I poll those firewall counters. Tore ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
On 11/May/15 13:27, Olivier Benghozi wrote: http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html Statement introduced in Junos OS Release 13.3 R4 We decided not to enable this now because I understand the plan is for 64-bit mode to become the default in later versions of Junos. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html Statement introduced in Junos OS Release 13.3 R4 Le 11 mai 2015 à 04:55, Colton Conor colton.co...@gmail.com a écrit : What version of 13.3 is this available in Adam? On Sun, May 10, 2015 at 6:25 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote: I know what you mean though there's an option so should the 4GB of RAM be not enough for a single BGP instance you can always start up to 3 more independent BGP instances to use all the memory you can. From 13.3 Junos BGP process can cross the 4GB boundary so there's no restriction on BGP scaling. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] CFM (Juniper - Alcatel)
Hi experts,
Kindly i want to know if there is someone who implement CFM between Juniper
Mx480 and Alcatel router.
The issue is that from Alcatel router, there is no neighbors detection.
From Juniper router, i can see the neighor but with this error:
Erroneous CCM received: yes
the configuration on juniper router is:
ethernet {
connectivity-fault-management {
maintenance-domain orange {
level 5;
maintenance-association HLR {
continuity-check {
interval 1s;
}
mep 13 {
interface et-5/0/0.3308;
direction down;
remote-mep 31;
lowest-priority-defect mac-rem-err-xcon;
}
}
}
}
}
Please help me...
Regards,
Omar.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JTAC Recommended Junos Software Versions Old?
Hi Colton, On Tue, May 12, 2015 at 10:35 AM, Colton Conor colton.co...@gmail.com wrote: So what is going to be the next recommended JTAC version after 12.3R8.7? The recommended release for most MX platforms changed the other day, to 13.3R6. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JTAC Recommended Junos Software Versions Old?
MX80s are still showing 12.3R8.7 as the recommended. Tim Raphael On 12/05/2015 8:40 am, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi Colton, On Tue, May 12, 2015 at 10:35 AM, Colton Conor colton.co...@gmail.com wrote: So what is going to be the next recommended JTAC version after 12.3R8.7? The recommended release for most MX platforms changed the other day, to 13.3R6. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Zetta Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this email by mistake and delete this email from your system. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. ZettaServe Pty Ltd accepts no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L2 tunnel over IP on ex4200-24t
Colleagues, I have several ex4200-24t switches with JunOS 12.3R6.6 and an Advanced licensed routing protocols license. Is there a way to tunnel L2 traffic over an IP network between two ex4200-24t switches? I wish to emulate a L2 trunk (with several VLANs, MSTP and OAM) over a Layer3 network. Now I am doing it with the help of two FreeBSD servers encapsulating Ethernet frames into UDP packets via a complicated netgraph setup. I would be happy to get rid of them and use only ex4200-24t switches if possible. Thank you for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
Hi Victor, The only way I am aware of that works with ex4200s is tunnelling over MPLS. This would require MPLS on the backbone to work. http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/mpls-ex-series-provider-edge-switches-ccc-cli.html Cheers, Mark On Tue, May 12, 2015 at 1:49 PM, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, I have several ex4200-24t switches with JunOS 12.3R6.6 and an Advanced licensed routing protocols license. Is there a way to tunnel L2 traffic over an IP network between two ex4200-24t switches? I wish to emulate a L2 trunk (with several VLANs, MSTP and OAM) over a Layer3 network. Now I am doing it with the help of two FreeBSD servers encapsulating Ethernet frames into UDP packets via a complicated netgraph setup. I would be happy to get rid of them and use only ex4200-24t switches if possible. Thank you for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Regards, Mark L. Tees ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
Mark Tees wrote: The only way I am aware of that works with ex4200s is tunnelling over MPLS. This would require MPLS on the backbone to work. http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/mpls-ex-series-provider-edge-switches-ccc-cli.html The third party IP network I would like to tunnel through has no MPLS support. Maybe I should run some sort of GRE tunnel over this network, and then MPLS over this GRE tunnel, and the L2 tunnel over MPLS? To think of it, even if it's possible with ex4200s, I'd rather keep the FreeBSD servers. This is a clever setup after all (sorry, the explanation is in Russian only, but the script is in sh): http://victor-sudakov.dreamwidth.org/330817.html -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JTAC Recommended Junos Software Versions Old?
So what is going to be the next recommended JTAC version after 12.3R8.7? On Thu, May 7, 2015 at 3:37 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote: 12.3R8.7 is going to be end of support next year and I'd expect Juniper to let people know what will be the recommended replacement some time before that happens so people can have some time to assess the new release and to schedule the upgrades. adam -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Colton Conor Sent: 29 April 2015 17:59 To: juniper-nsp@puck.nether.net Subject: [j-nsp] JTAC Recommended Junos Software Versions Old? Why is the JTAC Recommended Junos Software Version for the MX routers currently Junos 12.3R8.7? There are much newer versions of JUNOS out there. From the posts I have read so far, Junos 12.3 in general has flow and nat issues. I assume some of these bugs have been fixed with the latest .x versions like R8.7, but still why such an old version? Is there a guide showing the big changes from 12.3 vs 13.2 vs 13.3 vs 14.1 vs 14.2. I know there a release notes for all of these versions, but is there an outline showing the reason for the jump in version numbers? Most of the PR's I have seen show a bug was found and fixed in the current .x of most all these versions. I notice that the Juniper JTAC recommends Junos 13.3R4.6 for the MX104 and PTX series? If Junos 13.3R4.6 is stable enough to run on these platforms, then I assume its stable enough to run on the other MX platforms, the MX80 to be specific? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
I'm pretty sure MPLS over GRE is not supported on EX4200's. I would have my doubts that PFE could do it. If you want to do that you would be better off getting two of the branch SRX's (depending on traffic levels) to do this I think as it will give you more flexibility. On Tue, May 12, 2015 at 2:10 PM, Victor Sudakov v...@mpeks.tomsk.su wrote: Mark Tees wrote: The only way I am aware of that works with ex4200s is tunnelling over MPLS. This would require MPLS on the backbone to work. http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/mpls-ex-series-provider-edge-switches-ccc-cli.html The third party IP network I would like to tunnel through has no MPLS support. Maybe I should run some sort of GRE tunnel over this network, and then MPLS over this GRE tunnel, and the L2 tunnel over MPLS? To think of it, even if it's possible with ex4200s, I'd rather keep the FreeBSD servers. This is a clever setup after all (sorry, the explanation is in Russian only, but the script is in sh): http://victor-sudakov.dreamwidth.org/330817.html -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru -- Regards, Mark L. Tees ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Shaper burst size
Hello, We use egress shapers on our Juniper MX. They uses a default burst size that are set automatically based on the size of the shaper. So far, these defaults have served us well. We have notice that some downstream devices that perform rate conversion can't seem to buffer the bursts properly. Ex: - Traffic flow Start - 1G - DeviceA -1G - MX with 80M shaper - 1G - DeviceB - 100M - End The setup above works fine when DeviceB is connected at 1G on both interfaces. Likewise, it works fine when Start-DeviceA is also 100M. With the exact setup above, when DeviceB does 1G to 100M conversion, it can't seem to handle the bursts of data handed out by the MX and drops traffic. Configuring the MX burst size to 0 (actual lowest value possible is 1 Byte) seems to solve the problem: no more drops by DeviceB. Is setting the shaper burst size to 0 a good idea? Are there any consequences to doing this? Thanks,Serge ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Shaper burst size
On (2015-05-11 15:54 +), Serge Vautour wrote: Hey, The setup above works fine when DeviceB is connected at 1G on both interfaces. Likewise, it works fine when Start-DeviceA is also 100M. With the exact setup above, when DeviceB does 1G to 100M conversion, it can't seem to handle the bursts of data handed out by the MX and drops traffic. Configuring the MX burst size to 0 (actual lowest value possible is 1 Byte) seems to solve the problem: no more drops by DeviceB. Is setting the shaper burst size to 0 a good idea? Are there any consequences to doing this? Not only it is a good idea, it is only way to do QoS in other points than congestion points, because you cannot know buffer sizes downstream towards congestion. When you configure burst-size 1, you can observe 128 in PFE, but in QX actual burst-size is about 2.7ms times shaper-rate. As you said it solves your issues, you should be happy, your downstream equipment can handle this burst without dropping. If at all possible, always perform shaping/policing at last possible moment. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
