Configuration examples

---

1.  BGP configuration examples

Some BGP configuration examples may be found in Quagga docs

1.1  Example 1: BGP for beginners

Here we start a bgp instance for AS 65270, set router-id to the network address we announce (to easily find it in show listing),
announce two networks wich are directly attached,
describe our neighbors with their ip addresses and AS's,
set distance (metric) for routes, learned from bgp to 150.
In fact, this is the local network, with private ip and AS ranges,
and bgp is running to backup ospf, which is described below.
So, this bgp instance lets ospf routes dominate over bgp.

!
! Zebra configuration saved from vty
!   2006/06/09 16:13:05
!
hostname rr1-bgp
password zebra
enable password zebra
log file /var/log/quagga/bgpd.log
!
router bgp 65270
 bgp router-id 192.168.27.1
 network 192.168.27.0/24
 network 192.168.254.128/30
 neighbor 192.168.254.9 remote-as 65000
 neighbor 192.168.254.130 remote-as 65120
 distance bgp 150 150 150
!
line vty

1.2  Example 2: peering with IX

In this example we want to peer with Internet eXchange point (IX). We want to achieve the following goals:

1. announce our networks to the peer
2. send only aggregated prefixes
3. obey to IX rules that make us leave AS-path untouched
4. prefer routes from that peer

(line numbers have been added to make the example easier to read)

1. announcing networks is obvious, lines 3 and 4.
2. lines 5 and 6 do that
3. line 12
4. line 9 is it [Question: but why does it work? Answer should take the form of something like, "Higher weights are preferred and the default weight is X"]

!
1. router bgp 111
2.  bgp router-id x.y.122
3.  network 1.2.3.0/19
4.  network 2.3.4.0/24
5.  aggregate-address 1.2.3.0/19 summary-only
6.  aggregate-address 2.3.4.0/24 summary-only
7.  neighbor a.b.c.100 remote-as 666
8.  neighbor a.b.c.100 description whatever
9.  neighbor a.b.c.100 weight 2001
10.  neighbor a.b.c.100 activate
11.  neighbor a.b.c.100 soft-reconfiguration inbound
12.  neighbor a.d.c.100 attribute-unchanged as-path
13.  neighbor f.g.h.j <main neighbor statements>
!

1.3  Example 3: simple router reflector

This example show a simple route reflector configuration for both IPv4 and IPv6.

hostname RR
!
bgp multiple-instance
!
router bgp 64512 view 1
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 64512
 neighbor 10.0.0.2 description iBGP-PEER1
 neighbor 10.0.0.2 route-reflector-client
 neighbor 10.0.0.3 remote-as 64512
 neighbor 10.0.0.3 description iBGP-PEER2
 neighbor 10.0.0.3 route-reflector-client
 !
 address-family ipv6
 neighbor 10.0.0.2 activate
 neighbor 10.0.0.2 route-reflector-client
 neighbor 10.0.0.3 activate
 neighbor 10.0.0.3 route-reflector-client
!
end 

1.4  Example 4: BGP/OSPF failover

BGP, OSPF, single provider 2 BGP sessions, failover scenario

Network diagram is provided below, everything is plugged into a switch (broadcast network)

      RTP (10.0.0.1/27) AS: 666
            |
  /---------+---------\           <--- AS: 999
(eth0..2/27)      (eth0..3/27)
BGP1                  BGP2        <--- no need of iBGP here if failover case only,
(eth1..10.0.2.1/24)  (eth1..2/24)       iBGP is needed in load balancing case
  \---------+---------/
            |                     <--- switched network here
(eth0..3/24)|(eth0..4/24)
       RT1--+--RT2                <--- OSPF area 0
            |
           LAN 10.0.3.0/24

Area0: 10.0.2.0/24

Network advertised to RTP: 10.0.2.0/23

In this case, we want BGP2 to take over the whole traffic in case of BGP1 failure, and also RTR{1,2} to choose their default routes through reachable route.

RTP::

