Hi,
I have configured mGRE tunnel on VPP with one peer. What I noticed in GRE
multipoint case is that the show adjacency is displaying an entry with "
*arp-ipv4*" type which was NOT there when I configured only GRE P2P. Under
this situation, there is a crash in the main_thread pointing to ARP
resolution call stack as shown below.
Has someone tested mGRE and faced a crash like this?
Please let me know if something is missing from my side.
*LOGS (GRE multipoint case)*
*=========================*
vpp# show gre tunnel
[0] instance 0 src 20.20.99.99 dst 0.0.0.0 fib-idx 1 sw-if-idx 18 payload
L3 multi-point
vpp#
vpp# show teib
[0] gre0: 2.2.2.1 via [1]:20.20.99.99/32
vpp#
vpp#
vpp# show adj
[@0] ipv4-glean: loop0: mtu:9000 next:1 ffffffffffffdead000000000806
[@1] ipv4-glean: loop1: mtu:9000 next:2 ffffffffffffdead000000010806
[@2] ipv4 via 0.0.0.0 memif0/0: mtu:65535 next:3
[@3] ipv4 via 0.0.0.0 memif0/1: mtu:65535 next:4
[@4] ipv4 via 0.0.0.0 memif0/2: mtu:65535 next:5
[@5] ipv4 via 0.0.0.0 memif128/0: mtu:65535 next:6
[@6] ipv4 via 0.0.0.0 memif128/1: mtu:65535 next:7
[@7] ipv4 via 0.0.0.0 memif128/2: mtu:65535 next:8
[@8] ipv4-glean: VirtualFuncEthernet0/6/0.1556: mtu:9000 next:3
fffffffffffffa163e9a2c38810006140806
[@9] ipv4 via 0.0.0.0 memif192/0: mtu:65535 next:9
[@10] ipv4 via 0.0.0.0 memif192/1: mtu:65535 next:10
[@11] ipv4 via 0.0.0.0 memif192/2: mtu:65535 next:11
[@12] ipv4 via 0.0.0.0 memif210/0: mtu:65535 next:12
[@13] ipv4 via 0.0.0.0 memif210/1: mtu:65535 next:13
[@14] ipv4 via 0.0.0.0 memif210/2: mtu:65535 next:14
*[@15] arp-ipv4: via 7.7.7.7 gre0*
vpp#
vpp#
vpp# show ip fib
7.7.7.7/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:79 buckets:1 uRPF:97 to:[0:0]]
[0] [@3]: arp-ipv4: via 7.7.7.7 gre0
*LOGS (GRE P2P case)*
*====================*
vpp#create gre tunnel src 20.20.99.99 dst 20.20.99.215 outer-table-id 1
vpp#set interface ip address gre0 2.2.2.2/32
vpp#set interface state gre0 up
vpp#ip route add 7.7.7.7/32 via gre0
vpp# show adj
[@0] ipv4-glean: loop0: mtu:9000 next:1 ffffffffffffdead000000000806
[@1] ipv4-glean: loop1: mtu:9000 next:2 ffffffffffffdead000000010806
[@2] ipv4 via 0.0.0.0 memif0/0: mtu:65535 next:3
[@3] ipv4 via 0.0.0.0 memif0/1: mtu:65535 next:4
[@4] ipv4 via 0.0.0.0 memif0/2: mtu:65535 next:5
[@5] ipv4 via 0.0.0.0 memif128/0: mtu:65535 next:6
[@6] ipv4 via 0.0.0.0 memif128/1: mtu:65535 next:7
[@7] ipv4 via 0.0.0.0 memif128/2: mtu:65535 next:8
[@8] ipv4 via 0.0.0.0 memif192/0: mtu:65535 next:9
[@9] ipv4 via 0.0.0.0 memif192/1: mtu:65535 next:10
[@10] ipv4 via 0.0.0.0 memif192/2: mtu:65535 next:11
[@11] ipv4-glean: VirtualFuncEthernet0/7/0.1556: mtu:9000 next:3
fffffffffffffa163ec2b4f4810006140806
[@12] ipv4 via 0.0.0.0 memif210/0: mtu:65535 next:12
[@13] ipv4 via 0.0.0.0 memif210/1: mtu:65535 next:13
[@14] ipv4 via 0.0.0.0 memif210/2: mtu:65535 next:14
*[@15] ipv4 via 0.0.0.0 gre0: mtu:9000 next:15
4500000000000000fe2fcd6c14146363141463d700000800 stacked-on entry:77:
[@3]: ipv4 via 20.20.99.215 VirtualFuncEthernet0/7/0.1556: mtu:1500 next:16
fa163e4b6b42fa163ec2b4f4810006140800[@16] ipv4 via 20.20.99.215
VirtualFuncEthernet0/7/0.1556: mtu:1500 next:16
fa163e4b6b42fa163ec2b4f4810006140800*
vpp#
vpp#
Crash call stack during mGRE testing
===========================================
#0 0x00007fc5d0ca3ac1 in pthread_kill () from /lib64/libpthread.so.0
#1 0x00007fc5d12aec98 in outputBacktraceThreads () at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vppinfra/vcrash.c:538
#2 vCrash_handler (signo=signo@entry=11) at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vppinfra/vcrash.c:718
#3 0x00007fc5d1bc681f in unix_signal_handler (signum=11, si=<optimized
out>, uc=<optimized out>) at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vlib/unix/main.c:193
#4 <signal handler called>
#5 0x00007fc5d2b68a37 in clib_memcpy_fast (n=6, src=0x0, dst=0x1012825e48)
at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vppinfra/memcpy_sse3.h:213
#6 mac_address_from_bytes (bytes=0x0, mac=0x1012825e48) at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vnet/ethernet/mac_address.h:95
#7 ip4_neighbor_probe (dst=<synthetic pointer>, src=<synthetic pointer>,
adj0=0x7fc59ab12900, vnm=0x7fc5d3215180 <vnet_main>, vm=<optimized out>)
at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vnet/ip-neighbor/ip4_neighbor.h:56
#8 ip4_arp_inline (is_glean=0, frame=<optimized out>, node=0x7fc59ad27640,
vm=0x7fc5d1de1300 <vlib_global_main>)
at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vnet/ip-neighbor/ip4_neighbor.c:217
#9 ip4_arp_node_fn (vm=0x7fc5d1de1300 <vlib_global_main>,
node=0x7fc59ad27640, frame=0x7fc59af26cc0)
at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vnet/ip-neighbor/ip4_neighbor.c:242
#10 0x00007fc5d1b81c93 in dispatch_node (last_time_stamp=<optimized out>,
frame=0x7fc59af26cc0, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x7fc59ad27640,
vm=0x7fc5d1de1300 <vlib_global_main>) at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vlib/main.c:1271
#11 dispatch_pending_node (vm=vm@entry=0x7fc5d1de1300 <vlib_global_main>,
pending_frame_index=pending_frame_index@entry=1, last_time_stamp=<optimized
out>)
at
/usr/src/debug/vpp-20.05.1-2~g190cc47ed_dirty.x86_64/src/vlib/main.c:1460
Regards,
Vijay Kumar N
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18915): https://lists.fd.io/g/vpp-dev/message/18915
Mute This Topic: https://lists.fd.io/mt/81344488/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
