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