!
router bgp 666
 neighbor 10.0.0.2 remote-as 999
 neighbor 10.0.0.2 description Customer BGP1
 neighbor 10.0.0.2 soft-reconfiguration inbound
 neighbor 10.0.0.2 distribute-list 20 in
 neighbor 10.0.0.2 activate
 neighbor 10.0.0.2 weight 2000
 ...
 neighbor 10.0.0.3 remote-as 999
 neighbor 10.0.0.3 description Customer BGP1
 neighbor 10.0.0.3 soft-reconfiguration inbound
 neighbor 10.0.0.3 distribute-list 20 in
 neighbor 10.0.0.3 activate
 ...
 access-list 10 remark customer as999
 access-list 10 permit 10.0.2.0 0.0.1.255
!

BGP1::

!
! BGP part
!
router bgp 999
 neighbor 10.0.0.1 remote-as 999
 neighbor 10.0.0.1 description My Provider session 1
 neighbor 10.0.0.1 soft-reconfiguration inbound
 neighbor 10.0.0.1 distribute-list 30 out
 neighbor 10.0.0.1 activate
 ...
 access-list 30 remark My Networks
 access-list 30 permit 10.0.2.0 0.0.1.255
!
! OSPF part
!
interface eth1
 ip ospf message-digest-key 10 md5 HereIsMyPassword
 ip ospf prio 100
!
!
router ospf
 network 10.0.1.0/24 area 0
 area 0.0.0.0 authentication message-digest
 default-information originate
!

BGP2::

!
! BGP part
!
router bgp 999
 neighbor 10.0.0.1 remote-as 999
 neighbor 10.0.0.1 description My Provider session 1
 neighbor 10.0.0.1 soft-reconfiguration inbound
 neighbor 10.0.0.1 distribute-list 30 out
 neighbor 10.0.0.1 activate
 ...
 access-list 30 remark My Networks
 access-list 30 permit 10.0.2.0 0.0.1.255
!
! OSPF part
!
interface eth1
 ip ospf message-digest-key 10 md5 HereIsMyPassword
 ip ospf prio 99
!
!
router ospf
 network 10.0.1.0/24 area 0
 area 0.0.0.0 authentication message-digest
 default-information originate metric 300
!

RT1::

!
interface eth1
 ip ospf message-digest-key 10 md5 HereIsMyPassword
 ip ospf prio 10
!
!
router ospf
 network 10.0.1.0/24 area 0
 area 0.0.0.0 authentication message-digest
!

RT2::

!
interface eth1
 ip ospf message-digest-key 10 md5 HereIsMyPassword
 ip ospf prio 10
!
!
router ospf
 network 10.0.1.0/24 area 0
 area 0.0.0.0 authentication message-digest
!

Note, that neither RT1 nor RT2 should have default kernel route set, otherwise kernel route will be preferred.

BGP1 and BGP2 will advertise their default routes to each other, but it makes no difference since both BGP1 and BGP2 have full feeds, and actually need no default route.

In case of BGP1 failure, the only distributed default route, will be the one with metric 300. In standard case, traffic will go out through BGP1, and when weight at RTP is set, will also come back the same way.

Also note, that one cannot balance traffic over two routers, it is just simple failover scenario. In case of load balancing, a bit complicated setup is required.

1.5  Example 5: simple routing decision

Scenario: one BGP router, two upstreams, we want to prefer routers received from peer A no matter what (means AS-patch, better route exists, etc.)

router bgp 123

 neighbor 1.2.3.4 description peer A
 neighbor 1.2.3.4 remote-as 234
 neighbor 1.2.3.4 weight 2000
 neighbor 2.3.4.5 description peer B
 neighbor 2.3.4.5 remote-as 567

The configuration above has its bad sides too. Only routes that HAVE NOT been announced by peer A and HAVE been announced by peer B will get into the routing table. So the following configuration has no sense when accepting full feeds from both peers, as only routes coming from peer A will be installed. It is useful when only partial feed is received from peer A. You have been warned.

1.6  Example 6: as-path filtering

We want to match against specific clients (their ASNs that is)

!
router bgp 123
 neighbor ...
 neighbor route-map GOLDCLIENTS in
 neighbor ...
!
ip as-path access-list BLAH permit _123$
ip as-path access-list BLAH permit _234$
ip as-path access-list BLAH permit _567$
!
route-map GOLDCLIENTS permit 10 
 match as-path BLAH 
!

This way we can match only the following ASNs: 123 234 and 345. Using regexps 3 entries may become one, like this:

