| Ablu | Anyway, Either I am misunderstanding the output of dump-flows (it should print the flow table, right?) or something is going wrong. The creation and deletion of SFC resources does not seem to have any effect on the output of dump-flows. I would have expected that port chains would result in at least an additional entry, but that does not seem to be the case... Does anyone have any pointers regarding next steps in | 08:51 |
|---|---|---|
| Ablu | debugging this? | 08:51 |
| Ablu | Ok, https://youtu.be/0NF9cP1t5hg?t=639 shows that the dump-flows output shows new entries. So I guess I understood the output correctly | 09:03 |
| Ablu | hm. I see https://paste.fedoraproject.org/paste/wmng44mVMKfoqO3VMc1lqg in the logs, so it seems to at least attempt to create the flow entry | 10:34 |
| Ablu | HA. Found it. While `/etc/neutron/plugins/ml2/ml2_conf.ini` existed it was in fact not loaded by `neutron-openvswitch-agent`. So I had to place it in `/etc/neutron/plugins/ml2/openvswitch_agent.ini`. | 10:53 |
| Ablu | That was quite a learning curve... I enabled logging and followed the source code. Somehow the jump from neutron-server to the agent was not working (and apparently not generating any errors)? Anyway, sorry for the long monologue! | 10:56 |
| Ablu | Is there any way to log all packets with actions? I see that my rules hit (n_packets and n_bytes count up), but I do not see them in my target VM (running tcpdump there) | 18:58 |
| Ablu | dump-flows gives me `priority=30,tcp,in_port=77,nw_src=10.0.0.10,nw_dst=10.0.0.12,tp_dst=80 actions=group:1` and dump-groups `group_id=1,type=select,bucket=actions=set_field:fa:16:3e:fd:da:10->eth_dst,resubmit(,5)`. The MAC address there matches with the VM I am running tcpdump in... | 18:59 |
| Ablu | ok. I found out about ovs-appctl and it seems like my packets are submitted to some port 5 which leads to a drop (https://paste.fedoraproject.org/paste/Jk45rG~tE6u3vryHg7nQjw)... But why are they forwarded to this port 5 (trying to figure out what this port is currently) rather than the vm (which has port 78) | 19:23 |
| Ablu | ah, resubmit(,5) does not mean submit to port 5, but table 5... | 19:59 |
| Ablu | table 5 however does not seem to exist... My table looks like: https://paste.fedoraproject.org/paste/GeHwId4xMjUniRjHz0GOZQ (port numbers changed since I redeployed my VMs) | 20:01 |
| Ablu | Ok. Reading the code it looks like table 5 is reserved for cross-subnet forwarding. The software (OSM) which creates the flow classifier seems to automatically append "/32" to the ip addresses... Looks like I need to check on that end. | 20:12 |
| Ablu | hm, even if I widen the subnet it looks like the table 5 is being used. So I guess my issue is that this table 5 is never created/filled? | 20:54 |
| Ablu | Hm. The agent seems to receive `next_group_id` and `next_hop` == `None` which seems to block the path to the table 5 generation at https://git.openstack.org/cgit/openstack/networking-sfc/tree/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#n375 | 21:02 |
| Ablu | Well time to hit the bed for me. Here is a cleaned log of the neutron-server: https://paste.fedoraproject.org/paste/hhU46BeClEG3c8MP1ull3A and here one of the agent: https://paste.fedoraproject.org/paste/5r64gwAOfJaokm0aIImtSg/. If anyone has any clues please give me a hint :) | 21:20 |
| Ablu | Otherwise sorry for the spam 🙈 | 21:20 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!