Re: Populating BGP from Connected or IGP routes
If you're a little bigger and have BGP customers, then I highly recommend use of BGP communities to control your outbound route filtering. By defining and setting communties on received customer routes, you can turn up new BGP customers without having to modify anything beyond the router they're connected to. It amazes me that there are large networks still not setup this way. You need an after hours maintenance window to turn up a BGP customer? Yeah, we have to modify the prefix list filters on all our backbone routers. WTF? What about traffic filtering? You may use RPF for ingress traffic, but what to do about egress? Or does your router write those ACLs based on BGP community? thanks Thilo
Populating BGP from Connected or IGP routes
Hi all, I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? Thanks for everyone's input! Eric Miller
Re: Populating BGP from Connected or IGP routes
On Mon, Jan 23, 2012 at 12:46 PM, Eric C. Miller e...@ericheather.com wrote: Hi all, I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? This is one of those questions where the answer will depend heavily on who you ask. In my opinion, I would - Keep externally-learned eBGP routes in one table. The Internet table. - Keep internal links (loopbacks, single-homed (to me) customers, networks containing next-hops outside your AS) in an IGP (like OSPF or IS-IS). These routes should very rarely get exchanged outside the AS. - Where possible, have multi-homed customers speak BGP to your AS and just treat those routes as those you'll provide transit for (re-announcing them to other external peers) -- In cases where customers multi or single-home with their own address space that they'd like you to address, put very specific filters and tagging on the routes. This way, you can perform careful filtering on allowing those routes to cross the boundary from IGP to EGP (and onto your external peers). Cheers, jof
Re: Populating BGP from Connected or IGP routes
On Mon, 23 Jan 2012, Eric C. Miller wrote: I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. That depends on your architecture. There are several ways to deploy sane/scalable IGP and EGP architectures. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? Keep in mind that redistribute connected and a network statement in your IGP do two different things. For example, in OSPF, adding a network statement for an interface will enable OSPF on that interface, and your router will try to find other OSPF speaking devices that are connected to that interface and form an adjacency with them, unless you make the interface passive, which would negate the network statement. Routes for connected interfaces that are imported/redistributed into your IGP might carry a different origin, LSA type and/or metric, depending on how you import them. passive-interface default is your friend :) jms
Re: Populating BGP from Connected or IGP routes
On Mon, 23 Jan 2012, Eric C. Miller wrote: First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. The simple answer, for an ISP of small size, is use a traditional IGP such as OSPF or ISIS for internal routing (if any dynamic routing is even needed), and BGP for internet routing, with iBGP between your transit routers if you have more than one transit router. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? I haven't seen one. It's too easy to screw up and let routes out that shouldn't if you redistribute into BGP...the only exception being a well filtered setup for real time blackhole routing. For a small ISP, I'd suggest just using network statements and high metric static routes to null0 to make those network statements always advertise. If you're a little bigger and have BGP customers, then I highly recommend use of BGP communities to control your outbound route filtering. By defining and setting communties on received customer routes, you can turn up new BGP customers without having to modify anything beyond the router they're connected to. It amazes me that there are large networks still not setup this way. You need an after hours maintenance window to turn up a BGP customer? Yeah, we have to modify the prefix list filters on all our backbone routers. WTF? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
