BGP Question

wrwarwick

Ok, this might be a really dumb question but here goes:

I have just started the BGP studying for the ROUTE exam. I have a basic understanding of BGP and knew a little about it before I started studying but I have a few questions. If an organization runs BGP, say for multihoming, failover purposes, will the organization have the possibility of routing general Internet traffic? Or because they are essentially a "stub" off of an ISP who is closer to the Internet backbone, will they never have to worry about the issue? I assume there is some sort of security with BGP, or couldn't someone just jack up the entire global routing table?

Maybe I will get a clearer picture as I continue learning it, just wanted to throw it out here. I might find these questions silly in the next few days .

cxzar20

You only advertise your public IP space to your ISP. Your provider will likely only accept this route from you anyways. Internet traffic from many sources may hit the PE, but it shouldn't hit your CE. Keep in mind that it is pretty unlikely that the PE is only homed to your site anyways.

wrwarwick

cxzar20 wrote: »

You only advertise your public IP space to your ISP. Your provider will likely only accept this route from you anyways. Internet traffic from many sources may hit the PE, but it shouldn't hit your CE. Keep in mind that it is pretty unlikely that the PE is only homed to your site anyways.

Ahhhh that makes perfect sense. Thanks for the response!

ColbyG

It's definitely a concern. Most people will use an AS path ACL (^$) to ensure that they're only advertising prefixes from their own AS. This prevents an enterprise from becoming a transit AS.

SPs will typically filter to ensure this as well, but it can't hurt to be cautious.

Daniel333

wrwarwick wrote: »

Ok, this might be a really dumb question but here goes:

I have just started the BGP studying for the ROUTE exam. I have a basic understanding of BGP and knew a little about it before I started studying but I have a few questions. If an organization runs BGP, say for multihoming, failover purposes, will the organization have the possibility of routing general Internet traffic? Or because they are essentially a "stub" off of an ISP who is closer to the Internet backbone, will they never have to worry about the issue? I assume there is some sort of security with BGP, or couldn't someone just jack up the entire global routing table?

Maybe I will get a clearer picture as I continue learning it, just wanted to throw it out here. I might find these questions silly in the next few days .

From an enterprise point of view, you would use filter/access lists to prevent routes from going out that you don't want advertised. Loops are prevented by the "AS" number which is in each BGP packet.

If you were how a small ISP you might have a peering agreement and want the behavior as being seen as a transit network. So you would just share your full routing tables.

cxzar20

ColbyG wrote: »

It's definitely a concern. Most people will use an AS path ACL (^$) to ensure that they're only advertising prefixes from their own AS. This prevents an enterprise from becoming a transit AS.SPs will typically filter to ensure this as well, but it can't hurt to be cautious.

That is one way, we just use the no export community.

ColbyG

cxzar20 wrote: »

That is one way, we just use the no export community.

So you tag everything ingress with no-export? Why? It works, but why not use AS filtering? Or even both, if you're worried.

cxzar20

ColbyG wrote: »

So you tag everything ingress with no-export? Why? It works, but why not use AS filtering? Or even both, if you're worried.

It was just a general consensus among the team, our backbone connects to four different ISPs. I can also ask you why you prefer to use AS filtering? They both achieve the same goal.

ColbyG

I asked you first.:p

