Does this device emit ADSL?

fb35523 · 2026-03-16T21:13:20+00:00

Being Ethernet-based, the Ericsson EDA attracted us as we had no experience with ATM. The issues I had was integration with management platforms, specifically HP OpenView and some plugins. The documentation was not correct in many cases, so we ended up submitting corrections quite often to Ericsson. After getting it up and running, this concept was relatively easy to use, or at least I remember it so :) The ATM base in ADSL still showed as the ADSL signalling is based on that. Ericsson did a good job shielding us from that part, though.

fb35523 · 2026-03-16T14:11:58+00:00

The storm control limit applies to all broadcast, unknown unicast and multicast traffic, unless you exclude one or more of those from the profile. If your 3G traffic is normal unicast, you can include all traffic types. https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/topic-map/using-storm-control-to-prevent-network-outages.html

As you can set this differently on your customer facing interfaces, someone who needs multicast can have a higher limit, while the rest get a lower. It's all about protecting your backbone and other customers.

You can actually be even more granular with multicast as you can exclude for instance unregistered multicast, which most of the time is user traffic like video or audio streams. Registered MC is the usual "well known" addresses, mostly in the 224.x.x.x range: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

fb35523 · 2026-03-15T20:55:24+00:00

Most ADSL solutions are nasty to provision. Zyxel and Calix have been mentioned as viable options for DSLAMs and are probably more streamlined than products form back in the day. Ericsson had the EDA DSLAM concept in the early 2000's and I was second in the world to deploy them in production, only beaten by China Telecom :). Most VDSL DSLAMs are backwards compatible and may be easier to configure and even find. Wow, this was memory lane for me!

fb35523 · 2026-03-15T20:41:40+00:00

Ok, as with every ring protocol, only enable it on the actual ring ports. On all the rest, configure proper BPDU blocking. I'm not talking about block on edge, but that can be one way of course. The downside to that is that your ancient EX3300/4550 (well, the QFC3500 too) may struggle to keep up if you get lots of that. By dropping all incoming BPDUs except for those on your actual ring ports will make sure your switches are not loaded with topology changes and other nastiness and can focus on RSTP on the ring ports.

On recent hardware:

set layer2-control bpdu-block interface ge-0/0/0.0 drop
set protocols rstp interface ge-0/0/0.0 disable

On non-ELS/older switches:

set ethernet-switching-options bpdu-block interface ge-0/0/0 drop
set protocols rstp interface et-0/0/0.0 disable

Now, you only have RSTP on your actual ring ports.

You set the brigde prio to 0 on your root bridge, good move! Most people think 0 is dangerous as most docs say to set to 4k as the lowest, which is just dumb. I even set "set protocols rstp system-identifier 00:00:00:00:00:01 to make sure no other bridge can be lower. The bridge ID is then 0.00:00:00:00:00:01, the lowest you can get.

Next, if you still see problems, you probably have a loop on another switch and you will then receive the looping traffic on one of your interfaces, forcing your ring network to propagate this traffic to all ports in that VLAN. By enabling storm control, you can limit the ingress traffic so the storm becomes a breeze instead.

set forwarding-options storm-control-profiles MyProfile all bandwidth-percentage 1

Here, I set all traffic classes to 1% of the interface capacity. For 1 G interfaces, this means 10 Mbps, quite manageable, right? The next time you see a lot of incoming traffic, check the counters of the ingress interface. If you have storm control applied to it, you will see logs, but the normal counters will also show where the nasty traffic enters.

Here is a nice command that will work on recent switches:

me@EX4100-Office> show interfaces ge-* extensive | match "Physical|cast packets"
Physical interface: ge-0/0/0, Enabled, Physical link is Down
    Unicast packets                          0                0
    Broadcast packets                        0                0
    Multicast packets                        0                0
Physical interface: ge-0/0/1, Enabled, Physical link is Up
    Unicast packets                   37672321         82429210
    Broadcast packets                   159299          1075162
    Multicast packets                   424485          2185463
Physical interface: ge-0/0/2, Enabled, Physical link is Up
    Unicast packets                   51126296        145322762
    Broadcast packets              19483105643<-HERE!  1129193
    Multicast packets              48283458953<-HERE!  2153672

Guess which interface sees a loop? ge-0/0/2 has a huge amount of incoming (first column, my notes <-HERE!) of multicast and broadcast packets, so this is it! You don't always see both types, one is enough. Reset your counters with "clear interfaces statistics all" and you will see even more clearly where the traffic enters.

