November 2016 - dev - lists.frrouting.org

[cmaster-next] EVPN - notes on the Cumulus implementation
by Vivek Venkatraman 13 Dec '16

13 Dec '16

Here is some information on the Cumulus implementation. We can discuss further in tomorrow's meeting and/or subsequent ones. Functional description: The Cumulus implementation of EVPN is focused on EVPN as the control plane for VxLAN, though it is certainly feasible to extend it to support other encapsulations - e.g., MPLS. It is also clearly a work-in-progress. The implementation is focused on Linux as the network OS; there will be work needed to extend it for FreeBSD or provide the FPM-type interface. The current state of the implementation (end November 2016) allows for MAC learning and exchange but not for MAC+IP. The latter requires some enhancements to the Linux kernel's "ARP proxy" (ARP suppression) capabilities for VxLAN, and this is currently in the works. A precursor to MAC exchange is the exchange of VxLAN topology. This will build the mapping of VNIs to remote VTEPs and is required for handling BUM traffic through ingress replication. The exchange of this topology happens in BGP through the EVPN type-3 route. Currently, this is not configurable (i.e., these routes will always get exchanged). Additional options need to be added to disable this exchange (and hence, possibly, drop BUM traffic), attach to a multicast group or have the ability to go to a service or replicator node. Remote VTEPs learnt by BGP and informed to zebra will result in the "flood list" being setup - by installing the appropriate neighbor entry in the MAC FDB. MACs are exchanged using EVPN type-2 route. Local MACs get associated to the appropriate VNI. Remote MACs learnt by BGP and informed to zebra will be installed in the kernel MAC FDB. Some of the other aspects still in the works are the BGP encapsulation attribute (RFC 5512 - basic code already there in branch from Lou), the PMSI attribute (RFC 6514) and MAC mobility extended community (RFC 7432). All BGP protocol exchanges are as per RFC 7432 and draft-ietf-bess-evpn-overlay. Handling of access device dual homing (i.e., vPC, MLAG etc. in vendor speak) does not currently intend to use the EVPN type-4 route or EVPN type-1 route and related procedures. Instead, it will rely on the corresponding VTEPs using an "anycast IP" as their tunnel end point. This is in accordance with current industry practice (i.e., Cisco and Arista's approach). Work on L3 multi-tenancy (i.e., Inter-VxLAN routing) is at an early stage. This is where EVPN type-5 routes will be needed along with associating tenants to corresponding L3 VRFs, support for the Router MAC extended community etc. Provisioning/Management: As with other vendor implementations, there is no explicit configuration of a "MAC VRF" - the VNI defines the L2 domain and is the MAC VRF. VNIs (VxLAN interfaces), association of these to a bridge and mapping of access (VLAN) interfaces to the bridge are all supported (done) through existing Linux interfaces i.e., iproute2 or ifupdown2. There are no new Quagga commands to create or update these. The only essential pieces of Quagga configuration needed to activate EVPN (for the current and near-term functionality) are: a) enable EVPN - the current commands for this is "advertise-vni" b) activate EVPN address family for the remote VTEPs (or appropriate BGP peers, if peering is hop-by-hop) router bgp <as> address-family evpn advertise-vni neighbor <nbr> activate With the above configuration, VNIs known to the system will get associated with automatic RDs and RTs. The RDs are formed as "RouterID:VNI" and the RTs (import and export) are formed using "AS:VNI". Configuration options are provided to specify a different RD and/or RT value for a VNI. Whichever parameter that is not user-configured will be auto-derived. The VNI will of course be "active" only when it is known to the system (i.e., provisioned through existing Linux interface). router bgp <as> address-family evpn advertise-vni neighbor <nbr> activate vni <vni> rd <value> route-target import <value> ... route-target export <value> The main vtysh commands currently available to manage/monitor EVPN operation are: show evpn vni show evpn vni <vni> mac show bgp evpn summary show bgp evpn route show bgp evpn route rd <rd> Design description: zebra provides the kernel interface (through netlink) and maintains the VNI information and the MAC table per VNI. It should be considered later if these need to move into a "l2d"; this is best taken up for consideration, if at all, in conjunction with a "vrfd" and an "ifd" so that zebra effectively becomes "rtmd". The VNI hash table is populated with local VNIs which are learnt through existing netlink "link" notifications. The hash table also contains the remote VTEPs which are updated by BGP. Linux currently only supports an IPv4 address as the VTEP IP, so while the code has support for IPv6 address as a VTEP, it is incomplete. To be able to associate local MACs to the correct VNI (if they are associated with a VNI), zebra needs to understand bridges and bridge members and the VLAN to VNI mapping. These are built by listening mostly to existing netlink "link" notifications, however, some notifications related to the AF_BRIDGE family also need to be processed. The "L2" information for an interface is maintained in a structure linked off 'struct zebra_if'. The VNI hash table contains the MAC table corresponding to the VNI. This includes local MACs learnt from netlink "neighbor" notifications (AF_BRIDGE) as well as remote MACs updated by BGP. The remote MACs result in MAC FDB entries being installed in the kernel. When this is extended for MAC+IP, the IP information will result in creation of ARP "suppression" entries in the kernel. BGP also has a VNI hash table that it builds through interaction with zebra. Currently, there is no per-VNI routing table. Instead, EVPN routes (both local and remote) are only maintained in the main routing table where they are organized using a hierarchical radix tree in the same fashion as L3VPN routes and ENCAP routes. This is likely to need change in order to handle various scenarios. The change envisioned is that local EVPN routes will be only present in the per-VNI routing table from where they will be advertised to EVPN peers; remote (i.e., learnt) EVPN routes will be present in the global EVPN routing table from where they will be "imported" into one or more VNI routing tables; the import can/will be done as a separate thread. Thanks, Vivek

3 2

[cmaster-next] RD/RT discussion from Technical Meeting Yesterday
by Donald Sharp 02 Dec '16

02 Dec '16

During the meeting we discussed option #6 as the viable option. Reasoning: Closely modeled the ietf way of thinking Here it is in a broad outline: vrf <VRFNAME1> ip route … <---- Vrf specific Route router bgp XXX ! (address-family ipv4) network 1.2.3.0/24 route-map foo neighbor ... ! CE session redistribute ospf ! CE setup for OSPF ! no special parameters on redistribute needed; VRF name is already OK <here> - never RD/RT router ospf <INSTANCENUM> ! (is this under vrf config?) redistribute bgp ... router bgp AAA ! core instance address-family vpnv4 | vpnv6 | evpn Network <vpnv4> or <RT2/RT5> config [ rd <> ( could be used) ?] neighbor ... ! PE session vrf <VRFNAME1> rt {import|export|both} RTLIST rd {automatic|VALUE} network <> [<rd>] ! <- most used hopefully router bgp BBB ! core instance vrf <VRFNAME2> rt {import|export|both} RTLIST ! can have value overlap rd {automatic|VALUE} address-family vpnv4 | evpn Network <vpnv4> or <RT2/RT5> config neighbor ... ! PE session Questions asked: For VRF's would we extend this to MAC VRF's also? donald

3 2

[cmaster-next] [PATCH] bgpd: fix invalid memory access in peer_free()
by Renato Westphal 01 Dec '16

01 Dec '16

We shoult not call bgp_unlock() before calling bgp_delete_connected_nexthop() in the peer_free() function. Otherwise, if bgp->lock reaches zero, bgp_free() is called and peer->bgp becomes an invalid pointer in the bgp_delete_connected_nexthop() function. To fix this, move the call to bgp_unlock() to the end of peer_free(). Bug exposed by commit 37d361e ("bgpd: plug several memleaks"). Signed-off-by: Renato Westphal <renato(a)opensourcerouting.org> --- bgpd/bgpd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bgpd/bgpd.c b/bgpd/bgpd.c index 22d4dd8..d5aff84 100644 --- a/bgpd/bgpd.c +++ b/bgpd/bgpd.c @@ -1019,8 +1019,6 @@ peer_free (struct peer *peer) { assert (peer->status == Deleted); - bgp_unlock(peer->bgp); - /* this /ought/ to have been done already through bgp_stop earlier, * but just to be sure.. */ @@ -1092,6 +1090,8 @@ peer_free (struct peer *peer) bfd_info_free(&(peer->bfd_info)); + bgp_unlock(peer->bgp); + memset (peer, 0, sizeof (struct peer)); XFREE (MTYPE_BGP_PEER, peer); -- 1.9.1

3 3

[cmaster-next] [PATCH 0/2] Minor stable/2.0 patches
by Donald Sharp 01 Dec '16

01 Dec '16

These 2 patches fix issue #7. Donald Sharp (2): ospfd: Fix memory leak when not using json pimd: Fix large integer display of drpriority ospfd/ospf_vty.c | 6 ++++-- pimd/pim_vty.c | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) -- 2.5.5

2 1

[cmaster-next] link-params sub mode
by Donald Sharp 01 Dec '16

01 Dec '16

Olivier - We've noticed that link-params creates allot of config lines when you configure any part of it. Would you mind if I change the behavior to this: When link-params is configured it auto starts displaying 6000-02# conf t dell-s6000-02(config)# int swp1 dell-s6000-02(config-if)# link-params dell-s6000-02(config-link-params)# admin-grp 0x12345678 dell-s6000-02(config-link-params)# end dell-s6000-02# show run interface swp1 link-params enable metric 0 <----Remove the metric and bw lines max-bw 1.25e+06 max-rsv-bw 1.25e+06 unrsv-bw 0 1.25e+06 unrsv-bw 1 1.25e+06 unrsv-bw 2 1.25e+06 unrsv-bw 3 1.25e+06 unrsv-bw 4 1.25e+06 unrsv-bw 5 1.25e+06 unrsv-bw 6 1.25e+06 unrsv-bw 7 1.25e+06 admin-grp 305419896 exit-link-params ! I'd like to reduce this to: interface swp1 link-params enable admin-grp 0x12345678 <----- Fix this to be what we entered exit-link-params ! Finally do we need to display the enable line as well? donald

3 8

[cmaster-next] Topology Tests added to CI - and new BGPd crash discovered
by Martin Winter 01 Dec '16

01 Dec '16

(Testing the new mailing list as well) First of all: I finally got around and added some framework for Topology Tests based on Mininet to the CI testbed. As Mininet is all based on Python, the whole framework is based on pytest. At this time, there are 2 tests in it: - OSPFv3 simple topology - BGP Multiview topology The git for this setup is here: https://git.netdef.org/scm/netdef/topotests.git There is no proprietary code in it - all can be easy replicated on a Ubuntu 16.04 (I have not tested any other Distros and Mininet requires Linux). Just follow the directions in the README inside the git and you should be able to replicate the setup. The idea is to have some test setup which can be shared and anyone can add tests (The CI system runs all the tests in this git) Happy to hear any feedback on this setup… As a side note, the BGP Multiview test crashes BGPd on startup. Because of this, I have NOT YET enabled the test results parsing in the CI system (or all builds would fail at this time) If you look at the the latest build on our CI system, you’ll see a crash in BGPd See https://ci1.netdef.org/browse/QUAGGA-CMASTERNEXT-TOPOU1604-106 Seems to be a crash in the VNC code. (cc’ing Lou to make sure he see this…) Again, please provide feedback. The idea is to add many more topologies to the CI system, but would like to hear some feedback on the setup. - Martin

3 2

[cmaster-next] [PATCH] bgpd: Fix multiple bgp view vnc crash
by Donald Sharp 01 Dec '16

01 Dec '16

When configuring multiple bgp views without a default bgp session, the code will crash. This code change only fixes the crash from happening. I'm not entirely sure that the code will not misbehave with multiple bgp views and configuring vnc in this case. Signed-off-by: Donald Sharp <sharpd(a)cumulusnetworks.com> --- bgpd/rfapi/vnc_import_bgp.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/bgpd/rfapi/vnc_import_bgp.c b/bgpd/rfapi/vnc_import_bgp.c index 4215ce2..441bdee 100644 --- a/bgpd/rfapi/vnc_import_bgp.c +++ b/bgpd/rfapi/vnc_import_bgp.c @@ -1798,6 +1798,9 @@ vnc_import_bgp_exterior_add_route_it ( struct bgp *bgp_default = bgp_get_default (); afi_t afi = family2afi (prefix->family); + if (!bgp_default) + return; + h = bgp_default->rfapi; hc = bgp_default->rfapi_cfg; @@ -1992,6 +1995,9 @@ vnc_import_bgp_exterior_del_route ( afi_t afi = family2afi (prefix->family); struct bgp *bgp_default = bgp_get_default (); + if (!bgp_default) + return; + memset (&pfx_orig_nexthop, 0, sizeof (struct prefix)); /* keep valgrind happy */ h = bgp_default->rfapi; -- 2.5.5

3 4

[cmaster-next] [PATCH 2/2] pimd: Fix large integer display of drpriority
by Donald Sharp 30 Nov '16

30 Nov '16

When displaying drpriority you can enter unsigned integer values from 1-2^32. The display was turning the unsigned value into a signed value and thus we were displaying the wrong value. Ticket: CM-13787 Signed-off-by: Donald Sharp <sharpd(a)cumulusnetworks.com> Reviewed-by: David Ahern <dsa(a)cumulusnetworks.com> (cherry picked from commit db17265f1025e3ec578998ad537c33b49ed33cde) --- pimd/pim_vty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pimd/pim_vty.c b/pimd/pim_vty.c index f1c8930..037a00c 100644 --- a/pimd/pim_vty.c +++ b/pimd/pim_vty.c @@ -148,7 +148,7 @@ int pim_interface_config_write(struct vty *vty) /* IF ip pim drpriority */ if (pim_ifp->pim_dr_priority != PIM_DEFAULT_DR_PRIORITY) { - vty_out(vty, " ip pim drpriority %d%s", pim_ifp->pim_dr_priority, + vty_out(vty, " ip pim drpriority %u%s", pim_ifp->pim_dr_priority, VTY_NEWLINE); ++writes; } -- 2.5.5

1 0

[cmaster-next] [PATCH 1/2] ospfd: Fix memory leak when not using json
by Donald Sharp 30 Nov '16

30 Nov '16

When doing a show command under ospf, if not using json we would have a small memory leak in show_ip_ospf_common. Signed-off-by: Donald Sharp <sharpd(a)cumulusnetworks.com> (cherry picked from commit 50750712b1ac8364e290c67782eaf371025dc59e) --- ospfd/ospf_vty.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ospfd/ospf_vty.c b/ospfd/ospf_vty.c index b094660..43a4434 100644 --- a/ospfd/ospf_vty.c +++ b/ospfd/ospf_vty.c @@ -3299,8 +3299,10 @@ show_ip_ospf_common (struct vty *vty, struct ospf *ospf, u_char use_json) json_object *json_areas = NULL; if (use_json) - json = json_object_new_object(); - json_areas = json_object_new_object(); + { + json = json_object_new_object(); + json_areas = json_object_new_object(); + } if (ospf->instance) { -- 2.5.5

1 0

[cmaster-next] Technical Meetings Notes
by Donald Sharp 29 Nov '16

29 Nov '16

Branch Stuff: master -> Current development branch, holds cmaster-next + vtysh-grammar stable/2.0 -> Current Release Candidate, started from cmaster-next <see David's email sent earlier today> Moving Forward: Please send pull requests with an issue for it under github or send the commits to this alias, indicate what branch they should go against in cover letter subject, else master will be assumed. Move Meeting to every 2 weeks? General consensus is to not do this yet. Revisit after Xmas RD/RT finish up: -> General consensus was option #6 was the go to. I am going to send an separate email with an outline of what we discussed today to continue discussion here. EVPN Discussion: -> Vivek sent an email last night with the Cumulus Implementation currently. Vivek went over this email in today's meeting. More discussion next week. donald

1 0