February 2021 - frog - lists.frrouting.org

Yocto Recipe for FRR
by Amol Lad 10 Aug '21

10 Aug '21

Hi, Please advise if there is any Yocto recipe for FRRouting? If not, how to go about creating one for FRR? Yocto Recipe for FRR will hugely simplify integrating FRR in Yocto based embedded linux distributions. So please advise if there are any plans to develop this recipe? Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

4 10

Re: [FROG] FRRouting and MPLS (Yakov Sh.)
by Tomás Morales 05 Apr '21

05 Apr '21

Hi all I am trying Yakov blog below to test L3VPN using FRR7.5 and the last PE is not capable to de-encapsulate the labelled traffic and send it to the CE. This is the diagram in my lab: https://github.com/thomarite/linux-mpls-testing/blob/master/lab4-l3vpn/diag… For example CE1 (vrf_cust1 - 192.168.11.102/24) tries to ping CE3 (vrf_cust1 - 192.168.23.102/24) P1 is receiving the traffic with double labels as expected from PE1: 19:28:46.075164 MPLS (label 17, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.11.102 > 192.168.23.102: ICMP echo request, id 2296, seq 10, length 64 19:28:47.099199 MPLS (label 17, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.11.102 > 192.168.23.102: ICMP echo request, id 2296, seq 11, length 64 PE2 is receiving the traffic on ens8 with just one label after P1 doing PHP: 19:28:46.074437 MPLS (label 80, exp 0, [S], ttl 63) IP 192.168.11.102 > 192.168.23.102: ICMP echo request, id 2296, seq 10, length 64 19:28:47.098555 MPLS (label 80, exp 0, [S], ttl 63) IP 192.168.11.102 > 192.168.23.102: ICMP echo request, id 2296, seq 11, length 64 But then PE2 is not sending anything to CE3. I can't see anything in either end. I have checked iptables in my host just in case but I think PE2 is not sending anything. >From PE2, all routing seems correct: PE2# show mpls table Inbound Label Type Nexthop Outbound Label ----------------------------------------------------- 16 LDP 192.168.77.102 16 17 LDP 192.168.77.102 implicit-null 18 LDP 192.168.77.102 implicit-null 80 BGP vrf_cust1 - 81 BGP vrf_cust2 - PE2# PE2# show bgp summary IPv4 Unicast Summary: BGP router identifier 172.20.5.2, local AS number 65010 vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 1, using 21 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 172.20.5.1 4 65010 101 108 0 0 0 01:35:41 0 0 Total number of neighbors 1 IPv4 VPN Summary: BGP router identifier 172.20.5.2, local AS number 65010 vrf-id 0 BGP table version 0 RIB entries 7, using 1344 bytes of memory Peers 1, using 21 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 172.20.5.1 4 65010 101 108 0 0 0 01:35:41 2 2 Total number of neighbors 1 PE2# PE2# show ip route vrf vrf_cust1 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF vrf_cust1: B> 192.168.11.0/24 [200/0] via 172.20.5.1 (vrf default) (recursive), label 80, weight 1, 01:35:40 * via 192.168.77.102, ens8 (vrf default), label 16/80, weight 1, 01:35:40 C>* 192.168.23.0/24 is directly connected, ens6, 01:38:19 PE2# PE2# PE2# show isis neighbor Area ISIS: System Id Interface L State Holdtime SNPA P1 ens8 2 Up 28 2020.2020.2020 PE2# vagrant@PE2:~$ ip route default via 192.168.121.1 dev ens5 proto dhcp src 192.168.121.31 metric 1024 172.20.5.1 encap mpls 16 via 192.168.77.102 dev ens8 proto isis metric 20 172.20.5.5 via 192.168.77.102 dev ens8 proto isis metric 20 192.168.66.0/24 via 192.168.77.102 dev ens8 proto isis metric 20 192.168.77.0/24 dev ens8 proto kernel scope link src 192.168.77.101 192.168.121.0/24 dev ens5 proto kernel scope link src 192.168.121.31 192.168.121.1 dev ens5 proto dhcp scope link src 192.168.121.31 metric 1024 vagrant@PE2:~$ vagrant@PE2:~$ ip -4 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 172.20.5.2/32 scope global lo valid_lft forever preferred_lft forever 2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.121.31/24 brd 192.168.121.255 scope global dynamic ens5 valid_lft 2524sec preferred_lft 2524sec 3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vrf_cust1 state UP group default qlen 1000 inet 192.168.23.101/24 brd 192.168.23.255 scope global ens6 valid_lft forever preferred_lft forever 4: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vrf_cust2 state UP group default qlen 1000 inet 192.168.24.101/24 brd 192.168.24.255 scope global ens7 valid_lft forever preferred_lft forever 5: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.77.101/24 brd 192.168.77.255 scope global ens8 valid_lft forever preferred_lft forever vagrant@PE2:~$ vagrant@PE2:~$ ip -M route 16 as to 16 via inet 192.168.77.102 dev ens8 proto ldp 17 via inet 192.168.77.102 dev ens8 proto ldp 18 via inet 192.168.77.102 dev ens8 proto ldp vagrant@PE2:~$ vagrant@PE2:~$ ip route show table 10 blackhole default 192.168.11.0/24 encap mpls 16/80 via 192.168.77.102 dev ens8 proto bgp metric 20 broadcast 192.168.23.0 dev ens6 proto kernel scope link src 192.168.23.101 192.168.23.0/24 dev ens6 proto kernel scope link src 192.168.23.101 local 192.168.23.101 dev ens6 proto kernel scope host src 192.168.23.101 broadcast 192.168.23.255 dev ens6 proto kernel scope link src 192.168.23.101 vagrant@PE2:~$ vagrant@PE2:~$ ip vrf Name Table ----------------------- vrf_cust1 10 vrf_cust2 20 vagrant@PE2:~$ This is PE2 FRR config: PE2# show running-config Building configuration... Current configuration: ! frr version 7.5 frr defaults traditional hostname PE2 service integrated-vtysh-config ! interface ens8 ip router isis ISIS isis circuit-type level-2-only isis network point-to-point ! interface lo ip router isis ISIS isis passive ! router bgp 65010 neighbor 172.20.5.1 remote-as 65010 neighbor 172.20.5.1 update-source 172.20.5.2 ! address-family ipv4 vpn neighbor 172.20.5.1 activate exit-address-family ! router bgp 65010 vrf vrf_cust1 ! address-family ipv4 unicast redistribute connected label vpn export auto rd vpn export 65010:10 rt vpn both 1:1 export vpn import vpn exit-address-family ! router bgp 65010 vrf vrf_cust2 ! address-family ipv4 unicast redistribute connected label vpn export auto rd vpn export 65010:20 rt vpn both 2:2 export vpn import vpn exit-address-family ! mpls ldp router-id 172.20.5.2 ! address-family ipv4 discovery transport-address 172.20.5.2 ! interface ens8 ! exit-address-family ! ! router isis ISIS net 49.0001.1720.2000.5002.00 ! line vty ! end PE2# This is PE2 sysctl mpls config: root@PE2:/home/vagrant# sysctl -a | grep mpls net.mpls.conf.ens5.input = 0 net.mpls.conf.ens6.input = 0 net.mpls.conf.ens7.input = 0 net.mpls.conf.ens8.input = 1 net.mpls.conf.lo.input = 0 net.mpls.conf.vrf_cust1.input = 0 net.mpls.conf.vrf_cust2.input = 0 net.mpls.default_ttl = 255 net.mpls.ip_ttl_propagate = 1 net.mpls.platform_labels = 100000 root@PE2:/home/vagrant# This is PE1: PE1# PE1# show bgp summary IPv4 Unicast Summary: BGP router identifier 172.20.5.1, local AS number 65010 vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 1, using 21 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 172.20.5.2 4 65010 111 105 0 0 0 01:39:14 0 0 Total number of neighbors 1 IPv4 VPN Summary: BGP router identifier 172.20.5.1, local AS number 65010 vrf-id 0 BGP table version 0 RIB entries 11, using 2112 bytes of memory Peers 1, using 21 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 172.20.5.2 4 65010 111 105 0 0 0 01:39:14 2 2 Total number of neighbors 1 PE1# PE1# PE1# show mpls table Inbound Label Type Nexthop Outbound Label ----------------------------------------------------- 16 LDP 192.168.66.102 implicit-null 17 LDP 192.168.66.102 implicit-null 18 LDP 192.168.66.102 17 80 BGP vrf_cust1 - 81 BGP vrf_cust2 - PE1# PE1# show ip route vrf all default vrf_cust1 vrf_cust2 PE1# show ip route vrf vrf_cust1 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF vrf_cust1: C>* 192.168.11.0/24 is directly connected, ens6, 01:44:51 B> 192.168.23.0/24 [200/0] via 172.20.5.2 (vrf default) (recursive), label 80, weight 1, 01:39:18 * via 192.168.66.102, ens8 (vrf default), label 17/80, weight 1, 01:39:18 PE1# PE1# show isis neighbor Area ISIS: System Id Interface L State Holdtime SNPA P1 ens8 2 Up 30 2020.2020.2020 PE1# PE1# If I try to ping CE3 to CE1, I see exactly the same behaviour in PE1. Any idea what I am missing? Thanks tomas On Mon, Nov 23, 2020 at 12:00 PM <frog-request(a)lists.frrouting.org> wrote: > > > Date: Mon, 23 Nov 2020 10:27:44 +0000 > From: "Yakov Sh." <yman(a)protonmail.ch> > To: Olivier CALVANO <o.calvano(a)gmail.com> > Cc: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Subject: Re: [FROG] FRRouting and MPLS > Message-ID: > <TaX1p13MyS4pDJfNgZ_qra4Lqq-QppV4Gc_JkTUmi9s41lOR7krEd9PBvr1kfX52s03BEhaxOxsaeb_KiIeKoe0QVUUnx-zRhDI72rDSwrM=@ protonmail.ch> > > Content-Type: text/plain; charset="utf-8" > > Hi! > I had not much experience with FRR in production, but I gave it a try some time ago in a lab and was able to build L3VPN service on VMs with kernel VRF support. You can see details in my blog post - http://dvjourney.yman.site/2018/10/26/l3vpn-on-linux/ > For L2VPN, as stated in docs, only OpenBSD supports VPWS/VPLS at the moment. http://docs.frrouting.org/en/latest/overview.html#feature-matrix > > Yakov Sh. > telegram: @darkyman > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, November 23, 2020 12:15 PM, Olivier CALVANO < o.calvano(a)gmail.com> wrote: > > > Hello, > > > > I have just installed FRR for the first time on a Linux CentOS 8 distribution. I am therefore just starting out. > > > > I am gradually reading the forums but there is a lot of information. FRR manages without worries the BGP and the ISIS which I use regularly on my cisco routers. > > > > I am now trying to find out if FRR can integrate more deeply into my network, particularly at the MPLS level. as I understood it is in the Kernel that this is done and not in FRR, but is there a way to integrate VRF IP VPN? and the creation of a VLAN type subinterface directly in FRR? > > > > Then last question: Is there an implementation of the Cisco EoMPLS equivalent in FRR? (xconnect encapsultation mpls) > > > > thank you > > Olivier >

