Weird behaviour while trying to deploy a simple network with BGP

[chococlat]

Following some video lessons i replicated a Lab [https://github.com/chococlat/Lab4.1_BGP] The code is identical to the lessons one, but when i run it there are some problems:

• In the video lessons the line /etc/init.d/zebra start on any of the routers gives the output Starting Quagga daemons (prio:10) zebra bgpd. Starting Quagga monitor daemon:watchquagga. Meanwhile, during my replication, my output is just Starting zebra: zebra. I had to change the line "/etc/init.d/zebra start" with "/etc/init.d/quagga start" to have quagga running, but i'm not sure if this is the right approach.
• The second problem is about the actual routing of the network. During a "watch route" i notice that the routing table keeps changing, removing established rules and re-adding them in a loop. This makes my ping (from router-1 to router-3) go something like this:

Is there any possibility that something in the Kathara project changed and what im trying to do is not possible anymore? These are old lessons and at the moment i can't reach the creator. Im asking here since i have no idea of where to start.

Thanks for your time Alessandro

[tcaiazzi]

Hi @chococlat,

I'll try to answer to all your questions:

1. For /etc/init.d/zebra start, yes you have to use /etc/init.d/quagga start since something is changed in the Docker image.

2. I tried your lab, the error is caused by the interfaces configuration in the .startup files. It is always preferred to specify the netmask of the prefixes. I don't know why but the ifconfig commands you used to configure interfaces on 100.0.0.0/24 and 110.0.0.0/24 creates instead /8 prefixes. This leads to the routing tables loop that you noticed. Since the BGP announcement sent by r2 for the collision domain A is for a more specif /24, r1 accepts the announce, moving the nexthop 100.0.0.2 on the more specific prefix 100.0.0.0/24. At this point r1 sees that his nexthop is not directly reachable and invalids the announces. This creates the loop where r1 starts to consider the announces from r2: valid --> INVALID --> VALID.
   You can appreciate this inspecting the zebra routing table inside the device: You can apply the same also for r3.

3. Kathará runs only real software so updates can change the behavior of the software. If you need some example and labs try our official ones. They cover many arguments and are updated annually.

Let me know if you need something else!

Tommaso.

[chococlat]

Awesome, all working now. And yes, i'll watch some of the examples. Thank you very much!

Alessandro