Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
In an example log entry below, I'm showing an SPT (I guessing source port) of 32771, and a DPT (guessing destination port) of 53 (DNS).
Why two different ports? Is the port assignment getting changed between the sending NIC and receive NIC? Or am I reading this wrong? I'm wondering how to handle these in my iptables.
It's called session multiplexing, if I remember properly.
That's what allows you to open multiple sessions to the same host. For example, when you connect to a web server, if you only connected to and from port 80, you'd only be able to have one session open. That's slow and inefficient. So you hit the same web server from a multitude of source ports, and they all point at port 80; you can get several requests at once from a single web server.
Anyway, it's normal and all good. Generally, you filter your outbound traffic by destination port, or IP. You filter your inbound via source port, or IP. So for a DNS request, you'd want to allow anything out destined for port 53, and anything in sourced from port 53.
well it's not really called anything, that's just the way tcp sockets work.
client / source port numbers are picked generally from an "ephemeral" range, which is a block of space somewhere above port 1024, often way past there, which any process is allowed to open. non-root processes can't open a port under 1024 for security reasons, but essentially there is no relation between a source and destination port (except in some unusal cases like dhcp)
a tcp connection is defined as client_ip:client_port <--> server_ip:server_port and both parties keep track of those 4 attributes (amongst others relevant within that known connection) and so know what connection that is.
well i know it's for a reason..! Just that it's such a fundamentally low level piece of TCP/IP, it's not something that you actively look to modify or question to any extent.
Not to mention, knowing why it does what it does can come in handy later. Take this, for example. The OP had no knowledge of TCP/IP multiplexing, and as far as he knew, his ports were getting switched around en-route.
Imagine when he saw several connections to the same server from different ports. Someone not having knowledge of why this happens could be a little freaked out, and that's never good (although it can be funny.) lol
Personally, I've never accepted, or given a "just because" answer. While you can't change it, in depth knowledge of how something works is much better. Imagine if your phones were set up and the TDM used to separate phone calls was just accepted and never improved upon. You wouldn't have TDM over fiber, you wouldn't really have modems, and you wouldn't have DSL (since it uses frequency division multiplexing). Same with TCP/IP multiplexing; if you don't question how it works, you'll never know how it works, why it works, why it's implemented, and the massive number of uses for it.
Just imagine, as another example, if I just accept QoS for what it is in my job, but had no understanding of it. I'd have 4000 very unhappy VoIP users on my network, and I'd have no clue what was going on.
Not to sound demeaning, but auto qos voip illustrates where "just because" can get you.
While it can be used to QoS a network, it is not the end-all-be-all to QoS solutions, nor should it really be used permanently. It is a tool for base lining the QoS your network should need, and is a suggestion. You can choose to continue using it or not, but it will not always solve your problems. Cisco actually doesn't recommend you implement it as a permanent solution on your network.
Quote:
Yes, auto-qos is allowed in the lab. We used prohibit the usage of this feature, however, the retriction is lifted more than a year ago because it is indeed a useful feature for our customers. With that being said, I recommend you to use auto-qos to asssit you to establish a baseline QoS configuration, then read the lab question requirements carefully to make sure you customize or edit the configs to meet the specific requirements.
We actually use CallManagers; around 14 of them. Users are actually rather happy because the network is properly designed and the 6 engineers responsible for it have have in-depth knowledge of networking and the protocols.
Quote:
ever wished you'd not phrased something the way you had?
Am I serious, or am I joking? The world may never know.
Now see, if you'd have said Unity and Lotus were the bestest of buddies and worked flawlessly together, there's a joke. You'd have had me in stitches for the next 6 months with that. :-P
Keep in mind, I just came off a job with a "network manager" that thought himself a Cisco god. The guy barely knew what QoS stood for, and had absolutely no good words for Cisco's AVVID implementation.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.