| |
I0OJJ > 44NET 09.03.21 17:41z 89 Lines 3441 Bytes #999 (0) @ WW
BID : 93VI0OJJ_007
Read: GUEST
Subj: Re: Att: I0OJJ > Re: portal.ampr.org
Path: SR1BSZ<SR4BBX<DB0RES<ON0AR<OZ5BBS<CX2SA<OK2PEN<GB7CIP<I0OJJ
Sent: 210309/1717z @:I0OJJ.ITA.EU [Rome] obcm1.08-5-g2f4a
From: I0OJJ @ I0OJJ.ITA.EU (Gustavo)
To: 44NET @ WW
X-Info: Sent with login password
X-Info: Received by SMTP-gateway
Hi all,
On 3/9/21 4:34 PM, g4apl@gb7cip.#32.gbr.eu wrote:
> On 08/03/2021 18:00, N1URO wrote:
>> Path: !GB7YEW!W0ARP!CX2SA!VE2PKT!N1URO!
>>
>> Gus et al;
>>
>>> Important to note that: with the advent of BGP routing
>>> the 'ampr-ripd' program DOESN'T FUNCTION anymore in my
>>> situation (having a dynamic IP address), since the 'tunl0'
>>> DON'T WORK anymore for the tunneled data.
>>> So it is not more usable!
>>
>> This is not at all true. What you now must do _if_ the BGP end does not
>> support an encap path is to policy route any BGP routes through your
>> ip rules and source as your public IP to reach them. For me personally,
>> anyone on BGP that is too lazy to install a tunnel route doesn't need
>> any of my traffic nor do I wish theirs. This is amateur RADIO not amateur
>> ISP.
>>
>>> Note for Marius YO2LOJ: in my situation, the ampr-ripd
>>> program could continue to work (for me) ONLY if the RIP2
>>> broadcast are collected ALSO via eth(x) setup interface.
>>
>> This would break your routing to those who are encapped because you would
>> then send out without encapsulation to them and they would not know how
>> to decode your frames. Marius' ampr-ripd works just fine as it is.
>>
>>> My good thing is the use the ipencap resource of JNOS2
>>> and then puzzling on routing of linux box: not an easy
>>> matter :)
>>
>> In reality, ampr-ripd works better than the encap resource of JNOS2 and
>> it is an extremely faster switching system for packet switching than JNOS2
>> by a ratio of about 4:1 faster. Remember, for the frame to hit JNOS2 it must
>> first route through the linux kernel and that then will pass it to JNOS2.
>> Not at all taking away from the work in xNOS (this was actually a creation by
>> Phil Karn for NOS).
>>
>> I have a feeling your policy rules may be slightly off or you're not receiving
>> all the rip routes:
>> Which ip route are you looking for (no * please): 44.190.255.16
>> Searching the route for 44.190.255.16 ...
>> 44.190.255.16 via 169.228.34.84 dev tunl0 src 44.88.0.1
>> cache expires 482sec mtu 1480
>> TunnelSearch v1.0 by N1URO for URONode.
>>
>> and I get in just fine. I have to being a coordinator.
>> ---
>> SendBBS v1.1 by N1URO for LinFBB
>>
> Hi Brian and all
> I encounted the same issue at GB7CIP in recent months
> and due to my complex configuration as my system
> now has dedicated link to an EU BGP network.
> We ended up creating separate dedicated tunnels
> to handle the non 44net ipencap traffic between our two networks.
> Just added more complexity to my internal network configurstion.
> As they say!! "Just another challenge!"
>
> Link to the portal.ampr.org
> was also solved by adding a static routing
> on the ipencap routing side of this system
> and for linking to the conver EU_HUB.
> When the original BGP routing was changed,
> 73 de Paul g4apl
>
> --
> g4apl@gb7cip.ampr.org g4apl@gb7cip.#32.gbr.euro
> message generated with Thunderbird and LinFBB
However 'ampr-ripd' and the associated linux 'tunl0'
remain silent forever and so don't work here in my
station. The fact begin after the portal BGP asset.
My actual setup is proven to work with 44net and with
the European BGP 'hamnet' and '44.137' networks, so
that is enough for me :)
--
73 and ciao, gustavo i0ojj/ir0aab/ir0eq
non multa, sed multum
Read previous mail | Read next mail
| |