Why 169.254.0.0 appears by default in the routing table?












2















I defined a subnet on eth0 in /etc/network/interfaces with:



# interfaces(5) file used by ifup(8) and ifdown(8)  
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0


This subnet will be used to communicate to a Raspberry Pi connected on my ethernet port. Internet connection is not needed because already provided by wifi.



I was expecting my laptop to get the static ip address 192.168.1.1 when I run sudo ifup eth0 and it's the case. However, route -n shows:



Kernel IP routing table  
Destination Gateway Genmask Flags Metric Ref Use Iface
... (bunch of things) ...
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0



  1. Why do I have a 169.254.0.0 line?

  2. I believe it's unnecessary. How do I remove it?










share|improve this question

























  • Related serverfault.com/q/132657

    – Sergiy Kolodyazhnyy
    Aug 11 '15 at 22:43











  • Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

    – Shinagan
    Aug 12 '15 at 2:53











  • "However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

    – muru
    Aug 12 '15 at 3:14











  • Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

    – Shinagan
    Aug 12 '15 at 3:39
















2















I defined a subnet on eth0 in /etc/network/interfaces with:



# interfaces(5) file used by ifup(8) and ifdown(8)  
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0


This subnet will be used to communicate to a Raspberry Pi connected on my ethernet port. Internet connection is not needed because already provided by wifi.



I was expecting my laptop to get the static ip address 192.168.1.1 when I run sudo ifup eth0 and it's the case. However, route -n shows:



Kernel IP routing table  
Destination Gateway Genmask Flags Metric Ref Use Iface
... (bunch of things) ...
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0



  1. Why do I have a 169.254.0.0 line?

  2. I believe it's unnecessary. How do I remove it?










share|improve this question

























  • Related serverfault.com/q/132657

    – Sergiy Kolodyazhnyy
    Aug 11 '15 at 22:43











  • Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

    – Shinagan
    Aug 12 '15 at 2:53











  • "However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

    – muru
    Aug 12 '15 at 3:14











  • Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

    – Shinagan
    Aug 12 '15 at 3:39














2












2








2


1






I defined a subnet on eth0 in /etc/network/interfaces with:



# interfaces(5) file used by ifup(8) and ifdown(8)  
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0


This subnet will be used to communicate to a Raspberry Pi connected on my ethernet port. Internet connection is not needed because already provided by wifi.



I was expecting my laptop to get the static ip address 192.168.1.1 when I run sudo ifup eth0 and it's the case. However, route -n shows:



Kernel IP routing table  
Destination Gateway Genmask Flags Metric Ref Use Iface
... (bunch of things) ...
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0



  1. Why do I have a 169.254.0.0 line?

  2. I believe it's unnecessary. How do I remove it?










share|improve this question
















I defined a subnet on eth0 in /etc/network/interfaces with:



# interfaces(5) file used by ifup(8) and ifdown(8)  
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0


This subnet will be used to communicate to a Raspberry Pi connected on my ethernet port. Internet connection is not needed because already provided by wifi.



I was expecting my laptop to get the static ip address 192.168.1.1 when I run sudo ifup eth0 and it's the case. However, route -n shows:



Kernel IP routing table  
Destination Gateway Genmask Flags Metric Ref Use Iface
... (bunch of things) ...
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0



  1. Why do I have a 169.254.0.0 line?

  2. I believe it's unnecessary. How do I remove it?







networking ethernet static-ip






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 12 '15 at 3:12









muru

1




1










asked Aug 11 '15 at 22:37









ShinaganShinagan

13115




13115













  • Related serverfault.com/q/132657

    – Sergiy Kolodyazhnyy
    Aug 11 '15 at 22:43











  • Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

    – Shinagan
    Aug 12 '15 at 2:53











  • "However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

    – muru
    Aug 12 '15 at 3:14











  • Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

    – Shinagan
    Aug 12 '15 at 3:39



















  • Related serverfault.com/q/132657

    – Sergiy Kolodyazhnyy
    Aug 11 '15 at 22:43











  • Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

    – Shinagan
    Aug 12 '15 at 2:53











  • "However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

    – muru
    Aug 12 '15 at 3:14











  • Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

    – Shinagan
    Aug 12 '15 at 3:39

