1 1

Binding two IP addresses to bgpd
by Matt Riffle 04 Mar '21

04 Mar '21

Apologies if I’m missing something easy here — I think I’ve looked at this for too long. I want my bgpd process to listen to 2 IP addresses — one IPv4 and one IPv6. I cannot find a syntax that allows this to happen. I can listen to one or the other. I really don’t want to run two bgpd processes to accomplish it. (I could let it bind to the default 0.0.0.0 / :: and use a firewall, but, again, I’d rather just bind to the two addresses I need it on, if possible.) Thanks, -Matt

6 6

route-map set metric
by Joe Maimon 02 Mar '21

02 Mar '21

set metric shows -metric and +metric I have no idea how to use that, with IOS you can use the + or - with the metric number to either add to the existing metric or subtract I cant seem to duplicate that effect using the available syntax, in any event, I would think that configuration syntax compatibility in this instant would be a plus.

3 9

nhrpd event manager
by Joe Maimon 01 Mar '21

01 Mar '21

I have successfully gotten frr,nhrpd,strongswan,charon all running on another system for a dmvpn application. I am currently trying to do another setup, but without vpn/ipsec, just nhrp/gre. Its not working out well, debug logs show Netlink: Received msg_type 28 which if I recall correctly suggests that the neighbor entry isnt being installed correctly, trying it as root worked even less. So while poking around, I see there is an entire event manager unix sock structure. Perhaps I can parse that and do it myself? However, this is as far as I got. I am interacting with it via shell script. Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: sending event authorize-binding Mar 15 08:11:35 debian67 nhrpd[20977]: Send Registration-Reply(4) 192.168.241.129 -> 192.168.241.130 Mar 15 08:11:35 debian67 nhrpd[20977]: PACKET: Send 45.77.146.76 -> 209.51.164.27 Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: eventid=214 Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: result=accept Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: received: eventid=214 result= Mar 15 08:11:45 debian67 nhrpd[20977]: cache: t67 192.168.241.130: timeout Mar 15 08:11:46 debian67 nhrpd[20977]: Netlink: Received msg_type 28, msg_flags 0 I have looked at the source and I cant seem to convince the function to recognize that result should be "accept". Any advice appreciated. Joe For the interested, the below is the fledgling script #!/bin/bash PROGNAME=`basename $0` VERSION="0.0.1" usage() { echo "Usage: $PROGNAME -s nhrp-sock [-i interface-name] [-u user] [-g group] " echo "" echo "-s nhrp-sock file" echo "-i interface-name to execute on, may be repeated multiple times" echo "-u user to own the sock" echo "-g group to own the sock" exit 1 } SOCK="/var/run/frr/nhrp.sock" USER="frr" GROUP="frr" j=0 while getopts s:i:u:g: opt; do case "$opt" in s) SOCK="$OPTARG" ;; i) INTARR[((j++))]="$OPTARG" ;; u) USER="$OPTARG" ;; g) GROUP="$OPTARG" ;; esac; done coproc socat - UNIX-LISTEN:$SOCK,unlink-early,setuid-early=$USER || exit 1 OLDIFS="$IFS" while read -r S; do if [[ "$S" == "" ]]; then if [[ "$EVID" != "" ]]; then echo -e "eventid=$EVID\nresult=accept\n"; fi unset EVID unset EVINT continue; fi IFS="${IFS}=" SA=($S) IFS="$OLDIFS" case "${SA[0]}" in eventid) EVID="${SA[1]}" ;; interface) EVINT="${SA[1]}" esac done <&"${COPROC[0]}" >&"${COPROC[1]}" kill "$COPROC_PID"

2 3

route-map continue
by Joe Maimon 28 Feb '21

28 Feb '21

route-map contains the command continue Since it also contains the commands on-match goto and on-match next, I suppose that continue is there for syntax compatibility with IOS. IOS allows the continue command to be used with or without a next clause number, frr does not. Joe

2 2

Re: [FROG] How to test ipv6 anycast address with frr routing?
by Chriztoffer Hansen 27 Feb '21

27 Feb '21

On Sat, 27 Feb 2021 at 01:09, yan via frog <frog(a)lists.frrouting.org> wrote: > does frr routing support ipv6 anycast address configuration? Anycast routing in the essence of things is "just" announcing the same prefix from multiple locations. > How could I test ipv6 anycast address with frr routing? In the simplest of set-ups, configure multiple hosts to originate the same prefix (e.g. /32, /128) That would be anycast at the most basic level. (What services you will want to host from the anycast IP(s) is at your own descretion.) > Is there a tutorial about this? The official docs https://docs.frrouting.org does not contain such a tutorial. Thou I suspect more than one blogpost, conference talk has been given on the topic over the years (not being FRRouting specific). But most always this will be a generalized one. Skipping any in-depth (SW specific) tutorial content. And "just" explaining the concept. -- Chriztoffer

2 1

Re: [FROG] How to test ipv6 anycast address with frr routing?
by Chriztoffer Hansen 27 Feb '21

