Category Archives: routing protocols

OSPF route withdraw

OSPF has slightly different way of removing routes compared to BGP. On this short post, I will present how a link failure is propagated to other routers on OSPF domain. For this test, I have the following topology section in which AREA3 is connected to AREA0 and we simulate a link failure on the Junos router J39 which has the subnet 10.37.24.0/24

ospf-route-removal-withdraw

Before the failure, we can see that 10.37.24.0/24 is contained in router LSA.

Continue reading

BGP Route Refresh in JUNOS

What happens when you change a BGP import routing policy in your neighbor configuration? Changes take effect immediately or we need to issue the soft-inbound command to request the routes? Let’s see by an example.

We received the route 10.83.0.0/24 from 10.82.1.9 already as you see below.

Now I change the local preference from 2000 to 1999 in the import policy and commit the config.

Continue reading

BGP open message receives a TCP RST

On this micro post, I would like to show one reason why a BGP open message receives a TCP RST. For this test, I set up a BGP neighborship between two peers: PeerA(10.82.1.9) and PeerB(10.82.1.10)

PeerA initiates the connection and look what happens in the packet capture.

bgp-open-reset

According to the sequence, TCP seems to have established properly. 3WAY handshake is done and PeerA thinks it can send its capabilities in its OPEN message and it actually sends it but something weird happens. Remote side PeerB first closes the connection [FIN,ACK] and then sends a RST segment to our OPEN message but why does he do that?

Continue reading

OSPF Loop prevention

On this post, I will show an example of loop prevention on OSPF protocol. There is a nice document at here about the principles of loop prevention. What I will just do is to show this on Junos. In order to show this, I am using the following topology;

ospf-loop-prevention

On this topology, J40 and J32 are ABRs. J40 has a connection to Area3 in broadcast segment and J32 also has a link to Area3 via J201. It looks like we have multiple paths towards the same Area3 from backbone area. Let’s see how OSPF handles this.

Continue reading

OSPF equal cost path

On this post, I will try to show how OSPF behaves when there are two equal cost paths towards a destination. To demonstrate this, I have prepared my usual topology.

ospf-equal-cost-path-junos

On this topology all routers are running OSPF but our focus is on the router J32 which is circled at the bottom and our destination network is 172.40.1.0/24 Since we have set the reference bandwidth to 10G and each links are 1G a single link OSPF cost is 10. Now let’s see how J32 device reaches this destination network.

Continue reading

OSPF neighborship, database and routing table

OSPF sometimes can be a confusing protocol. For example if you turn on a light switch, you simply get the immediate result: Light is on. What if when you turn on the light switch but you see the shining light bulb after 40 seconds then it is more difficult to understand the result of your actions. This was a small introduction to this post which I will try to write about he link between OSPF neighborship, OSPF database and routing table. All tests are done on a virtual SRX firewall in packet mode. I have cropped a section of my OSPF topology to simplify this post.

ospf-neighborship-database-lsa

We simply have two routers connected via a point to point link and they both run OSPF. FF31 router is an ABR and J204 is an internal router (which is actually a routing instance on another router but we can ignore this detail)

On this setup following are the OSPF details

J204: Router ID=10.1.1.204, Interface IP: 200.1.2.2
J31: Router ID=10.1.1.31, Interface IP: 200.1.2.1

Continue reading

BGP: Connection collision resolution

I was doing couple of tests on BGP protocol today between two EBGP peers and monitoring the BGP trace file I enabled on my Junos box during which I have seen the following NOTIFICATION being sent by one of the peers.

I don’t recall of having seen this BGP NOTIFICATION before actually. Looking at RC4271 reveals why this occurs.

To prevent further race conditions like this from happening in the future, apparently setting the option “passive” for one of the peer allows us not to initiate BGP connection from both peers but only from active side.