03-17-2020 05:13 PM
Hi Guys,
I am having a issue with BGP conditional advertisement using an exist-map.
My scenario is as below
R1 connected to ISP1
R2 connected to ISP2
R1 and R2 have IBGP peering
I have split my /24 prefix into two /25 prefixes for inbound load sharing of the links.
When using an advertise map, all routes seem to get advertised (including the ones that I dont want to announce). Its almost like the map is not taking effect at all. It works fine when I use the route-map option instead of advertise map.
I have lab'd this on Version 12.4(25c) on GNS3.
Please find the relevant config as attached (I have attached only the config for R1 & ISP1).
Would be great if you could provide some suggestions to resolve this issue
03-17-2020 09:18 PM
Hi, I had gone through your configuration. Since you are using advertise map with exist map, then condition needs to be matched for advertise map to work. Please check route 192.168.1.0/30 is in your routing table.
Thanks
Vishaw
03-17-2020 10:14 PM
Thanks Vishaw.
It does exist in the BGP table as well as the routing table.
When I shutdown the connected interface to the firewall & the route is removed from the tables, the status changes to Withdraw (see below), so it does seem to pick up the exist-map. Its just not advertising the prefixes as per the route-map applied to advertise map.
sh ip bgp nei 10.1.1.2
BGP neighbor is 10.1.1.2, remote AS 65124, external link
Description: ISP
BGP version 4, remote router ID 10.1.1.2
BGP state = Established, up for 00:01:27
Last read 00:00:27, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
*
*
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 4, neighbor version 4/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
NEXT_HOP is always this router
Inbound path policy configured
Route map for incoming advertisements is ISP-IN
Condition-map P2P, Advertise-map TEST, status: Withdraw
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 1 (Consumes 52 bytes)
Prefixes Total: 0 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0
My show version is as below - Could the version be a limitation?
sh ver
Cisco IOS Software, 2600 Software (C2691-ADVENTERPRISEK9-M), Version 12.4(25c), RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 11-Feb-10 23:23 by prod_rel_team
03-17-2020 10:54 PM - edited 03-17-2020 11:00 PM
1 )Please check your route map name because in the configuration you shared it is sowing NP_P2P and in bgp configuration you are using P2P.
2) Other prefixes will not be affected by this configuration. The impact should be only on prefix specified in TEST route map.
03-18-2020 01:15 AM
@vishaw jasrotia wrote:1 )Please check your route map name because in the configuration you shared it is sowing NP_P2P and in bgp configuration you are using P2P.
That was typo in the extract that I attached to post. I have confirmed the route-map name & it is the right one. As mentioned previously, when I shutdown the interface to the FW, the status goes to Withdraw & goes back to Advertise when the interface is brought up again, so the exist map does seem to to work.
2) Other prefixes will not be affected by this configuration. The impact should be only on prefix specified in TEST route map.
So, does this mean that I'll need to apply an advertise map & a separate route-map if I want to filter routes to the ISP?
03-18-2020 01:53 AM
Yes, In your case it will impact 12.12.12.12/32 subnet (either advertise or not advertise).
03-17-2020 11:36 PM
Hi,
@pvzcisco07 The following config will work, as long as 192.168.1.0/30 is in the BGP table of the router; the conditional advertisement process runs along with the BGP scanner, each 60 seconds, so it may take up to 60 seconds after the 192.168.1.0/30 is int he BGP table or is gone from the BGP table, till your policy may take effect.
ip prefix-list COND_ADVERTISE permit 12.12.12.12/32
ip prefix-list COND_EXIST permit 192.168.1.0.30
!
route-map COND_ADVERTISE permit 10
match ip address prefix-list COND_ADVERTISE
!
route-map COND_EXIST permit 10
match ip address prefix-list COND_EXIST
!
router bgp 65123
network 12.12.12.12 mask 255.255.255.255
neighbor 10.1.1.2 advertise-map COND_ADVERTISE exist-map COND_EXIST
Regards,
Cristian Matei.
03-18-2020 01:53 AM
03-18-2020 12:23 AM
Hello
Just to confirm, you wish ONLY to advertise to ebgp neigbour 10.1.1.2, The prefix 12.12.12.12/32 when 192.168.1.0/30 is active and in the route table however if 12.12.12.12/32 is down then just advertised 192.168.1.0/30 correct?
If so @Cristian Matei has provided the solution already
03-18-2020 01:25 AM
03-18-2020 02:08 AM
Hello
@pvzcisco07 wrote:
Hi Paul,
I want to achieve this - the prefix 12.12.12.12/32 will need to be advertised as long as the connection to the FW (192.168.1.0/30 - exist map) is up. If the connection is down, it should stop advertising the prefix.
Regards,
Raj
As stated the solution @Cristian Matei provided should accomodate such request
03-18-2020 02:18 AM
Hi,
Towards each BGP neighbor, per address-family, you can make-use of both an outbound filter (prefix-list, AS-path list, route-map) and conditional-advertisement. If you use both conditional advertisement and one or more outbound filters:
- the prefixes first need to pass (be allowed) by the outbound filters
- prefixes that pass your outbound filters are inspected per the conditional advertisement rule, so the router knows to advertise it or not based on the condition
So, assuming you have the following prefixes in your BGP table: 1.1.1.1/32, 11.11.11.11/32, 2.2.2.2/32, 22.22.22.22/32, 3.3.3.3/32, 33.33.33.33/32, and you want the following:
- to advertise out to a BGP neighbor all these prefixes, except 33.33.33.33/32
- advertise 22.22.22.22 to the same BGP neighbor only if 11.11.11.11/32 exists in the BGP table
ip prefix-list ALLOWED_PREFIXES permit 1.1.1.1/32
ip prefix-list ALLOWED_PREFIXES permit 11.11.11.11/32
ip prefix-list ALLOWED_PREFIXES permit 2.2.2.2/32
ip prefix-list ALLOWED_PREFIXES permit 22.22.22.22/32
!
ip prefix-list COND_ADVERTISE permit 22.22.22.22/32
!
ip prefix-list COND_EXIST 11.11.11.11/32
!
!
route-map ALLOWED_PREFIXES permit 10
match ip address prefix-list ALLOWED_PREFIXES
!
route-map COND_ADVERTISE permit 10
match ip address prefix-list COND_ADVERTISE
!
route-map COND_EXIST permit 10
match ip address prefix-list COND_EXIST
!
router bgp 100
neighbor x.x.x.x route-map ALLOWED_PREFIXES out
neighbor x.x.x.x advertise-map COND_ADVERTISE exist-map COND_EXIST
Regards,
Cristian Matei.
03-18-2020 03:32 AM
03-18-2020 05:23 AM
Hi Cristian,
Thanks a lot for the detailed explanation!
Applying your example to my scenario, the conditional prefix is 22.22.22.0/24 instead of 22.22.22.22/32.
I have split this into 22.22.22.0/25 & 22.22.22.128/25 and would like advertise them out of both my internet routers (connected to two different internet links but with the same ISP) to achieve load sharing for inbound traffic.
In this context, could you please check if the following config will work to achieve load sharing as well as redundancy.
Configuration on Router R1 - Connected to ISP-Link1
ip prefix-list ALLOWED_PREFIXES permit 1.1.1.1/32
ip prefix-list ALLOWED_PREFIXES permit 11.11.11.11/32
ip prefix-list ALLOWED_PREFIXES permit 2.2.2.2/32
ip prefix-list ALLOWED_PREFIXES permit 22.22.22.0/25
ip prefix-list ALLOWED_PREFIXES permit 22.22.22.128/25
!
ip prefix-list COND_ADVERTISE1 permit 22.22.22.0/25
ip prefix-list COND_ADVERTISE2 permit 22.22.22.128/25
!
ip prefix-list COND_EXIST 11.11.11.11/32
!
route-map ALLOWED_PREFIXES permit 10
match ip address prefix-list ALLOWED_PREFIXES
!
route-map COND_ADVERTISE permit 10
match ip address prefix-list COND_ADVERTISE1
route-map COND_ADVERTISE permit 20
match ip address prefix-list COND_ADVERTISE2
set as-path prepend 65123 65123 65123
!
route-map COND_EXIST permit 10
match ip address prefix-list COND_EXIST
!
router bgp 100
neighbor x.x.x.x route-map ALLOWED_PREFIXES out
neighbor x.x.x.x advertise-map COND_ADVERTISE exist-map COND_EXIST
Configuration on Router R2 - Connected to ISP-Link2
ip prefix-list ALLOWED_PREFIXES permit 1.1.1.1/32
ip prefix-list ALLOWED_PREFIXES permit 11.11.11.11/32
ip prefix-list ALLOWED_PREFIXES permit 2.2.2.2/32
ip prefix-list ALLOWED_PREFIXES permit 22.22.22.0/25
ip prefix-list ALLOWED_PREFIXES permit 22.22.22.128/25
!
ip prefix-list COND_ADVERTISE1 permit 22.22.22.0/25
ip prefix-list COND_ADVERTISE2 permit 22.22.22.128/25
!
ip prefix-list COND_EXIST 11.11.11.11/32
!
route-map ALLOWED_PREFIXES permit 10
match ip address prefix-list ALLOWED_PREFIXES
!
route-map COND_ADVERTISE permit 10
match ip address prefix-list COND_ADVERTISE2
route-map COND_ADVERTISE permit 20
match ip address prefix-list COND_ADVERTISE1
set as-path prepend 65123 65123 65123
!
route-map COND_EXIST permit 10
match ip address prefix-list COND_EXIST
!
router bgp 100
neighbor x.x.x.x route-map ALLOWED_PREFIXES out
neighbor x.x.x.x advertise-map COND_ADVERTISE exist-map COND_EXIST
03-18-2020 06:07 AM
Hi,
The config provides both redundancy and load-sharing:
- you advertise both /25 prefixes from both of your routers, conditionally based on the existence of 11.11.11.11/32 in BGP table; this allows for redundancy/failover
- you advertise one /25 with AS-path prepended on one router, and the other /25 with AS-path prepending on the other router; this allows for load-sharing inbound
However, thing to be considered:
- the end functionality relies on the reliability of the exist-map/prefix; for example, if the tracked route of 11.11.11.11/32 is your BGP router interconnect, downstream facing your network, you will stop advertising your public prefixes only if the link goes down; this is ok, as long as the BGP border routers and the downstream layer3 device are directly attached, not through a switch; if there is s switch in between, maybe the downstream layer 3 device fails, but the link of your BGP router stays up, and you still advertise the prefixes, which may not be what you want; You also have to look downstream and take into account all possible failure scenarios, and maybe use another prefix in your exist-map, which the existence or inexistence of that prefix means that the downstream path is functional or not functional
- also ensure that the ISP makes use of the AS-path; maybe the ISP has a local-preference policy configuration, which in the BGP best-path selection process is before AS-path and will in the end route all traffic towards your public IP's, via a single link; you need to speak with your ISP and ensure he's routing for a /25 via your BGP router1 and for the other /25 via your BGP router2
Regards,
Cristian Matei.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide