-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 14 April 2015 10:32 PM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] Passing default route through BGP?
Thanks Mike,
If I set it to originate a default, then it does originate it. After some
I set it to originate-default=if-installed, then it is *passing* the default route it has learnt. However once a session is originating default, it will not receive default from that same peer.
I just set it up again, rtr01, originating-default if-installed to rtr03, and rtr03 sees the defaults from its upstream and rtr01 (and the static route)l:
[admin@rtr03] > /ip route print detail where dst-address=0.0.0.0/0 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=0.0.0.0/0 gateway=223.25.113.57 gateway-status=223.25.113.57 reachable via vlan308 distance=20 scope=40 target-scope=10 bgp-as-path="55707" bgp-local-pref=50 bgp- origin=igp bgp-communities=54320:55707 received-from=BGP_IPv4_AS55707 1 S dst-address=0.0.0.0/0 gateway=223.25.113.57 gateway-status=223.25.113.57 reachable via vlan308 distance=200 scope=30 target-scope=10 2 Db dst-address=0.0.0.0/0 gateway=103.235.52.65 gateway-status=103.235.52.65 reachable via vlan99 distance=200 scope=40 target-scope=30 bgp-as-path="9482,38285,1221" bgp-local-pref=50 bgp-origin=igp
bgp- communities=9482:14201,9482:19201,9482:65500,38285:4,38285:20,38285:22, 38285:1221,54320:9482 received-from=IBGP_IPv4_RTR01
Then I set originate-default if-installed on rtr03, and it's now only seeing the default route from its upstream (and the static route):
[admin@rtr03] > /ip route print detail where dst-address=0.0.0.0/0 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=0.0.0.0/0 gateway=223.25.113.57 gateway-status=223.25.113.57 reachable via vlan308 distance=20 scope=40 target-scope=10 bgp-as-path="55707" bgp-local-pref=50 bgp- origin=igp bgp-communities=54320:55707 received-from=BGP_IPv4_AS55707 1 S dst-address=0.0.0.0/0 gateway=223.25.113.57 gateway-status=223.25.113.57 reachable via vlan308 distance=200 scope=30 target-scope=10
I don't have redistribute-other-bgp set to yes, as the documentation seems to suggest that it is only learnt to share routes between BGP instances - and I'm only running one instance on each router? I did try turning it on tonight, and it made no difference though..
The only filter I have is an accept filter on the _in filter for the iBGP session, to only accept 0.0.0.0/0 if the 54320:9482 etc community is set, as I was randomly getting a default route via IBGP which didn't have bgp info on it (bgp-origin being 'incomplete') - I'm assuming that was when the other
was sending it's static default route as well as it's bgp learnt route?
Although a slightly related question which may render this all not overly needed (though would still be nice to have it working) - how much ram do I need to store four full BGP tables (IPv4 + IPv6) per router? I figured it would mean needing 2gb of ram, since one full feed of both requires 512mb, but reading the Mikrotik BGP FAQ, it looks like maybe I could get away with 1gb of ram? Though that's probably still leaving me needing a CCR as each edge router, as I don't think there's anything 'smaller' with that much ram? Even getting 512mb seems difficult. (Edgerouter Lite's are starting to look like a good cost point ($150 for 512mb and 3 x gig ports, and they actually will route gigabit), but I *really* like the CLI on routerOS, the REST API is awesome, and WinBox for quick changes is fantastic..)
Thanks,
Damien
On 14 April 2015 at 09:09, Mike Everest <mike@duxtel.com> wrote:
Hi Damien,
Are you sure it's not being filtered out somewhere? RouterOS definitely advertises default route when configured to do so (i.e. default-originate=if-installed) Of course you would also need to redistribute routes learned from other BGP too (i.e. instance has redistribute-other-bgp=yes set), but judging from your comments thus far, I guess you already know that :-}
Does default route show up in "rout bgp ad pr"?
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Monday, 13 April 2015 8:55 PM To: MikroTik Australia Public List Subject: [MT-AU Public] Passing default route through BGP?
Hi Guys,
Our primary upstream has had a couple of small periods of complete downtime the last couple of nights, which has given me the opportunity (lol) to test our failover with our other two upstreams.
Found an issue in that it looks like RouterOS doesn't pass default route through BGP?
I currently have one router setup per upstream, receives a default route plus full feed (but we filter to only directly-connected (one AS hop) prefixes for each upstream)
I then run IBGP between all edge routers. And also run OSPF between the four edge routers, and the core router, to send a default route to the core.
My thinking was that OSPF will redistribute a default route on any edge router with an active default route (i.e. BGP is up and/or gateway IP is pingable) Which works ok, IF the upstream gateway goes down. If I remove the hardcoded default routes, then it works as expected, but leaves those routers uncontactable.
I had also been expecting that the default route from each upstream was being passed on via iBGP to the other routers - to the point that I had been setting localpref on each one based on their cost and available bandwidth.
On checking tonight, it seems that the 0.0.0.0/0 routes are NOT being propagated via IBGP?
I can set default-originate=if-installed, which sends a default route from one peer to another, but it is not the one being received on eBGP from the usptream, as the localpref is wrong. And if I set default-originate=if-installed on the other peer, that peer stops receiving that default route.
Has anyone tried this? It works fine on quagga and cisco, but doesn't appear to be working on mikrotik (which if it's correct, makes me glad I found it before I'd forked out on another three hardware routers to go alongside my CCR when it arrives back)
Thanks,
DG
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of
Hi Damien, I'm not sure that I fully understand the behaviour that you are reporting :-} redistribute-other-bgp is intended to allow the router to advertise to its peers route prefixes that it has learned from other peers - which instance is involved instance itself shouldn't matter (don't think so, but haven't tested it! ;) If the default route is learned from your upstream, then I would have expected that you need that set to allow it to be re-advertised to your igp peers - are you saying that it is /not/ the case? That originate-default=if-installed will re-advertise the default route regardless? If you are saying that the learned route is re-advertised with the nexthop of the upstream router, then you need to force the nexthop to 'self' - look for 'nexthop-choice=force-self' attribute under bgp peer settings. But I get the feeling that I'm missing the important point of your thread - if so, sorry about that! :-} Regarding alternative platforms, I'm with you on that - routerOS is just too good to be easily overcome by lower price - but that's my own opinion, of course, and you'd expect someone who runs the largest Australia/pacific distributor of a product to have that opinion! :-D About RAM size for BGP tables - the answer is 'a lot' ;) I don't have any routers myself that contain even one full table, so I can't tell you exactly what a full table costs in RAM, but I'm sure that there are others on this list that can tell you ;) What I do know is that when it comes to multiple BGP peers with full global tables, CPU cost is a lot more important than RAM! The problem is that current routerOS (v6) is still limited to one thread for routing table update task, so you end up with one CPU core always pegged, and routing table update lagging. In one case that I am aware of, it caused sufficient grief that the network operator had no choice than to take out the CCRs and replace with other routers. Yes, they cost a lot more (A LOT MORE! ;) but CCR simply couldn't keep up with that demand. I don't know for sure what the actual demand was for that particular case, but again, someone else on the list might be able to offer some real-world data on that! Cheers, Mike. playing, if peer thunder.
We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au