> Subject:
> Re: [44net] Distributed BGP Announce
> From:
> Brian D Heaton <ky9k-lists(a)ky9k.org>
> Date:
> 07/29/2013 05:54 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> My experience is with Cisco's "ip tcp adjust-mss xxx". It works 100% in all cases I've seen. Some very large deployed networks use that functionality. The only times we have issues is when folks remove that statement thinking it is redundant to
> MTU size. (We set both)
>
> 73-KY9K/Brian
>
>
> On 7/25/2013 8:59 AM, Marc, LX1DUC wrote
>>> Also as it only really efficts TCP, I solve it on my GRE tunnels with
>>> ip tcp adjust-mss 1436 in cisco
>>> set interface $interface ip tcp adjust-mss 1436 in juniper
>>> tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent
>>
>> What is your experience with that setup? Does it always (99.999% :-D) work? If so, count me in an let's go with it.
>>
>> 73 de Marc, LX1DUC
I probably invented that :-)
I introduced it into my version of NET (derived from KA9Q NET) in august of 1995, to avoid the
fragmentation that frequently occurred when forwarding IP datagrams over NET/ROM transport.
In my version, the MSS was automatically calculated from the MTU of the incoming and outgoing
interface in the IP routing code. It worked very well. (MTU discovery did not exist back then)
In 2001, Cisco introduced it in IOS and I realized I should have patented it :-)
From changelog:
PE1CHL.950819:
TCP SYN packets are examined when routed, and the MSS option will be
adjusted down to the maximum MSS possible on the incoming and outgoing
interfaces. Thus, a more optimal end-to-end MSS is chosen, and
fragmentation is avoided (e.g. when running IP over NET/ROM somewhere
inbetween the endpoints)
Rob
So how are folks actually making use of all this nifty routing
technology on the air with Amateur Radio these days?
I don't remember the last time I've seen an "ampr.org" email address
here on the list. I kinda remember the last time I had one that
worked...
Bill
On 7/25/13 2:59 AM, Marc, LX1DUC wrote:
> By defautl GRE provides an Layer3 MTU of 1476 bytes. How will you cope
> with packet fragmentation or in case DF=1 with ICMP type=3 code=4 (The
> datagram is too big. Packet fragmentation is required but the 'don't
> fragment' (DF) flag is on.) filtering.
Yes, but this is why we have PMTUD. It works fine so long as ICMP is not
blocked. If ICMP is blocked, then some one along the path needs to get some
clue. I've only encountered this on private networks (LAN's, and packet cores
where IT runs it). Generally it's fixed with me screaming "YOU'RE BREAKING
THE INTERNET STUPID!" ;)
Also as it only really efficts TCP, I solve it on my GRE tunnels with
ip tcp adjust-mss 1436 in cisco
set interface $interface ip tcp adjust-mss 1436 in juniper
tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Is it possible to get the IPIP routes delivered by conventional routing
protocols (RIP, OSPF, etc) rather than running a custom daemon ?
Just curious.
-Neil
--
Neil Johnson -N0SFH
http://erudicon.com
I can't seem to get rip44d to hear the routes. I'm sure I'm doing something
dumb.
Here is my /etc/networking/interfaces configuration:
# Tunnel to amprnet
auto tun0
iface tun0 inet static
address 44.50.128.1
netmask 255.255.255.0
broadcast 44.50.128.255
pre-up iptunnel add tun0 mode ipip local 128.255.134.47
post-down iptunnel del tun0
If I run tcpdump on the tun0 interface I can see the routes coming down,
but when I run rip44d it never hears them.
I did I miss. I'm running ubuntu 12.04 LTS.
Thanks.
-Neil
--
Neil Johnson -N0SFH
http://erudicon.com
Hi,
First time posting on this list.
I am new to AMPRNet and actually still struggling to make gateway. I
realized that I have to download encap file with route definitions and
load them into my gateway router so my networks sees all other networks
in 44/8.
It is suggested that I have to get up Linux box that will do the gateway
job.
Thing is, I want to use Mikrotik router that I already have in use, and
which handles my network. I do not need another box just to play gateway.
I do not understand why standard dynamic routing protocol is not used in
first place, so we would not have this issue at all as all routers are
capable of dynamic routing?!?!
I noticed that there is a script made by Marius, YO2LOJ, that reads
encap file and then sets Mikrotik up to it. But, to run that script I
again need Linux box. I noticed there are other scripts that do the same
for other kind of routers.
I guess there are number of fellow hams that would like to use already
set router and not additional Linux box.
Why then such scripts are not run at portal.ampr.org so we can, besides
encap file, download prepared files for popular routers, so we do not
need to make conversions for ourselves?
If such download is provided, I would be able make Mikrotik itself to
download file and run it to set routes. I would not need additional
Linux box to do that.
That would make whole process simpler, easier to implement and even
cheaper (in manner not just money, but efforts, physical space,
maintenance...) and that could motivate more people to get involved.
If resources on portal.ampr.org are limited, mirror copies of those
files could be easily established to prevent problems.
YT9TP
Pedja
On 7/25/13 1:40 PM, Marc, LX1DUC wrote:
> However I'm not sure I'm able to provide an IS-IS capable router for
> the trial...
A Juniper O-series might work ;)
I think the 2811s from cisco are cheap enough now (under 400 on ebay). The
issue with cisco is you need some one to get the code for you now that they've
locked down the CCO site.
I'd love to use ALU gear, but it's just to expensive on the used market.
But this is all just discussion on how we wan to do it at this point.
We'll need some detailed proposals and come to a conciseness on it.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Marc, LX1DUC,
Per Brian in a Jan 22 note:
44.0.0.1 responds to pings received from the Internet. It does not
respond to pings coming into it over an encap connection to it, for
some reason that I've not been able to figure out. I believe it to
be a difficulty in getting it to recognize decapped pings.
If you are receiving the rip44 announcements, you have properly
configured your tunnel to receive IP-in-IP encapsulation from 44.0.0.1.
Feel free to use:
http://44.60.44.10/tools
or
http://kb3vwg-010.ampr.org/tools
I see your encap as:
44.161.202.0 via 46.29.183.253 dev tunl0 onlink window 840
44.161.203.0 via 46.29.183.253 dev tunl0 onlink window 840
44.161.229.0 via 46.29.183.253 dev tunl0 onlink window 840
Also, I am unable to ping 44.161.229.126. What script/configuration did
you use to enable your tunnel; did you specify a local or remote IP
(un-needed)? Feel free to look at my script at http://44.60.44.13/startampr
73,
Lynwood
KB3VWG
Any of you folks planning on attending the TAPR/ARRL Digital
Communications Conference in Seattle this September?
<http://www.tapr.org/dcc/>
I hope to be there.
- Brian
I have been following the conversation on what can we use the modern version
of the 44net for other than a futile attempt to compete with cable modems,
4G/LTE or fiber-optic links. The purpose of the 44net/JNOS project that we
are putting together for NYC-ARECS is for providing email/telnet services
for a served client in case their connection goes down or does not exist
in an ad-hoc location. I am wondering if we can expand on the usual email
and telnet sessions at 1k2 or even 9k6 to include things like routing our
own VoIP/Echolink-type connections? The Echolink manual states that it needs
24K+ data speeds to connect to it's servers and maintain a voice connection.
I know that there are other codecs that can work at lower speeds as well as
ongoing work with FreeDV operating in 1.5 Khz on 20 meters! Ideas anyone?
