- dev - lists.frrouting.org

[frr] Coverity Scanning of FRR
by Donald Sharp 07 Feb '17

07 Feb '17

All - We have setup semi-automatic scanning of the FRR code base in Coverity, via their open source usage policy. If you would like access to the results please respond here and we can add you. Yes, there are lots of things that need to be fixed and it would be nice for people to start tackling them :) thanks! donald

1 0

[frr] Today's Technical Meeting Agenda
by Donald Sharp 07 Feb '17

07 Feb '17

1) stable/2.0 status 2) Pull Requests 3) bgp timers - Default Not Visible 4) Packaging in Repo or not? 5) Anything else people would like to talk about? 11 AM EST https://bluejeans.com/9192742159

3 3

[frr] [PATCH 00/11] VRF Import Processing + VRF Multipath
by Philippe Guibert 07 Feb '17

07 Feb '17

This series of patch is the following of VRF and VRF RIB tables introduction in BGP. It enhances the import processing algorithm: it reuses the export route target extended community, as well as the local import route target configured per VRF, to append/remove NLRI entries from VPNv4 into VRF RIB entries. The received NLRI entries are stored in VRF RIB entries, then BGP best selection algorithm applies to select the best path. This patch also includes a new vty command to set the multipath per VRF. This makes then the selection algorithm more robust. All those multipath and selected entries are notified in a log message. This series of patch should be used in conjunction with the following series of patches: [PATCH v2] BGP VRF Route Distinguisher configuration Cheers, Philippe

5 35

[frr] New Repository
by Donald Sharp 01 Feb '17

01 Feb '17

All - Martin has developed a topotest repository that runs some basic tests against FRR. Eventually I would like to get to a point where the CI system autoruns these tests. We as a group should also decide if we want new features to include new tests for the feature as part of the acceptance criteria. The repository is at: https://github.com/freerangerouting/topotests thanks! donald

2 1

[frr] Todays Agenda
by Donald Sharp 31 Jan '17

31 Jan '17

If you need a meeting invite let me know please! 1) Status of RC-2 2) Status of Pull Requests Anything else that people want to discuss? donald

3 4

[frr] Linux src/dest feature has been merged into master
by Donald Sharp 31 Jan '17

31 Jan '17

All - The linux src/dest feature has been merged into master. Thanks to Christian and David for providing this work! donald

1 0

[frr] dst-src design/architecture intro
by David Lamparter 31 Jan '17

31 Jan '17

Hi all, as requested (with some delay, sorry), here's a design overview of what dst-src (aka sourcedest) routing is supposed to do. Disclosure: I've been working on this in IETF context: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing/ # Problem The problem this tries to solve is making multiple uplinks available in an IPv6 customer network that does not have its own address space in the BGP DFZ. Meaning, each of the uplinks assigns some fragment of that uplink's address space. Now since BCP38 filtering is reasonably commonplace (yay!), these uplinks will drop incoming packets if they have a source address from another ISP. NAT is an obvious solution that everyone hates with a passion, especially at the IETF. Alternate solutions basically started out with, well, we need to deliver the packets to the correct exit. This meant either tunneling/encapsulation or a change in routing lookups. # Solution So, the idea is to make it possible to route packets not only on destination, but also source address. So far, that's just policy routing. However, there is a major difference - the angle of approach is "reversed": Classic PBR divides routing lookups into separate tables based on source address (or more compilicated, e.g. firewall mark) lookups. Tables can be chained together on Linux, but left to their own they have no overlap and act fully independent. Essentially, there are fully independent networks with their own routing. Most importantly, source/firewall markers are looked up /first/. dst-src does this the other way around. There is only one table with destination prefixes as usual. However, for a particular destination - e.g. the IPv6 default route ::/0 - there can now be more specific "(D,S)" [Destination,Source] routes. The source prefix is looked up /second/ (but with "fallthrough" semantics). This implies a model of one single common network with specific D,S routes for a few select targets. On top of that, unlike with policy routing which is more or less beyond the scope of dynamic routing protocols (the user somehow has to configure a policy and do something like multitopology routing or filtering between tables), dst-src is explicitly in-scope of dynamic routing. IS-IS gets a new sub-TLV to carry source prefix information, and there is no policy to configure so D,S routes can be pushed through the network like any other route. (Compatibility and mixed deployment is a bit complicated, but solved.) So, ultimately this was designed to solve one problem and solve it reasonably well. People have found a few other use cases, for example using different assigned prefixes for different classes of service, and doing distinct routing for these classes. But all in all the primary use cases is "multiple uplinks with explicitly associated prefixes". # FRR impact The changes to FRR simply add the infrastructure to pass D,S routes along just like D-only routes. It's essentially an additional attribute on the route; but it needs to support D,S1 + D,S2 with S1 != S2 at the same time (so it's really an extension to the "route table key"). It's implemented as hanging a second route_table off the destination entry. If there are no D,S routes, this table will never even be created. It's only present for destination prefixes that have one or more D,S routes. The biggest impact is really that it makes the route_table code a bit more complicated. Forwarding semantics and such are all up to the kernel, FRR doesn't care. Linux has implemented this back in 3.x kernels; it had some bugs with the route cache though so AFAIR it needs something around 3.14 or so to work properly. # Caveats - all of this is IPv6-only, both in the Linux kernel and FRR - the core document specifies fallthrough lookup, e.g. packet to 2001:db8:2345::1 from 2001:db8:1234::1 route #1 2001:db8:2345::/48 src 2001:db8:eeee::/48 route #2 2001:db8::/32 src 2001:db8::/32 needs to match route #2, e.g. after finding no match on destination 2001:db8:2345::/48 the lookup needs to continue at less specific destination prefixes. (There is no implicit stop.) - it's not policy routing, and it can't be abused to do "real" policy routing. E.g. the draft for the IS-IS transport expects and assumes that the routing works as described in the core document. Crowbaring it as a transport mechanism for other policy routing will make hell break lose. It can replace PBR in /some/ applications, but it's essentially a subset. Hope this addresses open questions, -David