!
ip as-path access-list BLAH permit _(123|234|345)$
!

1.7  Example 7: prepending scenario

We want to apply different prepending to different prefixes

!
router bgp 123
 neighbor ...
 neighbor route-map ADVERTS out
 neighbor ...
!
ip prefix-list PL1 seq 10 permit 192.168.1.0/24
ip prefix-list PL2 seq 10 permit 192.168.2.0/24
!
route-map ADVERTS permit 10 
 match ip address prefix-list PL1
 set as-path prepend 123 123
!
route-map ADVERTS permit 20 
 match ip address prefix-list PL2
 set as-path prepend 123 123 123
!

In the above example, we apply the ADVERTS route-map to prefixes we announce to the neighbor. The ADVERTS route-map has 2 sections. Anything matching prefix-list PL1 will be padded twice, and anything matching PL2 will be padded 3 times.

---

2.  OSPF configuration examples

Some OSPF configuration examples may be found in Quagga docs

2.1  Example 1: ABR configuration

!
! Zebra configuration saved from vty
!   2006/06/09 16:13:05
!
hostname rr1-ospf
password zebra
enable password zebra
log file /var/log/quagga/ospfd.log
!
!
!
interface tu0
 ip ospf authentication-key SomeKey
!
interface eth0
!
interface eth1
 ip ospf network non-broadcast
 ip ospf authentication-key SomeKey
!
!
router ospf
 ospf router-id 192.168.27.1
 network 192.168.27.0/24 area 0.0.0.27
 network 192.168.254.9/32 area 0.0.0.0
 network 192.168.254.128/30 area 0.0.0.0
 area 0.0.0.0 authentication
 area 0.0.0.27 stub
 neighbor 192.168.254.130 poll-interval 5
!
line vty
!

Example 1 above is a configuration for an ABR. Network statements describe which interfaces we should include in ospf LSA, and to which areas they correspond. Here I also use a trick to solve a problem with VIA Rhine NIC (eth1). There is a problem with this NIC and multicast adresses, so we declare the network attached to this NIC as NBMA. This makes ospf use unicast hello packets with specific neighbors on this subnet. Dont forget to use the same poll-interval on both ends, or adjacency will fail.

2.2  Example 2: access concentrator as a part of NSSA area

!
log file /var/log/quagga/ospfd.log informational
hostname quagga-router
!
password zebra
!
interface dummy0
 ipv6 nd suppress-ra
!
interface eth0
 description TWE LAN
 ip address 111.111.133.2/26
 ip ospf message-digest-key 1 md5 lalalala
 ipv6 nd suppress-ra
!
interface eth1
 description DSLAM LAN
 ipv6 nd suppress-ra
!
interface eth1.20
 ipv6 nd suppress-ra
!
interface eth1.400
 ipv6 nd suppress-ra
!
interface gre0
 ipv6 nd suppress-ra
!
interface lo
!
interface loopback0
 ip address 10.30.30.169/32
 ipv6 nd suppress-ra
!
interface mpls-ppp0
 ipv6 nd suppress-ra
!
interface ppp0
 ipv6 nd suppress-ra
!
interface ppp1
 ipv6 nd suppress-ra
!
...
...
...
interface ppp244
 ipv6 nd suppress-ra
!
interface ppp245
 ipv6 nd suppress-ra
!
interface ppp246
 ipv6 nd suppress-ra
!
interface sit0
 ipv6 nd suppress-ra
!
router ospf
 ospf router-id 10.30.30.169
 redistribute connected
 redistribute static
 network 111.111.133.0/26 area 0.0.0.90
 area 0.0.0.90 authentication message-digest
 area 0.0.0.90 nssa translate-candidate
 distribute-list connected-nets out connected
!
ip route 111.111.146.0/23 Null0
!
access-list connected-nets deny 111.111.146.0/23
access-list connected-nets permit any
!
ip forwarding
!
line vty
!

Example 2 is a configuration for an Access-concentrator that's part of a NSSA and not an ABR. pppd sessions are created (using say pppoe-server) and then terminate locally, the Null0 route is to advertise a summarized route for the dynamic ip pool, the distribute-list is to filter out /32 routes in that pool, redistribute connected is for customers that are assigned static ips outside the ip pool range via radius. Note: Make sure the local address for each pppd is 10.30.30.169 (lo:0) and not what's in the "network area" command above, otherwise by default pppoe-server will select the eth0 interface, causing ospfd to list the PPP interface /32's in the router-LSA, which is not good.

