Re: [j-nsp] Layer 2 port mirroring on MX960
Hi, Does junos have the cisco limitation of 2 SPAN session per plateform ? Br. Kayssar -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ext Terry Jones Sent: Thursday, January 10, 2013 4:02 AM To: Sivasankar Subbiah Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Layer 2 port mirroring on MX960 Thank you much Siva, That does explain the missing bridge option. A lot of the documentation I looked at included the bridge option in the 'forwarding-options port-mirroring' section, but I am using the vpls option with no success. I didn't post the mirror interface information as I had nothing configured under it. After my email, I configured it under 'family bridge interface-type access' and added the same vlan-id as the monitor port and I started seeing traffic. However, I'm not sure that this traffic is being forwarded traffic from the firewall filter, but rather traffic on the vlan as if the interface is in promiscuous mode. Makes me concerned as it doesn't seem that I'm seeing all the packets. Also, from the examples and documentation I've read, it doesn't show configuring the mirror port as such. Terry From: Sivasankar Subbiah sivasankar@gmail.com Date: Wednesday, January 9, 2013 3:18 PM To: Terry Jones terry.jo...@war-eagle.me Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Layer 2 port mirroring on MX960 Hi, as per the Juniper documentation, Note: Under the [edit forwarding-options port-mirroring instance pm-instance-name] hierarchy level, the protocol family statement family bridge is an alias for family vpls. The CLI displays Layer 2 port-mirroring configurations as family vpls, even for Layer 2 port-mirroring configured as family bridge. Cheers Siva On 9 January 2013 22:44, Terry Jones terry.jo...@war-eagle.me wrote: Greetings All, I am trying to get a port mirror working with no success. I want to port-mirror ge-1/0/0 interfaces that is interface-type access. When I configure the forwarding-options, there is no longer a bridge option.only ccc, inet and vpls. Even though not showing, when I configure 'forwarding-options port-mirroring instance wireshark9 family bridge', it takes it, but changes it to 'forwarding-options port-mirroring instance wireshark9 family vpls'. The port-mirror output shows down on the output, but I do see the counters increment. Any thoughts, ideas or tips would be appreciated. tjo...@crsw01.cn.sb2# show forwarding-options port-mirroring instance wireshark9 | display set set forwarding-options port-mirroring instance wireshark9 input rate 1 set forwarding-options port-mirroring instance wireshark9 family vpls output interface xe-5/2/1.0 set forwarding-options port-mirroring instance wireshark9 family vpls output no-filter-check tjo...@crsw01.cn.sb2# show interfaces ge-1/0/0 | display set set interfaces ge-1/0/0 unit 0 family bridge filter input wireshark9 set interfaces ge-1/0/0 unit 0 family bridge filter output wireshark9 set interfaces ge-1/0/0 unit 0 family bridge interface-mode access set interfaces ge-1/0/0 unit 0 family bridge vlan-id 802 tjo...@crsw01.cn.sb2# show firewall family bridge filter wireshark9 | display set set firewall family bridge filter wireshark9 term 1 then count wireshark9 set firewall family bridge filter wireshark9 term 1 then accept set firewall family bridge filter wireshark9 term 1 then port-mirror-instance wireshark9 tjo...@crsw01.cn.sb2# run show forwarding-options port-mirroring wireshark9 Instance Name: wireshark9 Instance Id: 11 Input parameters: Rate : 1 Run-length: 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop vplsdown xe-5/2/1.0 tjo...@crsw01.cn.sb2# run show firewall counter wireshark9 filter wireshark9 Filter: wireshark9 Counters: NameBytes Packets wireshark9 80634 744 Thanks, Terry ___ 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] OSPF import policy
Hi,
I am getting this work but on SRX 3600 10.4R7.5 :
area 0.0.0.1 {
nssa summaries;
network-summary-export To-OSPF-A1;
interface reth0.1767;
}
policy-options policy-statement To-OSPF-A1
term 1 {
from {
protocol ospf;
route-filter X.X.X.X/Y exact;
}
then accept;
}
Br.
BEN HAMMADI Kayssar
NOKIA SIEMENS NETWORKS
Lead Engineer -BroadBand Connectivity
JNCIE (#471), CCIP
Mobile : +216 29 349 952 / +216 98 349 952
FIX : +216 71 108 173
Skype : kayssar ben hammadi
kayssar.ben_hamm...@nsn.com
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ext Luca Salvatore
Sent: Thursday, January 10, 2013 1:48 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] OSPF import policy
Hi All,
I'm trying to filter some inter-area OSPF routes from being installed into the
route table on a few routers.
I seem to remember that in Junos it isn't possible to filter inter-area routes
with an import policy - only externals.
However I do also remember a rumour that this feature would be available at
some point
Is this still the case? I'm thinking it isn't possible, since I can't get it
to work :(
Running Junos 11.5r5
Thanks
Luca
___
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 port mirroring on MX960
Hi , I have no exact idea about the number of instances you can configure in each platform(juniper).but i read it is 2 instances on mx960 on the same ports;only 1 instance at global level. Any experts please confirm the number of port-mirroring instances on juniper devices or atleast on mx960.? Cheers Siva On 10 January 2013 09:59, Ben Hammadi, Kayssar (NSN - TN/Tunis) kayssar.ben_hamm...@nsn.com wrote: Hi, Does junos have the cisco limitation of 2 SPAN session per plateform ? Br. Kayssar -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ext Terry Jones Sent: Thursday, January 10, 2013 4:02 AM To: Sivasankar Subbiah Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Layer 2 port mirroring on MX960 Thank you much Siva, That does explain the missing bridge option. A lot of the documentation I looked at included the bridge option in the 'forwarding-options port-mirroring' section, but I am using the vpls option with no success. I didn't post the mirror interface information as I had nothing configured under it. After my email, I configured it under 'family bridge interface-type access' and added the same vlan-id as the monitor port and I started seeing traffic. However, I'm not sure that this traffic is being forwarded traffic from the firewall filter, but rather traffic on the vlan as if the interface is in promiscuous mode. Makes me concerned as it doesn't seem that I'm seeing all the packets. Also, from the examples and documentation I've read, it doesn't show configuring the mirror port as such. Terry From: Sivasankar Subbiah sivasankar@gmail.com Date: Wednesday, January 9, 2013 3:18 PM To: Terry Jones terry.jo...@war-eagle.me Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Layer 2 port mirroring on MX960 Hi, as per the Juniper documentation, Note: Under the [edit forwarding-options port-mirroring instance pm-instance-name] hierarchy level, the protocol family statement family bridge is an alias for family vpls. The CLI displays Layer 2 port-mirroring configurations as family vpls, even for Layer 2 port-mirroring configured as family bridge. Cheers Siva On 9 January 2013 22:44, Terry Jones terry.jo...@war-eagle.me wrote: Greetings All, I am trying to get a port mirror working with no success. I want to port-mirror ge-1/0/0 interfaces that is interface-type access. When I configure the forwarding-options, there is no longer a bridge option.only ccc, inet and vpls. Even though not showing, when I configure 'forwarding-options port-mirroring instance wireshark9 family bridge', it takes it, but changes it to 'forwarding-options port-mirroring instance wireshark9 family vpls'. The port-mirror output shows down on the output, but I do see the counters increment. Any thoughts, ideas or tips would be appreciated. tjo...@crsw01.cn.sb2# show forwarding-options port-mirroring instance wireshark9 | display set set forwarding-options port-mirroring instance wireshark9 input rate 1 set forwarding-options port-mirroring instance wireshark9 family vpls output interface xe-5/2/1.0 set forwarding-options port-mirroring instance wireshark9 family vpls output no-filter-check tjo...@crsw01.cn.sb2# show interfaces ge-1/0/0 | display set set interfaces ge-1/0/0 unit 0 family bridge filter input wireshark9 set interfaces ge-1/0/0 unit 0 family bridge filter output wireshark9 set interfaces ge-1/0/0 unit 0 family bridge interface-mode access set interfaces ge-1/0/0 unit 0 family bridge vlan-id 802 tjo...@crsw01.cn.sb2# show firewall family bridge filter wireshark9 | display set set firewall family bridge filter wireshark9 term 1 then count wireshark9 set firewall family bridge filter wireshark9 term 1 then accept set firewall family bridge filter wireshark9 term 1 then port-mirror-instance wireshark9 tjo...@crsw01.cn.sb2# run show forwarding-options port-mirroring wireshark9 Instance Name: wireshark9 Instance Id: 11 Input parameters: Rate : 1 Run-length: 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop vplsdown xe-5/2/1.0 tjo...@crsw01.cn.sb2# run show firewall counter wireshark9 filter wireshark9 Filter: wireshark9 Counters: NameBytes Packets wireshark9 80634 744 Thanks, Terry ___ 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
[j-nsp] EX Switch Question
Hi folks.. We have a customer that has a Cisco 6500 - very old and they want to retire it out of service (12+ years old). The customer is a municipal fiber provider and their main business is providing connectivity (vs providing Internet). They have approached us about a Juniper replacement and I've been thinking about EX series but looking for some input please. Their requirements are what would seem fairly basic: 40-50 switch ports supporting up to 1G (all copper today as they use media converters and wish to continue using them) Dot1q support on each port (yup, easy enough) Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) When I have looked at the EX2200,3300,4200 series (which I'm reasonably familiar with) I don't see a way to do this. Our Juniper SE says the issue is ingress bandwidth control and that the rest of the criteria is easily met. As they also would prefer and are also used to having a chassis level box with power redundancy, switch processor redundancy etc then this has me looking at EX6200/8200 series. The EX6200 seems to be pretty much EX4200 modules so not sure if it solves my problem - thinking more towards EX8200 but not familiar enough to know if it will meet this criteria especially ingress *and* egress per VLAN bandwidth controls. Any thoughts are much appreciated ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Just avoid the 4500 if you need anything less than 1G copper. The ports on the 4500 won't negotiate to 10 or 100. I was told by the sales engineer that this switch is a top of rack switch so it doesn't support anything less than 1G. I found that funny since I have a whole rack of Avaya gear that Avaya insists must have the switch set to 100/Full. - Original Message - From: Tobias Heister [mailto:li...@tobias-heister.de] Sent: Thursday, January 10, 2013 08:31 AM To: Paul Stewart p...@paulstewart.org Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ 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] EX Switch Question
Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul -Original Message- From: Per Granath [mailto:per.gran...@gcc.com.cy] Sent: January-10-13 9:18 AM To: Paul Stewart; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] EX Switch Question The general idea is to do: Policing (firewall filter) on ingress Shaping (CoS) on egress http://www.juniper.net/us/en/local/pdf/implementation-guides/8010073-en.pdf Shaping is typically per port, and I am not sure if you can do that per VLAN. But the feature guide say there is CoS support on RVIs... https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/conc ept/ex-series-software-features-overview.html#cos-features-by-platform-table In that case, the EX4200 virtual chassis seems good. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, January 10, 2013 3:04 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX Switch Question Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thanks - yup, we are just deploying some EX4500 at a customer site and ended up keeping their EX4200's just for 100 meg ports ;( -Original Message- From: James S. Smith [mailto:jsm...@windmobile.ca] Sent: January-10-13 9:00 AM To: 'li...@tobias-heister.de'; 'p...@paulstewart.org' Cc: 'juniper-nsp@puck.nether.net' Subject: Re: [j-nsp] EX Switch Question Just avoid the 4500 if you need anything less than 1G copper. The ports on the 4500 won't negotiate to 10 or 100. I was told by the sales engineer that this switch is a top of rack switch so it doesn't support anything less than 1G. I found that funny since I have a whole rack of Avaya gear that Avaya insists must have the switch set to 100/Full. - Original Message - From: Tobias Heister [mailto:li...@tobias-heister.de] Sent: Thursday, January 10, 2013 08:31 AM To: Paul Stewart p...@paulstewart.org Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ 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] EX Switch Question
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, January 10, 2013 9:23 AM To: 'Per Granath'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I personally would not use the EX series in a metro ethernet deployment, as that's not where they are positioned to be. Perhaps the MX80 would work? You can get 40 ports of copper (using SFPs) into a single box, with both shaping/policing on a per-port/per-vlan basis. I don't think you can do this with an MX80-48T, though. The other option would be an MX240 with -X-Q or 3D-Q/EQ modules, but those can get rather expensive. Honestly, if you're looking for metro ethernet switches, I'd continue on with Cisco, primarily due to price compared with the MX80, and features specifically positioned for Metro-E compared with the EX series. ME3600 and ME3800 seem to be great switches with tons of features. This is an area where I think Juniper really needs to catch up on (vlan translation, swapping, QoS, MPLS, REP, etc.). -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Paul Stewart p...@paulstewart.org writes: Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Hello, Tobias Heister (Thu 2013-01-10 14:31:40 +0100) : We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) I don't know for the OP needs but for shure EX4200 does not have: - syslog in firewall filters - tcp flags (e. g. established) in firewall filters in egress (physical or VLAN interface). Juniper confirmed that this is a hardware limitation. That was the reason we went MX. Cheers, -- Emmanuel Halbwachs Observatoire de Paris Resp. Réseau/Sécurité 5 Place Jules Janssen tel : +33 1 45 07 75 54 F 92195 MEUDON CEDEX véhicules : 11 av. Marcellin Berthelot ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thank you - yes, both of those issues you highlighted have created problems for us especially lack of tcp established Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Emmanuel Halbwachs Sent: January-10-13 9:59 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hello, Tobias Heister (Thu 2013-01-10 14:31:40 +0100) : We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) I don't know for the OP needs but for shure EX4200 does not have: - syslog in firewall filters - tcp flags (e. g. established) in firewall filters in egress (physical or VLAN interface). Juniper confirmed that this is a hardware limitation. That was the reason we went MX. Cheers, -- Emmanuel Halbwachs Observatoire de Paris Resp. Réseau/Sécurité 5 Place Jules Janssen tel : +33 1 45 07 75 54 F 92195 MEUDON CEDEX véhicules : 11 av. Marcellin Berthelot ___ 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] EX Switch Question
Thanks We have a 6500 installation running hybrid IOS/CatOS and the CatOS component does it quite well. On another installation with MSFC2 supervisors and native IOS we also have it working... both installations are very ancient 10+ years :) Paul -Original Message- From: Benny Amorsen [mailto:benny+use...@amorsen.dk] Sent: January-10-13 9:41 AM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Paul Stewart p...@paulstewart.org writes: Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On 01/10/2013 10:21 AM, Paul Stewart wrote: Thank you - yes, both of those issues you highlighted have created problems for us especially lack of tcp established note also that (i believe still) packets which would pass through the box (when it's doing L3 things) but expire on the box... must be accounted for in the loopback filter, if you want to see ttl-expired messages. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX Virtual Chassis?
I'm curious if anyone has been using MX's in a VC config. It's supported on the new MPC blades, but supposedly not with the older DPCs. I haven't done any testing yet, just minimal research. Why would I want to? Well, I'm after redundancy with my services blades. Specifically, MS-DPCs. I've got a pair of 480s, each with a single MS-DPC. I'd be hoping to configure rsp interfaces on the VC. I'd appreciate thoughts on this. I use the MS-DPCs for my CG nat implementation. I'd rather not buy two more (rather expensive) blades just for redundancy sake. I'm not even sure how much redundancy the availability of the second blade would really provide. I have the impression that very few people are doing this. I'm already a bit borderline on the speed of response on support questions with TAC since I'm running enhanced SBCs, MS-DPCs, policing a few /16s on a per ip basis along with CG nat. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Just don't go there. EX is in no way a metro SP switch. Very common case, we've been discussing it with many customers, who their-selves want a Juniper metro SP solution, maybe once a week since the EX series was launched. After all that I am 100% sure this is not what EX is all about. 10.01.2013 18:23, Paul Stewart wrote: Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thanks Pavel... So is there anything reasonably priced in the Juniper lineup for this kind of situation or do we look at Cisco/other? Cheers, Paul -Original Message- From: Pavel Lunin [mailto:plu...@senetsy.ru] Sent: January-10-13 11:32 AM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Just don't go there. EX is in no way a metro SP switch. Very common case, we've been discussing it with many customers, who their-selves want a Juniper metro SP solution, maybe once a week since the EX series was launched. After all that I am 100% sure this is not what EX is all about. 10.01.2013 18:23, Paul Stewart wrote: Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX Virtual Chassis?
On (2013-01-10 14:53 +), OBrien, Will wrote: I'm curious if anyone has been using MX's in a VC config. It's supported on the new MPC blades, but supposedly not with the older DPCs. I haven't done any testing yet, just minimal research. Why would I want to? Well, I'm after redundancy with my services blades. Specifically, MS-DPCs. I've got a pair of 480s, each with a single MS-DPC. I'd be hoping to configure rsp interfaces on the VC. I firmly believe on average all of these software shared chassis solution offer worse availability than single box. Outage is most commonly caused by 1. operator 2. broken software 3. broken hardware And FT, VSS, VPC et.al. are reducing risk 3 by increasing risk 2. This will only decrease MTBF. We still regularly have problems with well tested, interoperating protocols such as BGP. I don't believe existing vendors have processes in place to produce proprietary non-interoperating feature which isn't totally broken. I wouldn't even do this with firewalls or any stateful fault tolerance anywhere. Acceptable configurations 1 1+1 2+1 2+2 Most commonly deployed configuration 2 (+ - routing separated) (2 - stateful fault tolerant) -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX Virtual Chassis?
On Thu, Jan 10, 2013 at 11:44 AM, Saku Ytti s...@ytti.fi wrote: On (2013-01-10 14:53 +), OBrien, Will wrote: I'm curious if anyone has been using MX's in a VC config. It's supported on the new MPC blades, but supposedly not with the older DPCs. I haven't done any testing yet, just minimal research. Why would I want to? Well, I'm after redundancy with my services blades. Specifically, MS-DPCs. I've got a pair of 480s, each with a single MS-DPC. I'd be hoping to configure rsp interfaces on the VC. I firmly believe on average all of these software shared chassis solution offer worse availability than single box. Outage is most commonly caused by 1. operator 2. broken software 3. broken hardware Although I agree in general (especially in the core of a network), I don't agree so much at the server edge. Servers generally do not speak the STP, OSPF, BFD, MPLS, etc. that would be necessary to reduce single points of failure. The best you can do is run LACP with your immediate uplink to protect against port or wire failures. With multi-chassis technology you can gain something which was not possible without it, namely the ability to protect against total hardware failure of your direct uplink switch/router by using an MC-LAG to your server. One still needs to consider broken software versus broken hardware, but it is at least no longer a question of 'highly likely broken software' (multi-chassis tech) versus 'maybe broken software' (standard protocols). -- Darius Jahandarie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX Virtual Chassis?
On (2013-01-10 12:41 -0500), Darius Jahandarie wrote: With multi-chassis technology you can gain something which was not possible without it, namely the ability to protect against total hardware failure of your direct uplink switch/router by using an MC-LAG to your server. If your server is linux, you can run 'bonding' to two different switches and you can use ARP liveliness detection to figure out when to switch to another port. Also emerging quite common pattern is to scale servers horizontally, where single server is not crucial to produce service. Then liveliness of service be advertised by BGP (e.g. exabgp). But granted, when you have proprietary service or server, which is SPOF in itself where you cannot influence of it's configured at all you may be out of options and may need to do something desperate. Personally if I find myself in such situation I'd accept that MTBF is going to be bad, and I'd opt to make MTTR small. So cold box sitting in another infra which I can remotely kick up, if the primary fails. I don't think, that even in such situation, multichassis will improve MTBF. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4550 experiences?
Does anyone have experiences / thoughts to share on EX4550 series? Thanks, james ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
http://domaine-de-montboulon.com/work.at.home.n.php?ID=020 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
I get sick of these idiots sending this... Does Juniper have any protection they can offer the puck list? :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
Route through google groups , Then it only bothers moderators. On Thu, Jan 10, 2013 at 4:32 PM, Paulhamus, Jon jpaulha...@iu17.org wrote: I get sick of these idiots sending this... Does Juniper have any protection they can offer the puck list? :) ___ 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] [SRX650] show pfe statistics weirdness
Hi Graham, On Wed, Nov 14, 2012 at 11:16 PM, Graham Brown juniper-...@grahambrown.info wrote: This is where the SRX platform differs from that of the M/T/MX etc. BFD processing is NOT offloaded to the PFEs - this is all done by the RE. This has caused one of my customers many problems and unfortunately is by design - this relates to the SRX 3600. Hmmm, this sounds .. a bit crap. Did you find any docs on this? I'm having trouble finding useful references. I have a network of J and SRX boxes -- everything from J2320 up to SRX5800 -- and I'd like to run BFD for OSPF (on IPsec tunnels). Our data centre routers (the srx5ks) have about 100 tunnels each, so I'd need 100 BFD sessions. How many BFD sessions was your customer running, and was it actually causing a problem? (high RE/control plane processor utilisation, I guess?) Did you end up using BFD anyway, or tuning the IGP, or .. ? cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Question about Routing Engine Redundancy on MX
On 1/10/2013 5:28 AM, Gabriel Blanchard wrote: Yes, just bought the book, for anyone that has MXes deployed...highly recommend. And Doug, just noticed, didn't you write this book? :-P Says Douglas Richard Hanks on my copy. Which is getting a little more thumb eared by the day. :-) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
As the list owner (it's not run by juniper) these are harder to block than you think and not that easy. Jared Mauch On Jan 10, 2013, at 4:53 PM, 叶雨飞 sunyuc...@gmail.com wrote: Route through google groups , Then it only bothers moderators. On Thu, Jan 10, 2013 at 4:32 PM, Paulhamus, Jon jpaulha...@iu17.org wrote: I get sick of these idiots sending this... Does Juniper have any protection they can offer the puck list? :) ___ 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