Related serverfault.com/q/132657

– Sergiy Kolodyazhnyy
Aug 11 '15 at 22:43





Related serverfault.com/q/132657

– Sergiy Kolodyazhnyy
Aug 11 '15 at 22:43













Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

– Shinagan
Aug 12 '15 at 2:53





Agreed, but I don't have the /etc/sysconfig folder on Ubuntu. Would you know what is the equivalent?

– Shinagan
Aug 12 '15 at 2:53













"However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

– muru
Aug 12 '15 at 3:14





"However, route -n shows:..." Are you sure your route -n output didn't have this before you activated eth0?

– muru
Aug 12 '15 at 3:14













Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

– Shinagan
Aug 12 '15 at 3:39





Yes. If I do "sudo ifdown eth0" there is nothing relating to eth0 in the "route -n" output. Then if I do a "sudo ifup eth0", I have the two lines I mentioned.

– Shinagan
Aug 12 '15 at 3:39










3 Answers
3






active

oldest

votes


















4














From the quoted link:




If a DHCP client attempts to get an address, but fails to find a DHCP
server after the timeout and retries period it will randomly assume an
address from this network. This allows communication with hosts that
have failed to obtain a DHCP address.




However, your interfaces file requests a static IP address that is likely impossible, so no valid address was given.



192.168.1.1 is likely the address of the router or other access point to which you are attempting to connect. Therefore, the address will not be granted. Moreover, if you expect to connect to the internet, you will need to specify DNS nameservers. May I suggest:



# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 192.168.1.1


Of course verify the exact details before you proceed.



Restart the interface:



sudo ifdown eth0 && sudo ifup -v eth0


Check:



ping -c3 www.ubuntu.com





share|improve this answer



















  • 1





    The king of networking questions is back :)

    – Sergiy Kolodyazhnyy
    Aug 12 '15 at 0:32











  • Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

    – Shinagan
    Aug 12 '15 at 2:59











  • Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

    – chili555
    Aug 12 '15 at 11:18













  • If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

    – Shinagan
    Aug 12 '15 at 13:20






  • 1





    What about the 169.254.0.0?

    – detly
    Nov 29 '15 at 3:37



















2














Per RFC 3927 (emphasis mine):




To participate in wide-area IP networking, a host needs to be

configured with IP addresses for its interfaces, either manually by

the user or automatically from a source on the network such as a

Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,

such address configuration information may not always be available.

It is therefore beneficial for a host to be able to depend on a

useful subset of IP networking functions even when no address

configuration is available. This document describes how a host may

automatically configure an interface with an IPv4 address within the
169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.




So, to summarize, the 169.254/16 subnet was reserved to allow for communications between two physically (or logically, e.g. through a switch) connected devices without having to rely on DHCP or manual assignment of static IP addresses.



To quote the Wikipedia article on private networks,




If a host on an IEEE 802 (Ethernet) network cannot obtain a network
address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may
be assigned pseudorandomly.




As an example of its usage, say you have two embedded devices that need to communicate with one another via a direct Ethernet connection, but you want one or both devices to first look for DHCP so they also have the possibility of being connected into a local area network. When the devices are connected directly together and there is no DHCP available, the devices may use a protocol such as multicast DNS to discover each other automatically, but each device must first have some arbitrary IP address assigned so they can actually talk to each other over the Ethernet link. Thus, the operating system automatically assigns an IP address to the Ethernet device from the 169.254/16 network.





Now, as for why that route is there in the routing table by default...if you look at /etc/networks, you can see that the 'link-local' network is defined as being in this subnet:



