The BGP-SRx implementation in quagga is a bit different that its counterparts (JunOS and IOS). You need two modules, one stand-alone server (SRx Server) to speaks RTR with the caches and the BGP-Quaggla-Plugin that connects with the SRx Server. Why you need two pieces of code instead of one plugin of RTR/Origin-validatio in Quagga? Well, according to the developers it simplifies the modifications that Quagga needs. It may be true, but it complicates a bit its implementation and troubleshooting.
I used CenOS 6, RIPE NCC validator-cache for these tests and our RPKI Demo repository:
The first step after getting the code is to compile the SRx Server, check the INSTALL file, there are some flags to set up. You will need to modify the server config (in a file /usr/local/bin/) with your cache parameters. After that you will be able to telnet the server to verify that it has received ROAs.
The next step is to compile and configure Quagga. You need to copy some libraries from the SRx Server and compile with some flags to add the origin-validation. After that the configuration is pretty straight forward.
router bgp 1 bgp router-id 192.168.56.103 network 10.0.1.0/24 neighbor 192.168.56.104 remote-as 20 !SRx Configuration Settigns srx display srx connect 127.0.0.1 17900 srx evaluation roa_only srx keep-window 900
This is very basic, I haven't played with policies to modify local preference according to the route validity but it gives you an idea.
The BGP routing table looks like:
bgpd# sh ip bgg BGP table version is 0, local router ID is 192.168.56.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Validation: v - valid, u - unknown, i - invalid, ? - undefined SRx Status: I - route ignored, D - SRx evaluation deactivated SRxVal Format: validation result (origin validation, path validation) Origin codes: i - IGP, e - EGP, ? - incomplete Ident SRxVal SRxLP Status Network Next Hop Metric LocPrf Weight Path *> B2E8F5E6 v(v,-) 10.0.0.0/16 192.168.56.104 0 0 20 i *> 093057FE i(i,-) 10.0.0.0/24 192.168.56.104 0 0 20 i * -------- ?(?,-) I 10.0.1.0/24 0.0.0.0 0 32768 i *> D58A50E7 u(u,-) 10.10.0.0/16 192.168.56.104 0 0 20 i
The ROA table is the same than in the JunOS example. As you can see 10.0.0.0/16 is valid, 10.0.0.0/24 is invalid and 10.10.0.0/16 is unknown.
The specific announce of one route looks like:
bgpd# sh ip bgp 10.0.0.0/16 BGP routing table entry for 10.0.0.0/16 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 20 SRx Information: Update ID: 0xB2E8F5E6 Validation: prefix-origin: valid path processing disabled! 192.168.56.104 from 192.168.56.104 (192.168.56.104) Origin IGP, metric 0, localpref 100, valid, external, best Last update: Wed Dec 31 22:38:17 1969
We will keep working on this and soon we will be able to provide a virtual machine ready to use. Meanwhile you can download the code from NIST and if you have questions please feel free to contact us.