BGP conundrum

Answered Question
Mar 14th, 2010
User Badges:
I have a 6500/Sup720 in a POP which is acting as a core, edge and aggregation device.  It's speaking EBGP, IBGP and OSPF.  I'm using OSPF only for point-to-point networks and loopbacks.  I'm using BGP for everything else.
The 6500 has a FWSM in it, which all traffic generating networks hang off of.  I'm using the BGP Stub feature on the FWSM announce these
prefixes into IBGP and sends them to the MSFC which picks them up and distributes them to the other IBGP speakers on my network.
The FWSM is pretty simple BGP speaker.  It only speaks IBGP, it only allows one neighbour (which has to be the MSFC), it doesn't process any UPDATE messages, it only announces connected and static routes (so long as they have a corresponding network statement) and that's about it.  You can't wrap a route-map around network statements, or set communities, or set metrics or weight or anything.  It really doesn't matter because I can set whatever policy I need on the MSFC.
Back to the MSFC - The prefix lengths in my IBGP table are either longer than or equal to the prefix lengths of the prefixes I'm anchoring for EBGP.  To prevent the spewing of these longer prefixes into EBGP, I've opted to tag the internal prefixes with the local-AS community.
Here's my conundrum...
The prefix 10.47.27.0/24 is anchored on this local box via a BGP network statement and a static route.  The same prefix is also being received from 10.47.26.5; the FWSM.  The problem is that the locally anchored route is the one being put into the routing table, so reaching 10.47.27.0/24 via 10.47.26.5 is impossible.  If I remove the static route anchoring the /24, it gets withdrawn from EBGP.
router#show ip bgp 10.47.27.0
BGP routing table entry for 10.47.27.0/24, version 946306
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x108C0
  Advertised to update-groups:
     1          2          3          4          5          6          7        
  Local
    0.0.0.0 from 0.0.0.0 (10.47.26.17)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      Community: 65535:100
  Local, (Received from a RR-client)
    10.47.26.5 from 10.47.26.5 (10.47.27.1)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: local-AS
router#show ip route 10.47.27.0
Routing entry for 10.47.27.0/24
  Known via "static", distance 250, metric 0 (connected)
  Advertised by bgp 65535
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1


router#
There may be a simple fix that I'm just not seeing.  Anyone have any ideas?
Correct Answer by Lei Tian about 7 years 4 months ago

If you want advertise the summary route, you can use aggregate-address freature. With summary-only key word, it will only advertise out the summary route, no need to set community.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
lamav Sun, 03/14/2010 - 20:03
User Badges:
  • Blue, 1500 points or more

Post deleted

jlixfeld Sun, 03/14/2010 - 20:09
User Badges:

Hi Lamav,


On my static route, I actually have the AD set to 250, which means that the iBGP route should be more preferred than the static route, should it not?

lamav Sun, 03/14/2010 - 20:15
User Badges:
  • Blue, 1500 points or more

I realized how the AD was set on the static route after I posted, and thats why I deleted my answer.

lamav Sun, 03/14/2010 - 20:28
User Badges:
  • Blue, 1500 points or more

Hi, I would have to lab this up, but I cant do it now. Way too late for me here on the east coast...


But I believe that what is messing you up is the fact that youre originating a route with the network statement and static route on the MSFC when you dont have to. I guess you are doing that because you want the MSFC to advertise that internal network to an external BGP peer.


If thats the case, you dont need to do that because the prefix learned through iBGP will automatically be advertised to the eBGP neighbor.


Like I said, I would have to test this in a lab, but you may want to remove the network AND the static route statement and see what happens.


make sure you clear all the BGP neighbors after doing so.


Sorry for the confusion earlier. I spoke too soon...


HTH


[EDIT]


This post was edited, so if you read it more than a minyte ag, re-read it.


[EDIT]

jlixfeld Sun, 03/14/2010 - 20:34
User Badges:

Hi,


I understand that the IBGP prefix will automatically be advertised to the EBGP neighbour.  The reason I have the static route in there with the high AD is so I have a route of last resort.  Basically, if the IBGP route becomes unavailable, or is withdrawn internally, I don't want to flap the prefix towards my EBGP neighbour.  The static, high AD route prevents that possibility of flapping.

lamav Sun, 03/14/2010 - 21:02
User Badges:
  • Blue, 1500 points or more

"The static, high AD route prevents that possibility of flapping."


So you would rather advertise a false route to your eBGP neighbor and blackhole the traffic destined for that prefix?

jlixfeld Sun, 03/14/2010 - 21:27
User Badges:

As opposed to having the prefix dampened by upstreams during a period of I[B]GP instability, I'd rather black hole it on my own network, yes.

Lei Tian Sun, 03/14/2010 - 20:43
User Badges:
  • Cisco Employee,

Hi,


That is because local originate has weight 32768 by default, it will never use the path learned from 10.47.26.5. To make it work you need to set the weight to higher than 32768 on the inbound direction of peer 10.47.26.5, so that way it will prefer route from 10.47.26.5.


HTH,

Lei Tian

jlixfeld Sun, 03/14/2010 - 20:50
User Badges:

Yes, if I set the weight higher, that path will certainly become the best path, but at that point, then the local-AS community will prevent that route from being announced to EBGP speakers.


As I said previously, I tag the routes learned from the FWSM with the local-as community to stop long prefixes from being announced to EBGP speakers.

Correct Answer
Lei Tian Sun, 03/14/2010 - 21:05
User Badges:
  • Cisco Employee,

If you want advertise the summary route, you can use aggregate-address freature. With summary-only key word, it will only advertise out the summary route, no need to set community.

jlixfeld Sun, 03/14/2010 - 22:56
User Badges:

I think the aggregate-address feature is probably the best fit.

Actions

This Discussion