Archives for category: bgp

Yes, it can be done by BGP. What was the question anyway?

Path hiding on a route server running BGP can happen if the route server has been configured to filter the chosen best path from reaching a particular route server client. Read the rest of this entry »

Advertisements

Internet runs on BGP. Securing the BGP is the foundation for Internet routing security.

But it is not only the protocol we must take care of. BGP as an application is also vulnerable to various threats, like route manipulation and route hijacking. BGP will originate IP prefixes as it is being told to do. It is up to network administrators to mitigate the risk of BGP misusage or exploit attempts. Internet was ment to be a place for well-behaved, but, being enormous as it is today it can not be based on trust anymore. Internet resources, like autonomous system numbers (ASNs) and IP prefixes, must be given a validatable proof of holdership. This kind of proof can be given by Resource Certification systems. The resource certificates offers the basics for a secure Internet routing, particularly BGP route origin validation.
Read the rest of this entry »

Granular, efficient and distributed firewalling based on good old BGP.

BGP can carry many different network-related information, sometimes described as address families or NLRI (Network Layer Reachability Information). One of them is FlowSpec (RFC 5575), which allows BGP to propagate a filter for a specific IPv4 packet flow. A flow, which is defined by an n-tuple, like a combination of source and destination IP address, protocol number and ports, can be discarded, rate-limited, redirected to some analysis or mitigation device etc. BGP is simply used to signal the routers to perform appropriate filtering actions for a certain flow. Read the rest of this entry »

Rarely used feature, but it might come in handy.

In the following scenario a service provider AS 1 has a customer which is using a private AS 65000 within his network. The customer has just received their own AS number and they are planning to migrate from the private one. Theirs intention is to introduce the new AS gradually and keep the old peerings with the private AS up and running during the migration.
What a customer needs is a feature that will allow a router to replace their own AS number with another one in the eBGP updates.
Read the rest of this entry »

The default route is the path toward all those networks which have no other matching routes defined. What a boring definition :-(. Let me try again: “The default route will take you to the unexplored areas of the divine Internet!”, or: “Follow the default route to eternity!”. Back to earth, ::/0 represents everything out there (except for the historic IPv4 stuff). Where does the route for ::/0 come from?

I was discussing a few options for generation of the default route in BGP, but did not pay much attention to the origin of the default route. How is this route created and put into the routing table? Read the rest of this entry »

Let’s play with BGP for a while. Remember, BGP is all about policy ;-).

Here, customer (AS 300) uses AS 1 for his primary upstream and he has another upstream provider for redundancy. In this simple scenario both providers announce a default route for the customer:
multihop_ebgp
Read the rest of this entry »

There are so many posts and other learning material about BGP out there! One of my favorites is the bucktowntiger‘s You Down With BGP? rap.

Admit it, being more innovative when discussing this technology is somehow mission impossible. My intension is not to challenge that, I’m only trying to add a few hints from my operational experience, which I hope you will find useful :-). In the next few posts I will discuss these topics:

  • multihop eBGP
  • BGP support for a dual AS configuration (useful in network AS migrations)
  • responsible generation of the default route for a downstream AS

Read the rest of this entry »

I should use the word “coexistence” instead “versus” in my short talk about BGP versus OSPF. Let us move on with a slightly more technical discussion about the collaboration and coexistence of the two protocols. I will discuss solid grounds first.

In order to be able to “route”, a router must know the next hop for a certain destination. And the next hop must be reachable! It is very important not to forget this basic rules when combining more routing protocols which interact with each other. Let’s have a look into a very basic network topology with an underlying OSPF and iBGP on top of it. Read the rest of this entry »

I’ve found one of the best answers to the question “What is BGP for?” in one of Philip Smith’s presentations (google for “BGP Best Current Practices”): “What is an IGP not for?”

Internal Routing Protocols (IGPs), like IS-IS and OSPF, are used to maintain infrastructure connectivity. They carry infrastructure addresses and are designed for rapid convergence within reasonably sized and manageable routing domains. On the other hand, BGP is designed primarily as a routing policy tool. External BGP carries Internet prefixes and exchanges them between autonomous systems according to some policy and rules of good behaviour. BGP is also used internally to carry customer prefixes and adds full flexibility to the routing decisions. BGP can handle huge routing tables, but in a somehow stable environment. It is designed to scale with expanding networks but not to respond quickly to topology changes. Read the rest of this entry »

Next-hop self for in a eBGP session? Yes – definitely at Internet Exchanges.

Except for a small red notice by Jarek Rek from Hacking Cisco (CCIE R&S Practice Journal) and a great post by Petr Lapukhov Understanding third-party next-hop, some case studies etc – most of the world-wide-web-spread copy/paste-ready tutorials keep on teaching you that BGP next-hop in external BGP session is always set to the IP address of the neighbor that announces the route. Well, not always … Read the rest of this entry »