OSPF is a protocol that is very well designed and is scalable to a very high degree. However, even though it does use areas very effectively to scale well, and it can use multiple processes, it is still not suitable for use on the Internet at large. Why? Well, for several reasons.
OSPF, like all IGPs, uses entries in the routing table that indicate the destination network and the next-hop IP. If it is designed well, this is fine if you have several thousand, or even tens of thousands of destination networks, and even thousands of OSPF routers. However, when you get to larger scales (hundreds of millions of destination networks, and millions of routers), the sizes of the routing tables and the processing power needed for routing decisions will quickly overwhelm the memory and CPU of any router, no matter how powerful.
For larger networks, a different type of routing process and algorithm is necessary, so that the routers involved will not be overwhelmed. Thatās where BGP comes in. BGP is a path-vector routing protocol. Instead of using next-hop addresses to get to where you want to go, it uses a hierarchical routing method. The whole internet is separated into Autonomous Systems (ASes), which are essentially groups of thousands of routers. BGP will maintain path information from AS to AS rather than from router to router, giving this hierarchical structure to routing that makes routing more efficient.
BGP is considered slow when we compare it to IGPs such as OSPF or EIGRP. IGPs must be fast, converging in well under a second, and often within a few milliseconds, whereas BGP may take several minutes. But this is not necessarily a bad thing, it is made this way by design.
BGP is made to exchange routes between ASes that may contain dozens or even hundreds of BGP routers each. At this scale, a āfastā convergence of under a second could prove disastrous, resulting in flapping routes everywhere.
Based on much research and testing, engineers have determined the best default timers for BGP to consider a route down, taking into account the scale of the networks that BGP provides routing for. These can of course be adjusted with various features such as next hop tracking, BGP PIC, and BGP additional paths, all of which can modify the default convergence behavior and speed to accommodate various needs, but in general, BGP must be comparatively slow.
Hello Everyone, in the BPG section with multihoming 3.3 If my single router is advertising my network to 2 different ISP/AS via redundant links and they are both configured to send me their entire routing tables. Wouldnāt I then receive a route back to my network from both ISPās once they shared a route to my network between themselves via eBGP? In essence, a loop? Thanks everyone. This site is awesome.
Thatās a very good observation. Indeed, such a situation would result in having ISP1 readvertise the network that your AS originally advertised to ISP2. However, BGP has loop prevention mechanisms to deal with such situations. Specifically, for this particular case, it uses the AS_PATH attribute.
Specifically, an eBGP router will not accept any BGP update to any destination that includes its own AS number in the AS_PATH. If that is the case, a loop can potentially take place, as you correctly observed. This of course can be overridden and there are some cases where you must do this to make sure BGP works correctly, but this should be done with caution. Some examples of such cases and the ways to change this behavior are described in the following lessons:
Hmm, Iām not sure exactly what you mean. When you say IN or OUT, do you mean iBGP and eBGP? Or do you mean how to manipulate BGP updates on an incoming and outgoing basis? Can you clarify what you mean so that we can help you out further.
I think on bgp manipulation .In some cases i see even people here on the forum asking why is some specific direction. I found a short video on youtube but i think you guys will have more simpler expiation for everything. Bellow link so you can have a batter view of what i am asking for.
Ah, OK I see what you mean. When we talk about applying changes to the BGP attributes in an inbound or outbound direction, we are not talking about user traffic. We are talking about manipulating the BGP attributes of the updates in the direction they are sent. So when a BGP update is sent from R1 to R2, and we change an attribute of the update as it exits R1, we are applying the change to that attribute as the update exits the interface of R1. R2 receives this update with the modified attribute and acts accordingly.
Hi Rene, thanks for this other lesson. I tried accessing the Looking Glass servers in the US but could not find how to do it. When I click on the links provided, nothing happens. How do I proceed to telnet into these servers? Are there IP addresses I can use to telnet into the servers? If yes, how can I find them? Can I use putty or Xshell to telnet into the servers?
Thank you
Hmm, thatās strange. Iām able to see the looking-glass site from both Europe, where I am, but also from a US IP addressā¦ Iām not sure why youāre not able to see it. When you click on the link you say nothing happens, but what error message is displayed? Try clicking on this link (itās the same one as the lesson) and let us know what you see:
To help you quickly get access, hereās what you see when you scroll down all the way to āCategory 2 ā IPv4 and IPv6 BGP Route Servers by region (TELNET access)ā
Here is a quick and dirty copy and paste of the Telnet links for those particular BGP route serversā¦
Region BGP Route Server (TELNET access) ISP / IXP website
Australia SingTel/Optus Route Server optus.net.au
$ telnet route-views.optus.net.au
Canada Group Telecom / Bell Canada Eastern Route Server gt.ca
$ telnet route-server-east.gt.ca
Canada Group Telecom / Bell Canada Western Route Server gt.ca
$ telnet route-server-west.gt.ca
Canada Telus Eastern Route Server telus.com
$ telnet route-views.on.bb.telus.com
Canada Telus Western Route Server telus.com
$ telnet route-views.ab.bb.telus.com
Canada Videotron Route Server videotron.net
$ telnet route-server.videotron.net
Switzerland Sunrise/TDC Route Server sunrise.ch
$ telnet routeserver.sunrise.ch
Germany BelWĆ¼ Route Server belwue.de
$ telnet route-server.belwue.de
Germany QSC/Broadnet Route Server qsc.de
$ telnet route-views.bmcag.net
Germany Tinet International Route Server tinet.net
$ telnet route-server.tinet.net
Europe Global Crossing European Route Server gblx.net
$ telnet route-server.eu.gblx.net
Finland EUnet Finland Route Server eunet.fi
$ telnet route-server.as6667.net
France OpenTransit/France Telecom Route Server opentransit.net
$ telnet route-server.opentransit.net
Italy Playnet Route Server playnet.it
$ telnet route-server.playnet.it
Luxembourg root S.A. Route Server root.lu
$ telnet rs.as5577.net
Netherlands SixXS IPv6 GRH Route Server sixxs.net
$ telnet grh.sixxs.net
Romania Evolva Telecom Route Server evolva.ro
$ telnet route-server.ipilink.net
United Kingdom COLT Telecom Route Server colt.net
$ telnet route-server.colt.net
United States AT&T IP Services Route Server att.com
$ telnet route-server.ip.att.net
United States AT&T/CerfNet Route Server cerf.net
$ telnet route-server.cerf.net
United States Global Crossing Route Server gblx.net
$ telnet route-server.gblx.net
United States Host.net/BroadbandONE Route Server host.net
$ telnet route-server.host.net
United States Hurricane Electric Route Server he.net
$ telnet route-server.he.net
United States Oregon Exchange Route Server oregon-ix.net
$ telnet route-views.oregon-ix.net
United States SAVVIS Route Server savvis.net
$ telnet route-server.savvis.net
United States Time Warner Telecom Route Server twtelecom.net
$ telnet route-server.twtelecom.net
South Africa IS South Africa Route Server is.co.za
$ telnet public-route-server.is.co.za
South Africa South African IX Route Server saix.net
$ telnet tpr-route-server.saix.net
In the meantime, please let us know what kind of error you see when the link fails so that we can attempt to resolve the issue for you and for all of our users.
Hi Team,
I am trying to understand BGP and IGP by thinking of some real life scenarios.
I have not come across any configuration of IGP such as OSPF/EIGRP or BGP while configurating corporate network so itās a bit difficult for me to get the image.
Could you give me some examples of how we use IGP and BGP in real life?
Thank you for your clear explanation. My understanding that eBGP giving us visibility on the entire Internet networks and we can send traffic to both ISP links by changing the attributes instead of ECMP 50/50 + the benefits of seeing AS paths.
In the scenario of SD-WAN, we can do load balancing based on weight, volume, bandwidth, latencyā¦etc and share 80/20 for example + proute for specific destinations going out the link you choose. What would be the benefits of using eBGP in this scenario? Letās assume it is dual homed design.
Please correct me if my understanding is not clear.
BGP is definitely able to deliver much more flexible routing capabilities compared to the ECMP that other routing protocols deliver. However, this is not due to the fact that it has visibility of the full Internet routing table. It is actually because of the fact that the BGP attributes used for routing are very granular in nature, and are highly configurable. It is these attributes that make BGP so flexible.
Here you are comparing SD-WAN to BGP. These are two distinct technologies that deliver different functionality, but can both be used to help load balance traffic across multiple paths.
SD-WAN is typically used to interconnect multiple remote sites using multiple WAN links. The load balancing here is achieved using an overlay network that is running on top of an underlay network, and it is the various components of the SD-WAN infrastructure that deliver this load balancing. But load balancing is only a very small part of what SD-WAN is designed to deliver.
BGP on the other hand can be used not only for interconnectivity of remote sites, but for internet routing in general, as well as on the edge of your network, when connected to multiple ISPs. How this can be achieved is detailed further in the following lesson:
SD-WAN and BGP are too different to compare directly. They can both load balance, however, this is done in such different scenarios that they cannot be directly compared.
Flowspec (Flow Specification) is a feature that provides a way to perform traffic filtering and rate-limiting based on specific flow characteristics, such as source and destination IP addresses, IP protocol, source and destination ports, and more. It is defined in the IETF standard RFC 5575 and extended by RFC 7674.
Flowspec allows network operators to distribute traffic filtering and rate-limiting rules across their network using BGP, which can help mitigate the impact of DDoS attacks and other unwanted traffic patterns.
When Flowspec is enabled, the router receives specially-formatted BGP Network Layer Reachability Information (NLRI) messages containing the flow characteristics and the desired actions to apply to the matching traffic. The router then uses this information to dynamically create and apply traffic filtering and rate-limiting policies.
To configure Flowspec on a Cisco IOS router, you need to enable BGP, configure a BGP session with a neighbor, and configure BGP policy templates with the desired traffic filtering and rate-limiting actions. Additionally, you may need to enable Flowspec client functionality and configure the router to accept and install Flowspec routes.
For a more detailed description of how to configure this Cisco documentation:
