Rare project developers

[Frédéric LOUI <>]

Hi,

> why did _not_ configured the par0101 to use geant's clearnet and went the 
> nmaas wireguard tunnel?
- Simply because at the time PAR0101 was deployed CLEARNET did not exist. It 
has been enabled after discussion in multicast mailing list.
  You could also have suggested the improvement at that time when you enabled 
AMT-relay
- PAR0101 is an old GTS server but still managed by GÉANT WP<x>T<y> team 
(sorry I don’t remember the GEANT Task's name)
  And we should not change the setup they put in place.
- It is convenient to have a common shared OOB access via NMaaS. (WG tunnel 
is also done over a GEANT INTERNET access from GTS facility) 
  Remember only AMS/PAR/POZ/FRA have a dedicated VPLS for OOB. This setup is 
simple and convenient to adopt as soon as we have a P4 switch 
  that does not fall under our responsibility
- We have access to this server via console server provided via Guacamole.

> we have it everywhere, the one-line installer, in alex's tofino images, the 
> prebuilts, and so on...

Thank for this recommendation. This is a change I wanted to suggest to the 
RARE team and ask your opinion. (but are thinking +100 strikes ahead of me :) 
)
But before doing that I wanted to bring it to our group as GP4L will have a 
broader picture and would involve more people.

Such decision should be taken collectively, correct me if I’m wrong but there 
is no reason to rush and bypass others.

In in all, thanks for your recommandation

All the best
Frederic



