Archives for the month of: January, 2013

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 »

A very simple question with a tricky answer ;-). How many OSPF areas are in this network?

For OSPF, areas are contiguous segments of networks and routers. One of the golden rules of standard area design is that all OSPF areas must have a connection to the backbone area (area 0). A simple topology that shows area 100 connected to the backbone is depicted below:

split_OSPF_area

How many OSPF areas are there in all? 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 »

Multiple OSPF processes with mixed network statements can really mess things up! Fortunately, there is a better way to assign an interface into an OSPF area.

I’ve discussed overlapping OSPF network statements in one of my earlier posts. In the a “pre-IPv6-era” we were taught to use network statements in the OSPF stanza to assign the interfaces to a certain OSPF area. This configuration

interface Vlan100
  ip address 10.0.100.1 255.255.255.0
!
router ospf 1
  passive-interface default
  no passive-interface Vlan100
  network 10.0.100.0 0.0.0.255 area 1

…enables OSPF process on the interface Vlan100 and assigns that interface to OSPF area 1.
What happens if one uses multiple and overlapping networks statements in order to assign interfaces into different areas? Read the rest of this entry »