1 0

[frr] frr-rc1 (latest git) now available in Ubuntu Store as snap
by Martin Winter 30 Jan '17

30 Jan '17

With all the snapcraft packaging files installed, I have now frr published in the Ubuntu Store At this time it’s only in the edge and beta channels (not in stable). I plan to move it up to stable once we have rc2 (or the release) If you use Ubuntu 16.04 or another OS which supports snap packages, then install it with snap install --beta frr I’m the one with access to publish the snap at this time (We can fix this once the org structures are in place) If you install, the execute frr.readme to see some information (i.e. you need to give network control privs to the snap and it shows you how and other details) - Martin PS: Only Intel 64bit Snap published right now. Will add more architectures later when we get more stable.

2 1

[frr] syntax for route map matching ipv6 prefix
by Thomas Hilse 30 Jan '17

30 Jan '17

Hi team, I have tried FRR (version 2.0-rc0-ci.NetDEF.org-20170126.021714-git.1e78204) downloaded from the "netdef" build system: https://ci1.netdef.org/ (FRR build #53 - version for freebsd 10.3) In my test setup - dual homed connection to one ISP - all seems to work as expected. (quagga 1.1.1 has a regression - https://bugzilla.quagga.net/show_bug.cgi?id=870 FRR in my setup is not affected from this regression.) However I am wondering how to define a route map matching an ipv6 prefix in FRR. The syntax which is working with quagga seems to be invalid in FRR (or not supported). I am using route maps to filter the redistribution of routes and to modify the BGP route metricies between the two connections to our ISP. ipv6 prefix-list V6-PREFIX seq 5 permit 2001:db8:1cc:222::/64 ! route-map V6-RM permit 10 match ipv6 address prefix-list V6-PREFIX ! Best regards Thomas

2 4

[frr] The bgpafisafi pull request
by Donald Sharp 26 Jan '17

26 Jan '17

https://github.com/freerangerouting/frr/pull/107 Philippe - You had a review comment two days ago: how do you initialise vrf in the case vrf_name is already null ( commands with no vrf at all)? I would lie the *vrf value to be set inside that function. I responded with: I do not believe this is the right thing to do. Only the calling function knows what the right defaults are for the afi/safi/vrf due to we assume different defaults based upon the command. This approach would break the ability for the calling function to do the right thing. As I stated I will update the Pull Request with better documentation for this funciton. I've also added a commit that updates the function to further explain it. Is there anything else you would like to have done? donald

2 1