)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"0f624e0105919dab8ae75cf2a81dd8f943cf1c5d","unresolved":true,"context_lines":[{"line_number":4,"context_line":"Commit:     Andrew Bonney \u003candrew.bonney@bbc.co.uk\u003e"},{"line_number":5,"context_line":"CommitDate: 2024-01-19 14:44:22 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"l3agent: add iptables rule to block mldv2 responses"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Linux sends gratuitous MLDv2 responses upon certain interface"},{"line_number":10,"context_line":"changes. These can be used by upstream switches to identify"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"488b787a_a6e892d6","line":7,"updated":"2024-01-19 16:13:22.000000000","message":"Is mldv2 the only protocol that is problematic here? at the very least, linux kernel may produce mldv1 that, AFAIU, would have identical effect. (This can be enforced with force_mld_version\u003d1 sysctl to reproduce.)\n\nI find this scenario an indication that we don\u0027t have a comprehensive drop-all rule pre-set for backup nodes, and mldv2 leak is just one of potential vectors to sneak through the hole and pollute switches\u0027 arp tables. I wonder if a more general solution should be considered here, that would block any and all packets until keepalived detects master down and takes over.\n\nI am thinking X-Neutron-State handler in L3 agent could install / remove drop-all iptables rules depending on the state of the router (drop-all for backups; remove the rule for masters).","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":31542,"name":"Andrew Bonney","email":"andrew.bonney@bbc.co.uk","username":"andrewbonney"},"change_message_id":"e6e9a962dbca01dc348d668c16efe4dcd332c4f7","unresolved":true,"context_lines":[{"line_number":4,"context_line":"Commit:     Andrew Bonney \u003candrew.bonney@bbc.co.uk\u003e"},{"line_number":5,"context_line":"CommitDate: 2024-01-19 14:44:22 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"l3agent: add iptables rule to block mldv2 responses"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Linux sends gratuitous MLDv2 responses upon certain interface"},{"line_number":10,"context_line":"changes. These can be used by upstream switches to identify"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"2973e875_1b37b8b8","line":7,"in_reply_to":"488b787a_a6e892d6","updated":"2024-01-22 08:15:03.000000000","message":"MLDv2 is the only one we\u0027ve seen an issue with, but I suspect you\u0027re right that forcing MLDv1 would cause similar impact. My intent was to provide a demonstration of something that works in our case as opposed to a comprehensive patch as I don\u0027t have enough knowledge of the code\u0027s history.","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"acc4f37020d21acd584e8889a438b8e857d9c956","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"49b0efb2_9643d90e","updated":"2024-01-19 21:51:17.000000000","message":"I\u0027m not sure if this approach will not break something else as it was tried once before.","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":31542,"name":"Andrew Bonney","email":"andrew.bonney@bbc.co.uk","username":"andrewbonney"},"change_message_id":"d100da30d9f68d2dc16a40453ef47dd18d9f91c9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e582a2bf_5cb3925e","updated":"2024-01-19 14:45:17.000000000","message":"This is a proof of concept fix for #2049909","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"}],"neutron/agent/l3/router_info.py":[{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"0f624e0105919dab8ae75cf2a81dd8f943cf1c5d","unresolved":true,"context_lines":[{"line_number":814,"context_line":"        if enabled:"},{"line_number":815,"context_line":"            self.driver.configure_ipv6_forwarding(ns_name, \u0027all\u0027, enabled)"},{"line_number":816,"context_line":""},{"line_number":817,"context_line":"        interface_name \u003d self.get_external_device_interface_name("},{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"}],"source_content_type":"text/x-python","patch_set":1,"id":"3c950fa1_f45d3d16","line":817,"updated":"2024-01-19 16:13:22.000000000","message":"This blocks mldv2 reports for master too, correct? I am not sure it\u0027s desired since the problem is not with mldv2 per se, but with backup interface leaking frames into fabric, misleading upstream switches.\n\nWould it be safer to limit the rule to just backup?","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":31542,"name":"Andrew Bonney","email":"andrew.bonney@bbc.co.uk","username":"andrewbonney"},"change_message_id":"e6e9a962dbca01dc348d668c16efe4dcd332c4f7","unresolved":true,"context_lines":[{"line_number":814,"context_line":"        if enabled:"},{"line_number":815,"context_line":"            self.driver.configure_ipv6_forwarding(ns_name, \u0027all\u0027, enabled)"},{"line_number":816,"context_line":""},{"line_number":817,"context_line":"        interface_name \u003d self.get_external_device_interface_name("},{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"}],"source_content_type":"text/x-python","patch_set":1,"id":"c9c92d9b_500c6bb2","line":817,"in_reply_to":"3c950fa1_f45d3d16","updated":"2024-01-22 08:15:03.000000000","message":"Yes, I did consider putting the iptables rules within the \u0027if disable_ra\u0027 block. I haven\u0027t tested its effectiveness yet but wouldn\u0027t be surprised if that worked too.","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"0f624e0105919dab8ae75cf2a81dd8f943cf1c5d","unresolved":true,"context_lines":[{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"},{"line_number":821,"context_line":"        mld_rule \u003d \u0027-o %s -p ipv6-icmp -d ff02::16 -j DROP\u0027 % (interface_name)"},{"line_number":822,"context_line":"        ip6tables[\u0027filter\u0027].add_rule(\u0027OUTPUT\u0027, mld_rule)"},{"line_number":823,"context_line":""},{"line_number":824,"context_line":"    def _external_gateway_added(self, ex_gw_port, interface_name,"}],"source_content_type":"text/x-python","patch_set":1,"id":"8455c068_89927b59","line":821,"updated":"2024-01-19 16:13:22.000000000","message":"Assuming the goal is indeed only limiting mld(v2?), should this rule be more specific, to cover only the relevant messages? MLDv2 is using icmp type \u003d 143 for reports. (For MLDv1, it\u0027s 131.)","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"acc4f37020d21acd584e8889a438b8e857d9c956","unresolved":true,"context_lines":[{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"},{"line_number":821,"context_line":"        mld_rule \u003d \u0027-o %s -p ipv6-icmp -d ff02::16 -j DROP\u0027 % (interface_name)"},{"line_number":822,"context_line":"        ip6tables[\u0027filter\u0027].add_rule(\u0027OUTPUT\u0027, mld_rule)"},{"line_number":823,"context_line":""},{"line_number":824,"context_line":"    def _external_gateway_added(self, ex_gw_port, interface_name,"}],"source_content_type":"text/x-python","patch_set":1,"id":"db758984_ccede228","line":821,"in_reply_to":"8455c068_89927b59","updated":"2024-01-19 21:51:17.000000000","message":"I think we tried using iptables in PS1 here: https://review.opendev.org/c/openstack/neutron/+/836198/1 but it didn\u0027t work as expected.\n\nThe problem is the kernel sends these packets when forwarding changes on an interface, hence the comment above. We\u0027ve had many bugs [0][1] and tried many fixes which seem to work, but something is missed.\n\nThe change https://review.opendev.org/c/openstack/neutron/+/707406 really should have addressed this problem I believe, but I wonder if Linuxbridge is different here than ML2/OVS?\n\n[0] https://bugs.launchpad.net/neutron/+bug/1787919\n[1] https://bugs.launchpad.net/neutron/+bug/1859832","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"945cb485c77aa0303cf04cc924242c3eab593261","unresolved":true,"context_lines":[{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"},{"line_number":821,"context_line":"        mld_rule \u003d \u0027-o %s -p ipv6-icmp -d ff02::16 -j DROP\u0027 % (interface_name)"},{"line_number":822,"context_line":"        ip6tables[\u0027filter\u0027].add_rule(\u0027OUTPUT\u0027, mld_rule)"},{"line_number":823,"context_line":""},{"line_number":824,"context_line":"    def _external_gateway_added(self, ex_gw_port, interface_name,"}],"source_content_type":"text/x-python","patch_set":1,"id":"b7022dc3_735f0fab","line":821,"in_reply_to":"c081010a_e37c2920","updated":"2024-01-29 21:49:56.000000000","message":"The patch (707406) was partially reverted, specifically the part that manages the link state: https://review.opendev.org/c/openstack/neutron/+/834162\n\nIt looks like the state transition should happen, just not in X-Neutron-State handler. It may be more important then to fix https://bugs.launchpad.net/neutron/+bug/1677279 that suggests to move interface parameters management to state-change script triggered by keepalived. (We could then also put link state up/down commands into the script too.)","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"},{"author":{"_account_id":31542,"name":"Andrew Bonney","email":"andrew.bonney@bbc.co.uk","username":"andrewbonney"},"change_message_id":"e6e9a962dbca01dc348d668c16efe4dcd332c4f7","unresolved":true,"context_lines":[{"line_number":818,"context_line":"            ex_gw_port)"},{"line_number":819,"context_line":"        ip6tables \u003d self.iptables_manager.get_tables("},{"line_number":820,"context_line":"            lib_constants.IP_VERSION_6)"},{"line_number":821,"context_line":"        mld_rule \u003d \u0027-o %s -p ipv6-icmp -d ff02::16 -j DROP\u0027 % (interface_name)"},{"line_number":822,"context_line":"        ip6tables[\u0027filter\u0027].add_rule(\u0027OUTPUT\u0027, mld_rule)"},{"line_number":823,"context_line":""},{"line_number":824,"context_line":"    def _external_gateway_added(self, ex_gw_port, interface_name,"}],"source_content_type":"text/x-python","patch_set":1,"id":"c081010a_e37c2920","line":821,"in_reply_to":"db758984_ccede228","updated":"2024-01-22 08:15:03.000000000","message":"Regarding the second patch, and looking at our network nodes in an LXB environment, all of the backup gateway interfaces for tenants are \u0027up\u0027. In fact, we\u0027ve seen issues previously where if they\u0027re down and keepalived/VRRP fails over, the interface isn\u0027t brought up and tenant connectivity fails.","commit_id":"a475b0f9a53935ff3305a1a9ab61241de71f44b6"}]}