Do I have to run BGP throughout my core to accomplish the following:
Currently eBGP is working with ISP A/B Peers in a multihomed configuration. I have a customer who wants to be able to use BGP that is connecting through one of our core routers.

Do I have to run BGP throughout the core (on all routing devices) in order to offer BGP routing to the customer, or can I just enable BGP routing on the closest router and iBGP between 10.1.1.1 and 10.1.2.2 over the IGP (OSPF). If the later due I have to create a PTP tunnel between the iBGP peers or can they peer over the IGP?

A few possibilities come to mind but one key question is:

What does the customer want to do with this arrangement? e.g. Do they want to vary which specific IP blocks they are advertising from time to time?

Purely for redundancy. They have a second peer.

OK - well assuming that you can arrange for your two upstream ISPs to accept the blocks of interest being advertised to them by your BGP process it would probably be simpler to:

1) Have the customer advertise the blocks of interest to you via a BGP process on your customer-facing router.
2) Redistribute those blocks into your IGP when present.
3) Redistribute the blocks to your ISP-facing BGP process with suitable adjustments to the BGP attributes to ensure that you are the secondary path when required.

I would avoid redistribution In and out of the IGP...too easy to create a routing loop later on unless you are very disciplined about filtering redistribution. Also, it creates complexity without bringing much of an added benefit. As a rule, we try to limit redistribution only to points in the network where a device is incapable of using a particular routing protocol.

The top options I would consider are:

1) enable BGP all the way to the customer on top of your IGP
2) L2 Tunnel from the BGP edge to the customer via EoMPLS or VPLS and then peer over a /30
3) MPLS L3 VPN from the PE to the BGP edge.

We have a presentation on BGP as an IGP from 2013 MUM in St Louis if you are interested.

http://mum.mikrotik.com/presentations/US13/kevin.pdf

Awesome... That slide was exactly what I was looking for...

The diagram I posted above was simplified. I have ECMP routes distributed via OSPF between multiple routers, and was afraid I'd lose that by using BGP.. Looks like I'll just enable BGP through the core and go that route.

I would avoid redistribution In and out of the IGP...too easy to create a routing loop later on unless you are very disciplined about filtering redistribution. Also, it creates complexity without bringing much of an added benefit. As a rule, we try to limit redistribution only to points in the network where a device is incapable of using a particular routing protocol.

It would be trivial to avoid a looping route in this case! ... and network engineers *should* be disciplined.

The requirement could certainly be met in a number of ways but applying two narrowly controlled redistribution points hardly seems more complex than overlaying iBGP or implementing MPLS. Redistribution is not as scary as it is sometimes made out to be. Technically, even importation of static & connected routes is redistribution....

While I agree with you that Network Engineers SHOULD be disciplined, a few points..

1) Redistribution in large networks with many routers is a Nightmare. I am not scared of redistribution, but when you get into very large scale Carrier/Data Center networks which is mostly what we work with, the risk becomes unacceptable if a routing protocol can be enabled end-to-end to solve the problem.

2) Routing information is almost always lost when you redistribute which can cause issues down the road.

3) Complexity is acceptable if there is a benefit - in this case BGP end to end with ECMP vs multipoint redistribution that must be edited twice every time a route is added if filtering is to be followed. Much better to advertise a route with a filter at the edge and not filter in the core if it can be helped.

Well at least we agree on the need to be disciplined...

