Rare project developers

[Maria Del Carmen Misa Moreira <>]

Hi Csaba,

So there is something that it can be done to solve this? 
You said that is FRA that ruine the IPv6 packets.

Regards,
Carmen Misa


> On 27 Jan 2023, at 18:02, mc36 <> wrote:
> 
> hi,
> interesting question... :) first of all, attaching you a gp4l emulation 
> entirely in software,
> in that, fra-bud works well, so it indicates that it'll be a long letter... 
> :)
> 
> next check what i've done, as it's bud, and bud-mchome have a direct link 
> (feel free to telnet from bud directly:)
> 
> mchome-demo>ping fd00:51e5::a:1:23:3 vrf p4lab
> 2023-01-27 17:13:52
> pinging fd00:51e5::a:1:23:3, src=null, vrf=p4lab, cnt=5, len=64, df=false, 
> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
> sweep=false, multi=false
> !!!!!
> result=100.0%, recv/sent/lost/err=5/5/0/0, took 27, min/avg/max/dev 
> rtt=5/5.2/6/0.1, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
> mchome-demo>ping fd00:51e5::a:1:23:2 vrf p4lab
> 2023-01-27 17:13:54
> pinging fd00:51e5::a:1:23:2, src=null, vrf=p4lab, cnt=5, len=64, df=false, 
> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
> sweep=false, multi=false
> !!!!!
> result=100.0%, recv/sent/lost/err=5/5/0/0, took 187, min/avg/max/dev 
> rtt=37/37.4/38/0.2, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
> mchome-demo>
> 
> this, after checking the rtt, tells us that if the packet arrives from a 
> different interface,
> then both the /128 and the /120 entries are well programmed in the asic so 
> it must be in bud0001-fra0001 link...
> 
> next what i've checked is p2p protocols over the link, which use multicast, 
> that seems ok:
> 
> BUD0001#show ipv6 ospf 1 neighbor
> interface  area  address              routerid  state  uptime
> sdn1       0     fd00:51e5::a:1:34:4  10.4.4.4  full   00:11:39
> sdn3.1955  0     fd00:51e5::a:1:39:9  10.5.5.5  full   00:11:32
> sdn9       0     fd00:51e5::a:1:23:2  10.2.2.2  init   00:11:32
> 
> BUD0001#
> BUD0001#show ipv6 neighbors sdn9
> mac             address                  time      static  router
> 004e.0503.6d26  fd00:51e5::a:1:23:2      00:00:27  false   false
> 004e.0503.6d26  fe80::24e:5ff:fe03:6d26  00:02:27  false   true
> 
> BUD0001#
> BUD0001#show lldp neighbor
> interface  hostname  iface    ipv4        ipv6
> sdn1       POZ0001   sdn1     10.1.34.4   fd00:51e5::a:1:34:4
> sdn1.10    POZ0001   sdn1.10  10.10.32.2  fd01:10:32::2
> sdn1.20    POZ0001   sdn1.20  10.20.32.2  fd01:20:32::2
> sdn1.30    POZ0001   sdn1.30  10.30.32.2  fd01:30:32::2
> sdn9       FRA0001   sdn2     10.1.23.2   fd00:51e5::a:1:23:2
> sdn9.10    FRA0001   sdn2.10  10.10.43.4  fd01:10:43::4
> sdn9.20    FRA0001   sdn2.20  10.20.43.4  fd01:20:43::4
> sdn9.30    FRA0001   sdn2.30  10.30.43.4  fd01:30:43::4
> 
> BUD0001#
> 
> FRA0001#show lldp neighbor
> interface  hostname  iface     ipv4         ipv6
> sdn1       AMS0001   sdn1      10.1.12.1    fd00:51e5::a:1:12:1
> sdn1.10    AMS0001   sdn1.10   10.10.14.1   fd01:10:14::1
> sdn1.20    AMS0001   sdn1.20   10.20.14.1   fd01:20:14::1
> sdn1.30    AMS0001   sdn1.30   10.30.14.1   fd01:30:14::1
> sdn2       BUD0001   sdn9      10.1.23.3    fd00:51e5::a:1:23:3
> sdn2.10    BUD0001   sdn9.10   10.10.43.3   fd01:10:43::3
> sdn2.20    BUD0001   sdn9.20   10.20.43.3   fd01:20:43::3
> sdn2.30    BUD0001   sdn9.30   10.30.43.3   fd01:30:43::3
> sdn3.103   PAR0101   sdn1.103  10.1.210.10  fd00:51e5::a:1:d2:a
> 
> FRA0001#show ipv6 neighbors sdn2
> mac             address                   time      static  router
> 0050.342c.2656  fd00:51e5::a:1:23:3       00:00:51  false   false
> 0050.342c.2656  fe80::250:34ff:fe2c:2656  00:01:51  false   true
> 
> FRA0001#show ipv6 ospf 1 neighbor
> interface  area  address                  routerid     state  uptime
> sdn1       0     fd00:51e5::a:1:12:1      10.1.1.1     full   00:56:59
> sdn2       0     fd00:51e5::a:1:23:3      10.3.3.3     xchg   00:56:58
> sdn3.103   0     fd00:51e5::a:1:d2:a      10.10.10.10  full   00:56:59
> sdn3.1213  0     fd00:515e:4bd::a:c:d:2b  10.9.9.9     full   00:56:53
> 
> FRA0001#
> 
> one interesting observation is that bud reports fra as init,
> whereas fra reports bud as xchg... ospf do the discovery in
> multicast, then it unicasts... init indicates that the hello
> packets are arriving at bud, xchg indicates that fra gets
> the unicast dbd replies to these...
> 
> next i flooded the link from bud... these logs are gone as i was logged 
> directly and when i reached the end, my terminal closed...
> so during the flood, from bud->fra, i saw fra getting the packets all the 
> way, both in sw and in hw counters, and it responded...
> next i flooded the other direction, fra->bud, and in bud i saw them 
> arriving in hw, but not in sw counters.. even eth0 was quite...
> then i did a "reload cold" on bud side just to be sure and to fully reset 
> the asic, and when it booted, i got a working ospf and ping:
> 
> BUD0001#show ipv6 ospf 1 neighbor
> interface  area  address              routerid  state  uptime
> sdn1       0     fd00:51e5::a:1:34:4  10.4.4.4  full   00:00:25
> sdn3.1955  0     fd00:51e5::a:1:39:9  10.5.5.5  full   00:00:26
> sdn9       0     fd00:51e5::a:1:23:2  10.2.2.2  full   00:00:26
> 
> BUD0001#ping fd00:51e5::a:1:23:2 vrf CORE
> pinging fd00:51e5::a:1:23:2, src=null, vrf=CORE, cnt=5, len=64, df=false, 
> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
> sweep=false, multi=false
> !!!!!
> result=100.0%, recv/sent/lost/err=5/5/0/0, took 78, min/avg/max/dev 
> rtt=15/15.4/16/0.2, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
> BUD0001#
> 
> but while i sentenced these about the flood ping above, the connection 
> become unidirectional again:
> 
> BUD0001#show ipv6 ospf 1 neighbor
> interface  area  address              routerid  state  uptime
> sdn1       0     fd00:51e5::a:1:34:4  10.4.4.4  full   00:01:53
> sdn3.1955  0     fd00:51e5::a:1:39:9  10.5.5.5  full   00:03:18
> sdn9       0     fd00:51e5::a:1:23:2  10.2.2.2  init   00:01:00
> 
> BUD0001#
> 
> next i reload cold-ed fra just to be sure, but i personally i didn't given 
> this too much chance...
> and seemingly this is what resulted in a working connection that lasts... 
> all this directs me
> to the conclusion that somehow the fra asic ruined the ipv6 packets on 
> sending, but only when
> they were unicasted? or maybe it was just the transport network, who 
> knows... im pretty sure
> that it was not freerouter simply because reload colds i pushed out the 
> today release which
> did a reload warm, moreover i tried clear p4 p4 on both sides which is the 
> dataplane version
> of reload warm...
> 
> br,
> cs
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 1/27/23 16:45, Maria Del Carmen Misa Moreira wrote:
>> Hi,
>> IPv4 is working on the interface sdn2 FRA and sdn9 BUD but not in IPv6
>>    FRA0001#ping 10.20.43.4 vrf VRF_CMS
>>    pinging 10.20.43.4, src=null, vrf=VRF_CMS, cnt=5, len=64, df=false, 
>> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
>> sweep=false, multi=false
>>    !!!!!
>>    result=100.0%, recv/sent/lost/err=5/5/0/0, took 0, min/avg/max/dev 
>> rtt=0/0.0/0/0.0, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>>    FRA0001#
>>    FRA0001#ping fd00:51e5::a:1:23:3 vrf CORE
>>    pinging fd00:51e5::a:1:23:3, src=null, vrf=CORE, cnt=5, len=64, 
>> df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
>> sweep=false, multi=false
>>    .....
>>    result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, 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
>>    FRA0001#
>>    FRA0001#ping fd01:20:43::3 vrf VRF_CMS
>>    pinging fd01:20:43::3, src=null, vrf=VRF_CMS, cnt=5, len=64, df=false, 
>> tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
>> sweep=false, multi=false
>>    .....
>>    result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, 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
>> However IPv6 is working in one VRF
>>    FRA0001#ping fd01:10:43::4 vrf VRF_ATLAS
>>    pinging fd01:10:43::4, src=null, vrf=VRF_ATLAS, cnt=5, len=64, 
>> df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, 
>> sweep=false, multi=false
>>    !!!!!
>>    result=100.0%, recv/sent/lost/err=5/5/0/0, took 0, min/avg/max/dev 
>> rtt=0/0.0/0/0.0, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>> I have the same configuration in AMS and POZ and both are working fine.
>> Any idea?
>> Thanks in advance,
>> Carmen Misa
> <zzz.zip>

Attachment: smime.p7s
Description: S/MIME cryptographic signature