Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IP2ME and Subnet (local) routes are not created for VLAN interface. #180

Closed
oleksandrivantsiv opened this issue Mar 23, 2017 · 4 comments
Closed
Assignees
Labels

Comments

@oleksandrivantsiv
Copy link
Collaborator

Steps to reproduce:

  • Prepare minigraph file with VLAN interface and at least one port attached to that interface
  • load minigraph
  • reboot device
  • Try to ping VLAN interface IP address

Observed behavior:
ARP request packets are trapped to the CPU. VLAN interface sends ARP replay.
ICMP packets with destination IP address equal to VLAN interface IP address are not trapped.
No notice messages about subnet and IP2ME routes creation for VLAN interface in logs.

@stcheng
Copy link
Contributor

stcheng commented Mar 23, 2017

I think the reason is that the VLAN subnet and the IP2ME routes are not created on the VLAN interface.
Could you check:

  1. If the VLAN interface is created on the kernel and the IP address is assigned to the interface and the interface status is UP?
  2. Does this issue happen every time?
  3. Check in the APP_DB the subnet route and IP2ME route is there or not.

@oleksandrivantsiv
Copy link
Collaborator Author

VLAN interface is up and has IP address:

cat /etc/network/interfaces
...
#
auto Ethernet0
allow-hotplug Ethernet0
iface Ethernet0 inet manual
    pre-up ifconfig Ethernet0 up
    post-up brctl addif VlanIntf100 Ethernet0
    post-down ifconfig Ethernet0 down
#
# Add || true to suppress the error when docker-teamd starts after docker-swss
auto VlanIntf100
iface VlanIntf100 inet static
    bridge_ports none
    address 10.0.0.0
    netmask 255.255.255.0
ifconfig VlanIntf100
VlanIntf100 Link encap:Ethernet  HWaddr 24:8a:07:05:31:40
          inet addr:10.0.0.0  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::303b:10ff:fed4:b68/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9216  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:506 (506.0 B)  TX bytes:23116 (22.5 KiB)
4: VlanIntf100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9216 qdisc noqueue state UP mode DEFAULT group default
    link/ether 24:8a:07:05:31:40 brd ff:ff:ff:ff:ff:ff
root@arc-switch1028:/home/admin# ip link show Ethernet0
35: Ethernet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9216 qdisc pfifo_fast master VlanIntf100 state UP mode DEFAULT group default qlen 1000
    link/ether 24:8a:07:05:31:40 brd ff:ff:ff:ff:ff:ff

Issue is reproducible every time.
Subnet route exists in RedisDB. IP2ME doesn't exist:

127.0.0.1:6379> KEYS *ROUTE*10.0.0.0*
1) "ROUTE_TABLE:10.0.0.0/24"
127.0.0.1:6379> HGETALL "ROUTE_TABLE:10.0.0.0/24"
1) "nexthop"
2) ""
3) "ifname"
4) "VlanIntf100"

In logs I see that IP2ME routes for other interfaces are created:

root@arc-switch1028:/home/admin# cat /var/log/messages | grep "Create IP2me route ip"
...
Mar 24 09:04:01 arc-switch1028 NOTICE orchagent: :- addIp2MeRoute: Create IP2me route ip:10.0.0.56
Mar 24 09:04:01 arc-switch1028 NOTICE orchagent: :- addIp2MeRoute: Create IP2me route ip:10.0.0.44
Mar 24 09:04:01 arc-switch1028 NOTICE orchagent: :- addIp2MeRoute: Create IP2me route ip:10.0.0.62

For VLAN interface is not created:

root@arc-switch1028:/home/admin# cat /var/log/messages | grep "Create IP2me route ip" | grep 10.0.0.0
root@arc-switch1028:/home/admin#

When trying to ping host I see that ICMP packets reach host. Host generates reply but replay is not trapped to CPU:
On switch:

root@arc-switch1028:/home/admin# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
root@arc-switch1028:/home/admin# tcpdump -vvv -i Ethernet0
tcpdump: listening on Ethernet0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:22:05.308626 IP (tos 0xc0, ttl 1, id 40869, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.0.0.46433 > 10.0.0.1.bgp: Flags [S], cksum 0x6582 (correct), seq 2810428925, win 27528, options [mss 9176,sackOK,TS val 207160 ecr 0,nop,wscale 7], length 0
09:22:05.670743 IP (tos 0x0, ttl 64, id 27625, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.0 > 10.0.0.1: ICMP echo request, id 5364, seq 8, length 64
09:22:06.678778 IP (tos 0x0, ttl 64, id 27860, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.0 > 10.0.0.1: ICMP echo request, id 5364, seq 9, length 64
09:22:07.686753 IP (tos 0x0, ttl 64, id 27988, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.0 > 10.0.0.1: ICMP echo request, id 5364, seq 10, length 64
^C

On host:

[root@arc-host61-005 ~]# tcpdump -vvv -i eth1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:22:08.932720 IP (tos 0xc0, ttl 1, id 40870, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.0.0.46433 > 10.0.0.1.bgp: Flags [S], cksum 0x5dae (correct), seq 2810428925, win 27528, options [mss 9176,sackOK,TS val 209164 ecr 0,nop,wscale 7], length 0
12:22:08.932733 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.0.0.1.bgp > 10.0.0.0.46433: Flags [R.], cksum 0x8039 (correct), seq 0, ack 2810428926, win 0, length 0
12:22:09.342781 IP (tos 0x0, ttl 64, id 28549, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.0 > 10.0.0.1: ICMP echo request, id 5364, seq 16, length 64
12:22:09.342829 IP (tos 0x0, ttl 64, id 7829, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.0: ICMP echo reply, id 5364, seq 16, length 64
12:22:10.351495 IP (tos 0x0, ttl 64, id 28650, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.0 > 10.0.0.1: ICMP echo request, id 5364, seq 17, length 64
12:22:10.351520 IP (tos 0x0, ttl 64, id 7830, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.0: ICMP echo reply, id 5364, seq 17, length 64

@stcheng
Copy link
Contributor

stcheng commented Mar 24, 2017

@oleksandrivantsiv
Could you change the VLAN name to Vlan100?
Currently it is the limitation that the VLAN names should be "Vlan****" the prefix "Vlan" following with the VLAN ID. So is the port channel interfaces' name as "PortChannel**".

Please modify the minigraph and see if the VLAN could be created or not.

We will enhance the logic in the future for the interface names.

@stcheng stcheng self-assigned this Mar 24, 2017
@oleksandrivantsiv
Copy link
Collaborator Author

@stcheng With prefix "Vlan" it works fine,

EdenGri pushed a commit to EdenGri/sonic-swss that referenced this issue Feb 28, 2022
oleksandrivantsiv pushed a commit to oleksandrivantsiv/sonic-swss that referenced this issue Mar 1, 2023
* Add sairedis bulk route_entry set

* Add sairedis bulk route_entry set tests

* Support bulk route set in syncd

* Fix test for bulkset

* Sai player support bulk route set api

* Disable tests temporary

* Fix return bug

* Enable tests

* Add try/catch to tests

* Temporary disable tests until fix in build environment
lukasstockner pushed a commit to genesiscloud/sonic-swss that referenced this issue Apr 2, 2023
…t#180)

Two new functions have been added to thermal_base.py for setting critical temperature thresholds.

Signed-off-by: d-dashkov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants