Rare project developers

[mc36 <>]

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

Attachment: zzz.zip
Description: Zip archive