Looking to provide BGP to downstream customers

miked · ‎07-08-2010

We have two separate/disparate networks (separate upstream providers, different IP networks, supernets, etc...). Both networks have BGP peers to different upstream providers. This has been in place for awhile now. Each network acts on it's own individually, completely disparate.

Because of these two networks we want to provide dual connections to our customers, acting as two separate ISP's for redundancy using BGP directly with them. This is something we haven't done yet, and what I'm looking for guidance on.

I've assigned them a /24 to use on both networks. I understand how to peer and advertise with our upstream's, and I understand how to peer to our customer just fine. And I understand how to to do this with on both networks.

The issue I'm trying to wrap my head around is, and it pertains to only one of my networks, if my connection to my customer goes down the BGP peer/session will drop between my router and the customers router and this will bring down BGP between us...and I will stop getting advertisements from them...

but, my peer with my upstream will still be active/advertising their /24 to the Internet!

So from the Internet's point of view I could still get traffic sent to my network that has a down BGP peer. In the event of my connection going down I want the advertisement of their IP's to stop being advertised to my upstream.

Is there a way for the peering between myself and my customer to control their IP block being advertised to my upstream?

I'm sure I'm missing something simple here, I hoping someone out there has done this before or is doing it.

Thanks in advance.

Laurent Aubert · ‎07-08-2010

Hi,

If your eBGP session get down you will update all your other BGP peers with a BGP withdraw message so there is nothing to worry about but it's too easy so I must miss something here ;-). Please provide diagram describing all your BGP session.

Thanks

Laurent.

miked · ‎07-08-2010

Thank you for the reply. Both my upstream connection and the downstream connection would both be their own eBGP session with my router. The upstream has an ASN, I have and ASN, and the customer has their own ASN.

The diagram is pretty simple:

I'll be peering between my router and the upstream in one BGP neighbor config, and I'll be peering between my router and the customer in another BGP neighbor configuration. The customer will advertise a /24 to me, and I'll be configured to advertise the same /24 to our upstream.

So, you're saying if the customer stops advertising his /24 to me I will automatically stop advertising the /24 to my upstream??? That would be nice but it seems like there is something missing as my session will still be up and advertising to the upstream.

I appreciate the help, if it is that easy I'm ready to go. Please confirm.

Laurent Aubert · ‎07-08-2010

BGP behaves like a distance vector routing protocol but it's more like a path vector so it means when I receive a bad news on one side, I propagate it on the other side.

On your router you have nothing to do to announce customer prefix as you will propagate it once you received it from him.

HTH

Laurent.

miked · ‎07-08-2010

Let me get this straight...

In my router I don't need any "network" or "aggregated-address" statements pertaining to the customers /24? All I might need to do is add the customers /24 into my "ip prefix-list" statements?

My upstream is set up to accept the /24 advertisement from us. But if I get this right I don't have to advertise it to them except for it passing through us???

Thanks for the help guys, one of my co-workers told me he has done this before so we signed up a customer and now he can't remember how he did...but int he end the buck stops with me, so I'm definitely appreciate the help!!!

Laurent Aubert · ‎07-08-2010

Correct. You just need to update the filtering rules you want to apply in inbound toward your customer and in outbound toward your upstream peer.

This link may help you to better understand BGP : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

HTH

Laurent.