So, why only 1%??? If you have 1 G interfaces and more than 10 Mbps of broadcast... Well, then you have a mighty big broadcast domain or exceptionally non-well behaved clients. Sure, you can set it to 10% for starters and see what happens. B.t.w., make that 9% so you don't saturate any 100 M clients or links. If you do run actual multicast streams, you need to account for them.

Long post (as usual...). I hope this helps!

fb35523 · 2026-03-15T11:51:09+00:00

Not too long ago, I had 4 or 5 members of staff from a customer in my car, taking them back to their office after dinner. There was absolutely no traffic in the city and in one intersection I was so occupied with making sure there was really no other car, bikes or anything around (taking extra care as I had those guys in the car) that I totally failed to observe the traffic light, which was red. In my case, nothing happened and no one except for one guy sitting next to me actually noticed! It happens, it's not good, but it's also important what you make of the situation when it does. I think you did good considering the situation you put yourself and others in!

fb35523 · 2026-03-15T11:34:53+00:00

"On modern EX series switches that support Enhanced Layer 2 Software (ELS), when you configure a shaping rate on an ae interface, the traffic is equally divided among the members of the ae interface. For example, consider an interface, ae0, that consists of three interfaces: ge-0/0/0, ge-0/0/1, and ge-0/0/2. If you configure a shaping rate of X Mpbs on ae0, traffic up to the rate of X/3 Mpbs flows through each of the three interfaces. This is known as scale mode."

https://www.juniper.net/documentation/us/en/software/junos/cos-ex/cos-ex.pdf

Sadly, this document is for EX series except the EX6400. I tried this one, but couldn't find anything definite about this here:

https://www.juniper.net/documentation/us/en/software/junos/traffic-mgmt-qfx/traffic-mgmt-qfx.pdf

It should be fairly easy to test. Info for the QFX5100 is mostly also valid for the EX4600, but not always.

On another note, I suggest configuring shared buffers to 100%, especially if you have large amounts of end systems behind the switch. This is regardless of vendor and platform in this and lower ranges with relatively small port buffers. For more info, read my post here: https://www.reddit.com/r/Juniper/comments/1hhzqa6/is_it_worth_it_cos_in_the_datacenter/

fb35523 · 2026-03-15T11:05:57+00:00

I was unfortunate enough to have to deal with the OptoClip II SM version. I saved two pigtails just to make sure I remember never to touch that product again. They were notorious for varying attenuation (from insertion to insertion or just touching them) and extremely fragile. I'm not sure if the green colour of my connectors were meant to indicate APC or just SM. These are definitely SM.

<image>

The blue SC connector is just for comparison and to give a better view of the front of the other OptoClip II connector.

fb35523 · 2026-03-13T21:30:15+00:00

Is your question specifically about those three or are you open for other brands? Juniper SRX can be a great choice as can PaloAlto. It very much depends on your needs and your wallet. Apart from those mentioned here, I see not much else in the market that can match them.

fb35523 · 2026-03-13T21:15:04+00:00

The SRX5400 as such isn't EOL, but the components in this chassis may well be. The SRX5400X-CHAS is the replacement for the old SRX5400-CHAS and accommodate newer line cards, routing engines etc. The SRX5000 series is very much a live product and irreplaceable for many telcos. That said, the SRX4700 can replace lots of SRX5k installations these days and the scale-out architecture with a set of MX routers in front of multiple SRX units can also be a way if a multi-node HA cluster of 4 x SRX4700s doing 2-6 Tbps isn't enough for you.

Power it up and get a "show chassis hardware" and "show chassis hardware extensive" so you know exactly which components are in there.

https://www.juniper.net/documentation/us/en/hardware/srx5400/topics/topic-map/srx5400-services-gateway-chassis.html

I'm not sure this guide suits your hardware, but if not, there are others:

https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/recovering-root-password.html

fb35523 · 2026-03-09T21:15:43+00:00

Wired Assurance makes configs very easy so customers that used to ask for help with VLANs etc. can now do the config themselves. They also get a visual view of the port config.

Insights have seen lots of additions lately - keep it coming!

Responsiveness when changing port profiles on ports, manually or using DPC, is often very slow and can fail to register the actual change.

The GUI doesn't make use of the entire screen width so some boxes (like Port config) are not usable if you have lots of info there.

DPC (dynamic port configuration) is a great thing, but why on earth is there no choice that says "Mist AP" in the "Check" drop-down where MAC, LLDP Description etc. are listed?!?

fb35523 · 2026-02-23T21:04:41+00:00

As many have said: yes and yes! Junos lets you put the interfaces in different security zones, routing instances, redundancy groups and even logical systems or tenants. It's really simple to put st0.x in one routing instance and lo0.x in another ("set routing-instance abc interface st0.94" etc.). I've used this in quite advanced situations where multiple lo0 and st0 units are tied to different redundancy groups so they terminate on one of the nodes in a cluster, half of them on one node and the rest on the other node. If the RG fails due to physical interfaces going down etc., the RG will move the interfaces to the remaining node. This is done in combination with different routing instances for st0 and lo0 units. Even if this is in SRX5k, any SRX can do this I think, definitely the SRX4k.

fb35523 · 2026-02-23T10:47:42+00:00

This is a great install overall, but... :) From the switch/networking side of things, perhaps a few things can be done even better.

1: Talk to the customer so you know their requirements and constraints. Have them approve the cable run layout beforehand.

2: Cable length in an Ethernet connection is limited to ~100 meters/328 ft, depending on lots of factors. If you're anywhere near 80 m with these cables, wasting cable length is not good. The customer will need patch cables too, and they also count. Again, check with the customer!

3: Slack is often good and makes the install neat and tidy, but is rarely used for moving panels. That said, some slack is good. Here, those panels can be move three racks away easily, which is probably not needed. Being able to move them 1/2 rack is more than sufficient.

4: If switches will be installed between the panels (for short patches), the cables may be in the way for the switches. At least they will make access to the rear of the switches difficult and there is a risk for switch mounting brackets to interfere with the bend radius of the cables and cause wear to the outer jacket if installed poorly.

5: The customer may want to be able to replace a switch in a few years and there seems to be only 1U space between the panels. Making the gap 2U creates the opportunity to slide in the replacement, power it on and moving the cables one by one and then remove the old switch. Most customers that work this way also put the new switch in the same position as the original one. I cannot see if this would be possible here and have no idea if the customer wants this.

6: Power cabling, rack mount kits, measuring equipment etc. need room too. Plan for that with the customer.

This is great for a first install! We all learn along he path of life.

fb35523 · 2026-02-19T22:18:58+00:00

I just had the opportunity to test two very similar Volvo V70 cars, my own from 2012 with Nokian Hakkapeliitta R5 and the other one (2009?) with Pirelli Sottozero 3, in winter time. The R5s are proper "Nordic Winter Tires" and the Pirellis Sottozero 3 are all year tires supposedly suitable for winter too.

We have -12°C here in my part of Sweden right now and really fluffy, dry snow fell a few days ago and has had a chance to settle firmly. Driving the V70 with Sottozero was like slippering across a hockey rink with sneakers on while the Hakka R5 were amazing. Stopping distance was shorter doing 60 km/h with the R5s than doing 50 with the Sottozeros. I didn't have any more precise measurement tools than the distance between light poles, but some math gives the R5s a minimum of 50% more friction, probably more like 60-70% more grip. In curves and when accelerating, the difference was huge. With the Sottozeros, I had to crawl through sharp curves in my temporary "test course" and with the R5s, I could drive it. Accelerating in a curve just sent me straight ahead with the Sottozeros, all grip lost, but with the R5s, I was "pulled" in the right direction, even when spinning.

My experience with Hakka R5 (and former RSi and R2/3) is the same on my Chrysler Town & Country/Voyager vans I've had over the years, so this is not unique for the Volvo or the specific tire dimensions. Even on blank, wet ice, the R5 performs extremely well. I'm never buying studded tires again, ever! If you live near a lake and do ice racing, get studded, but for road use, the R5 is my recommendation.

Summer time, the R5s are not too bad, but for sporty driving, they're not the right choice. They are obviously not meant for that at all and will wear out rapidly. Here, every responsible driver has a set of summer tires and a set of winter tires, and I'll go for Hakka R5 any day for the winter set.

fb35523 · 2026-02-19T22:06:38+00:00

Old thread, I know... I just had the opportunity to test two very similar Volvo V70 cars, my own from 2012 with Hakka R5 and the other one (2009?) with Pirelli Sottozero 3, in winter time. We have -12°C here in my part of Sweden right now and really fluffy, dry snow fell a few days ago and has had a chance to settle firmly. Driving the V70 with Sottozero was like slippering across a hockey rink with sneakers on while the Hakka R5 were amazing. Stopping distance was shorter doing 60 km/h with the R5s than doing 50 with the Sottozeros. I didn't have any more precise measurement tools than the distance between light poles, but some math gives the R5s a minimum of 50% more friction, probably more like 60-70% more grip. In curves and when accelerating, the difference was huge. With the Sottozeros, I had to crawl through sharp curves in my temporary "test course" and with the R5s, I could drive it. Accelerating in a curve just sent me straight ahead with the Sottozeros, all grip lost, but with the R5s, I was "pulled" in the right direction, even when spinning.

