- dev - lists.frrouting.org

[frr] Lists of defaults changed
by Donald Sharp 08 Feb '17

08 Feb '17

As per the meeting yesterday, here are the list of default changes: 1) vtysh now accepts 'router bgp' if there is only one bgp instance and it is already defined 2) bgp: import-check enabled by default 3) bgp: should display 'address-family ipv4' in the config 4) bgp: 'timers connect' default lowered to 10 5) bgp: MRAI is 0 6) bgp: 'log-neighbor-changes' enabled by default 7) bgp: keepalive changed to 3 and 9 8) ospf: spf timers '0 50 5000' by default 9) bgp: Display hostname by default 10) bgp: 'no-as-set' default for 'bgp as-path multipath-relax' 11) bgp: enable IPv6 ND by default for BGP unnumbered neighbors 12) bgp: relaxed peer-group restrictions, update-groups determine outbound policy anyways 13) ospf: 'log-adjacency-changes' turned on by default 14) bgp: deterministic-med enabled by default 15) zebra: IPv6 ND RA has lifetime set to 0 donald

1 0

[frr] frr package for Arch Linux (AUR)
by Konstantin Shalygin 08 Feb '17

08 Feb '17

Hello. On previous week I submit makepkg PKGBUILD to AUR: https://aur.archlinux.org/packages/frr At this time by default build from 'stable/2.0' branch. Package version generated automatically from git logs. Cheers.

3 4

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

08 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 08 Feb '17

08 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 02 Feb '17

02 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 01 Feb '17

01 Feb '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 01 Feb '17

01 Feb '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 31 Jan '17

31 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