I am pretty new to BGP so forgive me if this is a rather straight forward question.

Say I have my own AS number and I have two independent links to my upstream ISP
Lets call these links link A and link B.
Both connecting to the same ISP and thus peering to the same AS number

So lets say for the arguments sake I just have one /24 that I need to service all my customers.

The network may eventually be joined in an OSPF redundant circle but for now lets just assume that half the customers go out through Link A and the other half through Link B. Each customer will get a public IP (no NAT here) so my /24 needs to be used through both links A & B

I know I can only advertise a minimum of /24 to the ISP so I assume I will have to advertise this network at both link A & Link B.

My confusion comes when trying to understand how the routes back to my customers will work?
If a route comes into the ISP AS destined for my /24 how will it know what path to take to get to the customer if it knows two paths for the entire /24 and I assume it will choose one of the other as it does not know anything beyond where to send the whole block of /24.

Would this be impossible to achieve without routing through my own AS ?

The answer to your question is, you can set it up do what you like...

e.g if you wanted to load balance across the two interfaces,
http://wiki.mikrotik.com/wiki/Manual:BG ... interfaces

or if you wanted to do load sharing...
http://wiki.mikrotik.com/wiki/Manual:Si ... ring_setup

or use MED

http://wiki.mikrotik.com/wiki/Manual:BG ... _Algorithm

Ahh sorry I was not clear

The answer to your question is, you can set it up do what you like...

e.g if you wanted to load balance across the two interfaces,
http://wiki.mikrotik.com/wiki/Manual:BG ... interfaces

or if you wanted to do load sharing...
http://wiki.mikrotik.com/wiki/Manual:Si ... ring_setup

or use MED

http://wiki.mikrotik.com/wiki/Manual:BG ... _Algorithm

I meant to say that there will be a different router for Link A and B

they are in very different geographical locations

You might send a support request to your ISP's BGP team and ask them if they support longer prefix lengths for private links - I know Level3 and Windstream both allow prefixes more specific that /24 as long as they also have a "no-export" community set on them. (their own version of the standard one, but still the same concept).

If the ISP allows this, and they support MED then you're in great shape. Advertise your /24 in both places AND announce your more specific prefixes. I assume of course that your customers in geographic region A all come from a specific subset of your IP space (the same /27 for instance) and region B is also able to be aggregated into a single prefix.

(For those reading this thread who are NOT following this principle, this is one of the reasons you want to do this)

If your customers aren't in aggregated blocks, then this is not going to be possible without advertising lots and lots of long prefixes /31 and /32.... they may not want you cluttering up their routing table with all of this - especially since it amounts to them carrying your traffic for you instead of giving it to you at their most convenient interconnect and letting you carry it the rest of the way. (many top tier carriers get into peering wars over this)

In order for MEDs to work, you'll need to originate all of your specific prefixes at both routers so the ISP will see two different metrics on each prefix and route accordingly. If they don't want to use MEDs, then you can simply advertise region A subnets on link A, and region B prefixes on link B, and /24 on both links.

Advertise your /24 in both places AND announce your more specific prefixes. I assume of course that your customers in geographic region A all come from a specific subset of your IP space (the same /27 for instance) and region B is also able to be aggregated into a single prefix.

In order for MEDs to work, you'll need to originate all of your specific prefixes at both routers so the ISP will see two different metrics on each prefix and route accordingly. If they don't want to use MEDs, then you can simply advertise region A subnets on link A, and region B prefixes on link B, and /24 on both links.

Happy to aggregate customers into Geographical blocks.
I don't understand how do I Advertise a /24 in both locations and Announce a more specific prefix? like a /27

Could you go into a bit more detail as to the routerOS functions used to do this,
As I understand it I would have my /24 set as the BGP network on routers at both SIte A & Site B. What function do I then use to "ANNOUNCE" a prefix inside that unique at each site router.

Could you go into a bit more detail as to the routerOS functions used to do this,
As I understand it I would have my /24 set as the BGP network on routers at both SIte A & Site B. What function do I then use to "ANNOUNCE" a prefix inside that unique at each site router.

