Hardware for 2 full views

Abram · Tue Nov 10, 2009 1:19 pm

Hi all.

Currently I have one upstream and so didn't have any need for BGP; BR450G was OK for me.
Now I'm going to have second upstream and want to establish BGP peering with both ISPs.

What hardware would be fine for me? I'm going to recieve two full view tables to fully take advantages of 2 ISP connections.

Thanks.

mrz · Tue Nov 10, 2009 1:43 pm

Two full feeds requires a lot of RAM. You need router with 512MB of ram, like RB1000.
RB450G can handle only one feed.

Abram · Tue Nov 10, 2009 2:11 pm

Two full feeds requires a lot of RAM. You need router with 512MB of ram, like RB1000.
RB450G can handle only one feed.

OK, and so what about 3 full feeds? Is there any RouterOS-capable hardware? Or is there any way to upgrade memory in RBs?

mrz · Tue Nov 10, 2009 2:31 pm

You can change memory in RB1000. It uses SODIMM modules.

roc-noc.com · Tue Nov 10, 2009 2:55 pm

The RB1000 goes up to a maximum 1.5GB of RAM using a single 2GB DDR2 SODIMM.

Tom

Abram · Tue Nov 10, 2009 3:03 pm

First, thanks to all for replies.

So, would RB1000 really do the job? Or is it a cheap way and maybe I should look for something else (maybe x86)?

believewireless · Tue Nov 10, 2009 8:07 pm

The RB1000 doesn't do well with multiple BGP peers carrying full routes. Go with at least a dual core processors X86.

synologic · Tue Nov 10, 2009 10:23 pm

I have to agree with believewireless, it takes a very long time to receive and process the full bgp table, at which point the CPU is used 100% (and if you use ospf or other timing sensitive stuff, they will timeout).

X86 would be fine, but i didnt got around to replace the RB1000 i have.

Abram · Wed Nov 11, 2009 12:17 am

synologic,
believewireless,
Thanks for replies. What is the actual processing time? 5 minutes to process routes at boot time (and then just forget about the router for year or two

) would be ok.

Chupaka · Wed Nov 11, 2009 7:52 pm

Abram, please forget about full feeds! receive only default routes

thadem · Thu Nov 12, 2009 2:00 pm

that kinda fucks up the whole idea behind bgp, right? why should i limit myself if there is hardware available that can cope with a real full view?

Chupaka · Thu Nov 12, 2009 4:14 pm

limit? what kind of limiting do you mean? isn't 'full view' just a loud words for those whose server is RB450G and it's enough?.. so you simply get only default routes from uplink providers - and then announce your subnets with different prepend to these uplinks

dada · Thu Nov 12, 2009 4:18 pm

Abram, please forget about full feeds! receive only default routes

it is usefull only when you intend to use the second BGP peer as a backup one (and the ISPs doesn't want to use OSPF for it). But it will work as expected only when link to main ISP will go down. You will receive the default route even half on an Internet will have no connection to your main upstream ISP - so you will not be able to access these prefixes. In the case of 2 full views you will access the prefixes via second upstream...

Chupaka · Thu Nov 12, 2009 4:44 pm

absolutely wrong. if you announce all your prefixes to all your uplinks, but with different prepend - you get full backup, and at the same time you can control, via which uplinks you will receive the traffic for those subnets

Muqatil · Thu Nov 12, 2009 6:29 pm

Agree with Chupaka! Anyway you aren't going to use the routes you are receiving in a full view table.. Your Router can choose the route to go out by a policy routing you choose with only the default routes. And you can load balance /backup just subnetting your announces ( Announce on both peers your whole network [you got a /22 IE?] then announce it again with subnets [4x /24] to the prefered link. And Et voilà the traffic comes from that link! If that one goes down, the backup link has still the routes to your network [the /22]..
You need BGP full routing tables only if you have to do transport between AS [Carrier]
Ask to a consultant for further info about BGP tbh..
Hope it helps.

Edit: Chupaka, prepend isn't always working with peering with different AS

Chupaka · Thu Nov 12, 2009 10:31 pm

Chupaka, prepend isn't always working with peering with different AS

well, even in the worst case (many different ASes on one uplink to the ~tier1, almost direct connection via second uplink) bgp-prepend=5 (10, 20, etc

) saves the situation =)

