PBR/VRF are right up there with systems virtualization as band-aids to side step much deeper architectural deficiencies. Complexity in the network is something to be embarrassed about not celebrated.
Is not an argument. It's an unsubstantiated opinion. The world would be a better place if you knew the difference, and people like me would bother trying to put out light rather than heat. I wasn't brought upon this earth to be an idiot's network engineering education, but I've taken it upon myself to call out people with strong opinions about things they don't understand.
Nonsense. I conceded that morons may actually go through the work to totally break their PMTUD, IP error signaling channels, and make their nodes "invisible"
I understand "networking" at a level I'm pretty sure you only have a foggy understanding of.
I write applications that require layer-2 packet building all the way up to layer-4.
In short, he's a moron. I have reason to suspect you might be, too.
Let me make sure I understand you.
If my car now has an electric motor, but I can't make my old gasoline motor dash make much sense with it... My electric motor is the problem?
The 'new' tools turn turn 22 this year.
I first starting using them for LARTC about a decade ago, and was first *forced* to use them in RHEL7. Since then, I use them exclusively now. It's easier than trying to remember the idiosyncrasies of net-tools that give you straight up bad information on machines that may have complicated network configurations running on them.
Initially, I installed net-tools on every RHEL7 machine I deployed. I think I probably did that for a month. The last 40 or so are all net-tools free.
Nope. Distributions are removing them (RHEL7) because they've spent the last 20 years migrating over to iproute2 as net-tools became more and more antiquated, inaccurate, and irrelevant.
In case you're curious:
iproute (961225-1) unstable; urgency=low
As has been the case since about 1996. You had time to learn.
That aside, net-tools is still installable in every distribution that no longer installs it by default.
These "new" commands are, I hope, older than most of the asshole commenting on this thread.
If they aren't, then we're forced to face the simple fact that one of the most Linux-savvy technical commentary sites (or so I thought) is actually populated by people who have no fucking idea what they're doing, and are seemingly unaware of that fact.
iproute (and then iproute2) has been in development, and included in all major distributions since the mid 90s.
Over time, distribution ifup/ifdown architectures have been slowly moving their functionality over to it, for obvious reasons (RTNL interface is easier to extend than the bullshit IOCTL/proc interface that net-tools use, thus iproute/iproute2 was maintained and extended to use newer features of the OS, while net-tools were not)
These commands aren't new, a lot of people just didn't know that the replacement was happening beneath them while they played with their familiar lego blocks.
LOL. These 'new' commands have been in every major linux distro for almost 20 years.
What's wrong with just adding newer commands and leaving the old ones? Nothing. That's exactly what was done. After a couple of decades, some distributions have decided to stop including the old ones, because they're deprecated, show wrong and/or incomplete information, and don't even present a model that accurately represents the reality of the network stack.
Someone cared enough to implement an entirely different tool to do the same old jobs plus some new stuff, it's too bad they didn't do the sane thing and add that functionality to the old tool where it would have made sense.
It's not that simple. The iproute2 suite wasn't written to *replace* anything.
It was written to provide a user interface to the rapidly expanding RTNL API.
The net-tools maintainers (or anyone who cared) could have started porting it if they liked. They didn't. iproute2 kept growing to provide access to all the new RTNL interfaces, while net-tools got farther and farther behind. What happened was organic. If someone brought net-tools up to date tomorrow and everyone liked the interface, iproute2 would be dead in its tracks. As it sits, myself, and most of the more advanced level system and network engineers I know have been using iproute2 for just over a decade now (really, the point where ifconfig became on incomplete and poorly simplified way to manage the networking stack)
You can unlink() a socket.... as long as it's an AF_UNIX socket with a VFS entry....
Stop and think about what you wrote, though...
before I can even think of calling read(2) or write(2)?
Allow me to paraphrase:
before I can even think of calling the standard file descriptor access calls?
"Everything is a file" was *never* universally true in any POSIX compliant system in existence. It couldn't be. But it's mostly true in a lot of contexts.
That's hilarious...
I am *the guy* who runs the network. I am our senior network engineer. Every line in every router- mine.
You have no idea what you're talking about, at any level. "disabled ICMP"- state statement alone requires such ignorance to make that I'm not sure why I'm even replying to ignorant ass.
The network is the wrong layer for security, application availability, isolation and management regimes.
There is both truth, and utter fallacy in this statement. What's worse, is it belies complete ignorance to the topic at hand.
These things can all be handled more effectively in a more application appropriate manner at higher layers.
No, I'm sorry. Network isolation is not better handled at a 'more application appropriate manner' at higher layers.
I think you're speaking for a very application-centric viewpoint, with no idea how data actually gets to you.
I operate a carrier-grade network. As much as I wish all the idiosyncrasies of modern internet traffic and applications allowed for simple routing paradigms, they simply do not.
As we have seen with containers supplanting virtual machines, rise of E2E security, application controlled overlays and supplanting of VPNs the transition is already well underway.
We have seen containers filling in a niche that VMs never did suit very well. They are nowhere fuuuuuucking close to supplanting them, for the same reason. You can't use a container to replace the cases where you need a VM.
supplanting of VPNs
The hell? Most application-layer networks are almost purely virtual now (traveling over things like PBR and VRF substrates).
You can continue to build castle walls, fill the motes with alligators and police your cobblestone roads to your hearts desire but don't pretend there is any future in it.
None of that has anything to do with the reasons those things exist. It's about building a more elegant and capable transport network. Again, I don't think you're employed in the industry that deals with very complicated requirements. I'm jealous. At the same time, I'm not sure I could live with taking a 50% cut in salary and going back to lower-level network engineering.
PBR/VRF are right up there with systems virtualization as band-aids to side step much deeper architectural deficiencies. Complexity in the network is something to be embarrassed about not celebrated.
LOL. I'm unsure how to respond to this. You sir, are Not Even Wrong.
Definitely. There is no need for fiber optic, and in fact, being you can do multi-lane (QAM) easier (cheaper) than you can over fiber, copper is a superior solution in this regime anyway. As long as you don't need to go long distance- copper is the way.
A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not
They work fine as long as you have a very simple network configuration.
They do not work at all if you need vrf, policy routing, seperately scoped addresses, alias addresses (not the same thing as an alias interface)
If you get modded down, it's because you're ignorant and you don't know it, not because you're speaking the truth to power.
No. Much longer ago than that. I first starting using the iproute/iproute2 tools in 2008 or so when it became necessary to start utilizing linux for advanced routing in my workplace. It was already old then.
TFA is full of shit.
IP aliases have always and still do appear in ifconfig as separate logical interfaces.
No, you're just ignorant.
Aliases do not appear in ifconfig as separate logical interfaces.
Logical interfaces appear in ifconfig as logical interfaces.
Logical interfaces are one way to add an alias to an interface. A crude way, but a way.
The assertion ifconfig only displays one IP address per interface also demonstrably false.
Nope. Again, your'e just ignorant.
root@swalker-samtop:~# tunctl
Set 'tap0' persistent and owned by uid 0
root@swalker-samtop:~# ifconfig tap0 10.10.10.1 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.10.2/24 dev tap0
root@swalker-samtop:~# ifconfig tap0:0 10.10.10.3 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.1.1/24 scope link dev tap0:0
root@swalker-samtop:~# ifconfig tap0 | grep inet
inet 10.10.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
root@swalker-samtop:~# ifconfig tap0:0 | grep inet
inet 10.10.10.3 netmask 255.255.255.0 broadcast 10.10.10.255
root@swalker-samtop:~# ip addr show dev tap0 | grep inet
inet 10.10.1.1/24 scope link tap0
inet 10.10.10.1/24 brd 10.10.10.255 scope global tap0
inet 10.10.10.2/24 scope global secondary tap0
inet 10.10.10.3/24 brd 10.10.10.255 scope global secondary tap0:0
If you don't understand what the differences are, you really aren't qualified to opine on the matter.
Ifconfig is fundamentally incapable of displaying the amount of information that can go with layer-3 addresses, interfaces, and the architecture of the stack in general. This is why iproute2 exists.
iproute2 exists because ifconfig, netstat, and route do not support the full capabilities of the linux network stack.
This is because today's network stack is far more complicated than it was in the past. For very simple networks, the old tools work fine. For complicated ones, you must use the new ones.
Your post could not be any more wrong. Your moderation amazes me. It seems that slashdot is full of people who are mostly amateurs.
iproute2 has been the main network management suite for linux amongst higher end sysadmins for a decade. It wasn't written to sate someone's desire to change for the sake of change, to make more complicated, to NIH. It was written because the old tools can't encompass new functionality without being rewritten themselves.
Slashdot Mirror
PBR/VRF are right up there with systems virtualization as band-aids to side step much deeper architectural deficiencies. Complexity in the network is something to be embarrassed about not celebrated.
Is not an argument. It's an unsubstantiated opinion. The world would be a better place if you knew the difference, and people like me would bother trying to put out light rather than heat. I wasn't brought upon this earth to be an idiot's network engineering education, but I've taken it upon myself to call out people with strong opinions about things they don't understand.
Nonsense. I conceded that morons may actually go through the work to totally break their PMTUD, IP error signaling channels, and make their nodes "invisible"
I understand "networking" at a level I'm pretty sure you only have a foggy understanding of.
I write applications that require layer-2 packet building all the way up to layer-4.
In short, he's a moron. I have reason to suspect you might be, too.
Let me make sure I understand you.
If my car now has an electric motor, but I can't make my old gasoline motor dash make much sense with it... My electric motor is the problem?
If nothing else, I admire your persistence. I've got a cabin for sale on Walden Pond if you're interested?
The 'new' tools turn turn 22 this year.
I first starting using them for LARTC about a decade ago, and was first *forced* to use them in RHEL7. Since then, I use them exclusively now. It's easier than trying to remember the idiosyncrasies of net-tools that give you straight up bad information on machines that may have complicated network configurations running on them.
Initially, I installed net-tools on every RHEL7 machine I deployed. I think I probably did that for a month. The last 40 or so are all net-tools free.
Nope. Distributions are removing them (RHEL7) because they've spent the last 20 years migrating over to iproute2 as net-tools became more and more antiquated, inaccurate, and irrelevant.
In case you're curious:
iproute (961225-1) unstable; urgency=low
* Initial Release.
-- Tom Lees Mon, 30 Dec 1996 11:12:23 +0000
As has been the case since about 1996. You had time to learn.
That aside, net-tools is still installable in every distribution that no longer installs it by default.
No. Fucking. Shit.
This article commentary blows me away. I had no idea the level of Linux ignorance on this site was this damn high.
These "new" commands are, I hope, older than most of the asshole commenting on this thread.
If they aren't, then we're forced to face the simple fact that one of the most Linux-savvy technical commentary sites (or so I thought) is actually populated by people who have no fucking idea what they're doing, and are seemingly unaware of that fact.
iproute (and then iproute2) has been in development, and included in all major distributions since the mid 90s.
Over time, distribution ifup/ifdown architectures have been slowly moving their functionality over to it, for obvious reasons (RTNL interface is easier to extend than the bullshit IOCTL/proc interface that net-tools use, thus iproute/iproute2 was maintained and extended to use newer features of the OS, while net-tools were not)
These commands aren't new, a lot of people just didn't know that the replacement was happening beneath them while they played with their familiar lego blocks.
LOL. These 'new' commands have been in every major linux distro for almost 20 years.
What's wrong with just adding newer commands and leaving the old ones? Nothing. That's exactly what was done. After a couple of decades, some distributions have decided to stop including the old ones, because they're deprecated, show wrong and/or incomplete information, and don't even present a model that accurately represents the reality of the network stack.
You've already lost.. Sorry, chief.
Spot on.
Someone cared enough to implement an entirely different tool to do the same old jobs plus some new stuff, it's too bad they didn't do the sane thing and add that functionality to the old tool where it would have made sense.
It's not that simple. The iproute2 suite wasn't written to *replace* anything.
It was written to provide a user interface to the rapidly expanding RTNL API.
The net-tools maintainers (or anyone who cared) could have started porting it if they liked. They didn't. iproute2 kept growing to provide access to all the new RTNL interfaces, while net-tools got farther and farther behind.
What happened was organic. If someone brought net-tools up to date tomorrow and everyone liked the interface, iproute2 would be dead in its tracks. As it sits, myself, and most of the more advanced level system and network engineers I know have been using iproute2 for just over a decade now (really, the point where ifconfig became on incomplete and poorly simplified way to manage the networking stack)
It all runs on emacs anyway.
There are pretty credible theories that this assertion remains true all the way to the scale of the Universe.
Stop and think about what you wrote, though...
before I can even think of calling read(2) or write(2)?
Allow me to paraphrase:
before I can even think of calling the standard file descriptor access calls?
"Everything is a file" was *never* universally true in any POSIX compliant system in existence. It couldn't be. But it's mostly true in a lot of contexts.
Is it a binary JSON, a binary XML, is it ProtocolBuffers?
LOL. Kids.
We're so fucked if all the OS architects die tomorrow.
That's hilarious...
I am *the guy* who runs the network. I am our senior network engineer. Every line in every router- mine.
You have no idea what you're talking about, at any level. "disabled ICMP"- state statement alone requires such ignorance to make that I'm not sure why I'm even replying to ignorant ass.
The network is the wrong layer for security, application availability, isolation and management regimes.
There is both truth, and utter fallacy in this statement. What's worse, is it belies complete ignorance to the topic at hand.
These things can all be handled more effectively in a more application appropriate manner at higher layers.
No, I'm sorry. Network isolation is not better handled at a 'more application appropriate manner' at higher layers.
I think you're speaking for a very application-centric viewpoint, with no idea how data actually gets to you.
I operate a carrier-grade network. As much as I wish all the idiosyncrasies of modern internet traffic and applications allowed for simple routing paradigms, they simply do not.
As we have seen with containers supplanting virtual machines, rise of E2E security, application controlled overlays and supplanting of VPNs the transition is already well underway.
We have seen containers filling in a niche that VMs never did suit very well. They are nowhere fuuuuuucking close to supplanting them, for the same reason. You can't use a container to replace the cases where you need a VM.
supplanting of VPNs
The hell? Most application-layer networks are almost purely virtual now (traveling over things like PBR and VRF substrates).
You can continue to build castle walls, fill the motes with alligators and police your cobblestone roads to your hearts desire but don't pretend there is any future in it.
None of that has anything to do with the reasons those things exist. It's about building a more elegant and capable transport network. Again, I don't think you're employed in the industry that deals with very complicated requirements. I'm jealous. At the same time, I'm not sure I could live with taking a 50% cut in salary and going back to lower-level network engineering.
PBR/VRF are right up there with systems virtualization as band-aids to side step much deeper architectural deficiencies. Complexity in the network is something to be embarrassed about not celebrated.
LOL. I'm unsure how to respond to this. You sir, are Not Even Wrong.
Definitely. There is no need for fiber optic, and in fact, being you can do multi-lane (QAM) easier (cheaper) than you can over fiber, copper is a superior solution in this regime anyway. As long as you don't need to go long distance- copper is the way.
A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not
They work fine as long as you have a very simple network configuration.
They do not work at all if you need vrf, policy routing, seperately scoped addresses, alias addresses (not the same thing as an alias interface)
If you get modded down, it's because you're ignorant and you don't know it, not because you're speaking the truth to power.
No. Much longer ago than that. I first starting using the iproute/iproute2 tools in 2008 or so when it became necessary to start utilizing linux for advanced routing in my workplace. It was already old then.
He is. Ignorance masqueraded as condescending authority. The commentary on this article is fucking full of it.
TFA is full of shit. IP aliases have always and still do appear in ifconfig as separate logical interfaces.
No, you're just ignorant.
Aliases do not appear in ifconfig as separate logical interfaces.
Logical interfaces appear in ifconfig as logical interfaces.
Logical interfaces are one way to add an alias to an interface. A crude way, but a way.
The assertion ifconfig only displays one IP address per interface also demonstrably false.
Nope. Again, your'e just ignorant.
root@swalker-samtop:~# tunctl
Set 'tap0' persistent and owned by uid 0
root@swalker-samtop:~# ifconfig tap0 10.10.10.1 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.10.2/24 dev tap0
root@swalker-samtop:~# ifconfig tap0:0 10.10.10.3 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.1.1/24 scope link dev tap0:0
root@swalker-samtop:~# ifconfig tap0 | grep inet
inet 10.10.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
root@swalker-samtop:~# ifconfig tap0:0 | grep inet
inet 10.10.10.3 netmask 255.255.255.0 broadcast 10.10.10.255
root@swalker-samtop:~# ip addr show dev tap0 | grep inet
inet 10.10.1.1/24 scope link tap0
inet 10.10.10.1/24 brd 10.10.10.255 scope global tap0
inet 10.10.10.2/24 scope global secondary tap0
inet 10.10.10.3/24 brd 10.10.10.255 scope global secondary tap0:0
If you don't understand what the differences are, you really aren't qualified to opine on the matter.
Ifconfig is fundamentally incapable of displaying the amount of information that can go with layer-3 addresses, interfaces, and the architecture of the stack in general. This is why iproute2 exists.
iproute2 exists because ifconfig, netstat, and route do not support the full capabilities of the linux network stack.
This is because today's network stack is far more complicated than it was in the past. For very simple networks, the old tools work fine. For complicated ones, you must use the new ones.
Your post could not be any more wrong. Your moderation amazes me. It seems that slashdot is full of people who are mostly amateurs.
iproute2 has been the main network management suite for linux amongst higher end sysadmins for a decade. It wasn't written to sate someone's desire to change for the sake of change, to make more complicated, to NIH. It was written because the old tools can't encompass new functionality without being rewritten themselves.