BYO thoughts on BGP routing

Question

I'm a sys/net admin for a small hosting company, and I need to expand my understanding of how our WAN connections (two, exactly) work together to provide high availability for our hosted servers.

We have two onsite routers, each advertising BGP routes on our AS# 19772. We have one link over Sprint (BGP remote-as 1239) and one link over AT&T (BGP remote-as 7018). I have two questions - the second one considerably more in depth than the first - that I'd like an expert to chime in on, please & thank you :)

---

1.. When I run a BGP table lookup (e.g. Looking Glass) for one of the /23 subnets we host & advertise, it shows BGP table as:

BGP routing table entry for 63.164.138.0/23, version 3560718486
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  1239 19772
    154.54.12.22 (metric 10186060) from 38.28.1.83 (38.28.1.83)
      Origin IGP, metric 4294967294, localpref 100, valid, internal, best
      Community: 174:10004 174:20666 174:21000 174:22013
      Originator: 154.54.66.86, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.65, 154.54.66.49

Notice the paths traverse Sprint's AS & our AS as well. This leads me to believe that if AS1239 went down (or more realistically if our routers lost BGP session to it) traffic could still arrive at that subnet over AS19772 (presumably via neighboring AT&T AS7018).

But, I'd like to KNOW, somehow, that this failover behavior will indeed happen if we lose our session to our BGP peer on AS1239.

Is there any way to verify, ahead of time, that AS7018 will advertise a direct neighboring route to AS19772 when it needs to?

EDIT: OK I think I have answered this first question by checking from within AS7018 via AT&T's looking glass:

[email protected]> show route protocol bgp 63.164.138.0     

inet.0: 631792 destinations, 9475808 routes (631792 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

63.164.138.0/23    *[BGP/170] 1w6d 23:05:58, localpref 100, from 12.122.125.165
                      AS path: 7018 19772 I, validation-state: unknown
                    > to 12.0.1.1 via em0.0

Notice the AS Numbers 7018 & 19772, to me means 7018 is properly neighboring with 19772 for this subnet. Yay! OK, onto #2:

---

2.. We are also advertising four /26 prefixes as parts of a larger /24 prefix. Since Sprint AS1239 doesn't advertise peers less than /24, our /26s get "supernetted" into a /12 advertisement:

BGP routing table entry for 63.160.0.0/12, version 3549613850
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  1239
    154.54.12.22 (metric 10186060) from 38.28.1.83 (38.28.1.83)
      Origin IGP, metric 4294967294, localpref 100, valid, internal, best
      Community: 174:10004 174:20666 174:21000 174:22013
      Originator: 154.54.66.86, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.65, 154.54.66.49

which is not ideal.. Notice how our AS19772 is not mentioned at all in that route.. just the AS1239 on the /12.

To add to that, I'm being told that AT&T AS7018 doesn't forward routes smaller than /24 AT ALL, so in that case my /26s are lost as a direct neighbor.. Evidenced here via AT&T's looking glass:

[email protected]> show route protocol bgp 63.165.22.192 

inet.0: 631773 destinations, 9475523 routes (631773 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

63.160.0.0/12      *[BGP/170] 2d 13:58:14, localpref 100, from 12.122.125.106
                      AS path: 7018 1239 I, validation-state: unknown
                    > to 12.0.1.1 via em0.0

Shows AT&T AS7018 has the /12 route, through AS1239, but mention of the more specific /26 route via AS19772.

This leads me to believe that the /26s are not multi-homed properly, and if our AS1239 session is cut, those nets will be unavailable.

So, OK, why not just advertise the four /26s as one /24? Well, on the routers we have an interface on one of the /26 networks. The other three /26 nets are static routed out a different interface.. I seem to remember during router interface turn-up we were having connectivity issues until we made the BGP advertisement mask match the interface mask..

Does anyone know if BGP advertising a /24 from the routers would interfere with traffic on an interface that has a subnetted /26 from that same /24?

EDIT: Per the great answer provided by Ron:

OK, so the piece of the puzzle I am likely missing is the aggregate advertisement for BGP. If I begin advertising the /24 prefix, both neighboring AS's should see that and begin forwarding direct neighbor connections to it.

The last thing I would like to see is evidence that I can advertise an aggregate prefix that I don't have in the routing table. Does anyone have reference to some material I can review to confirm this?

Answer 1

1. Both of your neighbor ASes are advertising your networks. It just depends from where you are looking on the Internet as to which is the preferred route to your networks. If one of your neighbors goes down, the other neighbor will be the only one advertising your routes, so everywhere on the Internet will converge to that path.
2. I don't believe any ISPs will advertise prefixes longer than /24. You could of course advertise aggregate prefixes. If you tried manually combining four /26 prefixes into a single /24 prefix and using a network statement to advertise that, it would fail because BGP need the exact prefixes that it is advertising to be in the routing table. There is an exception to that, and it is called an aggregate address. You can advertise an aggregate address instead of the separate prefixes, and, BGP will advertise it as long as any one of the prefixes is in the routing table. You could also tell it to only advertise the aggregate address, or both the aggregate address and the individual prefixes.

---

Edit:

See the Cisco document Troubleshooting When BGP Routes Are Not Advertised section called Routes Announced Using a Basic Network Statement. Also, see Understanding Route Aggregation in BGP.