Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Understanding a Routing Table  (Read 721 times)

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Understanding a Routing Table
« on: August 08, 2020, 01:28:22 AM »

Earlier today, I came across the following --

| Destination      | Netmask          | NextHop/Iface    | Advert   | Metric   |
|------------------|------------------|------------------|----------|----------|
| 0.0.0.0          | 0.0.0.0          | 10.0.0.254       | True     | 1        |

With the temperature in the 33 - 34°C range this afternoon, my brain was fried. I looked at the above routing table and thought --

 助けて !  :help:

I look towards the usual persons for an explanation, please.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: Understanding a Routing Table
« Reply #1 on: August 08, 2020, 10:19:38 AM »

Default route via 10.0.0.254, flagged to be advertisible to other devices via whatever means available rather than strictly internal.

Lowest metric usually wins and that's a very low metric for a default route so that's a bit odd, but more specific routes will take precedence as that route is considered to have a 0 bit subnet mask.
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Understanding a Routing Table
« Reply #2 on: August 08, 2020, 12:11:50 PM »

The 0.0.0.0 netmask 0.0.0.0 means that it’s a route to the whole internet as CarlT said, and it’s via whatever 10.0.0.254 is.

It’s just pleasantly warm up here, none of the horrors of england’s temperatures- Janet mentioned something about 37C?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Understanding a Routing Table
« Reply #3 on: August 08, 2020, 05:30:51 PM »

Thank you for the explanation.

In the early hours of this morning (having cooled down whilst sleeping), I thought about my query and convinced myself that a netmask of 0.0.0.0 is, of course, /0 in CIDR. I then convinced myself that 0.0.0.0/0 is "everything" (but not necessarily in the way that Mr Creosote had "everything").

The temperature is now a more bearable 26°C . . .
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Understanding a Routing Table
« Reply #4 on: August 09, 2020, 11:48:18 PM »

Never having bothered to consider it before now, I took a look at the routing table (via the CLI) of my ZyXEL VMG1312-B10A . . .

~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
ww.xx.yy.zz     0.0.0.0         255.255.255.255 UH    0      0        0 pppoa1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 pppoa1
~ # 

The ww.xx.yy.zz is just the IPv4 address that I have currently been given by TalkTalk.

I'm struggling to understand the third line in the table and an interpretation would be appreciated, please.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Understanding a Routing Table
« Reply #5 on: August 09, 2020, 11:59:11 PM »

Doing some more "poking around", elsewhere, I came across another routing table fairly similar to that of my original query --

|Interface       |Mask           |Gateway        |Destination    |Metric  |Advertise|Type
|----------------|---------------|---------------|---------------|--------|---------|--------|
|WAN1            |0.0.0.0        |192.168.0.254  |0.0.0.0        |1       |disabled |static
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: Understanding a Routing Table
« Reply #6 on: August 10, 2020, 09:22:36 AM »

Sure - 3rd line is pointing to an interface rather than a gateway.

Standard fare for a PPP link.
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Understanding a Routing Table
« Reply #7 on: August 10, 2020, 10:37:59 PM »

Thank you. All is now clear.

Seeing zeros everywhere on that line was not something that I was expecting.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Understanding a Routing Table
« Reply #8 on: August 10, 2020, 11:27:17 PM »

All the zeros is confusing, because as you said, the CIDR prefix is /0 so the address field is in this case irrelevant having been all ANDed out with zeros, a prefix of zero length. An address of 0.0.0.0 of full length is otherwise an used to mean ‘self’ - ‘current network’ if a source address. (https://en.wikipedia.org/wiki/Reserved_IP_addresses)
Logged

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: Understanding a Routing Table
« Reply #9 on: August 11, 2020, 10:14:29 AM »

That makes sense. Routing tables of course are pointing to destinations so whatever IETF state in one of the three relevant RFCs isn't relevant here  :)

For various reasons sometimes it makes more sense to point to an interface rather than to an IP address as next hop. It's basically telling the networking stack to source the traffic from that interface and use that interface's routing table to make the next decision. In the case of PPP that means send it over the PPP link and let the BRAS work it out  ;)
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: Understanding a Routing Table
« Reply #10 on: August 11, 2020, 11:42:27 AM »

As an addendum that PPP link isn't talking IP. It's a gateway to something that talks IP so it genuinely has no option other than to shovel traffic over to the IP-aware node. If it has nothing preferable in its own IP routing table the only option is to fall back to the PPP or, actually, whatever, encapsulation link. Won't be running IP to anything.

A reminder - in many cases the actual 'real' publicly routable IP domain doesn't start until the other end of the tunnel. The device on the othe end of the tunnel advertises the IP connectivity then forwards it across a tunnel to your kit. Your kit does not actually have exposure to IP other than locally as far as talking to your end of the tunnel goes.

Public IPs run over a tunnel are certainly routable however there's encapsulation there, so an intermediate device needs a slightly odd routing table to handle than encapsulation. In the case of the mentioned line in the table that was the line bridging IP and PPP. It cannot provide an IPv4 next hop as it's not an IPv4 route, it's a logical interface route with the encapsulation and decapsulation of traffic pushed through that interface all it can rely on.

Realised I wasn't perhaps as clear as I could be earlier.
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Understanding a Routing Table
« Reply #11 on: August 11, 2020, 06:06:28 PM »

Thank you. With your latest explanation (I think) I can now understand why there are two lines with pppoa1 in the "Iface" column.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1650
    • My Broadband History
Re: Understanding a Routing Table
« Reply #12 on: August 12, 2020, 03:38:26 AM »

Thanks for that @CarlT as I've always wondered exactly how PPP works compared to say a VPN that is talking plain IP.

It does make sense though, its a bridge in the strictest sense of the word, just shoving traffic over the link and letting the other end decide what to do with it.

The does beg the question though, if its so simple, why does PPP have such a high CPU overhead?  Also, how does it deal with rate limiting if it tries to push traffic quicker than the link itself?
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadbamd Quality Monitors

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: Understanding a Routing Table
« Reply #13 on: August 12, 2020, 09:44:09 AM »

The does beg the question though, if its so simple, why does PPP have such a high CPU overhead?  Also, how does it deal with rate limiting if it tries to push traffic quicker than the link itself?

Most of the time the apparent overhead is because IP is hardware accelerated, PPP isn't. Running an all-software solution the differences are minimal though present as it's an additional layer of encapsulation and reduces MTU so slightly higher packets per second count required for the same throughput.

The capacity of kit that's been engineered to handle large amounts of PPP sessions is immense as it has hardware assistance.

Rate limiting: either use https://tools.ietf.org/html/rfc1663 or just buffering then dropping: IP, TCP, UDP get to handle the loss, not PPP's problem.
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.