Hello.

I have a noob question regarding BGP.

With the network command you can inject routes from the routing table into the BGP process.

Why the need to redistribute routes from another routing protocol into BGP using redistribution if you can do the job with the network command?

Thanks in advance.

I'm sure there lots of reasons but would you want to define every network if you had say a thousand ospf routes?


---
- Sent from my iPhone using Tapatalk

Depends on the situation really. But you have to think of other things like the origin attribute after redistribution.

_________________
"I will prepare and some day my chance will come." - Abraham Lincoln
http://danielhertzberg.wordpress.com - I blog about networks!

You don't. Back in the day, redistribution on most cisco routers sucked horribly -- tons of scalability issues. They fixed that for the most part now. Personally, though, I never redistribute connected routes due to some of these old bugs.

The only real reason for redist is if you want to easily filter routes for redist (e.g. ip prefix-list blablabla permit 1.1.0.0/16 ge 25 le 30, or only routes with a certain tag etc), or manipulate attributes right on the point of entry (BGP communities, localpref, prepend etc). It also lets you document each route using prefix-lists and route-map descriptions instead of thousands of random network statements, which makes them easier to remove later.

Origin of incomplete is no big deal -- provided you don't have another router that has it originated via a network statement (that would be a mistake in the network), and only then would it matter if you were using MED as localpref and AS path are earlier in the decision process.

Less statements.

_________________
http://blog.alwaysthenetwork.com

In a nutshell, you need the redistribution command because there are situations when you need to redistribute route, and you need the network command because there are situations where the BGP advertising router is generating that route itself and no redistribution is needed.

For example, in a large SP environment, most of your routes from your customers are going to be carried with an IGP. At the core of your BGP running routers, you are going to have to designate certain routers to act as the redistribution router where you will redistribute the customer routes into BGP. That's where you will see the redistribution command used to redistribute IGP, along around static and even connected routes.

At the edge of your core(s) where you are running eBGP, that's where you will often use the network (or aggregate network) command as you will be advertising the public IP block that the ISP owns. This is a static block so it calls for the use of network command.

The situation is not that all that different in a BPG-running Enterprise or data center except for scale, and you will most likely find both the network and redistribution command used on the same router.

_________________
"It can also be argued that DNA is nothing more than a program designed to preserve itself. Life has become more complex in the overwhelming sea of information. And life, when organized into species, relies upon genes to be its memory system."

Customer routes should never be carred in IGP. Customer routes should be carried in BGP. IGP is only for your internal networks like transit interfaces and loopbacks. Keep the IGP slim and convergence fast.

The reason to redistribute is that you might have many static routes that need to be redistributed and it does not make sense to put a network command for all of them. What you do instead is to do redistribute static and connected with a route-map for filtering. The route-map makes sure that you don't redistribute anything not belonging to you and no RFC1918 addresses and such.

I know some providers run customer routes in IGP but that is poor design to me and will have scalability issue if you have a large network.

_________________
http://lostintransit.se

There is nothing wrong with using an IGP as a PE->CE routing protocol, don't know where you have that idea from...

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

Yes for MPLS VPN it is perfectly fine to run IGP as PE to CE protocol but then it is in a VRF so it will not affect your own IGP. I was talking about how to build a scalable provider network for plain v4. You would not want to run IGP with customer for that.

Even if you run MPLS VPN you will still redistribute IGP into BGP to carry the routes. I still think BGP is more scalable even for those scenarios as you won't run into issues with having too many OSPF instances or such. Also BGP has much more options for filtering.

_________________
http://lostintransit.se

Advertising routes using the network command gives you more control so you can "specify" what you want to advertise. However with a large number of routes, this can become time consuming and tedious. So you can use the redistribute command to make the whole process dynamic and effectivly advertise 100's of routes using one redistribute command. The pitfall of using this method is the control is sacrificed to the dynamic nature of the routing protocols so if using this method, you definatly want to safe gaurd yourself using filters/route-maps/prefix list's to prevent loops and false routing information.

Thanks. I thought it would something more dark but it seems the difference is only about management purposes(and the origin attribute).

Origin can be changed.

Mobile Post

_________________
blog.brokennetwork.ca