> Le 29 août 2022 à 13:01, mc36 <> a écrit :
> 
> be prepared that as i last checked, the par0101 node does not have the 
> latest dpdk libs,
> that is, once the connection restored,
> (_whoever_ will do that finally) it'll self destruct itself, see attached 
> screenshot: the p4emu restarts continously
> the reason behind is that the new p4dpdk*.bin is linked against the 
> dpdk21.11 libs which is missing at par0101...
> 
> sorry, i misunderstood something, because i saw the clearnet working and 
> you said geant cage and never mentioned that it's just the p4lab...
> 
> and exactly that's what i still dont understand:
> why did _not_ configured the par0101 to use geant's clearnet and went the 
> nmaas wireguard tunnel?
> 
> here is a way to do so:
> proxy-profile clearnet
> vrf clearnet
> exit
> client http-proxy clearnet
> client name-proxy clearnet
> and the default nat config from the one-liner to have the linux also have 
> internet
> 
> we have it everywhere, the one-line installer, in alex's tofino images, the 
> prebuilts, and so on...
> 
> 
> 
> On 8/29/22 10:58, Fr  d  ric LOUI wrote:
>> Hi,
>> As it is a problem related to G  ANT P4 lab I   m stripping rare-users and 
>> 
>> If you feel that it is related to these mailing list feel free to add them 
>> again.
>> As mentioned PAR0101 problem was under G  ANT responsibility.
>> The problem has been identified and confirmed my observation but also your 
>> observation WRT PAR0101 inband management access working.
>> (Cf check thread below)
>> G  ANT support ticket  [TT#2022082434002594]
>> And here is their feedback:
>> <FEEDBACK FROM G  ANT support>
>> Le 25 ao  t 2022    07:19, GEANT Support <> a   crit :
>> Dear Frederic,
>> The servers need repatching, following the move to a new location within 
>> the data centre.  Unfortunately this was not possible to do during the 
>> move due to unforeseen circumstances. Engineers are scheduled to attend 
>> site on Monday to complete these tasks.
>> Please let us know if you require further information at this time.  We 
>> will provide further updates as they become available.
>> Kind Regards,
>> William Barber
>> G  ANT Operations Centre
>> Email: 
>> Tel: +44 (0)1223 733033
>> GEANT CERT - PGP Key ID: 0x99833085  / Fingerprint: 3CBF F211 8305 635D 
>> 5839 BB27 BA6B F34A 9983 3085
>>  Networks     Services     People
>> http://www.geant.org      G  ANT Vereniging (Association) is registered 
>> with the Chamber of Commerce in Amsterdam with registration number 
>> 40535155 and operates in the UK as a branch of G  ANT Vereniging. 
>> Registered office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands. UK 
>> branch address: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK.
>> 24/08/2022 10:15 - Fr  d  ric LOUI wrote:
>> Please note that the RARE P4 switch is working well.
>> What is not working is PAR-BMS4 internet access.
>> Accessing PAR-BMS via guacamole is OK and we see the Linux interface is UP
>> Just in case please allow me to add Milos and Alexander who are GTS 
>> subject matter
>> expert.
>> Maybe they can provide more details on what is broken at GTS_hardware@PAR
>> All the best,
>> Frederic
>>> Le 24 ao  t 2022    12:18, GEANT Support <> a   crit :
>>> 
>>> Dear Frederic,
>>> 
>>> Sorry for the delay in this.  We're currently working to try and resolve 
>>> the connectivity issues for the RARE servers in Paris and awaiting 
>>> engineers locally to be available to assist in this.  We are chasing this 
>>> at the moment and will update you when we have durther information.
>>> 
>>> Kind Regards,
>>> 
>>> William Barber
>>> G  ANT Operations Centre
>>> 
>>> Email: 
>>> Tel: +44 (0)1223 733033
>>> 
>>> GEANT CERT - PGP Key ID: 0x99833085  / Fingerprint: 3CBF F211 8305 635D 
>>> 5839 BB27 BA6B F34A 9983 3085
>> </END FEEDBACK FROM G  ANT support>
>> By the way I cross check with NMaaS support team, and they were not 
>> involve nor myself in shutting down the tunnel whatsoever.
>> Their firewall logs showed that the tunnel went down ~32 days ago which is 
>> roughly when G  ANT initiated cage move.
>> So the problem is identified and handled by G  ANT, further investigation 
>> is not needed from your part.
>> Thanks your help though !
>> Frederic
>>> Le 28 ao  t 2022    09:21, mc36 <> a   crit :
>>> 
>>> and finally, it's a wg tunnel and at the moment i really have questions 
>>> about it...
>>> i avoided using ec unless i absolutely had to with a reason: as it turned 
>>> out,
>>> most of the curves are backdoored ( https://safecurves.cr.yp.to/ ) and 
>>> what remains,
>>> provides not too much bits and under the hood, and ec is just a 
>>> multiplication...
>>> more about the question here: 
>>> https://lists.geant.org/sympa/arc/rare-dev/2022-08/msg00082.html
>>> 
>>> 
>>> 
>>> On 8/28/22 08:58, mc36 wrote:
>>>> okkk so just to summarize it up a bit for easier understanding:
>>>> -frederic said to me that it's a geant issue after a cage movement
>>>> -he configured the box to use the wg to nmaas for the oob's default
>>>> and as the wg code last changed 24 days ago (*) and the internet access 
>>>> is down for 12 days:
>>>> he simply asked the nmaas friends of him to shut down the tunnels
>>>> *: 
>>>> https://github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/clnt/clntWireguard.java
>>>> On 8/28/22 08:11, mc36 wrote:
>>>>> so we have a proverb for this in hungary: huzogatod a faszomon a bort 
>>>>> de nem nyeled le
>>>>> 
>>>>> 
>>>>> On 8/28/22 08:00, mc36 wrote:
>>>>>> clearly frederic the fuck are you doing?!?!?!?!?!
>>>>>> 
>>>>>> 
>>>>>> {"date":"2022-08-25T11:31:40.000Z","who":"fl","text":"BTW PAR0101 is 
>>>>>> down, GEANT moved their cage physcally in PAROS and obviously forgot 
>>>>>> things","flags":["incoming"],"remoteId":""}
>>>>>> {"date":"2022-08-25T11:31:43.000Z","who":"mc36","text":"hmm, then imho 
>>>>>> you'll send and i'll receive","flags":["outgoing"],"remoteId":""}
>>>>>> {"date":"2022-08-25T11:32:11.000Z","who":"mc36","text":"par0101 it'll 
>>>>>> recover later right?","flags":["outgoing"],"remoteId":""}
>>>>>> {"date":"2022-08-25T11:32:17.000Z","who":"fl","text":"I'm working with 
>>>>>> GEANT NOC in order to resolve that 
>>>>>> issue","flags":["incoming"],"remoteId":""}
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 8/28/22 07:57, mc36 wrote:
>>>>>>> okkk, btw at that point im pretty sure it was not geant btw.... 
>>>>>>> :))))))))))
>>>>>>> 
>>>>>>> On 8/28/22 07:39, mc36 wrote:
>>>>>>>> well, so the box will die for sure as geant recovers but if you used
>>>>>>>> client proxy clearnet
>>>>>>>> instead of
>>>>>>>> client proxy oob
>>>>>>>> which, is a wg to poznan then you wouldn't have to reinstall it from 
>>>>>>>> scratch...
>>>>>>>> clearly, what you had here is not oob but a tunneled one...
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/28/22 07:34, mc36 wrote:
>>>>>>>>> well it cannot be a routing issue :))))))))))))))))))))))))
>>>>>>>>> 
>>>>>>>>> PAR0101#ping 1.1.1.1 vrf CLEARNET
>>>>>>>>> pinging 1.1.1.1, src=null, vrf=CLEARNET, cnt=5, len=64, df=false, 
>>>>>>>>> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, 
>>>>>>>>> sweep=false, multi=false
>>>>>>>>> !!!!!
>>>>>>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 41, min/avg/max/dev 
>>>>>>>>> rtt=8/8.0/8/0.0, ttl 58/58.0/58/0.0, tos 164/164/164/0.0
>>>>>>>>> PAR0101#ping 195.111.97.109 vrf CLEARNET
>>>>>>>>> pinging 195.111.97.109, src=null, vrf=CLEARNET, cnt=5, len=64, 
>>>>>>>>> df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, 
>>>>>>>>> sweep=false, multi=false
>>>>>>>>> !!!!!
>>>>>>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 157, 
>>>>>>>>> min/avg/max/dev rtt=31/31.4/32/0.2, ttl 249/249/249/0.0, tos 
>>>>>>>>> 0/0.0/0/0.0
>>>>>>>>> PAR0101#
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 8/28/22 07:33, mc36 wrote:
>>>>>>>>>> my bad, i accidentally pinged in the wrong vrf, here is the good 
>>>>>>>>>> one:
>>>>>>>>>> 
>>>>>>>>>> PAR0101#show ipv4 route CLEARNET
>>>>>>>>>> typ     prefix                                         metric     
>>>>>>>>>> iface                             hop                              
>>>>>>>>>>            time
>>>>>>>>>> S             0.0.0.0/0                             1/0            
>>>>>>>>>>      sdn1.666                 62.40.109.30     00:09:39
>>>>>>>>>> C             10.10.10.0/30             0/0                 
>>>>>>>>>> hairpin6661     null                                     11d19h
>>>>>>>>>> LOC     10.10.10.1/32             0/1                 hairpin6661  
>>>>>>>>>>    null                                     11d19h
>>>>>>>>>> C             62.40.109.30/31     0/0                 sdn1.666     
>>>>>>>>>>             null                                     00:09:39
>>>>>>>>>> LOC     62.40.109.31/32     0/1                 sdn1.666           
>>>>>>>>>>       null                                     00:09:39
>>>>>>>>>> 
>>>>>>>>>> PAR0101#
>>>>>>>>>> PAR0101#ping 62.40.109.30 vrf CLEARNET
>>>>>>>>>> pinging 62.40.109.30, src=null, vrf=CLEARNET, cnt=5, len=64, 
>>>>>>>>>> df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, 
>>>>>>>>>> sweep=false, multi=false
>>>>>>>>>> !!!!!
>>>>>>>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 4, min/avg/max/dev 
>>>>>>>>>> rtt=0/0.6/1/0.2, ttl 64/64.0/64/0.0, tos 0/0.0/0/0.0
>>>>>>>>>> PAR0101#
>>>>>>>>>> 
>>>>>>>>>> so from this point, i cannot say a word.... well i could.... :)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 8/28/22 07:25, mc36 wrote:
>>>>>>>>>>> so helping to the irc question of you, that geant is unable to 
>>>>>>>>>>> provide internet access for 12 days now...
>>>>>>>>>>> fortunately the inband mgmt still works so you can help them find 
>>>>>>>>>>> the issue with the vlan666...
>>>>>>>>>>> seemingly we have some traffic and the good arp entry so it must 
>>>>>>>>>>> be a routing or acl issue at geant mx...:)))))))))
>>>>>>>>>>> bad news is that as today i unhold the dpdk21 packages and the 
>>>>>>>>>>> box haven't got the dpdk21.11 so it'll self destruct as geant 
>>>>>>>>>>> recovers.... :(
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> PAR0101#show platform
>>>>>>>>>>> freeRouter v22.7.26-cur, done by cs@nop.
>>>>>>>>>>> 
>>>>>>>>>>> name: PAR0101
>>>>>>>>>>> hwid: Dell Inc. PowerEdge R430/0CN7X8
>>>>>>>>>>> hwsn: null
>>>>>>>>>>> uptime: since 2022-08-16 11:33:15, for 11d19h
>>>>>>>>>>> reload: code#2=upgrade finished
>>>>>>>>>>> rwpath: /rtr/
>>>>>>>>>>> hwcfg: /rtr/rtr-hw.txt
>>>>>>>>>>> swcfg: /rtr/rtr-sw.txt
>>>>>>>>>>> cpu: 40*amd64
>>>>>>>>>>> mem: free=519m, max=1073m, used=1073m
>>>>>>>>>>> host: Linux v5.17.0-2-amd64
>>>>>>>>>>> java: Debian v19-ea @ /usr/lib/jvm/java-19-openjdk-amd64
>>>>>>>>>>> jspec: Oracle Corporation (Java Platform API Specification) v19
>>>>>>>>>>> vm: Debian (OpenJDK 64-Bit Server VM) v19-ea+32-Debian-1
>>>>>>>>>>> vmspec: Oracle Corporation (Java Virtual Machine Specification) 
>>>>>>>>>>> v19
>>>>>>>>>>> class: v63.0 @ /rtr/rtr.jar
>>>>>>>>>>> 
>>>>>>>>>>> PAR0101#show interfaces summary
>>>>>>>>>>> interface                     state     tx                        
>>>>>>>>>>>  rx                                         drop
>>>>>>>>>>> template1                     admin     0                         
>>>>>>>>>>>     0                                             588
>>>>>>>>>>> template666             admin     0                             0 
>>>>>>>>>>>                                             0
>>>>>>>>>>> loopback0                     up                 2402             
>>>>>>>>>>>     0                                             0
>>>>>>>>>>> loopback20965     up                 0                            
>>>>>>>>>>>  0                                             0
>>>>>>>>>>> ethernet0                     up                 45335            
>>>>>>>>>>>  115091610             0
>>>>>>>>>>> ethernet1                     up                 780              
>>>>>>>>>>>        4004                                 4004
>>>>>>>>>>> hairpin6661             up                 486+0             
>>>>>>>>>>> 486+0                             0+0
>>>>>>>>>>> hairpin6662             up                 486+0             
>>>>>>>>>>> 486+0                             0+0
>>>>>>>>>>> sdn1                                         up                 
>>>>>>>>>>> 44351+0     114894232+0     0+0
>>>>>>>>>>> sdn1.102                         up                 3628+0        
>>>>>>>>>>>  3958+0                         0+0
>>>>>>>>>>> sdn1.103                         up                 26429+0     
>>>>>>>>>>> 16116+0                     0+0
>>>>>>>>>>> sdn1.666                         up                 11930+0     
>>>>>>>>>>> 114479534+0     0+0
>>>>>>>>>>> sdn2                                         admin     0+0        
>>>>>>>>>>>              0+0                                     0+0
>>>>>>>>>>> tunnel123                     up                 670+0            
>>>>>>>>>>>  0+0                                     0+0
>>>>>>>>>>> tunnel2075                 up                 5462+0         
>>>>>>>>>>> 4238+0                         0+0
>>>>>>>>>>> 
>>>>>>>>>>> PAR0101#
>>>>>>>>>>> PAR0101#show running-config interface sdn1.666
>>>>>>>>>>> interface sdn1.666
>>>>>>>>>>>       description AMT RLY INTERNET facing interface
>>>>>>>>>>>       monitor-buffer 8192000
>>>>>>>>>>>       vrf forwarding CLEARNET
>>>>>>>>>>>       ipv4 address 62.40.109.31 255.255.255.254
>>>>>>>>>>>       ipv6 address 2001:798:dd:6::6 
>>>>>>>>>>> ffff:ffff:ffff:ffff:ffff:ffff:ffff:fffc
>>>>>>>>>>>       ipv6 enable
>>>>>>>>>>>       no shutdown
>>>>>>>>>>>       no log-link-change
>>>>>>>>>>>       exit
>>>>>>>>>>> !
>>>>>>>>>>> 
>>>>>>>>>>> PAR0101#show ipv4 arp sdn1.666
>>>>>>>>>>> mac                                                 address       
>>>>>>>>>>>                   time                     static
>>>>>>>>>>> a8d0.e5f7.8717     62.40.109.30     00:00:11     false
>>>>>>>>>>> 
>>>>>>>>>>> PAR0101#
>>>>>>>>>>> PAR0101#ping 62.40.109.30 vrf oob
>>>>>>>>>>> pinging 62.40.109.30, src=null, vrf=oob, cnt=5, len=64, df=false, 
>>>>>>>>>>> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, 
>>>>>>>>>>> sweep=false, multi=false
>>>>>>>>>>> .....
>>>>>>>>>>> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5001, 
>>>>>>>>>>> min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 
>>>>>>>>>>> 256/0.0/0/0.0
>>>>>>>>>>> PAR0101#
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>>>>>> Groups.io Links: You receive all messages sent to this group.
>>>>>>>>> View/Reply Online (#645): https://groups.io/g/freertr/message/645
>>>>>>>>> Mute This Topic: https://groups.io/mt/93302745/6006518
>>>>>>>>> Group Owner: 
>>>>>>>>> Unsubscribe: https://groups.io/g/freertr/unsub []
>>>>>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>>>>>> 
>>>>>>>>> 
> <2022-08-29-124441_1920x1080_scrot_000.png>