Route is not deleted
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I have a machine with Ubuntu 18.04.
with the following /etc/network/interfaces
auto ens160
iface ens160 inet static
address 10.16.21.80
gateway 10.16.21.254
netmask 255.255.255.0
dns-nameservers 10.16.15.1 10.16.15.2 127.0.0.53
dns-search eqx.solaredge.com
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
Each time when I restart the machine the routing of 10.16.15.0
is back to the routing table and I have to delete it manually. Is there another way to disable this route permanently?
I'm running the following command each time:
route del -net 10.16.15.0 netmask 255.255.255.0
I use /etc/rc.local
for one machine to run this command for each startup but I wonder if there is some other way.
networking server 18.04
add a comment |
I have a machine with Ubuntu 18.04.
with the following /etc/network/interfaces
auto ens160
iface ens160 inet static
address 10.16.21.80
gateway 10.16.21.254
netmask 255.255.255.0
dns-nameservers 10.16.15.1 10.16.15.2 127.0.0.53
dns-search eqx.solaredge.com
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
Each time when I restart the machine the routing of 10.16.15.0
is back to the routing table and I have to delete it manually. Is there another way to disable this route permanently?
I'm running the following command each time:
route del -net 10.16.15.0 netmask 255.255.255.0
I use /etc/rc.local
for one machine to run this command for each startup but I wonder if there is some other way.
networking server 18.04
add a comment |
I have a machine with Ubuntu 18.04.
with the following /etc/network/interfaces
auto ens160
iface ens160 inet static
address 10.16.21.80
gateway 10.16.21.254
netmask 255.255.255.0
dns-nameservers 10.16.15.1 10.16.15.2 127.0.0.53
dns-search eqx.solaredge.com
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
Each time when I restart the machine the routing of 10.16.15.0
is back to the routing table and I have to delete it manually. Is there another way to disable this route permanently?
I'm running the following command each time:
route del -net 10.16.15.0 netmask 255.255.255.0
I use /etc/rc.local
for one machine to run this command for each startup but I wonder if there is some other way.
networking server 18.04
I have a machine with Ubuntu 18.04.
with the following /etc/network/interfaces
auto ens160
iface ens160 inet static
address 10.16.21.80
gateway 10.16.21.254
netmask 255.255.255.0
dns-nameservers 10.16.15.1 10.16.15.2 127.0.0.53
dns-search eqx.solaredge.com
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
Each time when I restart the machine the routing of 10.16.15.0
is back to the routing table and I have to delete it manually. Is there another way to disable this route permanently?
I'm running the following command each time:
route del -net 10.16.15.0 netmask 255.255.255.0
I use /etc/rc.local
for one machine to run this command for each startup but I wonder if there is some other way.
networking server 18.04
networking server 18.04
edited Apr 7 at 10:59
vidarlo
10.9k52852
10.9k52852
asked Apr 7 at 7:47
Gidi KalefGidi Kalef
1
1
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You have a interface in the 10.16.15.0/24 net.
By default Linux will add a route to any local interfaces. How do you expect to contact devices on your 10.16.15.0/24 segment if you do not have a route for it? Do you want traffic to 10.16.15.0/24 to go via 10.16.21.254?
If so, simply remove the interface description for auto ens160:235
.
The section to remove would be
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
To expand the answer a bit.
When you want to send a packet to an address, your OS looks in its routing table. Commonly, the routing table consists of two entries: your local subnet, that's reachable directly, and a default gateway. It may contain any number of routes however.
Routes carry a weight, commonly known as metric. This can be seen in sample output below:
default via 10.0.3.1 dev wlan0 proto dhcp metric 600
10.0.3.0/24 dev wlan0 proto kernel scope link src 10.0.3.48 metric 600
Routes are selected on basis most specific route, and if two equal routes exists, the lowest metric is preferred. The default route is really 0.0.0.0/0, so it is as unspecific as you get with IPv4. This means that this is a route of last resort, if no other routes match!
You have a directly connected interface, with a netmask of /24, or 255.255.255.0. This is way more specific than a netmask of /0, so regardless of weight, it will win. Traffic destined for 10.16.15.0/24 will be sent directly on the ens160:235
interface, without any routing.
This is probably the behavior you want. If you attach a host to a L2 network segment, it's because you want that host to communicate with other hosts on the same segment, without the overhead of routing.
If you do not want this behavior, I suggest that you explain why you do not want it. It is a non-standard solution, so it may require scripting. The proper way to do that is to call the script or command when the interface is up.
But again, that is probably not what you want.
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
|
show 3 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1131813%2froute-is-not-deleted%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You have a interface in the 10.16.15.0/24 net.
By default Linux will add a route to any local interfaces. How do you expect to contact devices on your 10.16.15.0/24 segment if you do not have a route for it? Do you want traffic to 10.16.15.0/24 to go via 10.16.21.254?
If so, simply remove the interface description for auto ens160:235
.
The section to remove would be
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
To expand the answer a bit.
When you want to send a packet to an address, your OS looks in its routing table. Commonly, the routing table consists of two entries: your local subnet, that's reachable directly, and a default gateway. It may contain any number of routes however.
Routes carry a weight, commonly known as metric. This can be seen in sample output below:
default via 10.0.3.1 dev wlan0 proto dhcp metric 600
10.0.3.0/24 dev wlan0 proto kernel scope link src 10.0.3.48 metric 600
Routes are selected on basis most specific route, and if two equal routes exists, the lowest metric is preferred. The default route is really 0.0.0.0/0, so it is as unspecific as you get with IPv4. This means that this is a route of last resort, if no other routes match!
You have a directly connected interface, with a netmask of /24, or 255.255.255.0. This is way more specific than a netmask of /0, so regardless of weight, it will win. Traffic destined for 10.16.15.0/24 will be sent directly on the ens160:235
interface, without any routing.
This is probably the behavior you want. If you attach a host to a L2 network segment, it's because you want that host to communicate with other hosts on the same segment, without the overhead of routing.
If you do not want this behavior, I suggest that you explain why you do not want it. It is a non-standard solution, so it may require scripting. The proper way to do that is to call the script or command when the interface is up.
But again, that is probably not what you want.
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
|
show 3 more comments
You have a interface in the 10.16.15.0/24 net.
By default Linux will add a route to any local interfaces. How do you expect to contact devices on your 10.16.15.0/24 segment if you do not have a route for it? Do you want traffic to 10.16.15.0/24 to go via 10.16.21.254?
If so, simply remove the interface description for auto ens160:235
.
The section to remove would be
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
To expand the answer a bit.
When you want to send a packet to an address, your OS looks in its routing table. Commonly, the routing table consists of two entries: your local subnet, that's reachable directly, and a default gateway. It may contain any number of routes however.
Routes carry a weight, commonly known as metric. This can be seen in sample output below:
default via 10.0.3.1 dev wlan0 proto dhcp metric 600
10.0.3.0/24 dev wlan0 proto kernel scope link src 10.0.3.48 metric 600
Routes are selected on basis most specific route, and if two equal routes exists, the lowest metric is preferred. The default route is really 0.0.0.0/0, so it is as unspecific as you get with IPv4. This means that this is a route of last resort, if no other routes match!
You have a directly connected interface, with a netmask of /24, or 255.255.255.0. This is way more specific than a netmask of /0, so regardless of weight, it will win. Traffic destined for 10.16.15.0/24 will be sent directly on the ens160:235
interface, without any routing.
This is probably the behavior you want. If you attach a host to a L2 network segment, it's because you want that host to communicate with other hosts on the same segment, without the overhead of routing.
If you do not want this behavior, I suggest that you explain why you do not want it. It is a non-standard solution, so it may require scripting. The proper way to do that is to call the script or command when the interface is up.
But again, that is probably not what you want.
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
|
show 3 more comments
You have a interface in the 10.16.15.0/24 net.
By default Linux will add a route to any local interfaces. How do you expect to contact devices on your 10.16.15.0/24 segment if you do not have a route for it? Do you want traffic to 10.16.15.0/24 to go via 10.16.21.254?
If so, simply remove the interface description for auto ens160:235
.
The section to remove would be
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
To expand the answer a bit.
When you want to send a packet to an address, your OS looks in its routing table. Commonly, the routing table consists of two entries: your local subnet, that's reachable directly, and a default gateway. It may contain any number of routes however.
Routes carry a weight, commonly known as metric. This can be seen in sample output below:
default via 10.0.3.1 dev wlan0 proto dhcp metric 600
10.0.3.0/24 dev wlan0 proto kernel scope link src 10.0.3.48 metric 600
Routes are selected on basis most specific route, and if two equal routes exists, the lowest metric is preferred. The default route is really 0.0.0.0/0, so it is as unspecific as you get with IPv4. This means that this is a route of last resort, if no other routes match!
You have a directly connected interface, with a netmask of /24, or 255.255.255.0. This is way more specific than a netmask of /0, so regardless of weight, it will win. Traffic destined for 10.16.15.0/24 will be sent directly on the ens160:235
interface, without any routing.
This is probably the behavior you want. If you attach a host to a L2 network segment, it's because you want that host to communicate with other hosts on the same segment, without the overhead of routing.
If you do not want this behavior, I suggest that you explain why you do not want it. It is a non-standard solution, so it may require scripting. The proper way to do that is to call the script or command when the interface is up.
But again, that is probably not what you want.
You have a interface in the 10.16.15.0/24 net.
By default Linux will add a route to any local interfaces. How do you expect to contact devices on your 10.16.15.0/24 segment if you do not have a route for it? Do you want traffic to 10.16.15.0/24 to go via 10.16.21.254?
If so, simply remove the interface description for auto ens160:235
.
The section to remove would be
auto ens160:235
iface ens160:235 inet static
address 10.16.15.235
netmask 255.255.255.0
To expand the answer a bit.
When you want to send a packet to an address, your OS looks in its routing table. Commonly, the routing table consists of two entries: your local subnet, that's reachable directly, and a default gateway. It may contain any number of routes however.
Routes carry a weight, commonly known as metric. This can be seen in sample output below:
default via 10.0.3.1 dev wlan0 proto dhcp metric 600
10.0.3.0/24 dev wlan0 proto kernel scope link src 10.0.3.48 metric 600
Routes are selected on basis most specific route, and if two equal routes exists, the lowest metric is preferred. The default route is really 0.0.0.0/0, so it is as unspecific as you get with IPv4. This means that this is a route of last resort, if no other routes match!
You have a directly connected interface, with a netmask of /24, or 255.255.255.0. This is way more specific than a netmask of /0, so regardless of weight, it will win. Traffic destined for 10.16.15.0/24 will be sent directly on the ens160:235
interface, without any routing.
This is probably the behavior you want. If you attach a host to a L2 network segment, it's because you want that host to communicate with other hosts on the same segment, without the overhead of routing.
If you do not want this behavior, I suggest that you explain why you do not want it. It is a non-standard solution, so it may require scripting. The proper way to do that is to call the script or command when the interface is up.
But again, that is probably not what you want.
edited Apr 7 at 10:56
answered Apr 7 at 8:26
vidarlovidarlo
10.9k52852
10.9k52852
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
|
show 3 more comments
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
Yes, i except the traffic go via 10.16.21.254 , i create the change by network layer, you think just i have to delete the description line and it will be fixes?
– Gidi Kalef
Apr 7 at 9:36
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
@GidiKalef Updated my answer with what to remove. By default the most specific route wins, and a directly connected subnet is more specific than a default route. It thus has a lower cost and will be preferred.
– vidarlo
Apr 7 at 9:51
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
but i still need to use this interface if i will remove it , it will be missing and i need to assign a interface in this network
– Gidi Kalef
Apr 7 at 10:08
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
Why do you need to use this interface, if you will reach this subnet via a router? Your comments are self-contradictory, and either there's something you're not telling us, or there's something you're not understanding.
– vidarlo
Apr 7 at 10:19
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
This vip used for docker, on the same machine but the docker using a different network
– Gidi Kalef
Apr 7 at 12:20
|
show 3 more comments
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1131813%2froute-is-not-deleted%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown