Monday, 6 April 2015

Link-state BGP prefix announcements with quagga

Link-state BGP prefix announcements with quagga

The border routers should be excluded from the process of route origination in BGP unless they are configured to do a route aggregation. In all other cases they should only redistribute as BGP prefixes the routes created (originated) by the access routers inside the autonomous system. Most often the access routers run OSPF software and therefore the routes they originate are send to the borders through OSPF areas. It is a common practice to originate routes for the connected to the router networks based on the link-state of the interfaces. In that case if the interface of interest is up and if an IP address is configured on it, the network the configured IP address belongs to may become originated (if the configuration of the access router allows that). This post is intended to show how to do such kind of orignation by using quagga and BGP (not OSPF).

Lets describe the schema employed for the origination of connected routes. When an IP address is configured on a network interface (and the link state of that interface is "up") the operating system kernel marks the network the IP belongs to, as a connected (directly accessible) and creates the correponsing route in the routing table. That route represents the network as directly accessed through some interface name (without next-hop IP address). Routes directed by an network interface instead of next-hop IP address are connected routes. Accroding to both linux kernel and quagga specifications thay appear as supplied to the routing table by the routing protocol "connected". Because each connected route is related ony to a network interface it will be part of the kernel routing table as long as the link state of the interface is "up". When the interface is going down the kernel should delete from the routing table all routes (not only the connected ones) connected through it. The kernel should do the same if the IP address used for connecting the network is delted from the interface configuration.

The configuration bellow gives an idea how to configure bgpd to redistribute the connected routes into iBGP as prefixes. Both IPv4 and IPv6 route origination are described.

hostname bgpd
password zebra
log file /var/log/quagga/bgpd.log
!
router bgp 5421
 bgp router-id 62.44.127.19
 redistribute connected route-map REDISTRIBUTE_CONNECTED_IPV4
 neighbor BORDER_ROUTERS_V4 peer-group
 neighbor BORDER_ROUTERS_V4 remote-as 5421
 neighbor BORDER_ROUTERS_V4 next-hop-self
 neighbor BORDER_ROUTERS_V4 soft-reconfiguration inbound
 neighbor BORDER_ROUTERS_V4 route-map INCOMMING_IPV4_PREFIXES in
 neighbor BORDER_ROUTERS_V4 route-map OUTGOING_IPV4_PREFIXES out
 neighbor BORDER_ROUTERS_V6 peer-group
 neighbor BORDER_ROUTERS_V6 remote-as 5421
 neighbor 62.44.127.17 peer-group BORDER_ROUTERS_V4
 neighbor 62.44.127.18 peer-group BORDER_ROUTERS_V4
!
 address-family ipv6
 redistribute connected route-map REDISTRIBUTE_CONNECTED_IPV6
 neighbor BORDER_ROUTERS_V6 activate
 neighbor BORDER_ROUTERS_V6 next-hop-self
 neighbor BORDER_ROUTERS_V6 route-map INCOMMING_IPV6_PREFIXES in
 neighbor BORDER_ROUTERS_V6 route-map OUTGOING_IPV6_PREFIXES out
 neighbor 2001:67c:20d0:0:62:44:127:17 peer-group BORDER_ROUTERS_V6
 neighbor 2001:67c:20d0:0:62:44:127:18 peer-group BORDER_ROUTERS_V6
 exit-address-family
!
ip prefix list REDISTRIBUTE_IPV4 seq 5 permit 62.44.103.0/25
!
ipv6 prefix list REDISTRIBUTE_IPV6 permit 2001:67c:20d0:20::/64
!
route-map OUTGOING_IPV6_PREFIXES permit 20
 match community REDISTRIBUTE_CONNECTED_IPV6
 match ipv6 address prefix-list REDISTRIBUTE_CONNECTED_IPV6
 set community 5421:19
!
route-map INCOMMING_IPV4_PREFIXES accept 10
!
route-map INCOMMING_IPV6_PREFIXES accept 10
!
route-map REDISTRIBUTE_CONNECTED_IPV4 permit 10
 match ip address prefix list REDISTRIBUTE_IPV4
 set origin igp
!
route-map REDISTRIBUTE_CONNECTED_IPV6 permit 10
 match ipv6 address prefix list REDISTRIBUTE_IPV6
 set origin igp
!
line vty
!
end

How it works? When quagga is installed and configured as a routing protocol its zebra daemon takes in account the content on the kernel routing table and the changes happening there. For instancee if the IP addresses 62.44.103.1/25 and 2001:67c:20d0:29::/64 are configured on the interface enp3s0 the networks 62.44.103.0/25 and 2001:67c:20d0:20::/64 will appear as connected routes in the routing kernel table. That information becomes available to zebra (through NETLINK) and it forwards it to the other routing protocol daemons (such as ospfd, ospf6d, ripd, ripngd, bgpd, isisd). When bgpd receives updates from zebra it classify them by protocol (the one the kernel set as an atribute to the respective routes). Then it checks if the configuration (as the one given above) requires route redistribution. Because "redistribute connected" appears as a part of the bgp router configuration, those routes that matching the protocol "connected" will be processed. But only those of them that can successfully pass through the prefix lists (REDISTRIBUTE_IPV4 or REDISTRIBUTE_IPV6) will appear as BGP routes and will be eventyally announced to the border routers.

Note that the good practise in using quagga instists that the IP addresses should be configured on the respective interfaces by using the zebra configuration. For instance:

zebra@lcpe-gw(config)# interface enp3s0
zebra@lcpe-gw(config-if)# ipv6 address 62.44.103.1/25
zebra@lcpe-gw(config-if)# ipv6 address 2001:67c:20d0:29::/64

No comments:

Post a Comment