Re: [j-nsp] Different media in an AE cause framing issues?
On 04/01/2013 08:52 PM, Morgan McLean wrote: So at this point I'm wondering if mixing the fiber and DAC connections is a nono? Due to timing issues? Not sure how that would screw up the frame, but maybe somebody has more insight. That seems like a really complicated explanation; why would you assume that, rather than a fibre problem e.g. bad splice, dirty connector, etc? Or even bad SFP+? I'm unfamiliar with the EX platforms, but it would seem really odd if they had this kind of tight inter-port timing constraints just because they're in an aggregate; what about diverse fibre paths with radically different lengths, which are a common enough config? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX - Input packet rejects
Hello, I'm a bit puzzled by the 'Input packet rejects' counter shown by 'show interface .. extensive'. What exactly does that counter count? I have this output: Filter statistics: Input packet count38435461 Input packet rejects 23759 Input DA rejects 0 Input SA rejects 0 Output packet count25333064 Output packet pad count 0 Output packet error count 0 CAM destination filters: 0, CAM source filters: 0 The documentation says: Input packet rejects - Number of packets that the filter rejected because of either the source MAC address or the destination MAC address ... but the DA/SA rejects counter stays at 0. So what type of traffic increments this counter? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Different media in an AE cause framing issues?
On Apr 1, 2013, at 15:52, Morgan McLean wrx...@gmail.com wrote: Hey guys... So I just bought a bunch of avago SFP+'s from a local distributor, about 250 of them, so I'm in relatively deep here. I'm wondering if I just made a general mistake by adding another 20gbit of MM OM3 with these new modules to an existing 20gbit AE which is using DAC. I started noticing framing errors mostly on the two additional links I had added. It was around 100-300 per second per interface..the DAC interfaces were fine. The AE was only pushing around 1-2gbit duplex at the time when I noticed it (packet loss), and I shut down those interfaces. I'm using these modules to convert existing top of rack connections from twinax/DAC to fiber, which I haven't started, but I DID just roll out another 8 cabinets using these modules, and so far I haven't seen any framing errors...but then again I'm not pushing much traffic. I also didn't see these issues when I tested a couple modules before we bought them... The core AE is between two EX8208's, and the TOR connections are going out from the core to EX3300's. Here are the stats for one of the cabinet AE's from the core switch side, which looks clean: Interface: ae5, Enabled, Link is Up Encapsulation: Ethernet, Speed: 2mbps Traffic statistics: Current delta Input bytes: 264708836 (2040 bps) [1928] Output bytes: 5520922123 (23832 bps)[25257] Input packets: 2013442 (1 pps) [16] Output packets: 35600334 (22 pps) [256] Error statistics: Input errors:0[0] Input drops: 0[0] Input framing errors:0[0] Carrier transitions:18[0] Output errors: 0[0] Output drops:0[0] The EX3300 side looks good, as well as the AE for the VC between the 3300's, which also use these modules... So at this point I'm wondering if mixing the fiber and DAC connections is a nono? Due to timing issues? Not sure how that would screw up the frame, but maybe somebody has more insight. -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Although I've actually never done it, I've always assumed you could mix and match media types in an AE. I think you may be right, either mixing them is a no-no, or one/both of them are bad. Try replacing the DAC connections with SFP+ connections or turn up a new AE with only the new SFPs. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. Well, don't get me wrong. MPLS in the access is a lovely thing and I really understand what Mark from Juniper. Moreover I personally hate all the plain ethernet garbages in the access (people tend to insert more tiers on the way from access switch to the MX-like router because they can't connect every basement to an aggregation point and it just breaks the whole idea of access network). I just wanted to note, that from the money point of view at the time when MX80 was under construction, it /could/ be a wise decision to not compete against products like CES/CER and make it more router-alike than a MetroE optimized device. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Clustering J-series across a switch
Hey all, So I've been reading the clustering docs, and they make it pretty clear that the (at least) control link should connect the devices back-to-back. I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Now if Junos is going to use a new ether-type for control link communication it's pretty certain the devices would have to be connected back-to-back, but if control link traffic is within a specific VLAN switching it shouldn't be a problem, right? I'd q-in-q the traffic anyway. The health of the control and fabric links is determined by heartbeats only, not link state, so a switch wouldn't hurt that. I accept that clustering across a switch isn't necessarily advisable, I'm just wondering if it's fundamentally possible. Has anyone ever even tried to put a switch between a J-series, or SRX-series, cluster? Thanks Currently we've 2 J6350s on different floors of a building, with different providers. Around that building we have a 10Gbps VC ring of EX3300s. We want to cluster the J-series' but don't want the hassle or cost of running copper between the providers (if that's even possible) when the VC is way more than fast enough. Traffic levels are way way below 10Gbps, and it's highly unlikely they'll ever get that high. -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Clustering J-series across a switch
IIRC, it's possible but not recommended due to the reliability issue of the switch in between. In your situation, I'd probably give it a shot. Definitely use different VLANs for control and fabric. Aaron On Apr 2, 2013, at 10:47 AM, Mike Williams wrote: Hey all, So I've been reading the clustering docs, and they make it pretty clear that the (at least) control link should connect the devices back-to-back. I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Now if Junos is going to use a new ether-type for control link communication it's pretty certain the devices would have to be connected back-to-back, but if control link traffic is within a specific VLAN switching it shouldn't be a problem, right? I'd q-in-q the traffic anyway. The health of the control and fabric links is determined by heartbeats only, not link state, so a switch wouldn't hurt that. I accept that clustering across a switch isn't necessarily advisable, I'm just wondering if it's fundamentally possible. Has anyone ever even tried to put a switch between a J-series, or SRX-series, cluster? Thanks Currently we've 2 J6350s on different floors of a building, with different providers. Around that building we have a 10Gbps VC ring of EX3300s. We want to cluster the J-series' but don't want the hassle or cost of running copper between the providers (if that's even possible) when the VC is way more than fast enough. Traffic levels are way way below 10Gbps, and it's highly unlikely they'll ever get that high. -- Mike Williams ___ 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] Clustering J-series across a switch
02.04.2013 20:47, Mike Williams wrote: I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Yes, as already mentioned its revertible with set chassis cluster fabric-link-vlan enable/disable (hidden). show chassis cluster information will show you actual state. Also see KB23995 and KB23995. Has anyone ever even tried to put a switch between a J-series, or SRX-series, cluster? Yes, I have, but quite a long time back. It worked for me in a lab with SRX650 running very early code (9.smthng) but I've never seen it used in production. AFAIR, some switches (Cisco?) needed to be configured somehow to not check the payload was IP (not sure if it really was enabled by default). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Different media in an AE cause framing issues?
Phil, I can't imagine that BOTH connections I added to the AE are bad, whether it be SFP related or Fiber related. And I'm using the same fiber and SFP's out to the cabinets (with no issues as of yet), which leaves me with the DAC + SFP on an AE is a bad idea. Ben, Ya I'm thinking thats my next step, only problem is this is in production, and I would really hate to bring up an AE that drops packets out the ass. I think people would notice that one...Might be able to test it in a lab if I have the required stuff here. Morgan On Tue, Apr 2, 2013 at 1:29 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 04/01/2013 08:52 PM, Morgan McLean wrote: So at this point I'm wondering if mixing the fiber and DAC connections is a nono? Due to timing issues? Not sure how that would screw up the frame, but maybe somebody has more insight. That seems like a really complicated explanation; why would you assume that, rather than a fibre problem e.g. bad splice, dirty connector, etc? Or even bad SFP+? I'm unfamiliar with the EX platforms, but it would seem really odd if they had this kind of tight inter-port timing constraints just because they're in an aggregate; what about diverse fibre paths with radically different lengths, which are a common enough config? __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Clustering J-series across a switch
I've heard that it works. I have avoided it so far, however. Will O'Brien On Apr 2, 2013, at 11:48 AM, Mike Williams mike.willi...@comodo.com wrote: Hey all, So I've been reading the clustering docs, and they make it pretty clear that the (at least) control link should connect the devices back-to-back. I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Now if Junos is going to use a new ether-type for control link communication it's pretty certain the devices would have to be connected back-to-back, but if control link traffic is within a specific VLAN switching it shouldn't be a problem, right? I'd q-in-q the traffic anyway. The health of the control and fabric links is determined by heartbeats only, not link state, so a switch wouldn't hurt that. I accept that clustering across a switch isn't necessarily advisable, I'm just wondering if it's fundamentally possible. Has anyone ever even tried to put a switch between a J-series, or SRX-series, cluster? Thanks Currently we've 2 J6350s on different floors of a building, with different providers. Around that building we have a 10Gbps VC ring of EX3300s. We want to cluster the J-series' but don't want the hassle or cost of running copper between the providers (if that's even possible) when the VC is way more than fast enough. Traffic levels are way way below 10Gbps, and it's highly unlikely they'll ever get that high. -- Mike Williams ___ 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] Clustering J-series across a switch
It works on 11.4 (several versions) with running dual control and dual fabric links between 2 SRX3600 using cisco VSS switches in between. As long as control and data planes have different VLANs and you enable jumbo frames on the fabric it just works. Not tried to Q in Q the traffic though, just vanilla vlans for now. On 2 April 2013 17:57, OBrien, Will obri...@missouri.edu wrote: I've heard that it works. I have avoided it so far, however. Will O'Brien On Apr 2, 2013, at 11:48 AM, Mike Williams mike.willi...@comodo.com wrote: Hey all, So I've been reading the clustering docs, and they make it pretty clear that the (at least) control link should connect the devices back-to-back. I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Now if Junos is going to use a new ether-type for control link communication it's pretty certain the devices would have to be connected back-to-back, but if control link traffic is within a specific VLAN switching it shouldn't be a problem, right? I'd q-in-q the traffic anyway. The health of the control and fabric links is determined by heartbeats only, not link state, so a switch wouldn't hurt that. I accept that clustering across a switch isn't necessarily advisable, I'm just wondering if it's fundamentally possible. Has anyone ever even tried to put a switch between a J-series, or SRX-series, cluster? Thanks Currently we've 2 J6350s on different floors of a building, with different providers. Around that building we have a 10Gbps VC ring of EX3300s. We want to cluster the J-series' but don't want the hassle or cost of running copper between the providers (if that's even possible) when the VC is way more than fast enough. Traffic levels are way way below 10Gbps, and it's highly unlikely they'll ever get that high. -- Mike Williams ___ 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
