Archives for category: routing

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 »

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:
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 »

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 »

“Penny wise, pound foolish”, you might say about the proposal to use internal GRE tunnel to forward traffic between global router (GRT) and a virtual one within the same physical device. Well, it works well to a certain extent – performance is being halved but money for interface ports well saved.

We want to achieve the following:

  • traffic between servers A and servers B will use the green direct path between AS A and AS B
  • no other traffic must follow this green path
  • servers A and servers B will communicate via dashed backup path via internet in case the green path fails
  • servers A communicate with all other clients via blue paths and internet
  • servers A can only use router A for the gateway
  • no additional physical interfaces on router A can be used

Read the rest of this entry »

It is very common to isolate some special services into virtual private networks of some kind and provide only limited connectivity to these services from the outer world. Can this be done on a single box? Not without tricks 😉 .

Let’s face the following scenario. Autonomous systems A (blue on the right) and B (green on the left) decide to share services via a dedicated high-speed/low-latency/super-duper link (see green link on the picture below). They form a “servers VPN” which guarantees superb connectivity between servers A and B. But, what if the big green link fails? Read the rest of this entry »

A clean and powerful design of a routing policy in Juniper JUNOS rewards many network engineers, tired of looking into Cisco IOS route-maps, for crossing the line and juniperizeing themselves.

Routing tables (Routing information base – RIB) are like a heart in the router. These tables are pumping routes from one network neighbour to another and building up the forwarding table (Forwarding information base – FIB) which actually conducts the flow of the data packets. The interaction with network neighbours is controlled by policy. Routes are imported from some neighbour via some routing protocol and through some policy into a corresponding routing table. From there they can be exported via another policy to another protocol and to the outside world. Feeding the forwarding table is also controlled by an export policy.

It is easy to remember (while keeping in mind that routing table is the one in the centre): import to a routing table, export from a routing table, import to, export from, import to, export from …
Read the rest of this entry »