Forum Discussion
BGP - filtering kernel redistribution
Hello everyone,
I must be missing something on this setup:
I'm trying to configure BGP protocol to redistribute the Virtual Addresses that are configured on the unit, so that when monitors mark the VA down the route is retired.
I've got this exact same scenario working with OSPF already, and I'm using a route-map in imish configuration to do so.
When I configure the same statement in my iBGP lab, it works if I don't use a network-map statement, but since i have the 0.0.0.0/0 network configured as a static-route it shows up in my kernel routes and I really don't want to be announcing that (in prod, there's /32 static routes to DNS, NTP and more that must not be forwarded). When I tru to add a route-map, however, it just drops all advertisements.
##### IMISH show run on "sender" bigip :
!
bgp extended-asn-cap
!
router bgp xxxxxx
bgp graceful-restart restart-time 120
redistribute kernel
neighbor 10.163.191.3 remote-as xxxxxx
!
ip prefix-list lab description "Filter"
ip prefix-list lab seq 5 permit 1.1.1.0/27
ip prefix-list lab seq 10 deny any
!
route-map frontend permit 5
match ip address prefix-list lab
!
##### Output without route-map:
redistribute kernel
bigip.lab.local[0](config-router)#do sh ip bgp
BGP table version is 3, local router ID is 10.163.192.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0/0 10.163.192.1 32768 ?
*> 1.1.1.1/32 0.0.0.0 32768 ?
bigip2.lab.local[2](config-router)#do sh ip bgp
BGP table version is 3, local router ID is 10.163.192.202
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i0.0.0.0/0 10.163.192.1 0 100 0 ?
*>i1.1.1.1/32 10.163.191.2 0 100 0 ?
Total number of prefixes 2
##### Output with route-map:
redistribute kernel route-map frontend
bigip.lab.local[0]#sh ip bgp
bigip.lab.local[0]#sh ip route | grep K
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
K* 0.0.0.0/0 [0/0] via 10.163.192.1, F5_BE
K 1.1.1.1/32 [0/0] is directly connected, tmm
bigip.lab.local[0]#
bigip2.lab.local[2]>sh ip bgp
bigip2.lab.local[2]>
Again this looks so weird to me, since same commands work flawlessly with OSPF protocol. Also, route-map is the only command available in imish to follow "redistribute kernel" instruction. Version is v15.1.5.1
What am I missing?
BR,
CA
I had originally posted this statement:
" I have tried tuning prefix-list but it doesn't seem to work either "
ip prefix-list lab seq 1 permit 1.1.1.1/32
Actually, after more tests, this seems to be the solution -- I sorted it out by completely removing all "redistribute" statements on the process, and then when I added it back again with the "updated" prefix list to match, it worked as intended.
I've edited original post to fix this info.
I'm assuming matches on prefix-list statements require to be "exact matches", I was hoping subnet could match all.
I had originally posted this statement:
" I have tried tuning prefix-list but it doesn't seem to work either "
ip prefix-list lab seq 1 permit 1.1.1.1/32
Actually, after more tests, this seems to be the solution -- I sorted it out by completely removing all "redistribute" statements on the process, and then when I added it back again with the "updated" prefix list to match, it worked as intended.
I've edited original post to fix this info.
I'm assuming matches on prefix-list statements require to be "exact matches", I was hoping subnet could match all.
- wtwiggsAltocumulus
if you match an ip access list instead of prefix list it should work with subnet/cidr range. we are using similar syntax and it has been in production use for several years. we set a /16 mask/range in our access list and each time we enable route advertisement on a Virtual Address the new /32 address automatically redistributes (RHI aka route injection) thru OSPF and BGP (we use both). as a reminder, don't forget to enable route advertisement on each virtual address in LTM. regarding access list for your example it should look like this:
access-list lab permit 1.1.1.0/27
route-map frontend permit 5
match ip address lab
router bgp NNNNN
redistribute kernel route-map frontend
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com