Hey,
From practical standpoint, if device on one end puts ports into err-disabled state, the udld reset command will bring all of interfaces that are currently down due to udld, but is it required to commit this on both sides of the links, or only one is enough? Anyone?
2nd question if there isn't requirement for both sides - how does the other end knows, when to recover their links? UDLS sends some specific frames for that?
Appreciate any help and thoughts, thanks
Hi, I'm new here and in networking world in general (I finished a ccna course, but didn't take the exam).
I'm currently working on expanding a small business network.
Network consists of 6 clients, 1 printer, a Synology DS918+, 1 computer running ipfire that serves as a router, dns, dhcp server and firewall, a 24 port DGS-1100, and IPS provided fiber modem, all connected with twisted pair RJ-45 cables. I'm swapping ipfire pc for a mikrotik CRS109, adding a second switch (8 port), a printer and 6 clients.
https://imgur.com/a/JtWUH4t - still work in progress, but shows the general idea. I want to make downtime as short as possible by minimizing changes to existing setup (blue).
As you can see, i want to create separate LAN for new users. They need access to the synology, so, since it has two RJ-45 ports, I'd like to connect one of them to 192.168.1.0/24, and the other to 192.168.2.0/24. Is this a good idea, or should i create something similar to a DMZ between the two networks and place the server there?
Another idea I have considered was to split ports of 24-port switch into two vlans, make mikrotik router-on-stick, connect printers and users to corresponding vlans and server either to both vlans or to mikrotik in DMZ-like network, but I think it'd require a lot more time to set up.
I'm open to suggestions and constructive criticism.
Has any one come across this issue?
We have deployed EAP-FAST using Anyconnect NAM as a supplicant. On the supplicant there is a dot1x network configured and a normal wired network configured for when the users take the laptop out of the office.
When the laptops are put into locked mode for about an hour then logged back into, Anyconnect will change the network from DOT1x to Wired and the users lose network access as the switch requires authentication.
The laptops are not sleeping and the users are authenticated and the laptops working before being locked.
Once the laptops are unlocked Anyconnect NAM doesn't even try the DOT1X configuration, it just attempts Wired and will then sit there showing "Limited or no connectivity"
I am trying to connect a couple 4506 Switches with Sup 7E Cards by their 10 Gig ports with SFP+ modules
So far by connecting them and just doing switchport mode trunk and a no shut on the two interfaces but the interfaces do not come up.
Am I missing some command in order to enable 10Gigabit on them?
Cheers,
Chris
I was testing connectivity on a machine after moving it to a new ESXi host and one of the tests I was pinging 192.168.0.30.
But I mistyped it as 192.168.0.030 and what it did surprised me a little, I figured it would have still sent the ping to 192.168.0.30, but instead it attempted to ping 192.168.0.24.
Is there something I don't understand here? Or an issue I need to look into?
EDIT: When I ping 192.168.0.30 it pings that address just fine.
Hi guys,
I’ve been doing basic networking for about a year now, and I still don’t feel like I’ve fully grasped a lot of the in depth things. I’ve been trying to tackle my CCNA since I began this path, and there’s just so much detail. I understand the concepts and principles but after speaking with a few engineers, I just don’t understand how people reach such a high level of comprehension. For example, I understand how to configure OSPF, but when it comes to understanding the different types of LSA’s and what they do, I just can’t seem to understand it.
So, how long did it take you to reach your level of understanding?
Thanks everyone
Advanced warning, this is going to be long. First, some background, I bought a full Meraki stack for personal use back in April 2019. I got great pricing on it and I purchased an MX67, three MR42s APs, and four MS120 switches. At first, everything was great; I enjoyed configuring and tinkering with the various options / features. Sadly, this wore off shortly after I started encountering various bugs. MX bugs, MR bugs, Dashboard bugs, there seems to be no end of what doesn't work correctly. As a side note, I'm an active CCIE (for the last 13 years) and learn best when I have the gear on hand to work with. I'm not some goofball who bought some gear he knows nothing about.
On the MX side, my MX67 is afflicted by the following two really great ones in MX14.40 code:
Due to issues still under investigation, MX67(C,W) and MX68(W,CW) appliances may become inoperable after a device reboot occurs For a brief period of time upon boot, MX67(C,W) and MX68(W,CW) platforms can become bridged. This increases the likelihood of network loops forming in topologies with multiple inter-connected network devices for this brief period of time. Super. So, if my MX67 happens to reboot, it might just be a brick after. Maybe. Who knows? This defect has been in every 14.x release since I bought this MX67 back in April 2019. A device bricking defect is still around after 8 months? How is that possible? To go along with that, the MX67 bridges the WAN and LAN ports during bootup. That's super handy because it can bridge my cable modem to my internal LAN. At best this means that some internal devices get funky IP addresses, at worse it leaves open a nice security hole, especially if the device bricks itself while rebooting. Thankfully, MX 15.19 has a fix for the device bricking issue, but it comes with this known issue:
Due to issues still under investigation, there are significant performance regressions. Awesome. So, I can fix my device from turning into a brick at the cost of some unspecified "significant performance regressions." I opened a case to get clarity about what those regressions were but wasn't given any specifics. Instead I was told that they don't list bugs publicly and can't share with me what regressions might apply. I don't care which ones might apply, just tell me what they all are and I'll make the determination myself. Instead of being able to provide me guidance to make an informed decision about whether or not I wanted to risk bricking my device, or, if I wanted to deal with several performance impacts I'm instead left to just figure it out on my own. Then there's this bug, which is still open in all available versions of MX software:
After making some configuration changes on MX67(C,W) and MX68(W,CW) appliances, a period of packet loss may occur for 10 or more seconds. Why are there no specifics about what changes will cause a 10, or more, second period of packet loss? Surely they know what those items are, why aren't they listed? I haven't open a case on this one, but I assume I wouldn't be given any more information.
On the MR side I've run into equally frustrating bugs. First up, group policies. Meraki pushes these as a fancy way to do all kinds of interesting things. For example, one SSID can push different clients to different VLAN assignments based on what group policy they are assigned. At first, this sounded awesome, I could push my IoT devices into one VLAN and keep all my primary devices in another VLAN, all while keeping the same SSID and WPA2 PSK. Sadly, there was a huge bug in this where the access points wouldn't apply group policies correctly after reboot. This meant that after an MR or MS software upgrade, or power outage, the MRs would allow clients to connect, but some would get the wrong VLAN assignments because the group policy wasn't being applied. Then, the group policy WOULD get applied, but only after the devices in question already got a DHCP address. This meant the devices were in the correct VLAN, but had an IP address from the wrong VLAN, so nothing worked. This was recently fixed in MR26.5, 8 months after I reported the defect. Great, I'll just upgrade! The problem is MR26.5 causes frequent, random disconnects with my Nest cameras. They will just drop off the WiFI randomly for 10-20 minutes at a time, and then come back. This appears to be DHCP related as my DHCP server logs show DHCP DISCOVER / DHCP OFFER loops for the entire time the camera is offline. Sadly, this is (another) known issue in MR26.x where DHCP on bridged SSIDs sometimes just doesn't work. Seriously? DHCP on bridged SSIDs is broken? How basic is that function? It's been broken for MONTHS. Ok, no problem, I'll just skip group policies and then I can skip MR26.x and just run MR25.13. Not quite. MR25.x has a VoIP RTP packet loss defect that makes all VoIP calls via wireless completely unusable. It's not just VoIP handsets that are effected either. Facetime on iOS/MacOS also gets hosed because of this. In a household filled with iOS and MacOS devices this is unworkable.
On the MS side, I haven't run into too many issues, thankfully. These are just simple L2-only switches, how bad could it be? Sadly, I recently had an issue where the aggregation switch decided it lost connection to the Meraki cloud and therefore stopped forwarding any traffic. This took out connectivity for all devices behind it which meant I couldn't connect to anything to troubleshoot the problem. I'd be ok with this if my connection had actually gone out, but the MX67 did not report it's own connectivity problem during the exact same timeframe. Just this one MS120 switch decided to take everything down. I had to power cycle it to fix the problem. I opened a case to determine why and was told they didn't know why it dropped. Yesterday I changed STP priorities, a simple task, and it caused a 5 minute outage. STP doesn't take 5 minutes to propagate and there's no redundant paths/loops in my network, just single point to point links. Why should that take 5 minutes?
I knew what I was getting into from a feature / functionality perspective before I bought the equipment. However, there's still a number of things I find particularly annoying. In no specific order:
---Troubleshooting information is NONEXISTENT. You absolutely cannot syslog anything beyond simple firewall permit/deny messages. And, you can't count on support having any additional info, so, somethings are just impossible to troubleshoot.
---With regards to MX firewall permit/deny messages, the ONLY way to get them is via syslog. You can create the firewall rules in Dashboard, but there is zero facility to see what traffic, if any, is actually hitting those rules.
---Group policy firewall rules aren't actually firewall rules. They're ACLs. They aren't stateful. If you actually use group policy, which you shouldn't because of the above issue, have fun creating return ACL entries for all possible return traffic flows. There's even fewer options here, destination IP, port, and protocol. No source IP, no source port, nothing. This limited selection of fields makes dealing with return traffic practically impossible.
---Packet capturing via the Dashboard is a handy feature, except its broken. Want to capture for 3 minutes? Sorry, it'll stop after 10-15 seconds and show you no data. According to support this is a known issue and I've had a case open since late June with no fix.
---Stats via the Dashboard are handy, but the byte counts aren't accurate. Values shown at different places on the screen don't add up to the totals shown at the top. According to support this is another known issue.
---Absolutely no IPv6 support to speak of. In 2019.
---Want to configure specific traffic shaping rules so you can put particular traffic in a higher priority queue. Sorry, you can only specify destination IP addresses here, no source IP/port/DSCP combinations. Or, you can use the nebulous "Layer 7" rules they have predefined, but there's no specifics about what those rules are actually matching.
I could go on more, but honestly I'm tired of thinking about it. I spent a decent chunk of change on this gear and it has been a very frustrating experience. I've had way more bugs with it than the Ubiquiti gear I had before. I'm throwing in the towel. I'm gutting this Meraki gear and I've repurchased a new Ubiquiti stack and I'll use that going forward. This was truly a disappointing experience.
Can anyone recommend a reasonable ToR 10 GB switch for a small vSAN cluster (4 node)? I know there are many options in all different price ranges. Not looking to spend 10k on a switch if I dont have to. Thanks for the help.
I'm spinning up a new branch office next month for a few dozen users, and am going to be in need of buying a bunch of 6" and 1' ethernet cables for the patch panels. I love Monoprice as much as anyone, but the thought of cutting open the individual baggies and opening the twist ties on 200 patch cables is making my soul hurt.
Does anyone sell short patch cords that are packed in a not stupid and wasteful manner?
Hello everybody.
I have theses two switches, 3Com 4500 and 3Com 2928.
3Com 4500 - IP: 20.20.X.X ; Mask: 255.255.240.0
3Com 2928 - IP: 192.168.1.X; Mask: 255.255.255.0
And a printer(20.20.2.1) connected in the switch 3Com 4500 and i need access this printer from the devices on the 3Com 2928. I already tried to make a trunk between the switches, and the same Vlan(Vlan 100) in theses two switches one with interface and another without interface, and enable IP Routing, but doesn't work.
I dont know if this is good practice or not, but i did this way...
I create 2 Vlans in each switches
Switch A:
Vlan 255 - 10.5.0.1; 255.255.255.0
Vlan 100 - 192.168.100.2; 255.255.255.0
Swtich B:
Vlan 255 - 10.5.0.2; 255.255.255.0
Vlan 200 - 172.168.200.2; 255.255.255.0
So i create this routes:
Switch A:
10.5.0.1 - 255.255.255. - 10.5.0.2
172.16.200.2 - 255.255.255.0 - 10.5.0.2
Switch B :
10.5.0.2 - 255.255.255. - 10.5.0.1
192.168.100.2 - 255.255.255.0 - 10.5.0.1
Now the Switch A can ping i the switch and the vlans of the "B" and "vice versa". But i can't ping from Vlan 1 in any other vlan.