2.3  Example 3: simple ospf route summarization

router ospf

 ospf router-id 1.2.3.4
 network 1.2.3.0/24 area 0
 network 2.3.4.0/24 area 1
 area 0.0.0.1 range 2.3.0.0/16

Example 3 shows how to summarize routes in OSPF, area... range is the key here. It means all networks inside 2.3.0.0/16 will be suppressed and announced to other areas as 2.3.0.0/16 instad of whole bunch of smaller networks (e.g. 2.3.2.0/24).

---

3.  RIP configuration examples

Some RIP (and RIPng) configuration examples may be found inQuagga docs and here

3.1  example 1: real-life config example

key chain ripauth

 key 11
  key-string SecretPassword

interface eth1

 ip rip authentication mode md5 auth-length rfc
 ip rip authentication key-chain ripauth

router rip

 version 2
 network 1.2.3.0/27
 passive-interface default
 no passive-interface eth1
 route 128.0.0.0/1

In this example router rip v2 is enabled, md5 authentication is enabled on interface eth1 (which in this case is configured with IP: 1.2.3.1/27). Due to passive-interface default, we have to unpassive eth1. At the end, we want the announce the Other Half of the Internet through eth1.

---

4.  Route filtering examples

4.1  example 1: filtering redistributed routes using distribute-list (ospf/kernel)

We want only prefixes belonging to network 20.0.0.0/8 to be redistributed from kernel to ospf. E.g. 20.1.2.0/24 and 20.3.2.0/19 will be included in redistributed routes.

! 
router ospf 
 <other ospf router statements>
 redistribute kernel 
 distribute-list KERNELOUT out kernel 
!
!
access-list KERNELOUT permit 20.0.0.0/8 
!

4.2  example 2: accepting only default route from BGP peer (bgp)

 
!
router bgp 123
 neighbor 1.2.3.4 remote-as 222
 neighbor 1.2.3.4 description OurPeer
 neighbor 1.2.3.4 soft-reconfiguration inbound
 neighbor 1.2.3.4 activate
 neighbor 1.2.3.4 prefix-list DEFGWONLY in
!
...
! 
ip prefix-list DEFGWONLY seq 5 permit 0.0.0.0/0
!

Clearing of session is required after applying prefix-list above.

4.3  example 3: filtering redistributed routes using route-map (ospf/rip/connected)

In this example we use route-map to filter out unwanted connected and rip routes (10.254.254.0/24) and permit anything else

router ospf

 network 10.55.0.0/16 area 0.0.0.0
 redistribute connected route-map RIP_INTF
 redistribute rip route-map RIP_INTF

ip prefix-list DROPADDR seq 5 deny 10.254.254.0/24 ip prefix-list DROPADDR seq 10 permit any

route-map RIP_INTF permit 5

 match ip address prefix-list DROPADDR

---

5.  Configuring Quagga as a route server

Complete explanation how it works, and how to make Quagga act as route server is explained in Quagga docs

---

6.  Router Advertising Configuration

Below example shows how to advertise IPv6 prefix 2001:23b0:0401:3::/64 to local network.

!
interface eth1
 no ipv6 nd suppress-ra
 ipv6 nd prefix 2001:23b0:0401:3::/64
!

Attention, for IPv6 autoconfiguration to work, one must use /64.

In Linux, the following parameters must be set for IPv6 forwarding and autoconfiguring to work:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.router_solicitations = 0

(the example above has been ripped from here, credit goes to Debian Project)

---

7.  Access control

There are generally two ways to provide access control to Quagga's cli.

1. In case you want to make it accessible only from localhost, use -A parameter and make it pointing Ito 127.0.0.1, -A makes daemon bind to ip provided
2. Second case it when you want to limit access to several hosts from yuor local or remote network. You have to configure ACL this way:

!
line vty
 access-class localhost-in
!
access-list localhost-in permit 127.0.0.1/32
!

Second case is also usefull when you don not want to loose routes by restarting daemon, and really mus limit access to cli.