Carrier data centers of course generally have to run BGP and there is considerable benefit to sticking with one protocol where possible. They also have staff familiar with BGP (although I must admit I had one data center staffer recently try to describe iBGP to a customer as "BGP enhanced for use as an IGP"...... Really?

Losing routing information is unavoidable given the different metrics, but in a case where all that is required is to advertise a route as a secondary (or not) it shouldn't be an issue.

As regards filtering..... they would most likely be filtered once in either scenario. If the blocks change I suspect that changes on the traffic control side would outweigh any routing filter updates.

If the customer was being fed via a layer 2 VPLS path already I would be far more inclined towards handling the BGP at the existing BGP router - otherwise I honestly think it is a marginal call.
Just as well RouterOS doesn't also have EIGRP otherwise we could get into an endless discussion on the relative merits of the various permutations possible and their affect on convergence in various failure scenarios!

Fair points...really just boils down to design preference. I tend to lean on BGP for many designs because it solves hard problems much more elegantly than static routes or redistribution. That said, I much prefer redistribution into BGP than any other protocol if I have to redistribute.

I just recently corrected a major redistribution outage at large data center because the design was so vast and complex that the Network Engineers didn't remember all the redistribution points and it looped. Must be why I loathe redistribution right now

Fair points...really just boils down to design preference. I tend to lean on BGP for many designs because it solves hard problems much more elegantly than static routes or redistribution. That said, I much prefer redistribution into BGP than any other protocol if I have to redistribute.

I just recently corrected a major redistribution outage at large data center because the design was so vast and complex that the Network Engineers didn't remember all the redistribution points and it looped. Must be why I loathe redistribution right now

Which takes us neatly to documentation - or the cost of a lack thereof........

I certainly prefer unidirectional redistribution where possible. RouterOS currently lacks some of the provisions of other platforms which help to make bidirectional redistribution safe so it could be harder to ensure loop-free redistribution on RouterOS than would be the case on (say) IOS.

In this case, the Documentation was available and current, but the Network was huge (10,000+ nodes) and the engineers were under a tight timeline. It's not always easy to review 200+ Visio Diagrams when changes have to be made in hours and not days

Just to confirm, I ended up enabling BGP on all the core routers on top of OSPF and used routing filters to propagate full internet routing tables to respective peers.

OSPF does not redistribute any BGP learned routes. Loopback addresses are used for BGP peering to preserve OSPF ECMP routes.

No need for any tunneling protocols.

It sounds like you've already addressed your issue, but another option would have been to use multi-hop eBGP, and use static routes for the customer to reach your 10.1.1.1 router, and OSPF or static routes for your 10.1.1.1 router to reach your downstream customer's interface address and peer between them.

Some ISPs use this approach when their customer-facing edge devices may not be carrying full BGP tables.

Q why not create a tunnel from customer to your dnz area so that they are next to your ebgp routers....


Why polute your ibgp with their bgp prefixs.

Note not sure what your business is and you might want their traffic in your core. .

Why complicate things with tunnels? Using BGP and routing filters to propagate the intended routes to intended peers works just fine.

Maybe I didn't clarify that the customer needed full routes.

Why complicate things with tunnels? Using BGP and routing filters to propagate the intended routes to intended peers works just fine.

That is really a matter of opinion

I must state firstly I am not sure of the relationship of the 2 companies, maybe they way each others traffic to propogate into each others networks.

But if you want to seperate out the traffic and have only 2 points to manage for firewall rules. it would be easier to create a IPIP from their border (i think thats 10.0.95.254 to his border 10.1.1.1 (yes I know its /30 - he would have to change that to a /29).

Then they could create a BGP to BGP peer association.

Company B wouldn't be able to route into company a ( his company). But if he wants that then well... this might not be the best choice.

We're an ISP so I don't want to filter their traffic in the event that my customer's need to access their network.

Plus enabling BGP through the core puts the infrastructure in place for peering at different geographical locations.

I would avoid redistribution In and out of the IGP...too easy to create a routing loop later on unless you are very disciplined about filtering redistribution. Also, it creates complexity without bringing much of an added benefit. As a rule, we try to limit redistribution only to points in the network where a device is incapable of using a particular routing protocol.

The top options I would consider are:

1) enable BGP all the way to the customer on top of your IGP
2) L2 Tunnel from the BGP edge to the customer via EoMPLS or VPLS and then peer over a /30
3) MPLS L3 VPN from the PE to the BGP edge.

We have a presentation on BGP as an IGP from 2013 MUM in St Louis if you are interested.

http://mum.mikrotik.com/presentations/US13/kevin.pdf

I consider solution 3 as I get a peering (backup with another local ISP/Full feed) 2 hops away from the data center I have a peering now. We have 2 BGP Uplink routers now at this data center. We connect with 2 licensed links (different directions) into this center and do OSPF/MPLS/LDP through our network. I dont want to inject BGP routes into OSPF and I dont want to do multiple BGP Routers between the data center and the tower the backup BGP will be connected. So the idea is to do a VPLS Tunnel between one of my existing BGP Routers to a new BGP Router at the tower and do iBGP through the tunnel.
Any problem with this solution?