I prefer path filtering because it's the typical way to do things. So when someone comes behind me, they can easily understand what I'm doing. I also think there might be slightly less margin for error (in that you don't have to send communities my way).

Your turn, why do no-export instead of the mainstream solution?

cxzar20

ColbyG wrote: »

I asked you first.:p

I prefer path filtering because it's the typical way to do things. So when someone comes behind me, they can easily understand what I'm doing. I also think there might be slightly less margin for error (in that you don't have to send communities my way).

Your turn, why do no-export instead of the mainstream solution?

I think you see both methods in different organizations. Since switching careers in IT we have used no-export both places. It is easy to understand and clean IMO.

DPG

How big are your companies and how many networks are you announcing?

down77

cxzar20 wrote: »

I think you see both methods in different organizations. Since switching careers in IT we have used no-export both places. It is easy to understand and clean IMO.

Remember, you can over-rule a no export with some additional configuration. I'm with ColbyG, I'd prefer the as-path ACL ^$

networker050184

I'd rather just set/match communities. You can get as granular as you like and use them for traffic engineering while you are at it. Much better solution than either of the above.

DPG

This is why I like BGP. There are so many different ways to accomplish a specific requirement.

Forsaken_GA

ColbyG wrote: »

I asked you first.:p

I prefer path filtering because it's the typical way to do things. So when someone comes behind me, they can easily understand what I'm doing. I also think there might be slightly less margin for error (in that you don't have to send communities my way).

Your turn, why do no-export instead of the mainstream solution?

Honestly, the only reason it's considered mainstream is because communities weren't in widespread use when most of the literature was written. For example, most providers worth their salt will have communities setup to allow you to set the local preference on their end via communities. Or to do AS_PATH prepending on their end via communities. But you'll be hard pressed to find a single network book on the market that details the use of these techniques. Go look at nLayer's communities for an idea of what a provider SHOULD be giving you the option to do.

Tagging routes you don't want to go out with the no-export community is a good way to make sure they don't get leaked, anything tagged with no-export won't even be considered for propagation, it's my preferred method as well.

ColbyG

I agree that communities are fantastic, and I use them regularly for LP (along with prepending if needed). For something like this though, I think path filtering is much more common and therefore more readily understood by anyone who works behind me.

I also don't see the value in no-export over path filtering. Yes, the route isn't considered, I guess that could help a bit with resources, but it's not very compelling. More than one way to skin a cat though.

ColbyG

networker050184 wrote: »

I'd rather just set/match communities. You can get as granular as you like and use them for traffic engineering while you are at it. Much better solution than either of the above.

Not in the enterprise world, lol.

Forsaken_GA

ColbyG wrote: »

I agree that communities are fantastic, and I use them regularly for LP (along with prepending if needed). For something like this though, I think path filtering is much more common and therefore more readily understood by anyone who works behind me.

I also don't see the value in no-export over path filtering. Yes, the route isn't considered, I guess that could help a bit with resources, but it's not very compelling. More than one way to skin a cat though.

I largely prefer tagging with no-export because it lessens the administrative overhead. If I change providers, or add a new one, then I may have to adjust any configuration that I'm doing path filtering for.

With the no-export community, I just apply a route-map to the neighbor when I turn it up, and I'm done, I won't be acting as a transit AS for anyone that way. It's simple, clean, elegant, and less susceptible to mistakes since it's less I have to remember and document when doing work down the road, or for anyone else who may be working on it.

ColbyG

You lost me. Filtering ^$ is the same, administratively. You build your AS path ACL, and stick it in a route-map (so I guess you're saving a step with no ACL). There's nothing to adjust per provider if you're not a transit. The only difference is your route-map is in and mine is out.

Forsaken_GA

ColbyG wrote: »

You lost me. Filtering ^$ is the same, administratively. You build your AS path ACL, and stick it in a route-map (so I guess you're saving a step with no ACL). There's nothing to adjust per provider if you're not a transit. The only difference is your route-map is in and mine is out.

bleh, sorry, yeah, I'm thinking of something else as to why I don't like as path filters (confederations).

Now I remember why I do it that way - I have a standard route-map that gets applied to every external peer, dropping RFC1918 routes, my own routes, etc, all the normal crap that you should reject at your border. It was easiest just to add the no-export community to any routes we do take to that route-map, rather than configure a seperate filter list

ColbyG

Ah ha. That makes sense. Good talk.

ColbyG

Sorry to resurrect a relatively old thread, but I found a solid use for No-Export over AS Path filtering today. I was helping a friend out with some BGP (WAN/failover issues).

He's got an MPLS circuit between a couple sites for WAN connectivity and is using a GRE tunnel between the sites for failover. The root cause of the issues he was seeing was that his AS was forwarding prefixes to the WAN provider that he learned via the tunnel. This was causing some issues with failover (his provider was seeing his advertisements as the best path due to AS length, so he would receive no prefixes from the provider after a failback).

In his current situation you could use AS Path filtering (out) or No-Export (in) to resolve this. I chose No-Export in an attempt to future-proof his design. If he brings up more tunnels (DMVPN, maybe) to sites that do not have WAN connections and can only be accessed from his location, AS Path filtering won't fly (unless he uses IGP or iBGP between tunneled sites) as he'll need to forward other ASes.

Sorry for the rambling, just thought it was funny that I found a use for this less than a week after the discussion.