Solved: BGP conundrum

jlixfeld · ‎03-14-2010

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?

Lei Tian · ‎03-14-2010

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.

View solution in original post

lamav · ‎03-14-2010

Post deleted

jlixfeld · ‎03-14-2010

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 · ‎03-14-2010

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

lamav · ‎03-14-2010

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 · ‎03-14-2010

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 · ‎03-14-2010

"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 · ‎03-14-2010

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 · ‎03-14-2010

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 · ‎03-14-2010

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.

Lei Tian · ‎03-14-2010

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 · ‎03-14-2010

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