All_about_network

In one of the previous posts I went through steps necessary to add or delete the static routes on SPLAT and IPSO. This time I would like to go through dynamic routing – specifically OSPF . This article will be about Securre PLATform only.

This time I will start with SPLAT routing interface. For dynamic routing you need to be running SPLAT pro (and you need to pay  extra for that). If you happen to have the license but by any coincidence installed non pro version you can enable the routing features by the “pro enable” command. Once you run this you need to reboot.

Before you start playing around with the OSPF itself it let’s have a look into a topology.

In this scenario I will use 4 R70 gateways to run simple OSPF all in backbone area 0 (later I will hopefully get to more complex scenarios withdifferent areas NSSA, stub, virt. links etc.)

Step #0 configuring interfaces

As the first step you need to configure your splat environment and specifically the interfaces. You will achieve that with the “sysconfig” utility. You can use that for other system config as well.  There is one VERY important thing about SPLAT – it is very good idea to use some NTP server for time sync ad quite a few operation of these devices are dependent on consistent timestamps. Other very important note is for advanced linux users – please do not configure the interfaces through /etc/sysconfig/netconf.C as you would in red-hat. The reason for this is that SPLAT gets very confused when you do so and sometimes it just cannot handle the manual changes. This can actually result in partial or total system crashes.

Step #1 – create loopback interfaces

I will use loopback interfaces to bind the OSPF process to,  so we will follow the common OSPF practise (the reason for this is that ospf process will not flap in case of interface down event and thus the recalculations of paths are faster). The other reason is that I’ll redistibute the “networks ” thought the OSPF so I can prove that the route exchange actually works.

So how to add a loopback interface? again – with the sysconfig utility in the network connections menu.

Choose a connection type to add (‘e’ to exit):
————————————————————————————————————————————
1) Secondary IP on interface (alias)  5) Loopback connection
2) VLAN                                        6) PPPoE connection
3) Bridge                                      7) PPTP connection
4) Bond                                        8) ISDN connection
————————————————————————————————————————————
(Note: configuration changes are automatically saved)
Your choice: 5
Enter IP address for loop00 (press ‘c’ to cancel): 111.111.1.1
Enter network mask of the interface loop01 (press ‘c’ to cancel): 255.255.255.255
Network Mask [255.255.255.255] does not match IP [111.111.1.1]
Enter IP address for loop00 (press ‘c’ to cancel): 111.111.1.1
Enter network mask of the interface loop01 (press ‘c’ to cancel): 255.255.255.0

The interface is configured.
Current interface configuration is:

loop00 ip: 1.1.1.1, broadcast: 1.1.1.1, netmask: 255.255.255.252

Press Enter to continue…

Interesting note -as you can see SPLAT does not recognize 32 bit subnet mask for the loopback interface. The minimal mask-length is then 30 bit.

Step #2 – configure OSPF

Now when the environment is set you can enter the routing CLI with the command “router”.  You could be surprised as what you will enter is almost identical copy of Cisco’s IOS which is cut down to routing features  (with exception for static routes – you need to configure static routes through “sysconfig”). This CLI even has the 3 levels of privileged access  so if you want to access the routing stuff you need to go to thourgh “neble” to  ”configure terminal” as is shown below. So once you are there just continue as in Cisco’s IOS – router/ospf/ process id/ add networks set router ID etc (example is below).

[Expert@cpmodule]# router
localhost.localdomain>enable
localhost.localdomain#conf t
localhost.localdomain(config)#router ospf 1
localhost.localdomain(config-router-ospf)#network 1.1.1.0 0.0.0.3 area 0.0.0.0
localhost.localdomain(config-router-ospf)#network 1.1.1.12 0.0.0.3 area 0.0.0.0
localhost.localdomain(config-router-ospf)#network 111.111.1.0 0.0.0.255 area 0.0.0.0
localhost.localdomain(config-router-ospf)#router-id 111.111.1.1

There is one very important thing to note  the area numbers are not noted in simple decimal (as you can see on Huawei/Cisco) but in dotted decimal as an IPv4 IP address. Then you allow the OSPF on the desired interface(s).

[Expert@cpmodule]# router
localhost.localdomain>enable
localhost.localdomain#conf t
localhost.localdomain(config)#interface eth1
localhost.localdomain(config-if)#ip ospf enable
localhost.localdomain(config-if)#exit
localhost.localdomain(config)#interface eth2
localhost.localdomain(config-if)#ip ospf enable
localhost.localdomain(config-if)#exit
localhost.localdomain(config)#
localhost.localdomain(config)#interface loo0
localhost.localdomain(config-if)#ip ospf enable
localhost.localdomain(config-if)#exit
localhost.localdomain(config)#

Once you have done this on the you can verify the config through “show run” command from the “enable” mode. If you try to check if the routes are redistributed with the “show ip route ospf” command you will see that nothing is happening. That is because the initial (or other) policy is in place and is actually filtering out the LSAs. In the common deployment you just need to create an  allow rule for the muticast of the OSPF (reserved multicats address 224.0.0.5) so the communication can exit and reach the firewall.

If you have clean installation and do not care about anything as you just need to test it you can unload the policy in place by running “fw unloadlocal” from any mode (cpshell or expert). The routes are redistributed almost instantly.

You can verify the routing table from the router interface with the “show ip route” or from cpshell/expert(bash) with “netstat -nvr” commands.

the results should look like this:

or this

Well that was the easy part, now we will extend this scenario a bit – by changing the LAN’s interfaces addresses and netmasks to separate networks and assigning those to different OSPF areas and then redistribute them.

the interface changes will be done again by the sysconfig utility. The topology will change to this:

If you use the same instance for the ospf process with just different area number it is all you need to do to redistribute the subnets