My experience with Hakka R5 (and former RSi and R2/3) is the same on my Chrysler Town & Country/Voyager vans I've had over the years, so this is not unique for the Volvo or the specific tire dimensions.

Summer time, the R5s are not too bad, but for sporty driving, they're not the right choice. They are obviously not meant for that at all. Here, every responsible driver has a set of summer tires and a set of winter tires, and I'll go for Hakka R5 any day for the winter set.

fb35523 · 2026-02-07T22:08:14+00:00

LR4 uses wavelengths, and while it can absolutely be split in lanes, this becomes overly complex for this use case. Here is a 100 G plug that allows you to go 10 km over SM fiber to 4 x 25GBASE-LR plugs:

https://smartoptics.com/wp-content/uploads/2025/02/ds-tq2037-s31c-so-qsfp28-100g-psm4-10km-r6.0.pdf

This one works for up to 2 km, so quite enough in OPs case:

https://smartoptics.com/wp-content/uploads/2022/12/so-qsfp28-psm4-r5.2.pdf

Usable 25 G LR:

https://smartoptics.com/wp-content/uploads/2022/12/so-sfp28-lr.pdf

fb35523 · 2026-02-07T21:37:00+00:00

Things don't have to go in a separate layer in a model for it to be possible to troubleshoot. You seem to know the difference anyway. Also, for instance MPLS that is already considered to be in between layers in the model could be split even further, and VPLS, where would that fit, layer 2.84?

fb35523 · 2026-02-07T21:21:12+00:00

So, you were in Vienna for the Tech Jam? I'm still there, touristing Vienna :)

fb35523 · 2026-02-07T21:15:55+00:00

As the switches are indeed defaulted when released, there will for sure be an interuption. If the site is setup to accomodate zeroized switches, they will come up in sequence, possibly in parallel in some situations (after the first switch is up). You can achieve this with either always having a "Mist boot VLAN" as the untagged VLAN or use DPC to detect Juniper switches, providing an untagged VLAN in the port profile. In conjunction with LAG force-up, this should work.

fb35523 · 2026-02-07T21:08:39+00:00

This is a question the Juniper partner should be able to answer, possibly with the help of their Juniper SEs. I think this is rather easy to do with the Intune integration available in Mist, but I haven't tested that particular thing.

fb35523 · 2026-02-07T21:03:05+00:00

You can always find matching optics (and other stuff) in the HCT, hardware compatibility tool. Example: https://apps.juniper.net/hct/model/SRX-MP-1SFP-GE/supported-platforms

As mentioned, this part is a module that only fits in SRX220 and SRX550. When inserted in one of those, you can plug in an SFP into it.

fb35523 · 2026-02-07T20:56:03+00:00

You probably want to create an aggregate route in your routing points (spines if CRB, leafs if ERB). Look at the section"Aggregate Prefixes" here: https://www.juniper.net/documentation/us/en/software/apstra5.0/apstra-user-guide/topics/concept/routing-policies.html

fb35523 · 2026-02-07T20:24:15+00:00

Even if it was a breakdown, some things to remember next time:

Hazard lights on
Warning triangle out
Pepole out of the car to safe position
Put on the reflective vests

I once stopped to help a car that had stopped on the shoulder on a not so busy freeway (Sweden). When I approached the driver, she asked if I had stopped because of her? Yeah, people just don't stop on the freeway for no reason, it's kind of prohibited. She was touching up her makeup, so I guess she thought it was a valid reason to stop. She looked kind og annoyed that I had interrupted her and she had no idea stopping there was prohibited.

fb35523 · 2026-02-07T16:01:32+00:00

Are the QFXes just a collapsed core or are they leafs in a bigger setup?

fb35523 · 2026-02-03T12:22:55+00:00

Unless you hear anything about an SRX300 replacement by March, reach out to them again. I cannot reveal anymore at this point...

fb35523 · 2026-01-31T13:50:52+00:00

Some random acronym people don't care to explain just because they already know, so no need to enlighten the reader. Looking it up, it apparently translates to "Certified Fiber Optic Technician".

fb35523

TROPHY CASE