/r/networking appreciation post Networking

---

• /r/networking appreciation post
• Allowed vlans in trunk
• What NETWORK problem is best/easiest troubleshot by looking at packets in Wireshark?

/r/networking appreciation post Posted: 29 Dec 2019 09:14 AM PST Hi all, i just want to express my appreciation for everyone and everything in this sub as it helps me expand my knowledge about enterprise network in a huge way. Why you may ask? I have been deputy teamlead in technical 2nd level customer support at a quite big ISP here in GER for ~1,5yrs now. As deputy teamlead we are supposed to answer the technical questions from our colleagues and there's little to no documentation for technical things above our level. Sure there's a NOC and if you get to know some of the guys they answer the questions you have but I don't want to look like a total fool to them so i read books about networking, VoIP, etc. In addition to that i extensively lurk in this sub and read nearly every post including the comments as those are cases out of the field to which i wont have access. ​ TL;DR Great sub here, really enjoy all the discussion and analyzing of problems straight out of the field, they have taught me much i wouldn't have learned another way. Thanks & Everyone have a great 2020! submitted by /u/iamdegenerat3 [link] [comments]

Allowed vlans in trunk Posted: 29 Dec 2019 03:09 PM PST I've been looking over our switch configs that I've inherited and I have a question on allowed vlans on trunk ports. The interfaces I'm questioning have our access points connected to them. Currently all ports that have a access point connected to them look like this interface GigabitEthernet1/0/6 switchport trunk native vlan 9 switchport mode trunk spanning-tree portfast I feel they should be configured as below to only allow the vlans that we want: interface GigabitEthernet2/0/7 description AP-MS104 switchport trunk native vlan 9 switchport trunk allowed vlan 6,9,10,70,155-157 switchport mode trunk Edit: our VoIP is set up the same as our Access Points which definitely doesn't seem right. submitted by /u/Wizard210 [link] [comments]

What NETWORK problem is best/easiest troubleshot by looking at packets in Wireshark? Posted: 29 Dec 2019 09:32 AM PST Yesterday I made a semi-obnoxious comment in another thread that got me downvoted pretty hard. (At least for this sub.) That comment was that a good networking engineer didn't really need to learn how to read packet captures in Wireshark as a core networking skill, because our primary responsibilities are layers 1 through 3, and you should never need to open up Wireshark to troubleshoot ANY issue in those layers. However, I also posed a question in response to my backlash: If I'm wrong, prove me wrong. Name any situation where a NETWORKING problem (read: layers 1-3, something that you would have to fix on a switch or router) where you could only, or most easily, solve the problem by jumping to Wireshark and looking at packet captures. And honestly, no one was able to answer it. I stand by what I said, that for a Networking Engineer, you don't need to EVER go to Wireshark to solve any NETWORKING problem. Problems of a higher layer? Absolutely. If you want to see if a server didn't send a SYN+ACK, or see what error message it sent, something like that, that's not a Networking problem. At that point you're doing the application owner's or the server owner's job for them. You are NOT troubleshooting a network issue at that point. You're doing someone else's job for them. Wireshark is their tool, not ours. Here were some of the attempts at answering my inquiry, and my replies to them. Attempt: A VoIP Customer (apparently you are working at a UCaaS vendor?) is complaining of call drops and quality issues, and wants you to verify that their traffic is being marked with the proper DSCP values. What easier way to do this is there than viewing their traffic in Wireshark? My Response: Netflow, or even show policy-map interface and verify that the counters for Priority Queue and Signaling Queue are incrementing. Anyway, Netflow is the best answer, if the question is "verify that the traffic is being marked with the proper DSCP." Why would you EVER default to pulling captures and viewing them in Wireshark when Netflow, SFLOW, etc can easily tell you what traffic is going across your device, and if it has any DSCP markings. Done. Easy. Next! Attempt: How are you going to verify asymmetric routing? Only Wireshark can show you if packets with the wrong destination address are reaching a host. Response: That's not how asymmetric routing works. It doesn't cause packets with the wrong destination address to reach a host. ARP problems can typically cause that, and that's most easily troubleshot using show commands on your switch and/or router. Attempt: ICMP is working to the server, but SSH is not. Response. Then that's a higher layer issue, and it's NOT our problem as a Networking Engineer. It's not like we have protocol-based PBR installed on our network. We route packets based on destination address, if ICMP is working, but SSH is not, the problem is so obviously a server/app problem at that point a Networking Engineer does not need to be the one who is assigned to that ticket. Anyway I am just curious since that hit a smaller audience, if I open this one up to the entire subreddit, does anyone have any GOOD examples of a NETWORKING problem (again layers 1-3, something you need to fix on a router/switch) where jumping into Wireshark to look at pcaps is the best/easiest way to troubleshoot that. Because I honestly believe that there's basically no reason to ever do that. imo if you are at the point of looking at stuff in Wireshark, then you are already the wrong person looking at the issue, and it should go to the app/dev/server guy instead. submitted by /u/thosewhocannetworkd [link] [comments]

You are subscribed to email updates from Enterprise Networking news, blogs and discussion.. To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States