I have a simple question (I think)

I have a BGP session with one of my provider handing me the full routing table and default route. I need to make changes to that BGP session to where it would restart.

If I added a static Default route to the same destination while I was making that changes, would the static router apply fast enough to make it so I would not loose any connections?

If the explicit BGP routes disappear along with the BGP default route from the provider then assuming that:

these routes were all pointing at the same upstream and,
you have added a default route pointing at the same gateway,
no other routes come into play and the default route you added is active

then the traffic should go to the same gateway and be NATed as before (if NAT involved) so connections should not break.

For outbound traffic, probably. Do it at 2AM anyway.

If you are advertising routes to your provider, (Why would you run BGP if you're not?), then the routes you are advertising will probably go away until the BGP session rebuilds. That will most likely make your static default route immaterial from a packet loss perspective. This is one reason we have maintenance windows.

For outbound traffic, probably. Do it at 2AM anyway.

If you are advertising routes to your provider, (Why would you run BGP if you're not?), then the routes you are advertising will probably go away until the BGP session rebuilds. That will most likely make your static default route immaterial from a packet loss perspective. This is one reason we have maintenance windows.

All true. It sounds, though, like OP just wants to make sure that he isn't kicked out of the router and unable to get back into it if the neighbor session doesn't come back alive / has some problem with the route exchanges....

If he uses the router's peering address on the actual eBGP interface to talk to it, then that should stay available even w/o BGP.

For outbound traffic, probably. Do it at 2AM anyway.

If you are advertising routes to your provider, (Why would you run BGP if you're not?), then the routes you are advertising will probably go away until the BGP session rebuilds. That will most likely make your static default route immaterial from a packet loss perspective. This is one reason we have maintenance windows.

This is a great point I had overlooked. All inbound traffic would be lost to any subnets that I am advertising using the BGP session.

All I am attempting to do is enable "redistribute other bgp" on my instance to my provider. I wish I could enable it without restarting the session.

All true. It sounds, though, like OP just wants to make sure that he isn't kicked out of the router and unable to get back into it if the neighbor session doesn't come back alive / has some problem with the route exchanges....

If he uses the router's peering address on the actual eBGP interface to talk to it, then that should stay available even w/o BGP.

That is what I though. Since I'm not advertising my peering IP with my provider but it rather being static, it should not drop that connection.

My secondary concern is the effect on my customers. I think my provider would have to put static routes to my public subnets for them to retain service throughout that period of time.

Sounds like they are just going to have to go down for a minute.

Time for an all-nighter... again. lol

You mentioned "one of" your providers earlier. Are you not advertising your IP ranges on multiple providers?

Redistribute . . . always think twice before you use redistribution.

Redistributed routes are "third-class citizens." Without changing the local_pref or weight, BGP would take a journey through 12 ASes to reach a prefix originated with a network statement vs going directly to a neighboring eBGP peer that originated the prefix by redistributing.

If it's needed, it's needed - but a network statement is the best-practice way to originate routes into BGP.
(I just scanned my BGP table, and only 145 out of 525115 were originated with redistribution)

I took a long pause before hitting submit on this post. I don't want to sound like a pedantic know-it-all, or anything - it's just that I feel like this is an opportunity to share some things which I've come to understand as best practice. Ultimately you know your network and I don't - this is just my $0.02's worth of input.

If it's needed, it's needed - but a network statement is the best-practice way to originate routes into BGP.
(I just scanned my BGP table, and only 145 out of 525115 were originated with redistribution)

ZeroByte,

I hate to sound ignorant, but if they are someone elses Subnets that I'm advertising, wouldn't it be best for them to orginate them and I just redistribute? I have not done this before so I am wanting to do this in the most apropriate manner.

And if I use a "Network Statement" would it be just adding it to my routing/bgp/networks and then selecting "Sycronize" so that I only advertise it when they are giving it to me?

I hate to sound ignorant, but if they are someone elses Subnets that I'm advertising, wouldn't it be best for them to orginate them and I just redistribute? I have not done this before so I am wanting to do this in the most apropriate manner.

The customer has their own public AS number and they're handing routes to you with EBGP?

Then they should be speaking to the same BGP instance as your primary, (Cisco doesn't even allow multiple bgp instances, by the way) and you should be using route filters to keep the customer from sending you anything but their own routes. Then your BGP simply passes them along to other ASes.

That's how an as path is formed. They (customer) originate a prefix, which creates a path of just "i" (igp), you receive it from them with the path "AS1, i" and when you pass it to your providers / other customers, they will see AS path "AS2, AS1, i"

If they don't have an AS number and you're peering with a private ASN, then you should peer them with your primary BGP instance and manipulate the AS path to remove the private ASN / replace it with yours.

In any case, it sounds like the word "propagate" is a better term for what you're doing than "redistribute."

I know it sounds nit-picky, but these protocols have a lot of nuances to their behavior, and it helps to be precise.

The customer has their own public AS number and they're handing routes to you with EBGP?

Then they should be speaking to the same BGP instance as your primary, (Cisco doesn't even allow multiple bgp instances, by the way) and you should be using route filters to keep the customer from sending you anything but their own routes. Then your BGP simply passes them along to other ASes.

That's how an as path is formed. They (customer) originate a prefix, which creates a path of just "i" (igp), you receive it from them with the path "AS1, i" and when you pass it to your providers / other customers, they will see AS path "AS2, AS1, i"

If they don't have an AS number and you're peering with a private ASN, then you should peer them with your primary BGP instance and manipulate the AS path to remove the private ASN / replace it with yours.

In any case, it sounds like the word "propagate" is a better term for what you're doing than "redistribute."

I know it sounds nit-picky, but these protocols have a lot of nuances to their behavior, and it helps to be precise.

This is incredibly useful information, thank you!

I think this will help me quite a bit with my peering. Thank you!

No problem!

Just make sure that you always filter your advertisements upstream by prefix until you're 100% confident in everything you're doing with BGP - because if you make a mistake here you can become a path between your ISPs and neither you nor they want that.

Also - make sure that you filter your customers' advertisements by prefix as well so that they cannot send any other routes to you. Your customer does not want your network using them to reach dropbox.com right?