\documentclass[10.5pt,a4paper]{article} \usepackage[latin1]{inputenc} \usepackage{ngerman} \usepackage{graphicx} \usepackage{verbatim} \usepackage{latexsym} \usepackage{alltt} \usepackage{textcomp} \usepackage{geometry} \addtolength{\textheight}{5cm} \addtolength{\textwidth}{1cm} \addtolength{\headheight}{-2cm} \geometry{left=1.5cm,textwidth=18cm,top=1.5cm,textheight=25cm} \usepackage{vmargin} \setpapersize{A4} \setmargins{1.5cm}{1.5cm}% % linker & oberer Rand {18cm}{25cm}% % Textbreite und -hoehe {12pt}{25pt}% % Kopfzeilenhoehe und -abstand {0pt}{30pt}% % \footheight (egal) und Fusszeilenabstand \date{November 2004} \author{Marcel Noe} \title{Border Gateway Protocol v 4} \begin{document} \vspace{-5cm} \maketitle \pagenumbering{arabic} % PI und PA Adressspace \section{Motivation} Das Internet ist ein sehr komplexer Verbund aus vielen unterschiedlichen Netzen. Aufgrund dieser Komplexität und der Tatsache, dass das Internet einem ständigen Strukturwandel unterliegt, ist an eine manuelle Pflege der Routen zwischen diesen unterschiedlichen Netzen nicht mehr zu denken. Aus diesen Gegebenheiten erwächst das Bedürfnis nach einer weitestgehend automatischen Lösung zur Pflege der Routen zwischen den einzelnen Netzen. Diese Lösung muss darüber hinaus noch ein hohes Maß an Robustheit und Ausfallsicherheit mitbringen. Im allgemeinen verwendet man deshalb sogenannte dynmaische Routing-Protokolle, die automatisch die Routen zwischen einzelnen Teilnetzen aushandeln. Im Internet kommt hierfür das Border Gateway Protokoll (BGP) zum Einsatz. \section{Autonome System} Zunächst definieren wir den Begriff des Autonomen Systems. Ein Autonomes System ist ein Netzwerk bzw. eine Gruppe von Netzwerken, die eine gemeinsame Administration sowie eine gemeinsame Routing Policy (siehe unten) besitzen. Jedes Autonome System ist durch eine eindeutige Nummer -- die AS-Nummer -- gekennzeichnet, die wie die IP-Adressen von einer zentralen Stelle vergeben wird. \cite{Beijnum2002} Einige Beispiele für Autome Systeme sind z.B. das BelWue (553), KPN Eurorings (286) sowie das DTAG Netzwerk (Deutsche Telekom AG) (3320). \section{Einordnung des BGP} Routing-Protokolle kann man in zwei Bereiche einteilen:\cite{Beijnum2002} \begin{description} \item{Interne Routing-Protokolle (Interior Gateway Protocols):}\newline Diese Protokolle verbreiten Routing-Informationen innerhalb eines Autonomen Systems. \newline Beispiele: RIP, OSPF \item{Externe Routing-Protokolle (Interior Gateway Protocols):}\newline Diese Protokolle verbreiten Routing-Informationen zwischen Autonomen Systemen. \newline BGP ist momentan das einzige verwendete externe Routing-Orotokoll. \end{description} \section{Routing Algorithmus und grundlegendes Design} % http://mia.ece.uic.edu/~papers/Networking/msg00004.html Das BGP basiert auf einem sogenannten Distanzvektor Algorithmus. Bei einem Distanzvektor basierten Routing-Protokoll speichert jeder Router einen Distanz-Vektor mit Einträg zu jedem Zielrouter. Jeder dieser Einträge besteht unter anderem aus den Kosten, um das Ziel zu erreichen, sowie dem nächsten Hop zum Ziel. Falls mehrere Routen zu einem Ziel existieren, wird diejenige mit den geringsten Kosten verwendet.\cite{Uic.edu} \newline \newline % http://www.freesoft.org/CIE/Topics/88.htm Das BGP erweitert dieses Verhalten nun um einige Aspekte. Die Basisinformation im BGP ist der BGP Pfad (BGP Path), also die Route zu einem bestimmten Set von CIDR Präfixen. Diese Pfade werden mit einigen Attributen versehen, wovon die wichtigsten AS\_PATH und NEXT\_HOP sind. Der AS\_PATH ist prinzipiell eine Liste von allen autonomen Systemen, die zum Erreichen eines Ziels durchquert werden müssen. Diese Liste dient primär dazu, Schleifen zu verhindern. Ein Router ignoriert alle BGP-Pfade, in denen die eigene AS-Nummer im AS\_PATH-Attribut enthalten ist. \newline Im NEXT\_HOP-Attribut ist die IP-Adresse des Border Routers des nächstgelegenen AS gespeichert, das zum Erreichen des Ziels durchquert werden muss. Hierin liegt ein großer Unterschied zu anderen Distanzvektorbasierten Protokollen, die den nächsten Hop zu einem Ziel speichern. Der Router, der im BGP-NEXT\_HOP-Attribut steht, kann im Gegensatz hierzu jedoch durchaus einige Hops entfernt sein.\cite{Freesoft} \newline \newline Hieraus ergeben sich in erster Linie folgende beide Konsequenzen: Zum einen ist BGP für sich alleine nicht ausreichend, um ein bestimmtes Ziel zu erreichen. Hierzu sind entweder statische Routen zu den Border-Routern eines AS oder besser ein internes Routing-Protokoll erforderlich. Zum anderen müssen alle BGP-Teilnehmer innerhalb eines AS vollvermascht sein, d.h. von jedem Router zu jedem anderen Router muss eine BGP-Verbindung existieren. Dies kann sehr schnell zu einem Problem werden, weil die Anzahl der Verbindungen quadratisch mit der Anzahl der Router wächst. Diesem Effekt kann man prinzipiell entweder durch Zusammenschluss mehrerer Router zu einem Sub-AS -- einer sogenannten Konföderation -- oder durch den Einsatz von Reflektoren entgegenwirken\cite{Beijnum2002}. An dieser Stelle sei lediglich auf diese Möglichkeiten hingewiesen, eine genauere Diskussion würde den Rahmen dieses Dokumentes bei weitem sprengen. \section{Auswahl der besten Route} Aufgrund der Struktur des Internets ist es nicht unüblich, dass sehr viele Routen zu einem bestimmten Ziel führen. Man muss nun entscheiden, welche Route die beste ist, um über diese Route den Traffic zu einem Ziel zu senden. Das Standardverhalten von BGP ist, die Route zu einem Ziel, die die größte Übereinstimmung aufweisst, zu verwenden, also die mit der längsten CIDR Maske. Gibt es mehrere Routen mit der selben Präfix-Länge, wird diejenige mit dem kürzesten AS\_PATH verwendet. Leider ist die Route mit dem kürzesten AS\_PATH nicht immer auch die beste. Daher gibt es die Möglichkeit, lokale Präferenzen für bestimmte Ziele zu setzen. Hierzu verwendet man sogenannte Route-Maps, um festzulegen, welche Routen bevorzugt werden sollen\cite{Beijnum2002}\cite{Signaltonoise.net}. \section{Ablauf einer BGP Session} Im Gegensatz zu den meisten anderen Routing-Protokollen, die ihre Informationen per Broadcast über das lokale Netz verteilen, arbeitet BGP mit sogenannten Sessions. Eine Session findet immer zwischen zwei Routern statt. Die beiden an einer Session beteiligten Router nennt man BGP-Nachbarn oder BGP-Peers. BGP verwendet TCP als Transport-Protokoll, unterscheidet sich also auch hier von anderen Routing-Protokollen, die meist direkt auf der der IP-Schicht aufsetzen. Die Verbindung findet auf TCP-Port 179 statt und ist während der gesamten Session aktiv. Eine Session beginnt also mit dem Aufbau der Verbindung und gilt als etabliert sobald das erste Keep-Alive Paket gesendet wurde. Eine Session endet mit dem Abbau derselben TCP-Verbindung. Innerhalb einer Session gibt es folgende Steuernachrichten\cite{Beijnum2002}\cite{Signaltonoise.net}: % http://www.signaltonoise.net/library/bgp.html \begin{description} \item{Open:} Eine BGP-Session beginnt immer mit einer Open-Message, die sich die Nachbarn direkt nach dem Aufbau der Verbindung gegenseitig zusenden. Diese Message beinhaltet unter anderem die Protokollversion, die von dem jeweiligen Nachbarn verwendet wird, die AS-Nummer, die maximale Idle-Time einer Verbindung sowie weitere optionale Felder wie z.B. Authentifizierungsinformationen oder zusätzliche Features. Außerdem beeinhaltet die Message den sogenannten Identifier eines Nachbarn, welcher einfach eine der IP-Adressen eines Interfaces des ist. \item{Keep-Alive:} Wenn über einen gewissen Zeitraum (der mit der Open-Message festgelegt wird) keine Steuernachrichten zwischen den Nachbarn gesendet werden, geht der eine Nachbar davon aus, dass die Gegenstelle nichtmehr erreichbar ist und beendet die Session mit einem Timeout. Um dies zu verhindern werden in regelmäßigen Abständen Keep-Alive-Messages übertragen. \item{Update:} Mithilfe von Update-Messages teilen sich die Nachbarn gegenseitig ihre Routing-Tabellen mit. Hierbei wird allerdings nur direkt nach dem Aufbau der Verbindung die gesamte Routing-Tabelle übertragen. Später teilen sich die Nachbarn nur noch Änderungen mit, um den durch BGP verursachten Datenverkehr möglichst gering zu halten. \item{Notification:} Notification-Messages beenden eine BGP-Session. Sie werden entweder bei einem fatalen Fehler oder beim Terminieren einer Session generiert. In der Nachricht sind die Art des Fehlers, eine genauere Information und optional Diagnosedaten enthalten. \end{description} %BGP verwendet TCP als Transport Protokoll. Es wird Port 179 verwendet. %Nach dem Aufbau einer Verbindung senden sich beide Seiten direkt eine %\emph{Open Message}.\newline %Diese Steuernachricht enthält wichtige Informationen über %die Konfiguration und Fähigkeiten des Senders. Sie beinhaltet unter %anderem die BGP Version - in unserem Falle also immer eine 4 - die %AS-Nummer, die maximale Idle Zeit einer Verbindung bevor diese %mit einem Timeout beendet wird sowie einem Identifier. Der Identifier %ist eine der IP Adressen des Senders der Nachricht. Darüber hinaus %gibt es noch einige optionale Parameter, die z.B. für die %Authentifizierung oder erweiterte Fähigkeiten wie z.B. %Multiprotocol Routing zuständig sind. Falls die Open Message %von der Gegenstelle akzeptiert wird, antwortet diese mit %einer \emph{Keep-Alive Message} %und fängt an, die eigene Routingtabelle %zum Partner zu übertragen (in dem Rahmen, in dem es von den %Routing Policies erlaubt wird. Zu Routing Policies später mehr). Dazu %wird eine sogenannte \emph{Update Message} verwendet. Sobald dieser %Vorgang abgeschlossen ist werden lediglich noch periodische %Keep-Alive Messages sowie im Falle einer Änderung diese Mithilfe %einer Update Message übertragen. \section{Routing-Policies} % http://www.cisco.com/warp/public/cc/techno/protocol/tech/plicy_wp.htm Das Policy-Routing Konzept (auch Routing-Policies genannt) ist ein Feature von BGP, dessen Ziel es ist, den Datenfluss eines Autonomen Systems zu kontrollieren. Zur Implementierung dieses Konzeptes bietet BGP verschiedene Hilfsmittel wie Routen-Filter und Communities (s.u.).\newline Ziel von Policies ist es, das Standardverhalten des Routing-Protokolls aufzuheben, und das Verhalten an die Wünsche des Administrators anzupassen. Mit Policies versucht man vor allem folgende Ziele zu erreichen:\cite{Cisco.com} \begin{description} \item{Kosten sparen:} Dies kann erreicht werden, indem man z.B. weniger wichtigen Traffic über weniger zuverlässige, günstigere Routen und wichtigen Traffic über zuverlässigere, teure Routen lenkt. \item{Last verteilen:} Wenn mehrere Routen zu einem Ziel bestehen, die in etwa gleichwertig sind, kann man den Traffic zu diesem Ziel über diese Routen verteilen, um vorhandene Leitungen so besser auszunutzen. \item{Verteidigung gegen DoS:} Indem man die zur Verfügung stehende Bandbreite für typischen Denial-of-Service-Traffic limitiert oder versucht, den DoS-Traffic ins Leere zu lenken (siehe Communities) kann man die Folgen des Angriffs abschwächen. \item{Beschränkung des Routingtabellen-Umfangs:} Um Ressourcen des Routers zu schonen, kann es sinnvoll sein, nicht jede Route, die per BGP verbreitet wird, in die Routing-Tabelle zu übernehmen (siehe Filter). Dies war vor allem früher sehr wichtig, da vielerorts noch Router mit zu wenig Speicher, um alle per BGP verbreiteten Routen zu verwalten, im Einsatz waren. \item{Quellensensitives Routing:} Es ist möglich, Traffic von unterschiedlichen Quellen über unterschiedliche Routen zu lenken. \end{description} % http://www.riverstonenet.com/support/bgp/policies/ %- Defaultbehavior: Alle BGP Routen von allen Peers in die RIB importieren % und die beste BGP route zu allen peers exportieren. %- Wenn man eigene Policies definiert stoppt dieses Defaultverhalten und die % eigenen Policies treten in Kraft. Wenn man z.B. statische Routen % exportieren möchte, dann muß man zwei Policies anlegen, eine zum % exportieren von statischen Routen und eine für BGP Routen. %- Es gibt folgende optionen: excact, refines, between und resrict. %- Zur Policy gehört z.B. ob IGP Routen in BGP redistributed werden. %- Route Aggregation zur Verringerung der Größe der Routingtabelle \section{Filter} Filter werden verwendet, um eine Vorauswahl zu treffen, welche mittels BGP verbreiteten Routen man in die eigene Routing-Tabelle übernehmen möchte. Je größer die Routing-Tabelle eines Routers wird, desto mehr CPU-Leistung und vor allem Speicher benötigt er, um diese zu verarbeiten. Natürlich kann man einfach leistungsfähigere Hardware einsetzen, aber diese ist teuer und es ist auch nicht unbedingt sinnvoll, jedes Announcement anzunehmen. Welche Announcements man annimmt und welche nicht, hängt von der jeweiligen Routing Policy eines Autonomen-Systems ab. Prinzipiell kann man entweder nach AS-Pfaden oder nach den verbreiteten CIDR Präfixen filtern (Ein CIDR-Präfix ist einfach die Kombination aus einem Teil einer IP Adresse sowie der Angabe der Präfix-Länge --- z.B. 192.168.255.0/24, 10.1.0.0/16, 128.0.0.0/2 usw.). Gängig ist es zum einen, Routen auszufiltern, zu deren Erreichen man mehr als eine bestimmte Anzahl verschiedener AS durchqueren müsste, und zum anderen nur Announcements bis zu einer bestimmten Länge zuzulassen. \newline Es ist allerdings auch möglich, Filter auf ausgehende Announcements zu definieren. So ist es z.B. sinnvoll, nur Announcements der eigenen IP-Bereiche zu erlauben, um zu verhindern, dass Transit-Traffic von Peering-Partnern durch das eigene Netz fließt und so nutzlos Leitungen verstopft bzw. Traffickosten verursacht\cite{Beijnum2002}\cite{Riverstonenet}. \section{Schwarze Löcher} Falsche, vergessene oder unzureichende Filter können dazu führen, dass fremde Systeme Routen empfangen, zu denen sie keinen Traffic senden können. Solche Routen, die zwar verbreitet werden, aber bei denen nie Traffic ankommt, nennt man schwarze Löcher. Ein schwarzes Loch ist einer der schlimmsten Effekte, die beim Einsatz von BGP auftreten können. Das Problem ist, dass die Ursachen und vor allem die Stelle des Verschwindens des Traffics meist nur schwer lokalisiert werden können. Neben dem Ausfall eines Links können Paketfilter oder schlichtweg Fehlkonfiguration die Ursache für das Verschwinden des Traffics sein. Ein typisches Szenario ist, wenn Kunden mit mehreren Netzwerkverbindungen unzureichende Filter gesetzt haben und so versehentlich die Routen von fremden Netzwerken zu einem ihrer Provider verbreiten, und der Provider versäumt hat, Filter zu konfigurieren, die von einem Kunden lediglich Announcements über dessen eigenen IP-Bereich akzeptieren. Da ein Provider Routen über Kunden als besonders günstig konfiguriert hat, werden die Router versuchen, ausgehenden Traffic gesamt oder teilweise über den Kunden zu routen, der in aller Regel dieser Datenflut nicht gewachsen ist. Dass man fälschlicherweise Routen verbreitet, zu denen man eigentlich gar keinen Fremdtraffic transportieren möchte, entsteht durch das fälschliche Injizieren von Routen, die mittels BGP gelernt wurden, in das interne Routing Protokoll. Dies wird genau dann zum Problem, wenn man die Informationen des internen Routing-Protokolls wieder an das BGP exportiert. Dieses Setup ist zwar möglich, setzt aber sehr genaue Pflege der Filter voraus, und ist auf Grund der wenigen Vorteile, die man sich durch eine sehr hohe Fehleranfälligkeit erkauft, nicht empfehlenswert. Man muss allerdings an dieser Stelle noch anmerken, dass ein Schwarzes Loch manchmal bewußt erzeugt wird, um z.B. DoS Angriffe ins Leere zu leiten\cite{Beijnum2002}. \section{Communities} Mit Communities besteht die Möglichkeit, Routen zu markieren. Damit kann man Routern, die diese Routen empfangen, signalisieren, wie sie damit umzugehen haben. Communities sind ein sehr nützliches Werkzeug. Man kann es z.B. einsetzen, um eine Route gegenüber anderen zu bevorzugen, oder aber um DoS-Attacken ins Leere zu leiten. Communities werden oft in einer Kombination mit einer Technik, die sich Path-Prepending nennt, eingesetzt. Hierbei wird beim verbreiten an bestimmte Nachbarn die Nummer des eigenen AS öfter als einmal in das AS\_PATH-Attribut eingefügt, womit man eine gewisse Kontrolle hat, über welchen Nachbarn eingehender Traffic ankommt. Darüber hinaus kann man eine Route mit der Quelle, die sie announced hat, markieren. Anhand dieser Markierung kann man dann entscheiden, welche Route man für ausgehenden Traffic zu einem bestimmten Ziel bevorzugt. Auch dies wird dann wieder über Path-Prepending realisiert\cite{Beijnum2002}\cite{Supersparrow}. % Eigene AS: http://groups.google.de/groups?hl=de&lr=&threadm=8nriqc%241uai%241%40onizuka.vmunix.org&rnum=9&prev=/groups%3Fq%3Dbgp%2Bas%2Banzahl%26hl%3Dde%26lr%3D%26selm%3D8nriqc%25241uai%25241%2540onizuka.vmunix.org%26rnum%3D9 % AS Knappheit: http://groups.google.de/groups?hl=de&lr=&threadm=G45yrw.Ksn%40greenie.muc.de&rnum=1&prev=/groups%3Fq%3Das%2Bbgp%2Bknappheit%26hl%3Dde%26lr%3D%26selm%3DG45yrw.Ksn%2540greenie.muc.de%26rnum%3D1 % looking glas: http://www.nat.bg/look %- Provierunabhängigkeit %- Wenn man viele Systeme hat, die von aussen erreichbar sein müssen %- Traffic Engineering %- Peering \section{Verhalten beim Ausfall eines Pfades} Um das Verhalten beim Ausfall eines Pfades zu verdeutlichen, stellen wir uns folgendes Szenario vor: Provider A und B tauschen Datenpakete über einen Peering-Punkt aus. Dazu betreibt jeder der Provider einen Router (die wir zum besseren Verständnis Router A und Router B nennen), die über eine Fast-Ethernet-Verbindung verbunden sind. Zwischen beiden Routern besteht eine BGP-Session. Auf Grund eines Hardwarefehlers kommt die Betriebssoftware von Router B in einen indeterministischen Zustand, was dazu führt, dass über die Verbindung zwar keine Pakete mehr ankommen, das Interface allerdings nicht heruntergefahren wird und so Router A nicht sofort merkt, dass Router B nicht mehr verfügbar ist. Da Router A nun keine Keep-Alive-Pakete mehr von Router B bekommt, beendet er die BGP-Session nach dem in der Open-Message vereinbarten Timeout. So lange der Timeout allerdings nicht erreicht ist, versucht er weiterhin über diese Verbindung Pakete zu senden, die allerdings ihr Ziel niemals erreichen. Sobald die BGP-Session beendet ist, entfernt Router A die Route über Router B und sucht sich die nächstbeste Route. Diese übernimmt er in seine Routingtabelle. Danach sendet er eine Update-Nachricht an seine anderen BGP-Nachbarn, in der er diese über die geänderte Route informiert. Diese verbreiten diese Information ihrerseits an ihre Nachbarn weiter, was dazu führt, dass sich die neuen Routing-Informationen schneeballartig verbreiten. Alle Router fangen nach dem empfangen der Update Meldung an, ihre Routing Tabellen neu zu berechnen. Da der Weg über Provider A zu Provider B nun evtl. länger ist als der über andere Routen, kann es passieren, dass die Router ganz andere Wege wählen\cite{Beijnum2002}\cite{Supersparrow}. \section{Schwachstellen von BGP} % http://www.supersparrow.org/ss-0.0.0/reference/avi/bgp.html Beim Einsatz von BGP hat man primär mit zwei Problemen zu kämpfen. Das eine Problem ist die Anzahl der Routen, die über BGP verbreitet werden. Jeder Eintrag in der Routingtabelle belegt Systemressourcen. Von daher kann es sinnvoll sein, die Anzahl der Routen durch Filter einzuschränken. Ein viel größeres Problem von BGP ist allerdings die Tatsache, dass jede Änderung einer Route das ganze Internet betrifft. Eine Update-Message verbreitet sich immer über alle BGP sprechenden Router, die darauf hin ihre Routing-Tabelle neu berechnen müssen. Dies macht BGP sehr gefährlich. Eine kleine Unachtsamkeit in der Konfiguration kann globale Ausmaße annehmen und schlimmsten Falls dazu führen, dass große Teile des Internets sich gegenseitig nicht mehr erreichen können. Diese Effekte kann man zwar durch Filter und andere Sicherheitsmaßnahmen wie Damping reduzieren, aber nie ganz verhindern. BGP ist sozusagen der Single Point of Failure des gesamten Internets.\cite{Beijnum2002}\cite{Supersparrow} %- Dampening und Flapping %- Leitungsverstopfung %- Zunahme von Leuten, die keine Ahnung haben aber weltweit Router stressen %- Skalierbarkeit ab einer Obergrenze nichtmehr gegeben %- Viele sehr seltsame Announcements %- Diskrepanz zwischen Management und Technik %- Viele Leute bringen es nicht fertig, Adressspace zu aggregieren % LIR? % Local Pref? Böse? % Beeinflussung durch dritte: http://groups.google.de/groups?hl=de&lr=&threadm=kn18stc5dqt75vg79nnfc30bu0s388tah1%404ax.com&rnum=10&prev=/groups%3Fq%3Dbgp%2Bas%2Banzahl%26hl%3Dde%26lr%3D%26selm%3Dkn18stc5dqt75vg79nnfc30bu0s388tah1%25404ax.com%26rnum%3D10 %http://www.apnic.net/mailing-lists/bgp-stats/archive/2001/05/msg00024.html %Until 2001, the global routing table was growing exponentially, threatening an eventual widespread breakdown of connectivity. In an attempt to prevent this from happening, there is now a cooperative effort by ISPs to keep the global routing table as small as possible, by using CIDR and route aggregation. This has slowed the growth of the routing table to a linear process, greatly extending the time available before older routers need to be replaced. \begin{thebibliography}{99} \bibitem{Beijnum2002} Iljitsch van Beijnum \emph{The Border Gateway Protocol} \verb| O'Reilly Verlag - ISBN: 0-596-00254-8| \bibitem{RFC1771} \emph{RFC 1771: A Border Gateway Protocol 4 (BGP-4)} \verb| ftp://ftp.rfc-editor.org/in-notes/rfc1771.txt| \bibitem{WikipediA} \emph{WikipediA: Border Gateway Protocol} \verb| http://en.wikipedia.org/wiki/Bgp| \bibitem{Riverstonenet} \emph{Riverstonenet: Routing Policies} \verb| http://www.riverstonenet.com/support/bgp/policies/| \bibitem{Uic.edu} \emph{Brief explanation of Routing algorithms} \verb| http://mia.ece.uic.edu/~papers/Networking/msg00004.html| \bibitem{Freesoft} \emph{Freesort: BGP-4 Protocol Overview} \verb| http://www.freesoft.org/CIE/Topics/88.htm| \bibitem{Signaltonoise.net} \emph{Signaltonoise: Border Gateway Protocol (BGP)} \verb| http://www.signaltonoise.net/library/bgp.html| \bibitem{Cisco.com} \emph{Cisco: Policy based Routing} \verb| http://www.cisco.com/warp/public/cc/techno/protocol/tech/plicy_wp.htm| \bibitem{Supersparrow} \emph{BGP ROUTING PART I} \verb| http://www.supersparrow.org/ss-0.0.0/reference/avi/bgp.html| \end{thebibliography} \end{document}