$ cat /etc/networks
# symbolic names for networks, see networks(5) for more information
link-local 169.254.0.0


If you take this file's advice and check out man networks, you'll see:




This file is read by the route(8) and netstat(8) utilities.




So the route is created automatically on boot after route reads that file.





The route is only necessary if you plan to actually use link-local communications and don't want to assign a static IP address to the connected devices. But it doesn't do any harm to leave it in if you don't.



However, if you really want to remove it, you can do so with



sudo route del -net 169.254.0.0 gw 0.0.0.0


Or to remove it permanently, you should be able to just comment out its entry in /etc/networks and reboot.






share|improve this answer































    0














    As others have mentioned, 169.254.0.0 is present in your routing table because ifup is setting up the link-local network.



    To avoid this, consider using ifconfig instead of ifup.



    If necessary, run ifdown first.



    sudo ifdown eth0
    sudo ifconfig eth0 192.168.1.1


    ifconfig does less work and does not read /etc/network/interfaces.



    It should be possible to share internet access with the Pi. You need to turn on packet forwarding in the kernel on your laptop. I think this can be done without rebooting. I have done it in the past, but do not know how to do it off the top of my heard. This might help:



    How do I bridge network interfaces?






    share|improve this answer

























      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
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f660355%2fwhy-169-254-0-0-appears-by-default-in-the-routing-table%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      From the quoted link:




      If a DHCP client attempts to get an address, but fails to find a DHCP
      server after the timeout and retries period it will randomly assume an
      address from this network. This allows communication with hosts that
      have failed to obtain a DHCP address.




      However, your interfaces file requests a static IP address that is likely impossible, so no valid address was given.



      192.168.1.1 is likely the address of the router or other access point to which you are attempting to connect. Therefore, the address will not be granted. Moreover, if you expect to connect to the internet, you will need to specify DNS nameservers. May I suggest:



      # interfaces(5) file used by ifup(8) and ifdown(8)
      auto lo
      iface lo inet loopback

      auto eth0
      iface eth0 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 8.8.8.8 192.168.1.1


      Of course verify the exact details before you proceed.



      Restart the interface:



      sudo ifdown eth0 && sudo ifup -v eth0


      Check:



      ping -c3 www.ubuntu.com





      share|improve this answer



















      • 1





        The king of networking questions is back :)

        – Sergiy Kolodyazhnyy
        Aug 12 '15 at 0:32











      • Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

        – Shinagan
        Aug 12 '15 at 2:59











      • Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

        – chili555
        Aug 12 '15 at 11:18













      • If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

        – Shinagan
        Aug 12 '15 at 13:20






      • 1





        What about the 169.254.0.0?

        – detly
        Nov 29 '15 at 3:37
















      4














      From the quoted link:




      If a DHCP client attempts to get an address, but fails to find a DHCP
      server after the timeout and retries period it will randomly assume an
      address from this network. This allows communication with hosts that
      have failed to obtain a DHCP address.




      However, your interfaces file requests a static IP address that is likely impossible, so no valid address was given.



      192.168.1.1 is likely the address of the router or other access point to which you are attempting to connect. Therefore, the address will not be granted. Moreover, if you expect to connect to the internet, you will need to specify DNS nameservers. May I suggest:



      # interfaces(5) file used by ifup(8) and ifdown(8)
      auto lo
      iface lo inet loopback

      auto eth0
      iface eth0 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 8.8.8.8 192.168.1.1


      Of course verify the exact details before you proceed.



      Restart the interface:



      sudo ifdown eth0 && sudo ifup -v eth0


      Check:



      ping -c3 www.ubuntu.com





      share|improve this answer



















      • 1





        The king of networking questions is back :)

        – Sergiy Kolodyazhnyy
        Aug 12 '15 at 0:32











      • Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

        – Shinagan
        Aug 12 '15 at 2:59











      • Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

        – chili555
        Aug 12 '15 at 11:18













      • If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

        – Shinagan
        Aug 12 '15 at 13:20






      • 1





        What about the 169.254.0.0?

        – detly
        Nov 29 '15 at 3:37














      4












      4








      4







      From the quoted link:




      If a DHCP client attempts to get an address, but fails to find a DHCP
      server after the timeout and retries period it will randomly assume an
      address from this network. This allows communication with hosts that
      have failed to obtain a DHCP address.




      However, your interfaces file requests a static IP address that is likely impossible, so no valid address was given.



      192.168.1.1 is likely the address of the router or other access point to which you are attempting to connect. Therefore, the address will not be granted. Moreover, if you expect to connect to the internet, you will need to specify DNS nameservers. May I suggest:



      # interfaces(5) file used by ifup(8) and ifdown(8)
      auto lo
      iface lo inet loopback

      auto eth0
      iface eth0 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 8.8.8.8 192.168.1.1


      Of course verify the exact details before you proceed.



      Restart the interface:



      sudo ifdown eth0 && sudo ifup -v eth0


      Check:



      ping -c3 www.ubuntu.com





      share|improve this answer













      From the quoted link:




      If a DHCP client attempts to get an address, but fails to find a DHCP
      server after the timeout and retries period it will randomly assume an
      address from this network. This allows communication with hosts that
      have failed to obtain a DHCP address.




      However, your interfaces file requests a static IP address that is likely impossible, so no valid address was given.



      192.168.1.1 is likely the address of the router or other access point to which you are attempting to connect. Therefore, the address will not be granted. Moreover, if you expect to connect to the internet, you will need to specify DNS nameservers. May I suggest:



      # interfaces(5) file used by ifup(8) and ifdown(8)
      auto lo
      iface lo inet loopback

      auto eth0
      iface eth0 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 8.8.8.8 192.168.1.1


      Of course verify the exact details before you proceed.



      Restart the interface:



      sudo ifdown eth0 && sudo ifup -v eth0


      Check:



      ping -c3 www.ubuntu.com






      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Aug 12 '15 at 0:30









      chili555chili555

      38.3k55177




      38.3k55177








      • 1





        The king of networking questions is back :)

        – Sergiy Kolodyazhnyy
        Aug 12 '15 at 0:32











      • Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

        – Shinagan
        Aug 12 '15 at 2:59











      • Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

        – chili555
        Aug 12 '15 at 11:18













      • If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

        – Shinagan
        Aug 12 '15 at 13:20






      • 1





        What about the 169.254.0.0?

        – detly
        Nov 29 '15 at 3:37














      • 1





        The king of networking questions is back :)

        – Sergiy Kolodyazhnyy
        Aug 12 '15 at 0:32











      • Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

        – Shinagan
        Aug 12 '15 at 2:59











      • Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

        – chili555
        Aug 12 '15 at 11:18













      • If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

        – Shinagan
        Aug 12 '15 at 13:20






      • 1





        What about the 169.254.0.0?

        – detly
        Nov 29 '15 at 3:37








      1




      1





      The king of networking questions is back :)

      – Sergiy Kolodyazhnyy
      Aug 12 '15 at 0:32





      The king of networking questions is back :)

      – Sergiy Kolodyazhnyy
      Aug 12 '15 at 0:32













      Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

      – Shinagan
      Aug 12 '15 at 2:59





      Thanks! I am not looking to connect to the internet through this ethernet connection, this is already done through wifi. I want to use the subnet to communicate via ssh with my raspberry Pi. I'll edit the question!

      – Shinagan
      Aug 12 '15 at 2:59













      Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

      – chili555
      Aug 12 '15 at 11:18







      Is this also so you can share the internet with the Pi? Is wireless managed by Network Manager or by the interfaces file? If the latter, may we see the entire file?

      – chili555
      Aug 12 '15 at 11:18















      If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

      – Shinagan
      Aug 12 '15 at 13:20





      If internet could be shared with the Pi that would be AMAZING. But I have not been successfull yet. Wifi is managed by network manager. What you saw was the whole /etc/network/interfaces file, there nothing more in it.

      – Shinagan
      Aug 12 '15 at 13:20




      1




      1





      What about the 169.254.0.0?

      – detly
      Nov 29 '15 at 3:37





      What about the 169.254.0.0?

      – detly
      Nov 29 '15 at 3:37













      2














      Per RFC 3927 (emphasis mine):




      To participate in wide-area IP networking, a host needs to be

      configured with IP addresses for its interfaces, either manually by

      the user or automatically from a source on the network such as a

      Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,

      such address configuration information may not always be available.

      It is therefore beneficial for a host to be able to depend on a

      useful subset of IP networking functions even when no address

      configuration is available. This document describes how a host may

      automatically configure an interface with an IPv4 address within the
      169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.




      So, to summarize, the 169.254/16 subnet was reserved to allow for communications between two physically (or logically, e.g. through a switch) connected devices without having to rely on DHCP or manual assignment of static IP addresses.



      To quote the Wikipedia article on private networks,




      If a host on an IEEE 802 (Ethernet) network cannot obtain a network
      address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may
      be assigned pseudorandomly.




      As an example of its usage, say you have two embedded devices that need to communicate with one another via a direct Ethernet connection, but you want one or both devices to first look for DHCP so they also have the possibility of being connected into a local area network. When the devices are connected directly together and there is no DHCP available, the devices may use a protocol such as multicast DNS to discover each other automatically, but each device must first have some arbitrary IP address assigned so they can actually talk to each other over the Ethernet link. Thus, the operating system automatically assigns an IP address to the Ethernet device from the 169.254/16 network.





      Now, as for why that route is there in the routing table by default...if you look at /etc/networks, you can see that the 'link-local' network is defined as being in this subnet:



      $ cat /etc/networks
      # symbolic names for networks, see networks(5) for more information
      link-local 169.254.0.0


      If you take this file's advice and check out man networks, you'll see:




      This file is read by the route(8) and netstat(8) utilities.




      So the route is created automatically on boot after route reads that file.





      The route is only necessary if you plan to actually use link-local communications and don't want to assign a static IP address to the connected devices. But it doesn't do any harm to leave it in if you don't.



      However, if you really want to remove it, you can do so with



      sudo route del -net 169.254.0.0 gw 0.0.0.0


      Or to remove it permanently, you should be able to just comment out its entry in /etc/networks and reboot.






      share|improve this answer




























        2














        Per RFC 3927 (emphasis mine):




        To participate in wide-area IP networking, a host needs to be

        configured with IP addresses for its interfaces, either manually by

        the user or automatically from a source on the network such as a

        Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,

        such address configuration information may not always be available.

        It is therefore beneficial for a host to be able to depend on a

        useful subset of IP networking functions even when no address

        configuration is available. This document describes how a host may

        automatically configure an interface with an IPv4 address within the
        169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.




        So, to summarize, the 169.254/16 subnet was reserved to allow for communications between two physically (or logically, e.g. through a switch) connected devices without having to rely on DHCP or manual assignment of static IP addresses.



        To quote the Wikipedia article on private networks,




        If a host on an IEEE 802 (Ethernet) network cannot obtain a network
        address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may
        be assigned pseudorandomly.




        As an example of its usage, say you have two embedded devices that need to communicate with one another via a direct Ethernet connection, but you want one or both devices to first look for DHCP so they also have the possibility of being connected into a local area network. When the devices are connected directly together and there is no DHCP available, the devices may use a protocol such as multicast DNS to discover each other automatically, but each device must first have some arbitrary IP address assigned so they can actually talk to each other over the Ethernet link. Thus, the operating system automatically assigns an IP address to the Ethernet device from the 169.254/16 network.





        Now, as for why that route is there in the routing table by default...if you look at /etc/networks, you can see that the 'link-local' network is defined as being in this subnet:



        $ cat /etc/networks
        # symbolic names for networks, see networks(5) for more information
        link-local 169.254.0.0


        If you take this file's advice and check out man networks, you'll see:




        This file is read by the route(8) and netstat(8) utilities.




        So the route is created automatically on boot after route reads that file.





        The route is only necessary if you plan to actually use link-local communications and don't want to assign a static IP address to the connected devices. But it doesn't do any harm to leave it in if you don't.



        However, if you really want to remove it, you can do so with



        sudo route del -net 169.254.0.0 gw 0.0.0.0


        Or to remove it permanently, you should be able to just comment out its entry in /etc/networks and reboot.






        share|improve this answer


























          2












          2








          2







          Per RFC 3927 (emphasis mine):




          To participate in wide-area IP networking, a host needs to be

          configured with IP addresses for its interfaces, either manually by

          the user or automatically from a source on the network such as a

          Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,

          such address configuration information may not always be available.

          It is therefore beneficial for a host to be able to depend on a

          useful subset of IP networking functions even when no address

          configuration is available. This document describes how a host may

          automatically configure an interface with an IPv4 address within the
          169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.




          So, to summarize, the 169.254/16 subnet was reserved to allow for communications between two physically (or logically, e.g. through a switch) connected devices without having to rely on DHCP or manual assignment of static IP addresses.



          To quote the Wikipedia article on private networks,




          If a host on an IEEE 802 (Ethernet) network cannot obtain a network
          address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may
          be assigned pseudorandomly.




          As an example of its usage, say you have two embedded devices that need to communicate with one another via a direct Ethernet connection, but you want one or both devices to first look for DHCP so they also have the possibility of being connected into a local area network. When the devices are connected directly together and there is no DHCP available, the devices may use a protocol such as multicast DNS to discover each other automatically, but each device must first have some arbitrary IP address assigned so they can actually talk to each other over the Ethernet link. Thus, the operating system automatically assigns an IP address to the Ethernet device from the 169.254/16 network.





          Now, as for why that route is there in the routing table by default...if you look at /etc/networks, you can see that the 'link-local' network is defined as being in this subnet:



          $ cat /etc/networks
          # symbolic names for networks, see networks(5) for more information
          link-local 169.254.0.0


          If you take this file's advice and check out man networks, you'll see:




          This file is read by the route(8) and netstat(8) utilities.




          So the route is created automatically on boot after route reads that file.





          The route is only necessary if you plan to actually use link-local communications and don't want to assign a static IP address to the connected devices. But it doesn't do any harm to leave it in if you don't.



          However, if you really want to remove it, you can do so with



          sudo route del -net 169.254.0.0 gw 0.0.0.0


          Or to remove it permanently, you should be able to just comment out its entry in /etc/networks and reboot.






          share|improve this answer













          Per RFC 3927 (emphasis mine):




          To participate in wide-area IP networking, a host needs to be

          configured with IP addresses for its interfaces, either manually by

          the user or automatically from a source on the network such as a

          Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,

          such address configuration information may not always be available.

          It is therefore beneficial for a host to be able to depend on a

          useful subset of IP networking functions even when no address

          configuration is available. This document describes how a host may

          automatically configure an interface with an IPv4 address within the
          169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.




          So, to summarize, the 169.254/16 subnet was reserved to allow for communications between two physically (or logically, e.g. through a switch) connected devices without having to rely on DHCP or manual assignment of static IP addresses.



          To quote the Wikipedia article on private networks,




          If a host on an IEEE 802 (Ethernet) network cannot obtain a network
          address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may
          be assigned pseudorandomly.




          As an example of its usage, say you have two embedded devices that need to communicate with one another via a direct Ethernet connection, but you want one or both devices to first look for DHCP so they also have the possibility of being connected into a local area network. When the devices are connected directly together and there is no DHCP available, the devices may use a protocol such as multicast DNS to discover each other automatically, but each device must first have some arbitrary IP address assigned so they can actually talk to each other over the Ethernet link. Thus, the operating system automatically assigns an IP address to the Ethernet device from the 169.254/16 network.





          Now, as for why that route is there in the routing table by default...if you look at /etc/networks, you can see that the 'link-local' network is defined as being in this subnet:



          $ cat /etc/networks
          # symbolic names for networks, see networks(5) for more information
          link-local 169.254.0.0


          If you take this file's advice and check out man networks, you'll see:




          This file is read by the route(8) and netstat(8) utilities.




          So the route is created automatically on boot after route reads that file.





          The route is only necessary if you plan to actually use link-local communications and don't want to assign a static IP address to the connected devices. But it doesn't do any harm to leave it in if you don't.



          However, if you really want to remove it, you can do so with



          sudo route del -net 169.254.0.0 gw 0.0.0.0


          Or to remove it permanently, you should be able to just comment out its entry in /etc/networks and reboot.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 5 '16 at 19:44









          villapxvillapx

          1538




          1538























              0














              As others have mentioned, 169.254.0.0 is present in your routing table because ifup is setting up the link-local network.



              To avoid this, consider using ifconfig instead of ifup.



              If necessary, run ifdown first.



              sudo ifdown eth0
              sudo ifconfig eth0 192.168.1.1


              ifconfig does less work and does not read /etc/network/interfaces.



              It should be possible to share internet access with the Pi. You need to turn on packet forwarding in the kernel on your laptop. I think this can be done without rebooting. I have done it in the past, but do not know how to do it off the top of my heard. This might help:



              How do I bridge network interfaces?






              share|improve this answer






























                0














                As others have mentioned, 169.254.0.0 is present in your routing table because ifup is setting up the link-local network.



                To avoid this, consider using ifconfig instead of ifup.



                If necessary, run ifdown first.



                sudo ifdown eth0
                sudo ifconfig eth0 192.168.1.1


                ifconfig does less work and does not read /etc/network/interfaces.



                It should be possible to share internet access with the Pi. You need to turn on packet forwarding in the kernel on your laptop. I think this can be done without rebooting. I have done it in the past, but do not know how to do it off the top of my heard. This might help:



                How do I bridge network interfaces?






                share|improve this answer




























                  0












                  0








                  0







                  As others have mentioned, 169.254.0.0 is present in your routing table because ifup is setting up the link-local network.



                  To avoid this, consider using ifconfig instead of ifup.



                  If necessary, run ifdown first.



                  sudo ifdown eth0
                  sudo ifconfig eth0 192.168.1.1


                  ifconfig does less work and does not read /etc/network/interfaces.



                  It should be possible to share internet access with the Pi. You need to turn on packet forwarding in the kernel on your laptop. I think this can be done without rebooting. I have done it in the past, but do not know how to do it off the top of my heard. This might help:



                  How do I bridge network interfaces?






                  share|improve this answer















                  As others have mentioned, 169.254.0.0 is present in your routing table because ifup is setting up the link-local network.



                  To avoid this, consider using ifconfig instead of ifup.



                  If necessary, run ifdown first.



                  sudo ifdown eth0
                  sudo ifconfig eth0 192.168.1.1


                  ifconfig does less work and does not read /etc/network/interfaces.



                  It should be possible to share internet access with the Pi. You need to turn on packet forwarding in the kernel on your laptop. I think this can be done without rebooting. I have done it in the past, but do not know how to do it off the top of my heard. This might help:



                  How do I bridge network interfaces?







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Apr 13 '17 at 12:24









                  Community

                  1




                  1










                  answered Jan 10 '17 at 18:44









                  mpbmpb

                  37318




                  37318






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f660355%2fwhy-169-254-0-0-appears-by-default-in-the-routing-table%23new-answer', 'question_page');
                      }
                      );

                      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







                      Popular posts from this blog

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                      Eduardo VII do Reino Unido