phil@mindfury.net wrote:
...which is better?
Neither (both) is better, depending on the scenario. This is especially true when mixing in MPLS and other features.
My question is, which is the correct method of implementing this? Should we be redistributing static and connected routes on our borders into IGP, and not using next-hop-self? Or should we not redistribute and use next-hop-self?
next-hop-self seems to remain more stable overall. In some scenarios I believe it is even required (just as not using it is required in other scenarios). For your deployment, I'd say you are open to choose either, and next-hop-self would be the more stable of the two. The largest issue with NOT using next-hop-self that I have seen is the effect it has when that IGP route for the next hop disappears. BGP tends to be more graceful about removing routes via iBGP then handling routes locally when they are suddenly unreachable via IGP. Another benefit of next-hop-self is the fact that the IGP doesn't have to be overly enlarged when you have a large network (injecting hundreds or thousands of links into IGP). With OSPF/ISIS in a flat (single area) topology utilizing MPLS across the core, you would prefer stability in the link state database. Each edge network you place in IGP increases the chances of a database change, and in critical outages, they increase the number of changes that must be made. -Jack