In general terms, the network statements in BGP are a list of prefixes which the router will originate if it sees a matching route (exact match, both destination and mask) in the active routing table. In other words, it's a set of destinations that the router will tell the world it knows how to reach, but only if it actually knows how to reach them.
(I think of a little red flag going up a flag pole whenever the route is there, and the flag goes down whenever the route isn't there - I really see it that way in my head)

So - having said that, it should be no surprise when I tell you that you should put networks statements in your routers for the /24 and for every longer prefix you wish to announce to the ISP. So suppose 192.0.2.0/24 = main prefix, and 192.0.2.0/25 = region A, and 192.0.2.128/25 = region B. You just put all 3 prefixes in your list of networks. Bing! Easy!

Now you need to actually have the prefixes in your routing table. Remember that it's not necessary for the BGP router to be the ACTUAL source of the prefix in order to originate it into BGP - it just has to have a definititive IGP route to exactly that prefix before it will "raise the flag" in BGP space. Most beginner BGP how-tos tend to suggest that you "nail up" the route with a black-hole route. This is fine and it works, but it's a little too written in stone for my tastes. Suppose a border router loses its inward-facing ("lan") interface, but stays connected to the ISP. It will still advertise the prefix to the world, but it is in fact advertising a black hole. It should withdraw the route. I prefer to originate the prefixes in OSPF somewhere deep inside the network so that if a BGP router has a route to some prefix in its routing table, then the prefix is guaranteed to be actually reachable. Then the network statement simply picks up the prefix and originates it into BGP so that now the world will know how to reach you.

Let's take a moment and consider some examples from this scenario. Whatever router is the most central to region A, make it announce a summary route into OSPF for 192.0.2.0/25. Whatever router is most central to region B should announce 192.0.2.128/25. Both can have a black hole type route to 192.0.2.0/24. Redistribute those black hole sumary routes into OSPF. Your border routers (bgp routers) will of course be speaking OSPF also. (side note - it's the BGP routers which should be distributing default routes into OSPF, "if-installed" and so receiving a default route from the ISP in addition to full routes will be the 'secret sauce' for your automatic default route) When they see these aggregate routes in OSPF, they will match the network statements, and BGP will create prefixes and advertise them to your ISP. Whatever OSPF cost has accumulated onto the prefix will become the BGP "metric" which is used for MED announcements.

So the region A router will originate the prefix for region B, but will have a higher OSPF cost to reach B than the region B router will. Say router A sees the route with cost 50, while B sees it with cost 20. Both bgp routers will originate the prefix and send it to the ISP, but with MEDs enabled, the ISP will see link A having a metric of 50 to reach 192.0.2.0/25 and link B having a metric of 20 for that same prefix. ISP will choose link B to reach that prefix. Since both regions also originate the /24 prefix, this means that both bgp routers should have a 20 metric to reach the /24, so the ISP will see 20 as the metric, and thus it will choose whichever link is more convenient for the ISP's policy if you don't have a smaller prefix (suppose you were announcing /27 prefixes, but not all 8 of them)

Again - remember that all of this is "academic" if the ISP won't accept longer prefix length that /24 for its internal use.
Some ISPs do, some don't.

EDIT: I just read your message that the ISP will not allow this. That's unfortunate. You can only perform ingress traffic engineering per prefix that you advertise.... so if your entire network is just a single prefix (/24) then there's nothing you can do to influence a single ISP's multiple connections to you for ingress packets. Even if you had two separate ISPs, you couldn't cause region A to favor link A and region B to favor that link. Sorry to be the bearer of bad news.

In general terms, the network statements in BGP are a list of prefixes which the router will originate if it sees a matching route (exact match, both destination and mask) in the active routing table. In other words, it's a set of destinations that the router will tell the world it knows how to reach, but only if it actually knows how to reach them.

This is assuming the "Synchronize" option is enabled in the BGP networks right?

ZeroByte you are a legend, this post will be most useful to me in future I think

But alas as you said it is academic, as my ISP doesn't allow it
Guess We will just have to buy more /24 when we need them and try to use them up as best we can.

This is assuming the "Synchronize" option is enabled in the BGP networks right?

Yes. Good catch. I'm used to assuming this is the case, because it's the default behavior in Cisco. (I've never actually run production BGP on Mikrotiks, so some of the nuances might escape my attention)

In general - at least this design seems best to me:
originate your master and prefixes in BGP, and your regional prefixes in IGP at dedicated RR / route servers located at the regional cores. So if 10.10.0.0/16 is in Region 1, and 10.11.0.0/16 is in Region 2, there should be two RR at the core (diversely connected/located) of each of these regions which originate your prefixes. Border routers only know these prefixes if connected to your internal network, so if the router is up, its peering connection is up, but its internal connectivity drops, it will withdraw the prefixes of your network so as not to black hole yourself. Meanwhile, the border routers originate default routes into your IGP, conditional to their BGP sessions being up and valid and indicating good routes to the Internet. That way, if the router is up, but the Internet is down, it will stop announcing default GW info.