Thu Nov 12, 2009 10:33 pm

lol, the "full views" argument...

I come accross people wanting "full views" on a regular basis, when I probe further they have never been able to give a valid answer why.

Generally you will only need to receive a default route from your upstream peers, use a route-map/policy filter to pad the secondary path and then as Chupaka said pre-pend your AS on your secondary path.

eagle · Fri Nov 13, 2009 9:35 am

absolutely wrong. if you announce all your prefixes to all your uplinks, but with different prepend - you get full backup, and at the same time you can control, via which uplinks you will receive the traffic for those subnets

So, you insert a default route into your network and propagate the static route? If the largest subnet is a /24, prepending is enough to set the preferred uplink?

I am a bit worried about the capability of the RB to swallow a lot of routes in BGP, so simplifying that would be a plus. Have you got an example perhaps?

Thanks!

Chupaka · Fri Nov 13, 2009 10:28 am

If the largest subnet is a /24, prepending is enough to set the preferred uplink?

not sure about others, but our ISP receives only /24 ang greater networks. so you are likely can set preffered uplink per /24 subnet (or shorter mask)

Have you got an example perhaps?

an example of what? =)

eagle · Fri Nov 13, 2009 11:43 am

not sure about others, but our ISP receives only /24 ang greater networks. so you are likely can set preffered uplink per /24 subnet (or shorter mask)

The smallest subnet you can count on to be advertised properly, is a /24. So, advertising an /21 to the less preferred uplink and a /24 to the preferred, is not possible our case. So how do you manage incoming traffic? Prepending is not very reliable, I think.

an example of what? =)

An example of how you set the preference of the outgoing traffic (to the uplinks) with 'automatic' fallback (so, without manual interference in case the preferred uplink is down).

(We work on ios now, so I still have to learn the ROS ways)

Chupaka · Fri Nov 13, 2009 1:38 pm

So how do you manage incoming traffic? Prepending is not very reliable, I think.

prepending is exactly what you need

/routing filter
add action=accept chain=isp2 disabled=no prefix=1.1.1.0/24 set-bgp-prepend=5
add action=accept chain=isp1 disabled=no prefix=2.2.2.0/24 set-bgp-prepend=5

An example of how you set the preference of the outgoing traffic (to the uplinks) with 'automatic' fallback (so, without manual interference in case the preferred uplink is down).

/ip route rule
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp1
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp2

so now if you don't have a default route in 'isp1' table (isp1 failed, bgp session dropped = no default route) - RouterOS will lookup 'isp2' table

thadem · Fri Nov 13, 2009 2:07 pm

limit? what kind of limiting do you mean? isn't 'full view' just a loud words for those whose server is RB450G and it's enough?.. so you simply get only default routes from uplink providers - and then announce your subnets with different prepend to these uplinks

fully right, but as i think we are in a forum for isps there should be some propagating of these rules downwards to a customer, of course just take the default route otherwise.

eagle · Fri Nov 13, 2009 2:12 pm

prepending is exactly what you need

/routing filter
add action=accept chain=isp2 disabled=no prefix=1.1.1.0/24 set-bgp-prepend=5
add action=accept chain=isp1 disabled=no prefix=2.2.2.0/24 set-bgp-prepend=5

So, in this case each prefix will have a prepend on different isp. To have everything go through isp1 (isp1 is cheaper), it would be

/routing filter
add action=accept chain=isp2 disabled=no prefix=1.1.1.0/24 set-bgp-prepend=5
add action=accept chain=isp2 disabled=no prefix=2.2.2.0/24 set-bgp-prepend=5

(Or the prefix addition might be dropped all together, since it counts for all prefixes?)

Code: Select all
/ip route rule
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp1
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp2
so now if you don't have a default route in 'isp1' table (isp1 failed, bgp session dropped = no default route) - RouterOS will lookup 'isp2' table

Thanks. So this goes with 'normal' announcing our networks (and not default-originate).

I'll study the wiki this weekend

Chupaka · Fri Nov 13, 2009 2:24 pm

yes, for full backup you should just prepend all announces to your backup link (with one rule)

and of course you should _not_ announce default route to your upstream provider

eagle · Fri Nov 13, 2009 2:55 pm

yes, for full backup you should just prepend all announces to your backup link (with one rule)

