Using BGP when there are two channels on the Internet for selective announcement
Using BGP when there are two channels on the Internet for selective announcement
Input data
With two proprietary / 24 subnets, I was faced with the need for standard BGP operation, and by googling, I discovered the minimum amount of information on this topic. On the Runet’s open spaces, there are mainly cases when there is one grid / 24, and 2 providers, one of which is used as a backup. Yes, and even this case was considered incorrectly or scattered, normally met descriptions only on English-language resources.
Immediately make a reservation - the CiscoOS features considered: EXIST-MAP and NON-EXIST-MAP are not supported by UNIX counterparts (such as Quagga).
In this article I will consider two examples of configs, based on the following data.
- We have two channels: the main working and reserve. Both providers announce us a default. Using both channels is undesirable for us. We, in turn, will announce our subnets to them, but if the main channel is alive - we will forcibly prohibit the announcement of our prefixes to the backup channel, and we will announce it only if the working channel is dropped
- We have two working channels. And we need to always work (announce) our first subnet through the first channel, and our second subnet through the second channel. At the same time, both providers announce defaults to us. If one of the channels falls, we transfer the announcement from this channel to the survivor. When resuming the operation of the fallen channel - we return the announcements to the initial view - one subnet through each provider
')
Theory:
The BGP conditional advertisement feature uses the non-exist-map and the advertise-map keywords of the neighbor advertise-map command in order to track routes by the route prefix. If a route prefix is not present in output of the non-exist-map command, then the route specified by the advertise-map command is announced. This feature is useful for multihomed networks, in which some prefixes are advertised to one of the providers only if information from the other provider is not present (this indicates a failure in the peering session or partial reachability). Ie, if in short: the EXIST-MAP and NON-EXIST-MAP features are the conditions for checking the presence of the prefix in the route table in the route map. This is a trigger that occurs when a route disappears from the table (NON-EXIST-MAP) or vice versa appears (EXIST-MAP)
So, you have:
- its AS
- two of its class “C” subnets (prefixes less than / 24 - are not accepted by providers for the announcement)
- two providers, which agreed on the bgp-session
- cisco with OS version not lower than 12.4 (in versions below 12.4 there is no EXIST-MAP, NON-EXIST-MAP feature we need)
- both providers give you the default route and any prefix of any kind (hereinafter I will explain why this prefix)
Case # 1: all networks are given to one provider (main channel), announcement to the backup channel starts only if the main channel falls
This case is the simplest, you can find its various solutions anywhere, but almost always through “F”, that is, by increasing the path-prepend.
Standardly, both for Cisco, and for decisions on UNIX-systems (when using Quagga), the simultaneous announcement in both channels is. It's just that an announcement with a longer path prepend goes to the backup channel, but in my opinion this is not the best solution. Some providers pre-cut them (so I had, for example, with Rostelecom) and instead of the backup channel, we get a balance between the two channels.
The following solution is more flexible, but there are two nuances:
1. It cannot be implemented on Quagga - it does not know how to work with EXIST-MAP
2. It is necessary that one of the providers, in addition to the default, give some more (any) of its prefix, according to which EXIST-MAP, NON-EXIST-MAP will work. For this, an additional prefix can be easily negotiated with the provider - just tell NOC that an additional prefix from it is needed, because you will use EXIST-MAP, and your add. The prefix provider will add for you in the announcement, no problem.
Scheme:
Here, ComStar (vlan 100) is the main channel, QWERTY (vlan 200) is the backup channel, and Cisco is actually our device.
From logical data:
- FastEthernet0 / 0.100 watches ComStar main channel
- FastEthernet0 / 0.200 watches QWERTY backup channel
- 88.88.10.0/23 - our two C-class subnets (88.88.10.0/24, 88.88.11.0./24), which we will announce
- AS11111 - our autonomy
- 10.10.10.0/24 - additional prefix, which is announced to us by the provider of the main channel, in addition to the default route
Config tsiski:
! interface FastEthernet0/0 no ip address duplex auto speed auto ! ! â„–100, ComStar ! interface FastEthernet0/0.100 encapsulation dot1Q 100 ip address 10.192.0.10 255.255.255.0 ! ! â„–200 - QWERTY ! interface FastEthernet0/0.200 encapsulation dot1Q 200 ip address 192.168.1.10 255.255.255.0 ! ! ip forward-protocol nd ! ! - ( ), ! BGP . , - ! . ! ip route 88.88.10.0 255.255.254.0 Null0 ! ! BGP ! router bgp 11111 no synchronization ! router-id bgp router-id 10.192.0.10 no bgp enforce-first-as bgp log-neighbor-changes ! , network 88.88.10.0 mask 255.255.254.0 ! - - neighbor 10.192.0.200 remote-as 8359 neighbor 10.192.0.200 description ComStar neighbor 10.192.0.200 next-hop-self neighbor 10.192.0.200 soft-reconfiguration inbound ! () neighbor 10.192.0.200 weight 500 ! , neighbor 10.192.0.200 route-map comstar in ! , neighbor 10.192.0.200 route-map ournets out ! - neighbor 192.168.1.200 remote-as 8615 neighbor 192.168.1.200 description QWERTY neighbor 192.168.1.200 next-hop-self neighbor 192.168.1.200 soft-reconfiguration inbound ! ( ) neighbor 192.168.1.200 weight 100 neighbor 192.168.1.200 route-map qwerty in ! ! , ! , 88.88.10.0/23 ( ! non-exist-map neighbor 192.168.1.200 route-map ournets out ! , , 10.10.10.0/24 ! , . neighbor 192.168.1.200 advertise-map ournets non-exist-map NONEXIST_MAP no auto-summary ! ! , ip prefix-list NONEXIST seq 5 permit 10.10.10.0/24 ! ! "" , ! ip prefix-list bogons description Bad-nets ip prefix-list bogons seq 10 permit 127.0.0.0/8 le 32 ip prefix-list bogons seq 20 permit 172.16.0.0/12 le 32 ip prefix-list bogons seq 25 permit 192.168.0.0/16 le 32 ip prefix-list bogons seq 30 permit 169.254.0.0/16 le 32 ip prefix-list bogons seq 35 permit 224.0.0.0/4 le 32 ip prefix-list bogons seq 40 permit 240.0.0.0/4 le 32 ! ! , ip prefix-list our-network seq 5 permit 88.88.10.0/23 ip prefix-list our-network seq 10 deny 0.0.0.0/0 ! ! ! - ! QWERTY: ! "" route-map qwerty deny 100 match ip address prefix-list bogons ! , . , ! , route-map qwerty permit 110 set local-preference 200 ! ! route-map comstar deny 100 match ip address prefix-list bogons ! route-map comstar permit 110 set local-preference 100 ! ! NON-EXIST-MAP route-map NONEXIST_MAP permit 10 match ip address prefix-list NONEXIST ! ! route-map ournets permit 100 description Permit our prefixes match ip address prefix-list our-network What happens when this happens?
, - ( 10.10.10.0/24). , . . 10.10.10.0/24, 88.88.10.0/23 . bgp- , 10.10.10.0/24, advertise-map ournets non-exist-map NONEXIST_MAP - ( - , . It seems to be all, and on this, with the first option finish.
Case number 2: each provider is given one subnet. If one of the links is dropped - the subnet / 24 announcement, from the dropped link, is transferred to the survivor, and when the channel is restored - the announcements return to the initial state - one for each channel
The logical data is almost the same:
- 88.88.10.0/24 - announce to the main channel, 88.88.11.0/24 - to the backup
- in addition to the default route, the prefix 10.10.10.0/24 is obtained additionally from the first provider, and 20.20.20.0/24 - from the second one - the trigger NON-EXIST-MAP will be triggered by them
ip forward-protocol nd ! ip route 88.88.10.0 255.255.255.0 Null0 ip route 88.88.11.0 255.255.255.0 Null0 ! router bgp 11111 no synchronization bgp router-id 10.192.0.10 no bgp enforce-first-as bgp log-neighbor-changes ! /24 network 88.88.10.0 mask 255.255.255.0 network 88.88.11.0 mask 255.255.255.0 ! neighbor 10.192.0.200 remote-as 8359 neighbor 10.192.0.200 description ComStar neighbor 10.192.0.200 next-hop-self neighbor 10.192.0.200 soft-reconfiguration inbound ! neighbor 10.192.0.200 weight 500 ! neighbor 10.192.0.200 route-map comstar in ! (allournets - ) neighbor 10.192.0.200 route-map allournets out ! 20.20.20.0/24, - ! 88.88.11.0/24 neighbor 192.168.1.200 advertise-map ournets11 non-exist-map NONEXIST_MAP2 ! - neighbor 192.168.1.200 remote-as 8615 neighbor 192.168.1.200 description QWERTY neighbor 192.168.1.200 next-hop-self neighbor 192.168.1.200 soft-reconfiguration inbound neighbor 192.168.1.200 weight 100 neighbor 192.168.1.200 route-map qwerty in neighbor 192.168.1.200 route-map allournets out ! 10.10.10.0/24, - ! 88.88.10.0/24 neighbor 192.168.1.200 advertise-map ournets10 non-exist-map NONEXIST_MAP no auto-summary ! ! ., , ip prefix-list NONEXIST seq 5 permit 10.10.10.0/24 ! ! . ip prefix-list NONEXIST2 seq 5 permit 20.20.20.0/24 ! ip prefix-list bogons description Bad-nets ip prefix-list bogons seq 10 permit 127.0.0.0/8 le 32 ip prefix-list bogons seq 20 permit 172.16.0.0/12 le 32 ip prefix-list bogons seq 25 permit 192.168.0.0/16 le 32 ip prefix-list bogons seq 30 permit 169.254.0.0/16 le 32 ip prefix-list bogons seq 35 permit 224.0.0.0/4 le 32 ip prefix-list bogons seq 40 permit 240.0.0.0/4 le 32 ! ! ip prefix-list allour-network seq 5 permit 88.88.10.0/24 ip prefix-list allour-network seq 10 permit 88.88.11.0/24 ip prefix-list allour-network seq 15 deny 0.0.0.0/0 ! ! ( NON-EXIST-MAP) ! ip prefix-list our-network10 seq 5 permit 88.88.10.0/24 ip prefix-list our-network10 seq 10 deny 0.0.0.0/0 ! ! ( NON-EXIST-MAP) ! ip prefix-list our-network11 seq 5 permit 88.88.11.0/24 ip prefix-list our-network11 seq 10 deny 0.0.0.0/0 ! ! ! - route-map qwerty deny 100 match ip address prefix-list bogons ! route-map qwerty permit 110 set local-preference 200 ! ! NON-EXIST route-map NONEXIST_MAP permit 10 match ip address prefix-list NONEXIST ! route-map NONEXIST_MAP2 permit 10 match ip address prefix-list NONEXIST2 ! ! , . 1 2 route-map ournets10 permit 100 description Permit our prefixes match ip address prefix-list our-network10 ! route-map ournets11 permit 100 description Permit our prefixes match ip address prefix-list our-network11 ! ! route-map allournets permit 100 description Permit our prefixes match ip address prefix-list allour-network ! route-map comstar deny 100 match ip address prefix-list bogons ! route-map comstar permit 110 set local-preference 100 What happens when this happens?
, - ( - .: - 10.10.10.0/24, - 20.20.20.0/24). 1. , 88.88.10.0/24 , 88.88.11.0/24 - . 2. , 10.10.10.0/24, "neighbor 192.168.1.200 advertise-map ournets10 non-exist-map NONEXIST_MAP", 88.88.10.0/24 . 3. , 20.20.20.0/24, "neighbor 10.192.0.200 advertise-map ournets11 non-exist-map NONEXIST_MAP2", 88.88.11.0/24 . - - . I repeat - both of these options can be solved by increasing the preppends and announcing all the networks to all the channels, but you can get to trim these very prepends, or to the provider who ignores them - and then it turns out that the traffic will run through the channel that we don’t want use.
Both of these configurations are working and successfully worked on the GNS3 benchmark virtual machine.
One nuance - if you do not use vrf-lite, then at the current setting, the traffic will run along the default route.
Ie, using the example of the second option - the network 88.88.10.0/24 is announced to the first provider, 88.88.11.0/24 - to the second one. Default is accepted from the first provider. The incoming signal to the network 88.88.11.0/24 will go through the second channel (as it should), but the answer (outgoing traffic) will go through the default route, through the first channel, which will lead to traffic asynchronization. To avoid this, the vrf-lite feature is configured. Perhaps I will consider examples in the next article, if matured.
By the way, I will be very grateful if someone will help with examples of vrf for the second option.
Source: https://habr.com/ru/post/150969/
All Articles