 Hello, I'm Phil. I'm working for Red Hat and today I would like to elaborate a bit on the question, why should you use IP route 2? Or in detail, should you at all? So, what is IP route 2 about? It's mostly famous, the IP utility, which many of you know about, but there's actually more that comes with the package. We have a replacement for net start, which is called SS, a bit of a bad name for German. There are a bunch of statistics utilities, like obviously there weren't enough statistics already. We have some obscurity utility, which does things with bridges, but it's not exactly replacement to bridge utilities. We have the famous TC, everyone doing QoS probably had to deal with it. And yeah, there's some minor stuff like this transparent IPC configuration utility. I personally didn't use. And obviously there are many more, which I have no idea if they are used at all or just dinosaurs from for in time. I will in this talk basically just cover the first three items, because the rest is beyond the scope. Okay, so general question. Do you really want to use this? And many of you would say you don't. And well, I got used to it, so I can't really answer this question why, but I did some research on the Internet and people were complaining and I tried to write together what they were complaining about. So the biggest issue is it's hard to learn, especially when your muscle memories remember the old stuff. And Manpage isn't exactly readable to people not perfectly used to BNF. In addition, it has a whole of 17 subcommands. So the IP main page is pretty overwhelming. You can, in order to reduce typing, you can abbreviate them, which means your friend who reads your history doesn't have an idea what you were doing. And sometimes you have to take care how you order the different parameters. It's not exactly get-hop. So to be precise, not at all. So it's not intuitive. Many people also said it's simply inconvenient. With if config, you could just set if config, eth0, IP address, and boom, you have your interface. With IP route, you have to add the IP address and then in addition, set it up. And when you list your interfaces, you don't see the statistics by default, so you don't see what it's doing. But in addition, you get all the disabled interfaces which many don't like or are not interested in. So, yeah. And which is kind of funny if you try to mess with your co-working Swiss admin, you can add IPv4 aliases which are not seen by if config, so you can play games with them. Further things. Output formatting is a big issue. It's like you're trying to display the routing table, but you don't see a table at all. It's just a number of messy lines. SS kind of goes the opposite way. It overdusts tabling, so you always get the full terminal width, no matter how wide your terminal is, and it still tends to break lines. Another thing I heard was IP route 2 is Linux specific. If config, net start, load, these are basically Unix commandos, so going to BSD or whatever, true 64, you can at least have an idea what you should look at. IP route 2 isn't existing there at all. And yeah, it's a bit cheating, but still you can't do everything with it. Yeah. Of course, I couldn't display my presentation using IP route. Not that I would want to, but still you have ETH tool and IW config. There's no support for wireless or hardware like that. So, yeah. Next up. Okay. To illustrate a bit, I have a number of questions for you. First one is, what does IPRS really stand for? We have route set, route show, route set, route show. The answer is IP route show. That was pretty obvious. So, we take the next simple example, IPLS. Is it L2TP set, show, link set, or link show? You're undecided? Okay. Let's see. It's IP link set. So, not exactly what you would expect. Next thing is, we're covering parameter ordering. I've colored the different parts of the parameters for you to easily recognize them. So, the link part is always red. Then we have green, the name, and blue, the type. Actually, only one of them is red. I know it's too hard. It's too hard. So, see what's the right answer. I'll explain this right now. So, I didn't write that code, luckily. But I can try to explain it a bit. At least, why things are like this. So, let's start with, let's start with parameter shortening. What IP route basically does is it calls a function which is called matches. And matches does just check is the parameter which you gave it shorter than what you have passed a second argument, or shorter or equal. So, it's not exceeding it. And then it compares only that part. So, if you, given this in a main function, and you pass f as arc v, then it will default to foo bar instead of feedback, simply because it comes first. And this is not intuitive because they are not alphabetically sorted. But it's like this in the code. So, you could always look up the code if you want to know what is the default. Okay. Now, ordering constraints, they are, they actually make sense. Although you wouldn't recognize if you don't know. The point is here that the type keyword actually, in secret, dispatches to type specific code. So, while the interface name and the link parameter which says which interface to link this interface name to belongs to the generic IP, and the ID is a parameter which belongs to the VLAN specific code. So, that's why you have to order it like this. And once you know it, the previous question can simply be answered. Okay. SS output formatting. I try to fix this, and it's not so easy. The problem is that it's not so easy. It supports unix sockets. Unix sockets are just a file, and it displays the whole path. So, you can't say, okay, it's at max 128 bits in IPv6 notation, but it could be any path named with arbitrary length. So, it just tries to use the maximum space available so it can display them. It uses, well, it finds out how wide the terminal is, and then just expands the columns. And it tries to separate this all from extended socket info by inserting a bit of spaces. So, the extended data gets forced into the next line. Not with a new line, but just because it's too wide, and it knows how wide the terminal is. In addition to that, some extended info is still prefixed by a new line character. So, if you have a small terminal, you type a command, and you maximize it, this won't go in one line. So, that's just how it is, and let's see if something can be done about it in the future. So, still, I think you should use APROT, and this is how. We have, well, we have, well, we have lots of tools which are being deprecated or replaced by APROT. Yeah, the obvious ones, of course. In addition to that, you can do the full VLAN device management with it. You can manage Ethernet bridges, bonding configuration, Tantab interfaces. You can set IPsec parameters, security associations, and policies. You can control the neighbor cache also of IPv6. So, I don't know if there's a dedicated tool for that. You can do multicast address management with it. Various IP tunnels, there are a dozen of them also, and interface renaming, which is usually done either by Namev or by Udev, or SystemD, I don't know. You can do it with IPROT too. Okay, it supports a wide variety of interface types. There are definitely more than this, but those are only, well, not even all, but those are those for which you have type-specific code. So, like for the VLAN interfaces, the ID parameter, stuff like that. I don't list MACSEC interfaces here, because as far as I know, it's not yet upstream, but yeah, apart from that, I guess pretty much everything is meanwhile implemented in IPROT tool, and there are no dedicated tools anymore for newer device types, which get added to the kernel, and therefore, the default is IPROT. You can have, well, documentation is not as clear, but there is link-specific helps. So, if you use IP link hub, with all the code parameter, it will show you generic options, and in addition to that, the number of a list of interface names, or type names, which it supports, and passing it the type, you should get type-specific help texts. You should, because on Red 7 it's not there yet, but it's in the process. Okay, so IP address is better than if config. A few examples, you don't need to have IP aliases to have multiple IPv4 addresses per interface. You can select devices by giving a selector, and, well, it displays peer addresses. This is just something that if config doesn't know about or isn't able to. Below is an example of this. So, what I did was I wanted to show the addresses of ETH0, which go to the subnet, and as you see it prints me three different addresses in a subnet, actually, which is quite fine. I could also skip away the device parameter, so I get all addresses which the host has to the subnet for every address. And the second example shows a peer address, so it's basically point-to-point. There is more info, like, for example, the dynamic keyword, which shows that this interface, that this address was added by DHCP, and the last line shows a label, ETH0.colon1, which is compatibility mode for if config. So, if config will then show you an ETH0.colon1 with this IP address. Next one, IP route, which supersedes route by supporting policy routing, which of course goes hand-in-hand with multiple routing tables. You can, just like with IP address, look up routes selectively. You can save and restore routes, just like you can do with, for example, IP tables. I have no idea. I think maybe. Because I couldn't mention that you just have the kernel done the whole route, the whole routing table. That would be atomic, kind of, and I'm not sure how the kernel implements this. And it might be possible that you can add several routes at once, so the restore would be the same way. But I would have to check the code for that. In addition to that, IP route supports extended features and flags, which I couldn't find in route documentation. It might be wrong. I don't use it for a very long time now. I have some examples here as well, like showing a route for the subnet. I guess it has to be exact with the show command, and it shows me which source address will then be used. In addition to that, there is a get command, which shows me if I wanted to route a packet to this destination IP, which way would the kernel choose? And that's pretty neat. So it shows me that this IP goes on to ETH0 with this source address and cache. You can try that later. It's a good idea, so I know what I do. Okay. The last line just shows a pretty useless example of how to save and restore. So save just writes binary data to send it out, and IP route restore reads binary data from send it in. So you can use this to do stuff that doesn't make sense, but you can also redirect it into... What is IPv6? I might be wrong, but I would guess that IP route simply outputs the v4 routing table, because usually when using IP route, you have to specify minus 6 explicitly, so you get IPv6 routes. It could be that this is IP version agnostic, but I doubt so. I guess you would have to do the same for IPv6 as well. Okay. Why is SS better than net start? Although you wouldn't expect. In addition to the well known socket formats, it displays also netlink and packet sockets. It has a built-in socket filter, which makes the ungrapable output a little bit more grabable by having a built-in grab. It uses the netlink DRG interface, but it can fall back to procfs, which is used by netstart. This in particularly allows it to display lots more information about the socket than procfs does. And below is an example. So I filter for established sockets with a source port lower or equal to 1024. And by surprise, I have an example of a socket that is only the SSH connection I have to this machine. I see which user there is with PID and which FD number that is. I see, for example, TCP info, like the congestion control mechanism, which has been used, and stuff like the maximum segment size. So that's pretty nice. I have some bonus material for the case that I have too much time, like I guess I have. There is, for all of you who prefer if config just because of convenience, there is if CFG, which tries to do everything even a little bit better than if config. Maybe it overdoes it a bit, but it, of course, sets your link up. It performs duplicate address detection. You can use it like if config with IP alias notation and knows what to do. It sends unsolicited up replies. It adds some fancy routes. And it can even trigger router discovery for IPv6. Still, I'm not pretty sure this will, this is completely compatible to IPv6. So it might be that there are some hidden pitfalls. Okay, you have, there is a tool which allows you to list routes as tables. It's basically implemented as a shell wrapper. It lists IPv4 and IPv6 routes at the same time. Although you can't select them specifically. If, well, it supports the table, but if you choose the table to display, then it automatically displays only IPv4, which is pretty much a bug. And table formatting is still a bit broken because of that column choosing algorithm, which is not quite understandable and, well, not pretty well implemented. Another thing which I find very nice to do with IP route is listing network namespaces, which are, in case you're unfamiliar, is like a virtual network stack on your local host. You can move network interfaces into there, which are then limited to that scope. And you can run a process in there which only sees the network as it is represented by this network namespace. Very quick how-to, lots of commands. First line adds a network namespace named test and lists it. Second command adds a virtual Ethernet pair and automatically moves the VETH1 part into the test net and then two commands, lines 3 and 4, to contribute the interface and set it up. Lines 5 and 6 do the same to the local interface and that's all. Finally I can ping the other side. This allows me to do server client tests, for example, on a local machine without having to have some virtual machine or anything. Statistics, most importantly, and I guess not really well known, is LNSTAT, which is able to monitor everything that's within Prognet STAT. There are many files in there and the format is not really human readable. You can choose from which file, which key or which column you want to monitor and it supports running in iterations. So it's like with watch attached. To make things a little bit more convenient, there's a minus D parameter, which just prints what keys are presented in which file and an example usage is to iterate every two seconds and list the key or the column hits from the file up cache and entries from RT cache. There are more statistics using LNSTAT, these monitor different things, but the implementation is pretty much identical, which has the same box finally. It supports some demon mode, which is a bit unintuitive, that's why I have it here explicitly. So you start, for example, if STAT minus D10, so it will update its statistics every 10 seconds and this will fork into background and with if STAT minus S, you call the demon to dump the statistics. So although this watch command will update every two seconds by default, the data will only update every 10 seconds. Okay, hands on. Things will get funny right now. I heard one suggestion to look at what was that, routes dumping, so questions, how do we do this? Is it okay? So how do we interpret this? I have no idea actually. It's not ASCII format, otherwise you would see it on the right side. So that's binary, but I have an idea. I have those IPv6 routes, so I'll add an IPv6 address, have another IPv6 routing table entry and I can simply compare the output. This is cheating, you know. So probably it just updated the counters. I didn't show them before, did I? You see parameter ordering. Yeah, another way to tackle this. Oh, you finally see a difference. So I can't be completely sure, but I'd say this is limited to IPv4 and you have to specify minus 6 to have the IPv6 routing table. That's what we do. I could look at Ellenstart. This is the output you get from the minus D command. So you can basically choose what to dump here. That's basically the table format you get. That's as beautiful as it looks. Yes? By table? By table or by what? By type. Ah, by type. Yeah, it's problematic here because it's possible upstream, but not in REL7 yet. You could do something like this and it might also be a missing feature. So you can't list addresses by type, but you can list links by type and given the link, you can show the address by specifying the device. Yes? Sure, go ahead. Can you say a word or two about the relationship to Admin Manager because it basically has to stop there. Yeah, Network Manager is front end, I'd say, in regards of the relationship between both. And looking at, well, if you try to use both concurrently, you'll maybe run into issues. So Network Manager at least doesn't recognize what you're doing. And yeah, with Network Manager, you... The reason I'm asking is because I think with REL7 you supposed to use Network Manager. Yeah, but, well, just so much for this, I'm using IP route for testing in there and it's not like it's taking me the IP address away or something. So it doesn't interfere. Yeah, I don't do anything in Network Manager and as long as I don't do that, it's fine. I guess I have to try to hit you with this car. Any more questions? Not a question, but rather a proposal. No questions? From what I see, you are slowly implementing a skill like interface to Admin Manager. Perhaps it's time to consider the implement and SQL interface with your language within your set of tools. This sounds more practical rather than trying to implement your own version of your talk. Yeah, I mean, we could maybe implement a dual interface to REL2. Well, the scripted language, it's pretty famous and it's flexible. Well, that's probably interesting, but what the time to achieve or the time to resolve is easier to solve with SQL. Because what you're doing is to select from the same way. We got a new query language. Yeah. Our language is using proper languages for the task. Actually, maybe do this pretty simple by dumping the data, full data into a SQL database, and then currently that's okay. I really feel like throwing the scarf at you is wrong. Any other questions? I think I have a little bit to sort it out. Because the order of the interfaces is going to be very good. So I saved the output of the gateway address show, and removed the machine, and then the other one. The order is different. Yeah, I'll put real order input. Well, with the explanation, natively the output is ordered by interface index. Yes. And those change. It will be possible to sort by the name of the interface. Yeah, I have some option. But then the effort indexes will be different, so the word will be still different. So the names are present as well. Yeah, but the effort index is on the beginning of the line will be different. Yeah, but it doesn't matter if I sort of, if I, if the output in your index is ordered, if I want to sort by the name of the interface, so I don't understand what the name is. If you would sort by the name and do it in between the outputs, is it still actually not, and that the input index could have changed already, and there might be some other information which is slightly different for you? I don't want to cut you off, but before people leave, I would like to thank you. Here are some links to documentation, like main pages. Yeah, and you can leave feedback if you like, apart from that. Thanks for listening.