They told me I could do anything, So I broke OSPF

As many readers have been aware I have been working away at Juniper posts. Working through various topics I have passed Junos and Enterprise. Security looks to be on the horizon. I will see how I feel when I get back from my VMware boot camp.

Now, how did I break OSPF? Well, maybe I was a bit dramatic but I definitely did something I shouldn’t have. I have had this blog post on ice for a little bit whilst would roll back configurations and lab when I got the change. There are definitely a good way of controlling routes as opposed to breaking the OSPF DB and I chose a poor way.

I wanted to block routes from another OSPF device in the same area.

policy-statement SUPPRESS_192_168_250 {
    term BLOCK_BELOW {
        from {
            route-filter exact;
        then reject;
    term ALLOW_OTHERS {
        then accept;
[email protected]# show protocols ospf 
import SUPPRESS_192._168_250;
area {
    interface fe-0/0/0.0;

Now this didn’t actually block the route from entering the route table. I was thinking to my self why? Why is it doing this? My face was hurting and many quick attempts to resolve it (time has been limited of late) were futile. Well if I have more than one interface assigned to an area, the Type 1 and 2 LSAs would be sharing with other OSPF speakers in the area.

[email protected]> show route

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both      *[OSPF/10] 00:01:56, metric 2
                                > to via fe-0/0/0.0

So it is still in the routing table. You cannot safely reject an internal route from an import policy in the OSPF routing table unless all routers in the area have the same policy.   Now a recent item appeared in my studies recently which I should have thought of. I needed to suppress a route from a devices. Martian Addresses. Martian addresses are addresses from which any routing information is ignored. 100 percent.

set routing-options martians exact

Now let us see what OSPF thinks of that!

[email protected]# run show route     

inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)

[email protected]# run show route hidden 

inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both       [OSPF/10] 00:12:54, metric 2
                                > to via fe-0/0/0.0

There we go. Again proof there is many ways to find a solution and I am sure readers may have another. Now this will kill this route for any protocol that listens to the  Martian list so it may not be the best solution but it is one. It goes to prove that you need to think and apply yourself to many technologies to achieve a result and not expect it to come land in your lap.

EDIT: Speaking of landing in laps….

Leave a Reply

Your email address will not be published. Required fields are marked *