RIP: Difference between revisions

From 44Net Wiki
Jump to navigation Jump to search
← Older editNewer edit →
4Z4ZQ (talk | contribs)
90 edits
mNo edit summary
Kb3vwg (talk | contribs)
258 edits
added detailed differences and explanations of the protocol from Marius, YO2LOJ
Line 1: Line 1:
Information about other AMPRNet [[gateway| gateways]] can now be received dynamically via modified [http://en.wikipedia.org/wiki/Routing_Information_Protocol RIPv2] advertisements. Previously, routes were obtained by creating a [[munge script]] that parsed [[Encap.txt]].
Information about other AMPRNet [[gateway| gateways]] can now be received dynamically via modified [http://en.wikipedia.org/wiki/Routing_Information_Protocol RIPv2] advertisements. Previously, routes were obtained by creating a [[munge script]] that parsed [[Encap.txt]].
= What's the difference? =
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and
interface where the RIP broadcast was received on. The gateway
information is used only as an optimization element, in case a route
with to that gateway already exists so that the one with the lower
metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND
gateway information.
= Detailed description =
So, assuming a point to multipoint interface, if there is let's say an
announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0
interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the
gateway (the RIP sender), while in the second case it is encapsulated to
1.2.3.4.
On a mikrotik router it even goes a step further:
it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates
a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net
gateway we assume that the gateway is published by BGP and is directly
reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there
are 2 route set:
44.128.0.1 via default-gw  (which is autodetected), and
44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2
specifications, its usage is completely different.


= RIP44 Daemons =
= RIP44 Daemons =

Revision as of 19:34, 2 October 2018

Information about other AMPRNet gateways can now be received dynamically via modified RIPv2 advertisements. Previously, routes were obtained by creating a munge script that parsed Encap.txt.


What's the difference?

There is a big difference in how the packets are processed.

The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.

In our case, we use the RIP announcements to transport the subnet AND gateway information.

Detailed description

So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:

44.128.0.0/24 via 44.0.0.1 if ipip0

while ampr rip would translate this to:

44.128.0.0/24 via 1.2.3.4 if ipip0

In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.

On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route

44.128.0.0/24 via ampr-1.2.3.4

This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:

44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation

So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.

RIP44 Daemons

Two programs are available for GNU/Linux to utilize these updates:

Availability/Compatibility

The RIP44 daemons have been tested and known to work on the following operating systems:

  • BSD
  • OpenWRT/LEDE
  • Raspbian
  • Slackware Linux
  • Ubuntu/Debian Linux
  • Vyatta/VyOS

Non-RIP44 Workarounds

The devices below do not possess a known, end-user method to install additional software (i.e. ampr-ripd). Operators have developed scripts to parse inbound routing packets to make them compatible for usage on AMPRNet:

See Also

Retrieved from "https://wiki.ampr.org/w/index.php?title=RIP&oldid=774"