27 Feb '21

York, On Sat, 27 Feb 2021 at 01:09, yan via frog <frog(a)lists.frrouting.org> wrote: > I want to test ipv6 anycast address with frr routing with several linux PC host. However, I cannot find a way to setup ipv6 address on my linux host which is Ubuntu 12.04. I also cannot find a way to config ipv6 address on frr routing suite. > > So does linux support ipv6 anycast address? Or does frr routing support ipv6 anycast address configuration? How could I test ipv6 anycast address with frr routing? Is there a tutorial about this? Ubuntu 12.04 from 9y ago? Have you at least tried with a more recent and (still) supported LTS version of Ubuntu? Asking, since little to no support can be expected to be given/provided if using non-supported OS releases. Also, can you specify what FRR version you are using in your set-up? -- Chriztoffer

1 0

How to test ipv6 anycast address with frr routing?
by yanhc519＠aliyun.com 27 Feb '21

27 Feb '21

Hi, all. I want to test ipv6 anycast address with frr routing with several linux PC host. However, I cannot find a way to setup ipv6 address on my linux host which is Ubuntu 12.04. I also cannot find a way to config ipv6 address on frr routing suite. So does linux support ipv6 anycast address? Or does frr routing support ipv6 anycast address configuration? How could I test ipv6 anycast address with frr routing? Is there a tutorial about this? Thanks. York

1 0

No RIP packets, rejecting distribute-list and redistribute
by jimc 26 Feb '21

26 Feb '21

