[EMAIL PROTECTED] wrote:
>
> HiYa!
>
> As a part of the new Intenet-Solution BIT, the Bundesverwaltung will
> improve their Internet-Services : On the
> one hand that our services will be fast and reliable for the public and on
> the other hand that the bundesverwaltung-users/servcices have a fast and
> reliable service as well.
>
> To overcame some BGP limitations we are deploying an additional service
> which takes care of response-time, link-load, packet loss,etc.
As a long-time BGP fellow in the Swiss Internet there is one major tip
with regard to response-time etc.: PEER WITH EVERYONE at TIX and CIXP!
(The term "peering" is for zero-cost I-send-my-AS-and-You-send-your-AS
things, "Upstream" is for ISPs which give you the entire Internet and all
~140k routes).
This alone will take down your response-time to essentially all Swiss
Internet Users to a very good level of only a few milliseconds (depending
on their local loop type). The problem is that most major ISPs in CH do
not peer with smaller ones and thus the path a packet has to take is far
longer than necessary. For example IP-Plus does not peer with Swiss ISPs
except for Sunrise and Cablecom (who are probably paying them). For example
do a traceroute from IP-Plus to www.tiscali.ch or some other mid-sized
Swiss ISP. When you have a direct peering with them, it'll usually be below
5ms RTT.
To link-load. You should have sufficient capacity from your internal network
to all your uplink points (@TIX and @CIXP I gather from an earlier mail from
you). So if one fails the other one should be able to handle the full load.
Especially with BGP you can never exactly tell via which link the traffic
will come back to you.
To packet-loss. Should never happen. If it happens, then kick the link out
of your IGP immediatly if it's within your network or links. If it is at
one of your upstreams, then shut down the BGP session with them and route
over the others until it is fixed. If it is somewhere else in the Internet
then there is not much you can do.
Speaking from long time experience, the link-load/packet-loss things you
list above are not of great concern and normally no real issues. The
important thing is that you get your internal BGP network setup right
and that you a have coherent preference hierarchie for outgoing routes.
That makes things much more easier and leads to consistent routing
(route-maps to prefer certain things even if the path is longer, etc.).
Split routing is not nice for your kind of network (that is one router
sends traffic for the same destination this way and the other one that
way) and makes tracing problems rather hard and difficult.
Upstreams Internal Upstreams
| | |
GE <-------------> BIT-BE <-------------> ZH
| |
CIXP peers TIX peers
Not to go into deep detail but the Internal network should be connected
via (preferrably more than one) BGP speaking router which a iBGP session
to the routers in GE+ZH. The connections to GE+ZH should end at different
routers in BE. Run some sort of IGP (OSPF or ISIS) between all routers
to distribute reachablility information of the connected networks. All
your own prefixes should be announced from the appropriate internal
routers. This is essential to be fail-save if one of the GE/ZH links
goes down. With something like this you get a very robust and tolerant
network that will survice many incidents that happen occasionally. The
real test is to simply unplug any component (including power rails or
entire racks) and see whether the network continues to work.
> We are thinking about about RadWare linkProof or F5 BigIP LinkController.
> These producty may be "well known" for you or of one of your customer.
The products you list here most likely do not work for your setup. For
example the F5 and the RadWare want to sit in the connection path for all
of your upstreams and then use NAT to do its magic. That is the reason it
can "manage" the inbound traffic. The major disadvantage is that your
/16 networks won't be visible from outside but hidden behind some small
blocks of IP addresses you get assigned from all your upstream ISPs. So
you are not doing real and full BGP and do not advertise your own netblocks
to the world via BGP. Also this prevents peering at the Internet Exchanges
TIX and CIXP.
> We are looking for alternative for those products described above and have
> found:
>
> "Cisco Optimized Edge Routing OER"
> http://www.cisco.com/go/oer
This would be the only one that give you true and full BGP routing.
> Do you have any experience with this "IOS-Feature"?
No, it seems to be fairly new and thus I suspect early-adopters to be the
usual Cisco beta-testers. Expect a lot of work to get it to work ;-)
> Unfortunatelly, OER is available today only for outgoing traffic...So it
> will only improve our own hosted services and not the inbound traffic.
With BGP you can't really improve the inbound traffic in the sense you
are probably thinking. Mostly it just works. You have to use tools like
Netlantis or the RIPE Route Collectors and other looking glasses to find
out how your networks are being seen by the world. Then you might have
to prepend towards some upstreams. However this can have other undesired
side-effects. It takes some experience to get it well.
With Netflow or our tools ASSTAT (not yet released to the public) you
can analyze your top-50 ASs you have traffic to and from. Then you take
a look at the list and most likely you'll find many ISPs you can have a
direct peering with at TIX and CIXP. For the rest you look how your
upstreams connect to them.
If you want to try the ASSTAT tool (requires a FreeBSD box as collector)
send me a private email and I can send it to you with usage instructions.
> cheers,
> Marcel
>
> P.S: Personally I'll prefer a dedicated Box like RadWare/F5
--
Andre
(Shameless plug, we provide carrier-neutral BGP consulting)
www.networx.ch
_______________________________________________
swinog mailing list
[EMAIL PROTECTED]
http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