and of course you should _not_ announce default route to your upstream provider

Right, got it

Just another question...

On the LAN side we only have directly connected networks (so no routing). Should we still have to add default routes on that router to the ISP IP's? Having doubts now.

ip route 0.0.0.0 0.0.0.0 <neighbor1>
ip route 0.0.0.0 0.0.0.0 <neighbor2>

Chupaka · Fri Nov 13, 2009 3:15 pm

you need to have routes to the networks you are routing. if you have Internet access - then yes, you need default route - to the Internet =)

dada · Fri Nov 13, 2009 3:23 pm

absolutely wrong. if you announce all your prefixes to all your uplinks, but with different prepend - you get full backup, and at the same time you can control, via which uplinks you will receive the traffic for those subnets

incoming traffic has no problem, of course. But there is no easy way how to send your packets to the destinations which are not (temporarily accessible via the default route provider (if you have no better routes from the other uplink - as we are discussing the case we have 2 default routes to two upstreams).

eagle · Fri Nov 13, 2009 3:39 pm

Thanks for the quick replies.

Is there an advantage for taking default routes over directly connected routes? I understand that the directly connected routes take more memory (at least a little) and it probably takes ROS a bit more time to update , but apart from that, what could be an advantage for default routes?

Chupaka · Fri Nov 13, 2009 3:48 pm

wo_Ot

these are absolutely different things

'default' means 'dst-address=0.0.0.0/0'
'connected' means 'gateway=some interface, not nexthop address'

eagle · Fri Nov 13, 2009 4:12 pm

Thanks, better start reading up on things....

eagle · Fri Nov 13, 2009 5:29 pm

/ip route rule
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp1
add disabled=no src-address=1.1.1.0/24 action=lookup table=isp2

More questions keep popping up....I looked at the wiki but I can't find anything on how the identity of 'table=isp1' and 'table=isp2' is set up. In other words, I have no clue on how the syntax is built.

Are the table names 'isp1' and 'isp2' derived from the peering setup (the names configured for each peer)? As I said,the wiki doesn't solve this for me.

Thanks for your time (again).

eagle · Fri Nov 13, 2009 6:35 pm

I feel like hijacking the thread. Sorry for that.

The info is a bit fragmented. Seems I have to add 'extra' tables:

ip policy-routing> table isp1
ip policy-routing table isp1> add dst-address=0.0.0.0/0 gateway=<ip-isp1>

ip policy-routing> table isp2
ip policy-routing table isp2> add dst-address=0.0.0.0/0 gateway=<ip-isp2>

So this is correct?

Chupaka · Fri Nov 13, 2009 7:07 pm

either you add static routes, as you wrote, or you receive your default routes via BGP and then set necessary routing-mark in routing filters

eagle · Fri Nov 13, 2009 7:40 pm

We will receive default bgp routes ...

I'll do some additional reading on route markers.

Abram · Sun Nov 15, 2009 12:25 am

limit? what kind of limiting do you mean? isn't 'full view' just a loud words for those whose server is RB450G and it's enough?.. so you simply get only default routes from uplink providers - and then announce your subnets with different prepend to these uplinks

Well, right now I have only 35 mbits on one uplink ISP, so it's enough for me now. In a month or two, I'll have two different 100 mbit uplinks, so that's going to be a problem

. Actually, I'm here to find the solution before my ass hurts

.

Chupaka, thanks for announcing my subnets idea. I wasn't thinking of that. I guess in this case RB1000 with 1.5GB RAM would be enought for me before I buy a dedicated server or Cisco router. That's really great idea so I'll even forgive you your skepticism

.

Can I contact you via ICQ or something?

Chupaka · Sun Nov 15, 2009 1:01 am

well, on our BGP border router we have 1 Gb RAM, 923 Mb free with three uplinks

p.s. it's not scepticism, it's realism =)

p.p.s. the best place for contacts is the Forum

for private questions - my SkypeID is 'pavel.skuratovich'. but forum is better

Abram · Sun Nov 15, 2009 4:23 am

p.p.s. the best place for contacts is the Forum for private questions - my SkypeID is 'pavel.skuratovich'. but forum is better

Well, I like using Russian while I speak it better than English.

And thanks again for idea. Что-то я тупею...

Hardware for 2 full views

Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Re: Hardware for 2 full views

Who is online