add more bgp config schema and add increment config

[batmancn]

** What I did **

Now BGP config shema have some limitation: only support BGP asn and BGP neighbor and its increment config.

To use SONiC in more scenes

1. I create or add more schema into BGP config like these:
   BGP_PEER_RANGE, VLAN_INTERFACE, INTERFACE, LOOPBACK_INTERFACE, BGP_METADATA, STATIC_ROUTE, BGP_AS_SET, BGP_COMMUNITY_SET, BGP_POLICY_ROUTE_MAP, BGP_PREFIX_SET, IP_ACCESS_LIST.

2. I add increment config method associate with schemas above.

3. I add retain route feature into config file of quagga.

4. I add "del" opcode for handler function in bgpcfgd, which could verify "add" or "del" of config converted from CONFIG DB of redis, refer to: add opcode for notification of redis DB sonic-py-swsssdk#42

** Detail of these shema **

Most of these schema bellow support increment config.
All of increment config support add/delete.
Some of increment config support update, like static route.

1. BGP asn(this is original repo code):
   {
   "DEVICE_METADATA": {
   "localhost": {
   "bgp_asn": "5001"
   }
   }
   }

2. BGP neighbor:
   {
   "BGP_NEIGHBOR": {
   "192.168.1.10": {
   "admin_status": "up",
   "asn": "5001",
   "name": "test",
   "local_addr": "192.168.1.20",
   "policy_in": "BGP_POLICY_NAME_1|BGP_POLICY_NAME_2|BGP_POLICY_NAME_3|BGP_POLICY_NAME_4",
   "policy_out": "BGP_POLICY_NAME_1|BGP_POLICY_NAME_2",
   "policy_import": "BGP_POLICY_NAME_1|BGP_POLICY_NAME_2|BGP_POLICY_NAME_3|BGP_POLICY_NAME_4",
   "policy_export": "BGP_POLICY_NAME_1|BGP_POLICY_NAME_2",
   "remote_as": "20",
   "description": "DESCRIPTION",
   "password": "PASSWORD",
   "ebgp_multihop": "64",
   "maximum_paths": "64",
   "prefix_in": "BGP_PREFIX_SET_NAME_1|BGP_PREFIX_SET_NAME_2",
   "prefix_out": "BGP_PREFIX_SET_NAME_1|BGP_PREFIX_SET_NAME_2"
   }
   }
   }

Add BGP policy, remote as, password, eBGP multihop, maximun path, prefix list config.
Detail of these config is bellow.

3. BGP network for vlan, loopback, L3 interface:
   {
   "VLAN": {
   "Vlan3998": {
   "vlanid": "3998"
   }
   },
   "LOOPBACK_INTERFACE": {
   "Loopback1|10.18.0.32/32": {}
   },
   "VLAN_INTERFACE": {
   "Vlan3998|100.8.1.2/24": {}
   }
   }

Add L3 interface IP to advertise in BGP using network command in quagga.
Add "del" opcode to verify add or delete operate, refer to: sonic-net/sonic-py-swsssdk#42

4. static route, redistribute:
   STATIC_ROUTE: {
   "dst_ip:1.1.1.1/24|nexthop:1.1.1.2": {
   "metric": "30"
   }
   },
   BGP_METADATA: {
   "localhost": {
   "redistribute": "static"
   }
   }

5. BGP neighbor peer group:
   {
   "BGP_NEIGHBOR": {
   BGP_NEIGHBOR_PEER_GROUP_NAME: {
   "admin_status": "up",
   "asn": "5002",
   "name": "peergroup1",
   "local_addr": "192.168.1.20"
   },
   "12.12.12.12": {
   "peer_group": BGP_NEIGHBOR_PEER_GROUP_NAME
   }
   }
   }

6. ip as-path access-list:
   {
   "BGP_AS_SET": {
   "as_path_1": {
   "description": "as_path_1",
   "action": "permit",
   "line": "^3356$ _65101$"
   }
   }
   }

7. ip community-list:
   {
   "BGP_COMMUNITY_SET": {
   "community_1" : {
   "description": "community_1",
   "line": "7675:70 7675:80 7675:60",
   "action": "deny"
   }
   }
   }

8. ip prefix-list:
   {
   "BGP_PREFIX_SET": {
   "0.0.0.0/0|CU_IN|deny": {
   "description": "CU_IN",
   "compare": "le",
   "length": "32",
   "seq": "5"
   }
   }
   }

9. route-map:
   {
   "BGP_POLICY_ROUTE_MAP": {
   "bgp_policy_1|deny|20": {
   "description": "I am description",
   "match_as_path": "as_path_1",
   "set_as_path": "1"
   },
   "bgp_policy_1|deny|21": {
   "match_prefix_list": "ipv6|match_prefix_list_ipv6_name",
   "set_metric": "10"
   },
   "bgp_policy_1|deny|22": {
   "match_prefix_list": "ipv6|match_prefix_list_ipv6_name",
   "set_community": "4567:10"
   },
   "bgp_policy_1|deny|23": {
   "match_prefix_list": "ipv6|match_prefix_list_ipv6_name",
   "set_local_preference": "10"
   },
   "bgp_policy_1|deny|24": {
   "match_prefix_list": "ipv6|match_prefix_list_ipv6_name",
   "set_ip_next_hop": "127.0.0.1"
   }
   }
   }

10. access-list:
    {
    "IP_ACCESS_LIST": {
    "filter|deny 1.2.1.2/24 exact-match": {},
    "filter|permit 2.1.2.1/24": {},
    "filter|remark 2424:24 3232:32": {}
    }
    }
    }

11. graceful-restart:
    {
    "BGP_METADATA": {
    "localhost": {
    "graceful_restart_param": "restart-time 120|stalepath-time 360"
    }
    }
    }

this is for user define gr capacity, not support increment config.

12. maximun-path:
    {
    "BGP_METADATA": {
    "localhost": {
    "maximum_paths": "30"
    }
    }
    }

this is for user define maximum, not support increment config.

** Test cases **

I add test json file here: https://github.com/batmancn/sonic-buildimage/tree/testcase_of_bgp_config_schema_enhance_and_increment_config/dockers/docker-fpm-quagga/unit_test

You could test functions above by bash bgp_test.sh or frr_test.sh.

** issues **

1. static route schema is now same as Add static route #1848

[jipanyang]

The transition of taking FRR as the default routing stack probably will be done in sonic March release of next year, will it make sense to support FRR too? Or even take FRR support as the priority?

[batmancn]

The transition of taking FRR as the default routing stack probably will be done in sonic March release of next year, will it make sense to support FRR too? Or even take FRR support as the priority?

I will have a look at this, and report here.
I want to know detail plan of "replace QUAGGA by FRR", like why do this, how do this, etc. If there are some proposal or design spec or something.

[jipanyang]

I will have a look at this, and report here.
I want to know detail plan of "replace QUAGGA by FRR", like why do this, how do this, etc. If there are some proposal or design spec or something.

I think @zhenggen-xu @rodnymolina @nikos-github have been handling FRR related work, probably they could answer your questions better.

[rodnymolina]

@batmancn Simon, as you may know, most of the SONiC<->FRR integration work has been already done over the last couple of years. You can easily build an FRR-based sonic image by simply changing the ROUTE_STACK knob present in rules/config file. At this point only minor items are pending, such as double-checking that the existing Quagga jinja templates are fully compliant with FRR (which they mostly are), and update SONiC's testing framework to deal with potential CLI differences between Quagga and FRR.

I agree with @jipanyang suggestion of extending your PR to FRR's routing-stack.

[batmancn]

FRR

The "extending your PR to FRR's routing-stack" is also I need to do in my environment, I will have a look at this.

I will pay attention on discuss/design spec/proposal/... of QUAGGA<->FRR. And I will search these, it's thankful if someone tell these to me.

[zhenggen-xu]

@batmancn Please take a look at this PR for some details about the FRR support: #2099

High level the reason we want to move to FRR is that it has a more active community, and has the features we need on SONiC roadmap etc.

If you can extend the template to FRR, that would be great.

Ansible framework changes were also upstreamed to sonic-mgmt repo. The default stack is quagga on github but internally we have done the ansible tests without any problem at the time the PR was submitted.

[batmancn]

@batmancn Please take a look at this PR for some details about the FRR support: #2099

High level the reason we want to move to FRR is that it has a more active community, and has the features we need on SONiC roadmap etc.

If you can extend the template to FRR, that would be great.

Ansible framework changes were also upstreamed to sonic-mgmt repo. The default stack is quagga on github but internally we have done the ansible tests without any problem at the time the PR was submitted.

OK, thank you.

The last, you mean testcase of mgmt repo is worked on FRR, that's great.

[batmancn]

I have added frr increment config feature by moving these code to sonic-frr, refer to this commit "ac574f86" on branch "bgp_config_schema_enhance_and_increment_config".

These code has been tested by the same way described in 1st conversation "Test cases" section, by "frr_test.sh" script.