Note that if I dont use the loopback -- lcp --tunnel interfaces, just use
the plain physical interface to connect the two routers, both frr and bird
are working ok.
It smells a little bit fishy here.
On Fri, Mar 4, 2022 at 4:27 PM Chunhui Zhan <chun...@emmuni.com> wrote:
> Hi, Pim,
> I disable the ping_plugin.so, now the icmp passed through the interface.
>
> I could not make frr work, so tried bird2, but got same results as frr.
> The ospf hello packet was not picked up one of the peer router.
> Here is my test topology
>
> pc1 loop1 ---lcp---vpp1 loopback === gre tunnel ==== vpp2
> loopback---lcp---loop1 pc2
> 10.10.0.201/31
> 10.10.0.200/31
>
> on pc1 tcpdump: both the hello packet are in and the bird show the state
> as Init
> bird> show ospf neighbors
> ospf4:
> Router ID Pri State DTime Interface Router IP
> 127.0.0.200 1 Init/Other 34.845 loop1 10.10.0.200
>
> on pc2, tcpdump show both hello packet are send and receive from the
> interface, but the bird log only show send the hello packet, not recv any.
> so on pc2, the neighor is empty, the bird log contradict with the tcpdump.
>
> Any idea here?
> Thanks.
> Chunhui
>
> pc2 bird log, only send, no recv packets
> 2022-03-05 00:20:21.998 <TRACE> ospf4: HELLO packet sent via loop1
> 2022-03-05 00:20:31.997 <TRACE> device1: Scanning interfaces
> 2022-03-05 00:20:31.999 <TRACE> ospf4: HELLO packet sent via loop1
> 2022-03-05 00:20:41.997 <TRACE> device1: Scanning interfaces
> 2022-03-05 00:20:41.998 <TRACE> kernel4: Scanning routing table
> 2022-03-05 00:20:41.998 <TRACE> kernel4: Pruning table master4
> 2022-03-05 00:20:41.998 <TRACE> kernel6: Pruning table master6
> 2022-03-05 00:20:41.998 <TRACE> ospf4: HELLO packet sent via loop1
>
> but on pc2(10.10.0.200) tcpdump, clearly show the hello packets send also
> recv hello from pc1(10.10.0.201).
> 00:10:01.999053 2a:ab:3c:4d:5e:6f (oui Unknown) > 01:00:5e:00:00:05 (oui
> Unknown), ethertype IPv4 (0x0800), length 78: (tos 0xc0, ttl 1, id 30153,
> offset 0, flags [none], proto OSPF (89), length 64)
> 10.10.0.200 > ospf-all.mcast.net: OSPFv2, Hello, length 44
> Router-ID 127.0.0.200, Backbone Area, Authentication Type: none (0)
> Options [External]
> Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
>
> 00:10:09.994781 2a:ab:3c:4d:5e:7f (oui Unknown) > 01:00:5e:00:00:05 (oui
> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0xc0, ttl 1, id 63898,
> offset 0, flags [none], proto OSPF (89), length 68)
> 10.10.0.201 > ospf-all.mcast.net: OSPFv2, Hello, length 48
> Router-ID 127.0.0.201, Backbone Area, Authentication Type: none (0)
> Options [External]
> Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
> Designated Router 10.10.0.201
> Neighbor List:
> 127.0.0.200
>
>
> the bird.conf basically are same here.
> protocol ospf v2 ospf4 {
> debug all;
> ipv4 { export where source = RTS_DEVICE; import all; };
> area 0 {
> interface "lo" { stub yes; };
> interface "loop1" { type broadcast; cost 5; };
> };
> }
>
>
>
>
>
> On Fri, Mar 4, 2022 at 1:01 AM Pim van Pelt <p...@ipng.nl> wrote:
>
>> +vpp-dev
>>
>> I wasn't aware of a mailinglist outage, but I'm sure it'll solve itself
>> soon enough :-) putting the list back on CC.
>>
>> VPP has a ping plugin, which you are recommended to turn off when using
>> Linux controlplane - see the note all the way at the bottom here:
>> https://s3-docs.fd.io/vpp/22.06/developer/plugins/lcp.html?highlight=ping
>>
>> Leaving the ping plugin on will allow VPP to respond to pings itself (ie
>> not punt them into the TAP device for Linux to see), but as you observed,
>> higher level tools, like FRR, will not receive the packets in this case.
>> You didn't specify it very clearly, but for other readers, I assume when
>> you said 'running FRR, ... only see the hello broadcast packets' , that you
>> meant to run OSPF and you saw hello multicast packets. Incidentally, I
>> don't know why FRR insists on pinging its neighbors before establishing an
>> OSPF adjacency - it seems unnecessary, and even undesirable to me.
>>
>> groet,
>> Pim
>>
>> On Fri, Mar 4, 2022 at 1:15 AM Chunhui Zhan <chun...@emmuni.com> wrote:
>>
>>> Hi, Pim,
>>> The vpp-dev mail group is down, so I DM you here:
>>>
>>> I am using vpp 21.10 plus your private lcp repo
>>> github.com/pimvanpelt/lcpng.git/
>>>
>>> I have a loopback interface 10.10.0.200/31 as bvi on two different
>>> boxes, and gre tunnel them together. The loopback interfaces are lcp to
>>> the hosts.
>>>
>>> I could ssh from one host loopback to another box, icmp ping works too.
>>> But the icmp reply is directly coming from the loopback on the vpp, the
>>> icmp packet was not forwarded to the host interface(verified through
>>> tcpdump).
>>> Running frr on the lcp host interface failed, only see the hello
>>> broadcast packets.
>>>
>>> Does the lcp not work on the loopback interface.
>>>
>>> Thanks.
>>> Chunhui
>>>
>>
>>
>> --
>> Pim van Pelt <p...@ipng.nl>
>> PBVP1-RIPE - http://www.ipng.nl/
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20954): https://lists.fd.io/g/vpp-dev/message/20954
Mute This Topic: https://lists.fd.io/mt/89555183/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
