Hiya Andre!

Will you attend @Swinog-9?

I would like to speek about our new Internet-Access and the possibility to
hire you for a few days:
- to check our planned peerings and our little "internet-core"
- tips & tricks for the peering and the BGP-"Tuning", incl. the usage of
tools to find out good BGP-params
-etc.


Greetings,
marcel


Marcel Leuenberger
Network Engineer CCIE #8005
Bundesamt für Informatik und Telekommunikation BIT
Monbijoustrasse 74
CH-3003 Bern

Telefon +41 31 323 87 05
Telefax +41 31 325 90 30
[EMAIL PROTECTED]

www.bit.admin.ch

Der Eisbrecher: Die Kundenzeitung des BIT
www.bit.admin.ch/eisbrecher

MY PGP PUBLIC KEY BLOCK is located:
ldap://keyserver.pgp.com


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Andre Oppermann
Sent: Freitag, 6. August 2004 01:42
To: [EMAIL PROTECTED]
Subject: Re: [swinog] Cisco Optimized Edge Routing OER


[EMAIL PROTECTED] wrote:
> 
> Hi Andre!
> 
> Thanks a lot for your answer!

You are welcome. :-)

> Some comments:
> 
> - Yes, we WILL peer with many ISP as possible @TIX and @CIXP, if possible
> @SwissIX as well.

Great! :-)

> Maybe I have to explain what we have planned in more detail:
> Our Access to the Internet will look like the one you have described:
> 
>                 Upstream                             Upstream
>                     |                                      |
>   CIXP-Peers -  [EMAIL PROTECTED]                    [EMAIL PROTECTED] -
> TIX-Peers
>                     |                                      |
>                     |                                      |
>                    iBGP                                  iBGP
>                     |                                      |
>                     |                 iBGP                 |
> to other iBGP-Rt <[EMAIL PROTECTED] - - -  [EMAIL PROTECTED]>to other
> iBGP-Router
>                     |                                      |
>                     |                                      |
>                     ---------LinkLoadBalancer in/outbond---
>                     |                                      |
>                     |                                      |
> 
>                                 Data Center/UserProxy
> 
> Our main internet access will use BGP to advertise our prefixes and to
catch
> the prefixes learned fom all peerings.
> We place a router @TIX and a router @CIXP and have 2 other Routers in Bern
-
> this 4 routers will build our "Internet"-core.

Make sure you run a full iBGP mesh (including an iBGP session between
BIT-Router
@CIXP and @TIX).

> There will be other routers within our "Internet-Network" so will act as
an
> "ISP" for our goverment-customer.

Sounds good.

> The idea was to use LoadBalancer between this "Internet-Infrastructure"
and
> our Data-Centers/Userprox/etc.
> Generally the data-center is a customer of the "BIT-ISP". There will be no
> BGP between the Data-Center and the our "Internet-Router"
> So the loadbalancer will only be used for this datacenter and not our
> "internet-routing" itself.
> The loadBalancer will use PA-Adresses assigned from one [EMAIL PROTECTED] and one
> [EMAIL PROTECTED] for the source-NATing.
> The goal of this is to have only one path from the IXP to our [EMAIL PROTECTED]
> and hopefully this will be the "best" one.

If you use PA-Addresses from your upstreams you will lose all benefits of
BGP routing and all access from other ISPs to these servers will go through
those two ISPs. The peerings with other ISPs doesn't give any benefit
anymore
and you have the long RTT again (depending on the upstreams you get PA
from).
In addition you have to do (rather large) policy-routing hacks to send the
PA-Addresses back through the right links and ISPs. I can only strongly
recommend against doing this for a large network as yours. With small ones
it works fine (like in the data sheets for F5 and RadWare where the ISP
Upstreams connect directly to the linkbalancer) but it get really messy
with everything more complex than that. On top of that you would have to
get additional separate multihop-eBGP sessions from the PA-providing
upstreams for the linkbalancers.

The NATing load balancer only help for user access but not for servers. See
below. However in your case with full BGP routing there is no advantage with
using NATing boxes.

>       "To link-load....To packet-loss. "
> The base idea was to implement another ADDITIONAL mechanism to have the
best
> End-TO-End path from the BIT to the other end- and have faster failover
(in
> a end-2-end-view)
> in the case of any routing-failures wihtin our (Upstream)-ISPs.
> Of course I'm happy if this is not necessary and BGP will do the right
> thing.
> I was not sure if BGP will converge quick enough in the case of
> routing-issues and
> if BGP will select the "best" path to reach a remote destination.

BGP convergance is certainly fast enough for this. The other systems are
in no way faster. At least Radware and OER are rather coarse and I doubt
they would make much difference, if any at all.

> This was the reason to thinking about linkloadbalancer for our datacenter.

If you have PA-Addresses you have worse convergence for incoming traffic
than doing pure BGP. For the PA-Address space solution you have to use some
DNS based load balancing as well. DNS convergence will be longer than pure
BGP convergence. This is the same way the BGPDNS solution works. However
BGPDNS is not as fast as real BGP because of the DNS TTL which has to be
set to some reasonable level (at least 5 minutes). If you make it too short
the client will have to do a DNS lookup every time he clicks on a link and
that will add ever more delay in page loading for the user experience.

>    "With BGP you can't really improve the inbound traffic in the sense you
>    are probably thinking....."
> Yes, our ideas was to use linkbalancer for the inbound traffic destined
for
> our datacenter.

A linkbalancer can't balance the incoming load to your server over different
ISPs. Only BGP can do that. Normally incoming traffic to servers is only a
fraction compared to the outgoing traffic from the servers (~15%) and thus
not of importance.

> As well, as a "public servant" we will choose the laziest way and are not
> willing to tune BGP:-))
> No, you are right, we have to do some BGP tuning. But our crew has only
BGP
> knowledge and we have not a lot of
> experience with Internet-Routing itself, with all its tricks.

To cut the learning curve quite a bit it would certainly be not bad to hire/
consult someone who will lend you his knowledge and experience.

> So will test the tools you have mentioned to opmise our Internet-Routing
as
> soon as our little internet-BB is in operation.

You can use the tools right now, even though you only have IP-Plus as
upstream.
It doesn't matter. It simply does a statistic how much traffic you have with
which AS'es. This will be the same before and after you do your own BGP. It
doesn't optimize or measure delay/bandwidth or anything else. It just shows
you with whom you have the most traffic.

> So the idea with OER was an alternative solution than the usage of Radware
> or F5.
> Even OER on our [EMAIL PROTECTED] or on a dedicated box between the
> internet-core and the datacenter.
> Unfortunately OER us only for outband traffic.

You don't need any F5, RadWare or OER. I don't know anyone with full BGP
routing who has or uses such a thing. There is just no need for it. Pure
BGP works very well (at least for all the ISPs in Switzerland).

> And this was the reason of my question if someone have experience with EOR
> in a setup like the one above.
> 
> Sorry, my first posting was really not clear enough:-(

No problem. BGP core routing is no easy thing. You should make the first
steps with someone who has done it a few time before and has real-world
ISP experience. You'll be an ISP anyway, so the same "rules" apply.

PS: Will you come to SwiNOG-9 on 29th September 2004 in Berne?

-- 
Andre

www.networx.ch
_______________________________________________
swinog mailing list
[EMAIL PROTECTED]
http://lists.init7.net/cgi-bin/mailman/listinfo/swinog

_______________________________________________
swinog mailing list
[EMAIL PROTECTED]
http://lists.init7.net/cgi-bin/mailman/listinfo/swinog

Reply via email to