Version: frr-7.5-3.3.x86_64 from OpenSuSE Tubleweed. This is probably a near duplicate of bug 1279 (2017-10-02) https://github.com/FRRouting/frr/issues/1279 except the OP omidit was trying to use BGP while I have RIP[ng]. I'm pointing the finger of blame at a documentation issue; in other words, almost certainly my frr.conf file (appended with comments) lacks some prerequisite which would resurrect the redistribute and distribute-list commands. Presenting symptoms: ripd and ripngd never emit any RIP[ng] packets, even though the sub-router has a route to the subnet that I want the local LAN to be able to reach. Plus: when I specify "redistribute" and "distribute-list", frr -C complains: ``` line 56: % Unknown command[4]: distribute-list xenanet in line 57: % Unknown command[4]: distribute-list xenanet out line 61: % Unknown command[4]: redistribute kernel line 63: % Unknown command[4]: redistribute static line 65: % Unknown command[4]: redistribute connected ``` Back in 1987 I could just start rpc.ripd on SunOS-3 (no authentication in RIPv1), but 34 years later, Quagga looked like it gave a lot of people a lot of trouble to configure it, so I thought to reinvent the wheel. But for political and national security reasons I think it would be a real good idea to have open source routing used more widely, and so I decided to give Quagga my best try. It succumbed to the same issue complained about here, attributed to an unfixed bug by many OP's, and I dug through the source code but was not able to find the "bug". But I also hit references to FRR and tried it in the hope of a fix. No such luck. Currently I'm guessing that the problem is not in the code but in the documentation, so I've missed some important setup aspect. I'm planning to write up my experiences and of course it will include the conf file. In the appended instance I've retained comments, and if you spot any misconceptions among them I would appreciate corrections, so errors don't propagate. ``` # /etc/frr/frr.conf # This file contains plaintext passwords and needs permission 640 frr:frr # Revision history: # 2021-02-17 jimc Becomes FRR (Free Range Routing) unified config file. # 2021-02-04 jimc Initial setup for Quagga / rip[ng]d, abandoned. # hostname itsname # Default is the system's 1-component name per uname -n. # Without a password, vtysh will not connect; the enable password enables # interactive reconfiguration. But it uses PAM; password not needed for root. # Warning, security is not robust; turn this off in production. password redacted#1 enable password redacted#2 # Log file for all daemons log file /var/log/frr/frr.log # /etc/frr/daemons controls which protocol daemons to start, but you also have # to enable them. Not needed for staticd or zebra. router rip #rejected: version 2 # Do not receive v1 (which can't do authentication) router ripng # "vtysh -C [-f other_file.conf]" will check the configuration file; default # is /etc/frr/frr.conf. It would appear that if no protocol is enabled (e.g. # by "router rip") for which a particular command (e.g. "network") is relevant, # the command is reported as "Unknown command[4]: network 192.9.200.0/24", not # considering the parameters (e.g. with "router ripng", the IPv4 version is # not unknown). # Interfaces with an IP address in this range may send and receive protocol # packets. You can also enable named interfaces e.g. en0. network 192.9.200.0/24 network 2600:3c01:e000:306::/64 # We're only going to include these subnet(s) in incoming + outgoing packets. # In Quagga you could also use an access-list. ip prefix-list xenanet permit 192.9.200.176/29 ip prefix-list xenanet deny any # Syntax: 'route-map' its_name permit|deny line_number; matches etc. follow. # A number is a valid identifier and you confusingly see this in tutorials. route-map cnmap permit 1 match ip address prefix-list xenanet route-map cnmap deny 2 # Zebra can filter incoming routes per protocol or for any protocol. It just # ignores non-permitted routes. Looks like the default is to deny everything. ip protocol any route-map cnmap # In incoming and outgoing packets, only the specified subnets are included. distribute-list xenanet in distribute-list xenanet out # Daemons send routes that they learned from these sources. # kernel = set in system routing table by non-FRR, e.g. "ip route add..." redistribute kernel # static = configured in a FRR conf file. (CouchNet has none.) redistribute static # connected = seen in protocol packets from neighboring routers. redistribute connected # Turn on authentication (RIP v2 only). Mode md5 (hiss, boo!) makes a HMAC # over the packet with a pre-shared key prepended; the sender and receiver must # use the same key. It's OK to turn on auth for interfaces that don't exist. key chain CouchNet key 1 key-string redacted#3 interface en0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface br0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface rad0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun1 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun9 ip rip authentication mode md5 ip rip authentication key-chain CouchNet # Default timer values are used. # update 30sec, send a gratuitous RIP packet this often. # timeout 180sec, a route absent from "learn from" sources (e.g. # neighbors) for this long is redistributed as expired. # garbage 120sec, after this long, expired routes are no longer announced. ``` -- James F. Carter Email: jimc(a)jfcarter.net Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)

2 1