Survey about maintenance operations
Dear All, In the framework of research projects, we are working on techniques to reduce the impact of planned maintenance operations on the routing protocols and the packet forwarding (see e.g. discussions on ordered IGP convergence in RTGWG at IETF). Several studies of ISIS or OSPF data have shown that maintenance operations are very frequent in large ISP networks. We would like quantify the number of maintenance operations that occur in large networks and would appreciate if you could answer the following survey (please reply directly to me, I'll summarize to the list) : Network size : - approx # routers - approx # links - approx # eBGP sessions Maintenance operations : - How often do you need to completely reboot each of your routers ? [ once per day, once per week, once per month, never,...] - How often do you change the IGP metric of each of your links ? [ once per hour, once per day, once per week, once per month, never, ...] - How often do you manually shutdown each of your intradomain links ? [ once per hour, once per day, once per week, never, ...] - How often do you need to stop and restart each of your eBGP sessions ? [ once per hour, once per day, once per week, never ...] - Do you use special operational procedures to perform those maintenance operations to reduce their impact on routing and packet forwarding ? [ please provide comments if any ] Thanks for your help. Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Modelling a large ISP network with C-BGP
Dear All, C-BGP is an efficient and open-source simulation tool that allows to simulate the behavior of the intra- and interdomain routing protocols in large ISP networks. C-BGP is able to simulate networks with thousands of routers. A key feature ofco C-BGP compared to other simulators is that it is able to support the complex routing policies that are used by ISPs. Thanks to the support of France Telecom R&D, we have been able to use C-BGP to reproduce the behavior of BGP in a large Tier-1 ISP network. For this analysis, we have developped several tools to automatically convert the BGP configurations of Juniper (JUNOS) and Cisco (IOS) routers, the IGP topology and the BGP routes in the C-BGP format. With these tools, any network operator can easily build a C-BGP model of his/her network. With such a model, it is possible to perform different types of analysis on the ISP network, such as : - predicting the flow of the traffic through the network or determining the traffic matrix based on Netflow data (see article in January issue of ACM SIGCOMM Computer Communication Review) - predicting the impact of adding a new peering link on the BGP routes selected by the routers (see article in Nov/Dec issue of IEEE Network Magazine) - predicting the impact of link or router failures on the ISP network You can obtain C-BGP, the conversion tools and several papers describing the utilization of C-BGP to model an ISP network or compute traffic matrices from : http://cbgp.info.ucl.ac.be The website also contains several examples, such as a complete C-BGP model of the Abilene Network based on their publically available JUNOS configurations files. We believe that C-BGP could be very useful for ISPs willing to optimise the distribution and the selection of the BGP routes in their network. Comments, suggestions and questions from network operators are more than welcome. Best regards, Bruno Quoitin, Sebastien Tandel and Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Re: Load balance over multiple bgp feeds
Mike, I was wondering what everyone does to load balance over multiple bgp feeds. We currently have 5 bgp feeds with 2 providers. Do you just randomly pick networks, or use something like netflow to try and pick the best path. You might be interested by the following papers : S. Uhlig and O. Bonaventure. Designing BGP-based outbound traffic engineering techniques for stub ASes. ACM SIGCOMM Computer Communication Review, 34(5), 2004. S. Uhlig, O. Bonaventure, and B. Quoitin. Interdomain traffic engineering with minimal BGP configurations. In 18th International Teletraffic Congress (ITC), September 2003. http://totem.info.ucl.ac.be/publications.html Best regards, Olivier
Re: (newbie) BGP For Dummies?
On Fri, 2004-12-10 at 21:35, David E. Smith wrote: > "Hi, long-time listener, first-time caller..." > > Can anyone recommend a good forum for BGP questions? I've got my copy of the > O'Reilly book handy, but having never really worked with BGP before, I find > it's not really the best novice-level work. Within the E-Next network of excellence, we organised two weeks ago a two-days tutorial on BGP. This tutorial assumes that the attendees have a basic understanding of IP routing works but no prior knowledge of BGP is assumed. The tutorial has a theoretical part covering the behaviour of the BGP protocol and a practical part with the C-BGP simulator (http://cbgp.info.ucl.ac.be) whose syntax is close to Cisco routers. Upon request from some attendees of the tutorial who intend to deliver BGP courses within their universities, we have released all the training material under a creative commons licence, see : http://totem.info.ucl.ac.be/bgp.html Suggestions and comments on improvements to this training material are welcome Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
CFP : Special issue on interdomain routing in IEEE Network Magazine
Dear colleagues, A short note to inform you that the November/December 2005 issue of IEEE Network Magazine will be devoted to interdomain routing. The submission deadline is March 15, 2005 and you can find the full call for papers here : http://www.comsoc.org/pubs/net/ntwrk/special.html Best regards, Olivier Bonaventure, Anja Feldman, Lixin Gao, Tim G. Griffin and Z. Morley Mao
Re: BGP Load Sharing
Chris, > I am hoping to learn from the great pool of experience on this list. > > We currently have 2 OC3 connections going to 2 seperate providers. We > are using netflow statistics to balance our traffic flows (which > outgoing is our major concern). Flow tools, snmp output, some custom > scripts, and some bgp weighting does the trick. For his Ph.D. thesis, Steve Uhlig developped and evaluated by simulations several techniques to solve this problem. You can find details about those techniques in his thesis : http://www.info.ucl.ac.be/~suh/thesis.ps.gz A description of these techniques is expected to appear soon in ACM Computer Communication Review. The techniques were evaluated by using simulations performed with perl scripts on Netflow traces. The perl scripts are also available from Steve's website : http://www.info.ucl.ac.be/~suh In parallel to this work, we are developping an open source traffic engineering toolbox ( http://totem.info.ucl.ac.be ). If there is interest from network operators, we could place some of the scripts developped by Steve in the toolbox. Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Re: Open Source BGP Route Optimization?
Sam, > > You can get the received routes via SNMP. I've done this manually on > > occasion for the purposes of doing "what-if" analysis of potential > > traffic plans - take a dump of all available external routes via SNMP, > > apply to that the proposed policy with regard to selecting the best > > route, then correlate the resulting route choices with known traffic > > statistics to determine the resulting utilisation levels of each > > external link. This has proven useful in a number of situations where > > radical changes to external routing were being made, to avoid > > unexpectedly overloading particular links. > > I would had liked to had been able to have done such things in the past. I > was thinking about having a go at writing something, but it's not like I > have enough time as it is, and our network isn't really big enough to > warrant it. > > Though I am interested in what tools already exist to support this (more out > of curiousity than need). C-BGP (http://cbgp.info.ucl.ac.be) developped by Bruno Quoitin, can be used to perform this kind of analysis. It can import the BGP routes in MRTD format, but other formats can be easily converted to the MRTD format. C-BGP allows you to build a model of your network that considers both the IGP, the iBGP and eBGP sessions as well as the BGP routing policies that you use. Each C-BGP router is configured by using a Cisco-like syntax that should be familiar to most network engineers. One the model has been written, you can use it to perform different types of what-if analysis such as : - impact of IGP weight change - impact of the loss of one eBGP session - impact of the addition of a new peer/provider If there are other types of analysis that you would like to be able to perform in your network, let us know... Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Re: Open Source BGP Route Optimization?
Noel, > > Does anybody happen to know of any open source project working on a BGP > route optimizer like what Route Science or Internap or the likes have > commercially? The TOTEM project (see http://totem.info.ucl.ac.be/ ) is building a set of open source traffic engineering tools. Our focus is currently on tools that can allow ISPs to engineer/capacity plan their network by : - tuning BGP configuration - tuning IGP weights - establishing intra- and inter-domain MPLS tunnels The TOTEM toolbox will evolve over a three years period and the first version will be available this fall from the project web site. Concerning BGP, the project has already developped a tool called C-BGP (http://cbgp.info.ucl.ac.be) that can be used to simulate the behavior of BGP in large networks. C-BGP supports a configuration language similar to current routers and we have used it to simulated networks with 10.000 routers. We are currently using CBGP to perform what-if analysis to evaluate the impact of link, router and peering failures in transit networks. We are interested in discussing with ISPs who would like to use/test such an opensource traffic engineering toolbox on ther network. Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Re: Outbound Route Optimization
Hello, > I am trying to determine for myself the relevance of Intelligent > Routing Devices like Sockeye, Route Science etc. I am not trying to > determine who does it better, but rather if the concept of optimizing > routes is addressing a significant problem in terms of improved > traffic performance ( not in cost savings of disparate transit pipes ) > An alternative to using such devices would be to tune the BGP configuration of the routers. See below for a description of an algorithm that allows to determine the optimum configuration of BGP routers for some traffic objectives [UBQ03] S. Uhlig, O. Bonaventure, and B. Quoitin. Interdomain traffic engineering with minimal BGP configurations. In 18th International Teletraffic Congress (ITC), September 2003. http://totem.info.ucl.ac.be/publications.html This work is being pursued in the framework of a governement-funded three-years research project, where we are developping an open-source traffic engineering toolbox. This objective of this toolbox is to provide a set of tools that can be used by ISPs and entreprise networks to optimize their intradomain and interdomain traffic flow. The first release of the toolbox is planned for november 2004. To help us fit this toolbox to the needs of ISP and enterprise networks, we would appreciate if you could fill our survey at : http://totem.info.ucl.ac.be/te_form.html Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
A web interface to check the consistency of RPSL policies
Dear All, In the framework of a research project on interdomain traffic engineering, Vincent Magnin, has developped a tool and a web interface that could be useful for network operators. The tool relies on the RPSL databases from the main 19 IRR and builds a map of the global Internet based on this information. Furthermore, by using a few heuristics the tool is able to infer the type of relationship (customer->provider, provider->customer, peer-to-peer, ...) between two autonomous systems. This heuristic works well when both AS register accurately their routing policies. Unfortunately, not all ASes correctly maintain their RPSL policy. In those cases, the heuristic will either perform an educated guess or indicate a potential problem found in the RPSL specification. The web interface of the tool allows to easily browse through the 19 RPSL databases and we believe that it could be useful for ISPs willing to check the consistency of their RPSL policy compared to the policy of their neighbors. You can access the web interface of the tool at the URL below : http://rpsl.info.ucl.ac.be Your feedback, to [EMAIL PROTECTED] is welcome as we intend to later release the tool in open source if it appears to be useful for operators. Best regards, Vincent Magnin, Steve Uhlig and Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Pricing model for transit services
Hello, We are working on a research project on interdomain traffic engineering and would like to quantitatively evaluate interdomain traffic engineering solutions in a realistic way. We have a BGP simulator that allows us to simulate networks with a few hundreds of AS and are adding several mechanisms to this simulator. To complement the simulator, we are looking for realistic cost models of transit services. Since we do not buy transit services, we have some difficulties finding this information. For the moment, our cost models are the following : - flat fee for a L Mbps link - volume based, y $ per Mbps (95% quantile) for a L Mbps link - burstable, flat fee for x Mbps on a L Mbps and z $ per Mbps above x We would like to know whether these three cost models accurately reflect the current pricing schemes of transit services and what are the most popular ones ? If you know other pricing schemes that should be taken into account, we would appreciate to have additional information. I heard of destination-based pricing schemes, but do not have enough details on them and don't know whether they are frequently used. You can either answer directly to us ([EMAIL PROTECTED] and [EMAIL PROTECTED]) and we will summarize or directly to the list. Thanks a lot for your help, Olivier Bonaventure --- http://www.infonet.fundp.ac.be
Re: selective prepends (RE: Cogent service)
"E.B. Dreger" wrote: > > > Date: Sun, 22 Sep 2002 23:16:20 -0400 (EDT) > > From: jlewis > > > Speaking of special...having played around a little with the > > BGP communities supported by C&W and Sprint, I'm wondering > > which other big transit providers (it seems almost a waste to > > say Tier 1 anymore) support community strings that will let you > > (the customer) cause them to selectively prepend route > > announcements to their peers. > > 1239, 3356, 3549, 3561 > > Other than that, I don't know of any positives. I was going to > compile a list and make a webpage... but I've had underwhelming > response to past posts on the subject. There is an ongoing effort with IETF to define a special type of extended communities to support this type of interdomain traffic engineering in a standardize manner within the ptomaine working group. See http://www.ietf.org/html.charters/ptomaine-charter.html Those redistribution communities have been implemented in zebra http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-03.html There is also a detailed survey of the utilization of communities that might be of interest http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html Best regards, Olivier Bonaventure
Re: BGP Tutorial update...
Hank, > > If you want a nice example of well documented community values via whois > try Level-3: > > whois -h whois.radb.net as3356 > > Everyone should take an example from them. I agree that Level3's traffic engineering communities are well documented. However, operators willing to utilize the community values in the private AS space (e.g. 64990:, 64991:xx below) should think twice before deploying configurations to support those community values on their routers. A first issue is that the status of those values is unclear within IETF and IANA and anyone can define its own semantic. Second, since the community attribute is transitive, you might receive routes from any peer containing such community values and apply an invalid filter to those routes. This leakage of community values is not uncommon in practice based on our analysis of the BGP routing tables (see http://alpha.infonet.fundp.ac.be/anabgp and http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html ) To take a simple example, assume that you implement the same community values as Level3, e.g. : remarks: 64990:0 - announce to customers but not to NA peers remarks: 64990:XXX - do not announce on NA peerings to AS XXX remarks: 64991:XXX - prepend once on NA peerings to AS XXX remarks: 64992:XXX - prepend twice on NA peerings to AS XXX remarks: 64993:XXX - prepend 3x on NA peerings to AS XXX remarks: 64994:XXX - prepend 4x on NA peerings to AS XXX remarks: Then, you might well receive the following routes from your upstream peer : route-views.oregon-ix.net>sh ip bgp community 64994:12076 BGP table version is 4638455, local router ID is 198.32.162.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 81.64.0.0/14 209.244.2.1150 0 3356 9057 6678 i * 195.132.0.0/16 209.244.2.1150 0 3356 9057 6678 i * 212.198.0.0/16 209.244.2.1150 0 3356 9057 6678 i Using such community values for traffic engineering purposes could quickly become a headache unless every one filters the community values that it annouces to peers, but few operators have implemented such filtering. A safer solution from an operational point of view would be to use for this purpose non-transitive extended communities with a well-known semantics that could be easily directed supported by router vendors. See Bruno Quoitin's presentation at NANOG25 or http://www.infonet.fundp.ac.be/doc/reports/draft-ietf-ptomaine-bgp-redistribution-00.txt Olivier -- http://www.infonet.fundp.ac.be
Re: BGP community settings in the real world
Adam, > > To what extent does setting communities on BGP routes work in the real > world? > > I can't help suspecting that in reality, routes would get aggregated, > or communities would be dropped or replaced, somewhere between source > and destination. In order to prepare an IETF draft on the utilization of extended communities to control the redistribution of routes (see http://www.infonet.fundp.ac.be/doc/reports/draft-bonaventure-bgp-redistribution-02.txt) we did a study of the utilization of the community attribute for traffic engineering purposes. This study was based on two sources of information : - the RIPE whois database for the advertised communities - the BGP routing tables collected by RIPE and routeviews This analysis shows that BGP communities are becoming frequently used for traffic engineering purposes. A summary of our findings is available as http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html and you can find the analysed data on the web as well, see http://alpha.infonet.fundp.ac.be/anabgp/ Our intention is submit this analysis as an informational RFC one day to document the common utilizations of the community attribute in today's Internet. Comments on the above mentionned report are welcome. Best regards, Olivier Bonaventure --- http://www.infonet.fundp.ac.be
