{"id":2164,"date":"2021-11-19T13:19:46","date_gmt":"2021-11-19T13:19:46","guid":{"rendered":"https:\/\/www.hostinger.com\/blog\/?p=2164"},"modified":"2022-03-29T13:15:59","modified_gmt":"2022-03-29T13:15:59","slug":"network-validation-evolution-at-hostinger-part-2","status":"publish","type":"post","link":"https:\/\/www.hostinger.com\/blog\/network-validation-evolution-at-hostinger-part-2","title":{"rendered":"Network Validation Evolution at Hostinger [Part 2]"},"content":{"rendered":"

In our previous post<\/a>, we discussed how Hostinger started using network validation before going live. By implementing network validation for our core network, we have maintained complete control over running the network at scale. <\/p>

Among other things, the post summarizes the use of Suzieq<\/a> to validate key aspects of the network. This time, we’ll get into more detail on how Hostinger uses Suzieq to perform network validation and cover a more detailed overview of Batfish<\/a>. <\/p>

To give you some numbers, we have 9 data centers (DCs) around the globe, with more coming soon. Each DC is different in terms of size – it can span from a couple to tens of racks per data center.  Using automation on top of that doesn’t make a considerable difference, despite how quickly changes are pushed to production. For the end customer, using services provided by a company that continuously contributes and performs network validation adds to building the foundation of trust and reliability of Hostinger products.<\/p>

Suzieq<\/strong><\/h2>

Continuously Running Poller Vs Snapshot<\/h3>

One of the first decisions we had to make with any tool we used to perform network validation was whether to run the poller in standalone mode or in continuously running mode.<\/p>

A continuously running poller has a higher engineering cost, no matter the tool, though it is the correct approach. With it, the poller has to be running all the time, and it must be highly available, i.e. the poller must recover from failures.<\/p>

Running the poller in the snapshot mode is trivial from a maintainability perspective. It can be run independently in any environment – on a local machine (workstation) or in CI\/CD without a need to have any running service in mind. In our case, we poll the data once and then run the Python tests. At Hostinger, we have deployments spread across many geographic regions – Asia, Europe, US, and we have multiple DCs in each of these regions. We use Jenkins for our CI\/CD pipeline. To ensure we run the same tests across all regions, we launch multiple Jenkins slaves. If we’d used a continuously running poller, the engineering cost would’ve been higher to set up and maintain.  <\/p>

Here’s an example of running sq-poller<\/strong> (running in a loop for each DC or region):<\/p>

for DC in \"${DATACENTERS[@]}\"\ndo\n  python generate_hosts_for_suzieq.py --datacenter \"$DC\"\n  ..\/bin\/sq-poller --devices-file \"hosts-$DC.yml\" \\\n    --ignore-known-hosts \\\n    --run-once gather \\\n    --exclude-services devconfig\n  ..\/bin\/sq-poller --input-dir .\/sqpoller-output\n  python -m pytest -s -v --no-header \"test_$DC.py\" || exit 5\ndone<\/pre>
You might be asking whether this combination of commands is necessary.<\/p>
generate_hosts_for_suzieq.py<\/strong> serves as a wrapper to generate hosts from the Ansible inventory but with more sugar inside, like skipping specific hosts, setting ansible_host<\/strong> dynamically (because our OOB network is highly available, it means we have several doors to access it). <\/p>
The generated file looks similar to:<\/p>
- namespace: xml\n  hosts:\n    - url: ssh:\/\/root@xml-oob.example.org:2232 keyfile=~\/.ssh\/id_rsa\n    - url: ssh:\/\/root@xml-oob.example.org:2223 keyfile=~\/.ssh\/id_rsa<\/pre>
Why bundle run-once and sq-poller? There is an already open issue<\/a> that is going to solve this problem. Eventually, it requires just adding a single –snapshot<\/em> option, and that’s it.<\/p>
Workflow for Validating Changes<\/h3>
Every new pull request (PR) creates a fresh, clean Python virtual environment (Pyenv) and starts the tests. The same happens when a PR is merged. <\/p>
The simplified workflow was: <\/p>
  1. Make changes.<\/li>
  2. Commit changes, create a PR on GitHub.<\/li>
  3. Poll and run PyTest tests with Suzieq (\/tests\/run-tests.sh <region|all><\/em>).<\/li>
  4. We require tests to be green before a PR is allowed to merge. <\/li>
  5. Merge the PR.<\/li>
  6. Iterate it on all our DCs one by one – deploy, and run post-deployment PyTests again.<\/li><\/ol>
    Something like:<\/p>
    stage('Run pre-flight production tests') {\n  when {\n    expression {\n      env.BRANCH_NAME != 'master' &amp;&amp; !(env.DEPLOY_INFO ==~ \/skip-suzieq\/)\n    }\n  }\n  parallel {\n    stage('EU') {\n      steps {\n        sh '.\/tests\/prepare-tests-env.sh &amp;&amp; .\/tests\/run-tests.sh ${EU_DC}'\n      }\n    }\n    stage('Asia') {\n      agent {\n        label 'deploy-sg'\n      }\n    }<\/pre>
    Handling False Positives<\/h3>
    Every test has a chance of a false positive, i.e. the test reveals a problem that is not real. This can be true if it’s a test for a disease or a test for verifying a change. At Hostinger, we assume that false positives will happen, and that’s normal. So, how do we handle them, and when? <\/p>
    In our environment, false positives occur mostly due to timeouts, connection errors during the scraping phase (poller), or when bootstrapping a new device. In such a case, we re-run the tests until it’s fixed (green in the Jenkins pipeline). But if we have a permanent failure (most likely a real one), tests always remain in a red state. This means the PR does not get merged, and the changes are not deployed. <\/p>
    However, in the case of a false positive, we use a Git commit tag Deploy-Info: skip-suzieq<\/strong> to tell Jenkins pipelines to ignore tests after we see this behavior (as you may have noticed before in the pipeline file). <\/p>
    Adding New Tests<\/h3>
    We test new or modified tests locally first before they land in the Git repository. To add a useful test, it needs to be tested multiple times unless it’s really trivial. For example:<\/p>
    def bgp_sessions_are_up(self):\n    # Test if all BGP sessions are UP\n    assert (\n        get_sqobject(\"bgp\")().get(namespace=self.namespace, state=\"NotEstd\").empty\n    )<\/pre>
    But if we are talking about something like<\/p>
    def uniq_asn_per_fabric(self):\n    # Test if we have a unique ASN per fabric\n    asns = {}\n    for spine in self.spines.keys():\n        for asn in (\n            get_sqobject(\"bgp\")()\n            .get(hostname=[spine], query_str=\"afi == 'ipv4' and safi == 'unicast'\")\n            .peerAsn\n        ):\n            if asn == 65030:\n                continue\n            if asn not in asns:\n                asns[asn] = 1\n            else:\n                asns[asn] += 1\n    assert len(asns) &gt; 0\n    for asn in asns:\n        assert asns[asn] == len(self.spines.keys())<\/pre>
    This needs to be carefully reviewed. Here we check if we have a unique AS number per DC. Skipping 65030 is used for routing on the host<\/em> instances to announce some anycast services like DNS, load balancers, etc. This is the snippet of tests output (summary):<\/p>
    test_phx.py::test_bgp_sessions_are_up PASSED\ntest_phx.py::test_loopback_ipv4_is_uniq_per_device PASSED\ntest_phx.py::test_loopback_ipv6_is_uniq_per_device PASSED\ntest_phx.py::test_uniq_asn_per_fabric PASSED\ntest_phx.py::test_upstream_ports_are_in_correct_state PASSED\ntest_phx.py::test_evpn_fabric_links PASSED\ntest_phx.py::test_default_route_ipv4_from_upstreams PASSED\ntest_phx.py::test_ipv4_host_routes_received_from_hosts PASSED\ntest_phx.py::test_ipv6_host_routes_received_from_hosts PASSED\ntest_phx.py::test_evpn_fabric_bgp_sessions PASSED\ntest_phx.py::test_vlan100_assigned_interfaces PASSED\ntest_phx.py::test_evpn_fabric_arp PASSED\ntest_phx.py::test_no_failed_interface PASSED\ntest_phx.py::test_no_failed_bgp PASSED\ntest_phx.py::test_no_active_critical_alerts_firing PASSED\ntest_imm.py::test_bgp_sessions_are_up PASSED\ntest_imm.py::test_loopback_ipv4_is_uniq_per_device PASSED\ntest_imm.py::test_loopback_ipv6_is_uniq_per_device PASSED\ntest_imm.py::test_uniq_asn_per_fabric FAILED\ntest_imm.py::test_upstream_ports_are_in_correct_state PASSED\ntest_imm.py::test_default_route_ipv4_from_upstreams PASSED\ntest_imm.py::test_ipv4_host_routes_received_from_hosts PASSED\ntest_imm.py::test_ipv6_host_routes_received_from_hosts PASSED\ntest_imm.py::test_no_failed_bgp PASSED\ntest_imm.py::test_no_active_critical_alerts_firing PASSED<\/pre>
    Here, we notice that this DC’s test_imm.py::test_uniq_asn_per_fabric <\/em>test has failed. Since we use an auto-derived ASN per switch (no static AS numbers in the Ansible inventory), a race could happen that might have a duplicate ASN, which is bad. Or something like:<\/p>
    def loopback_ipv6_is_uniq_per_device(self):\n    # Test if we don't have duplicate IPv6 loopback address\n    addresses = get_sqobject(\"address\")().unique(\n        namespace=[self.namespace],\n        columns=[\"ip6AddressList\"],\n        count=True,\n        type=\"loopback\",\n    )\n    addresses = addresses[addresses.ip6AddressList != \"::1\/128\"]\n    assert (addresses.numRows == 1).all()<\/pre>
    This is done to check whether we have a duplicate IPv6 loopback address per device for the same data center. This rule is valid and was proven at least a couple of times. It mostly occurs when we bootstrap a new switch and the Ansible host file is copy-pasted. <\/p>
    Mainly new tests are added when a failure occurs, and some actions need to be taken to quickly catch them or mitigate them in advance in the future. For instance, if we switch from an L3-only to EVPN design, we might be surprised when ARP\/ND exhaustion hits a wall, or L3 routes drop from several thousand to just a few. <\/p>
    Batfish<\/h2>
    We have already evaluated Batfish<\/a> twice. The first was kind of an overview and dry-run to see its opportunities for us. The first impression was something like “What’s wrong with my configuration?<\/em>” because, at that time, Batfish didn’t support some of the configuration syntaxes for FRR<\/a>. FRR<\/a> is used by Cumulus Linux and many other massive projects. It’s becoming the de-facto best open-source routing suite. And that’s why Batfish has FRR as a vendor included as well.  It’s just that FRR as a model needs more changes before being used in production (at least in our environment). <\/p>
    Later on, a month or two ago, we began investigating the product again to see what could really be done. From the operational perspective, it’s a really cool product because it allows the operator to construct the network model by parsing configuration files. On top of that, you can create snapshots, make some changes and see how your network behaves. For example, disable a link or a BGP peer and predict the changes before they go live. <\/p>
    We started looking at Batfish as an open-source project too to push changes back to the community. Here are a couple of examples of missing behavior modeling for our cases:<\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7671\/commits\/4fa895fd675ae60a257f1e6e10d27348ed21d4a0<\/a><\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7694\/commits\/115a81770e8a78471d28a6a0b209eef7bc34df88<\/a><\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7670\/commits\/10ec5a03c15c48fd46890be4da394170fa6eb03a<\/a><\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7666\/commits\/f440c5202dd8f338661e8b6bd9711067ba8652b6<\/a><\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7666\/commits\/974c92535ecb5eedfe8fd57fc4295e59f2d4639d<\/a><\/p>
    https:\/\/github.com\/batfish\/batfish\/pull\/7710\/commits\/a2c368ae1b0a3477ba5b5e5e8f8ebe88e4bf2342<\/a><\/p>
    But a lot more are missing. We are big fans of IPv6<\/a>, but unfortunately, IPv6 is not (yet?) well-covered in the FRR model in Batfish. <\/p>
    This is not the first time<\/a> we’ve missed IPv6 support, and, we guess, not the last either. We’re looking forward to and hoping Batfish will get IPv6 support soon. <\/p>
    Some Best Practice Observations on Testing<\/h2>
    We would say that segregated tests serve to avoid throwing spaghetti at the wall at first. Write easy, understandable tests. If you see that two tests are depending on each other, it’s better to split them into separate tests. <\/p>
    Some tests can overlap, and if one fails, then the other will too. But that’s good because two failed tests can say more than one, even if they test similar functionality. <\/p>
    To confirm that tests are useful, you have to run and use them daily. Otherwise, there isn’t much point in having them.<\/p>
    If you can guess what may happen in the future, covering the possibility in tests is a good idea unless it’s too noisy. <\/p>
    As always, the Pareto Principle<\/a> is the best answer to whether it’s worth it and how much worth is covered by tests. If you cover at least 20% of the critical pieces with tests, most likely, your network is in good shape. <\/p>
    It’s absolutely not worth automating and testing all the things you come up with. It’s just additional taxation for no reason. You have to think about the maintainability of those tests with your team and make a decision. <\/p>
    What makes us happy is that Suzieq is great by default, and there is no need to write very sophisticated tests in Python. CLI is really awesome and trivial even for starters. If you need something exceptional, you are always welcome to write the logic in Python which is also friendly. Wrapped with the pandas<\/strong> library you can manipulate your network data as much as you want, it’s very flexible.<\/p>
     <\/h2>\n","protected":false},"excerpt":{"rendered":"
    In our previous post, we discussed how Hostinger started using network validation before going live. By implementing network validation for our core network, we have maintained co\u2026<\/p>\n","protected":false},"author":39,"featured_media":2166,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[82],"tags":[2312,2279,2285,1195,264,2286,2283,2290,2289],"hashtags":[],"class_list":["post-2164","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-batfish","tag-developer","tag-engineering","tag-hosting","tag-hostinger","tag-network","tag-network-validation","tag-suzieq","tag-testing"],"hreflangs":[],"_links":{"self":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/2164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/comments?post=2164"}],"version-history":[{"count":14,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/2164\/revisions"}],"predecessor-version":[{"id":2756,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/2164\/revisions\/2756"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/media\/2166"}],"wp:attachment":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/media?parent=2164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/categories?post=2164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/tags?post=2164"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/hashtags?post=2164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}