Hello all,

I work for a smallish WISP who multihomed (we'll call them ISP1 and ISP2, ISP1 being the first/original provider) and was allocated a /22. I've set up a routerOS border router (atom/x86) where I've successfully brought up BGP sessions with both providers, set up route filters that drop bogons and equalize the scope and target-scope (one is multi-hop and was getting different scope values, causing everything to route out that way), etc. The router has been inserted between the core router (which was the original primary connection to the original ISP) and our two providers. I have a static route for our /22 going into our core, static routes for our non-portable blocks from ISP1 back into our core, a route going back to ISP1 (which is marked), and a mangle rule making sure all packets originating from the space provided by ISP1 go back through ISP1 via the marked route. At this point the only oddities I'm seeing:

1.) When I do a traceroute into our network (to orig. space or new) our bgp border router always responds back with ISP2's route link address even if it comes through ISP1. Outbound traceroutes seem to work fine. I'd like to correct this but without having to do any more mangle rules if possible - I've got a minimal firewall on this router, protecting mainly itself, and would rather not have it do any more packet inspection than it has to. So, anyone have any ideas what I should look at? As I said, one provider is multihop while the other is a direct connection, and the one always showing up (ISP2) is the multihop one.

2.) When looking at the routing table, all routes are showing a bgp-origin of igp - shouldn't these be egp? Is this some kind of effect from having a multihop BGP peer?

2. route-origin is virtually always IGP - that flag is set by the router that originated the route you're receiving, and that router virtually always got the route from an internal routing protocol within its AS. The flag does NOT signify what source YOUR router received the route from.

Thanks for the clarification, that makes the route table make more sense to me.

In regards to #1, I found out I had asymmetric routing going on - in many cases, the Mikrotik was preferring ISP2 over ISP1 for the reply packets when the AS hops were equal, even if the source preferred ISP1. From what I've read it appears that all things (hops) being equal whichever BGP session came up first gets preference. So, since we want most traffic to go in/out ISP1 anyway I've added an extra AS hop to ISP2 via the route filters for now which seems to have normalized things. I imagine the better solution would be using mangling to mark the incoming connections and force them back out the same interface they came in via a route table. I'll have to set up a lab rig mimicing our live setup and play with it in case we ever decide to get rid of the extra administrative hop. So far the CPU on this dual-core atom rig rarely breaks 5% unless the route tables are being rebuilt so I doubt I'd load it up much with some extra filter/mangle rules (we only max ~30Mbps of routed traffic to/from our upstreams so far).

On that note, I know Mikrotik recommends that you shut off SNMP on BGP routers but that wasn't an option for us - we need to monitor the router's CPU, inbound/outbound traffic, etc. I set up our NMS (zenoss) to never touch the route OIDs - which I wouldn't want it to do anyway - and so far I haven't seen any random CPU spikes or performance penalties. <fingers crossed>

I'd recommend setting localpref on the incoming routes. The route with the highest localpref wins.

Localpref is the way to control outound traffic.

If you need to control inound traffic, use route filter