19 May
2017
19 May
'17
2:01 p.m.
I expect you could have more luck by looking in to
SLAX scripting as it
should not be to hard to do this fully from the junos api's
I did not check this but i don't think the ipip
driver would be
standard.
Well, it is not very straightforward so when it is your first script you
are probably going to have a hard time...
In Linux there is a point-to-multipoint IP tunnel, much as was the case in JNOS
when this whole IPIP mesh was designed. You configure only a single IP
tunneling interface, usually called tunl0, and you put a set of routes in
the route table with the destination subnets, the tunl0 device, and the remote
endpoint of the tunnel as the gateway address. Like this:
44.2.2.0/24 via 216.218.207.198 dev tunl0 onlink
44.2.7.0/30 via 73.185.12.233 dev tunl0 onlink
44.2.10.0/29 via 104.49.12.130 dev tunl0 onlink
The onlink attribute is required to suppress the "gateway not reachable"
warning
you would normally get when the gateway is not directly reachable from the system.
With this facility, the updating is relatively easy: just make sure the actual routing
table agrees with the distributed information, by adding and deleting single routes.
Without such point-to-multipoint tunneling, you will have to create a separate
tunnel interface for each gateway, and setup routes to the remote subnets pointing
to the correct gateway tunnel. Remember there are (way) more subnets than gateways,
you need to find the routes with the same remote gateway, and create only a single
tunnel device for those combinations, and point the matching subnet routes to that
device.
To obtain the information about the subnets, you either listen to the RIP broadcasts
made by amprgw, or you regularly download the "encap.txt" which has this
format:
route addprivate 44.2.2/24 encap 216.218.207.198
route addprivate 44.2.7/30 encap 73.185.12.233
route addprivate 44.2.10/29 encap 104.49.12.130
so you need to parse that and get the subnet and gateway fields from it.
(this format is the commandline format that JNOS used)
There is no separate "list of endpoints" so you have to create that yourself
from that list of routes (take the last field and put it in a list, removing
duplicates).
Now when you have written a script to transform this into commands to create
the proper tunnel devices and add the routes, the real fun begins!
The next time you get the information, you need to check if there are changes.
When there are, there usually will be a change of tunnel endpoint address (for
a gateway that is on a dynamic internet address). You will find several entries
in the information that suddenly have a different next hop address, but of course
they are not grouped together, they are scattered through the lines you received.
You will need to locate the correct tunnel device (which you will need to look up
using the *previous* table of received information) and change its endpoint.
But, there are other possibilities, ocurring less often: a subnet could have been
added or removed from a gateway (and maybe moved to another), a new gateway can be
added, or a gateway can be removed (with all its subnets).
And of course, combinations of the above, e.g. a gateway has its endpoint address
changed and at the same time adds or deletes a subnet.
That is probably a rare occurrence, but it should not cause disaster (like a crash).
Of course you could simplify things by just deleting everything (routes and devices)
and rebuilding it from zero whenever there is some change. But that could cause
brief interruptions of the routing and/or high load on the CPU.
Sure, it can be done. But for someone who is not experienced in programming in
general, and has to learn the scripting language for the particular platform as
well, it will be tough.
I would certainly advise to look at Marius' script for MikroTik, as it of course
has the algorithms described above. It would have to be rewritten in a different
language and the constructs to add/delete tunnel devices and routes will have to
be changed.
Rob
19 May
19 May
11:21 p.m.
New subject: Traffic not routing to my gateway
I am very close to having a bash shell script that will generate the needed
JUNOS commands. I can only hope that it works on JUNOS...doubtful since
JUNOS uses the CSH shell. :( But If I can get the logic worked out in
bash, it should convert easy enough.
is there an automated way to download the encap file? Is it hosted on a
ftp server where our amprnet credentials would give us access to the file?
I see that the URL for the gateway list just calls a PHP file that creates
the file and then allows it to be downloaded. But curl using my
credentials doesn't pull the file. More experimenting. :)
Thanks,
Craig
On Fri, May 19, 2017 at 2:01 PM, Rob Janssen <pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
I expect you could have more luck by looking in
to SLAX scripting as it
should not be to hard to do this fully from the junos api's
I did not check this but i don't think the ipip driver would be
standard.
Well, it is not very straightforward so when it is your first script you
are probably going to have a hard time...
In Linux there is a point-to-multipoint IP tunnel, much as was the case in
JNOS
when this whole IPIP mesh was designed. You configure only a single IP
tunneling interface, usually called tunl0, and you put a set of routes in
the route table with the destination subnets, the tunl0 device, and the
remote
endpoint of the tunnel as the gateway address. Like this:
44.2.2.0/24 via 216.218.207.198 dev tunl0 onlink
44.2.7.0/30 via 73.185.12.233 dev tunl0 onlink
44.2.10.0/29 via 104.49.12.130 dev tunl0 onlink
The onlink attribute is required to suppress the "gateway not reachable"
warning
you would normally get when the gateway is not directly reachable from the
system.
With this facility, the updating is relatively easy: just make sure the
actual routing
table agrees with the distributed information, by adding and deleting
single routes.
Without such point-to-multipoint tunneling, you will have to create a
separate
tunnel interface for each gateway, and setup routes to the remote subnets
pointing
to the correct gateway tunnel. Remember there are (way) more subnets than
gateways,
you need to find the routes with the same remote gateway, and create only
a single
tunnel device for those combinations, and point the matching subnet routes
to that device.
To obtain the information about the subnets, you either listen to the RIP
broadcasts
made by amprgw, or you regularly download the "encap.txt" which has this
format:
route addprivate 44.2.2/24 encap 216.218.207.198
route addprivate 44.2.7/30 encap 73.185.12.233
route addprivate 44.2.10/29 encap 104.49.12.130
so you need to parse that and get the subnet and gateway fields from it.
(this format is the commandline format that JNOS used)
There is no separate "list of endpoints" so you have to create that
yourself
from that list of routes (take the last field and put it in a list,
removing
duplicates).
Now when you have written a script to transform this into commands to
create
the proper tunnel devices and add the routes, the real fun begins!
The next time you get the information, you need to check if there are
changes.
When there are, there usually will be a change of tunnel endpoint address
(for
a gateway that is on a dynamic internet address). You will find several
entries
in the information that suddenly have a different next hop address, but of
course
they are not grouped together, they are scattered through the lines you
received.
You will need to locate the correct tunnel device (which you will need to
look up
using the *previous* table of received information) and change its
endpoint.
But, there are other possibilities, ocurring less often: a subnet could
have been
added or removed from a gateway (and maybe moved to another), a new
gateway can be
added, or a gateway can be removed (with all its subnets).
And of course, combinations of the above, e.g. a gateway has its endpoint
address
changed and at the same time adds or deletes a subnet.
That is probably a rare occurrence, but it should not cause disaster (like
a crash).
Of course you could simplify things by just deleting everything (routes
and devices)
and rebuilding it from zero whenever there is some change. But that could
cause
brief interruptions of the routing and/or high load on the CPU.
Sure, it can be done. But for someone who is not experienced in
programming in
general, and has to learn the scripting language for the particular
platform as
well, it will be tough.
I would certainly advise to look at Marius' script for MikroTik, as it of
course
has the algorithms described above. It would have to be rewritten in a
different
language and the constructs to add/delete tunnel devices and routes will
have to
be changed.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
20 May
20 May
12:22 a.m.
New subject: Traffic not routing to my gateway
Yes, it's on an FTP server. I'll mail you the details off-list.
- Brian
On Fri, May 19, 2017 at 11:21:07PM -0400, Craig Brauckmiller wrote:
is there an automated way to download the encap file?
Is it hosted on a
ftp server where our amprnet credentials would give us access to the file?
I see that the URL for the gateway list just calls a PHP file that creates
the file and then allows it to be downloaded. But curl using my
credentials doesn't pull the file. More experimenting. :)
12:47 a.m.
New subject: Traffic not routing to my gateway
On FreeBSD, which you've mentioned is the basis for JUNOS, the crontab
file executes with /bin/sh by default, rather than /bin/csh. I don't
know if you've got access to a crontab on JUNOS but watch out for the
difference in shells if you do.
BTW, the encap file does not change much. On average, one line in it
will change per hour, as a gateway with a dynamic address updates its
address (and it's often the same gateway flipping between two or three
addresses), but gateways come and go at a much lower rate -- I'd guess
one or two a week. So you'd be pretty safe just FTPing and processing
a new encap file perhaps once a day if it winds up being a chore.
- Brian
On Fri, May 19, 2017 at 11:21:07PM -0400, Craig Brauckmiller wrote:
I am very close to having a bash shell script that
will generate the needed
JUNOS commands. I can only hope that it works on JUNOS...doubtful since
JUNOS uses the CSH shell. :( But If I can get the logic worked out in
bash, it should convert easy enough.
2743
days inactive
2744
days old
3 comments
3 participants
participants (3)
-
Brian Kantor -
Craig Brauckmiller -
Rob Janssen