Routing Information Protocol RIP is an interior gateway protocol IGP, implemented based on a distance-vector algorithm.

RIPv1 characteristics

1. A classful routing protocol
2. Uses broadcast address to update routes
3. Uses UDP port 520 to send and receive packets

Let’s look at the captured request and response packets of RIPv1:

As we can see from the picture, router broadcasts packets with source and destination port 520. The remaining packet fields of RIPv1:

• Command – can be request (1) or response (2)
• Version – can be 1 or 2
• Address Family Identifier – can be unspecified (0-request for entire routing table) or IPv4 (2-IPv4 response)
• IP address – destination IP address
• Metric – hop count

Now we can compare RIPv1 with RIPv2:

The main differences:

• RIPv2 is classless routing protocol (Netmask field has been added)
• RIPv2 uses multicast IP to update routes
• New fields have been added: Route Tag for imported external routes and Next Hop

Except those differences, RIPv2 supports CIDR, route summarization and authentication. As you can notice from the packet format, there is no separate field for authentication. Authentication uses Address Family Identifier field like below:

Three timers of RIP

[R1]display rip
Public VPN-instance    
    RIP process : 1
       RIP version   : 2
       Preference    : 100
       Checkzero     : Enabled
       Default-cost  : 0
       Summary       : Enabled
       Host-route    : Enabled
       Maximum number of balanced paths : 32
       Update time : 30 sec              Update time : 30 sec 
       Garbage-collect time : 120 sec 
       Graceful restart  : Disabled
       BFD               : Disabled
       Silent-interfaces : None 
       Default-route : Disabled
       Verify-source : Enabled
       Networks : 
       10.0.0.0           192.168.20.0   
       Configured peers             : None 
       Number of routes in database : 12
       Number of interfaces enabled : 5
       Triggered updates sent       : 16
       Number of route changes      : 30
       Number of replies to queries : 3
       Number of routes in ADV DB   : 10

  Total count for 1 process : 
       Number of routes in database : 12 
       Number of interfaces enabled : 5 
       Number of routes sendable in a periodic update : 60
       Number of routes sent in last periodic update : 14

Relationship between RIP timers

After a router receives an update from its neighbor, Age Time starts counting till 180 sec:

[R1]display rip 1 route 
 Route Flags : R - RIP
               A - Aging, G - Garbage-collect
 ----------------------------------------------------------------------------
 Peer 192.168.20.2 on Serial0/0/0
      Destination/Mask        Nexthop     Cost   Tag     Flags   Sec
     192.168.10.0/24      192.168.20.2      1    0        RA      10
       172.16.0.0/24      192.168.20.2      2    0        RA      10
       172.16.1.0/24      192.168.20.2      2    0        RA      10
       172.16.2.0/24      192.168.20.2      2    0        RA      10
       172.16.3.0/24      192.168.20.2      2    0        RA      10

The router expects to receive the next update after 30 seconds. As soon as it gets it, Age Time is reset and starts counting again.

[R1]display rip 1 route
 Route Flags : R - RIP
               A - Aging, G - Garbage-collect
 ----------------------------------------------------------------------------
 Peer 192.168.20.2 on Serial0/0/0
      Destination/Mask        Nexthop     Cost   Tag     Flags   Sec
     192.168.10.0/24      192.168.20.2      1    0        RA       1
       172.16.0.0/24      192.168.20.2      2    0        RA       1
       172.16.1.0/24      192.168.20.2      2    0        RA       1
       172.16.2.0/24      192.168.20.2      2    0        RA       1
       172.16.3.0/24      192.168.20.2      2    0        RA       1

What will happen if the router is not receiving the expected update after 30 seconds? Let’s try to simulate it.

R1 router believes to receive an update from R2 router after 30 seconds. Accidentally we caused passwords for RIP authentication inconsistent between R1 and R2. In this case R1 is not receiving update from R2. Let’s have a look at RIP routing table of R1:

[R1]display rip 1 route
 Route Flags : R - RIP
               A - Aging, G - Garbage-collect
 ----------------------------------------------------------------------------
 Peer 192.168.20.2 on Serial0/0/0
      Destination/Mask        Nexthop     Cost   Tag     Flags   Sec
     192.168.10.0/24      192.168.20.2      1    0        RA      51
       172.16.3.0/24      192.168.20.2      2    0        RA      51
       172.16.2.0/24      192.168.20.2      2    0        RA      51
       172.16.1.0/24      192.168.20.2      2    0        RA      51
       172.16.0.0/24      192.168.20.2      2    0        RA      51

As you can see, we still have these routes in RIP routing table. Moreover, these networks are still available:

[R1]ping 172.16.1.1
  PING 172.16.1.1: 56  data bytes, press CTRL_C to break
    Reply from 172.16.1.1: bytes=56 Sequence=1 ttl=254 time=40 ms
    Reply from 172.16.1.1: bytes=56 Sequence=2 ttl=254 time=80 ms
    Reply from 172.16.1.1: bytes=56 Sequence=3 ttl=254 time=30 ms
    Reply from 172.16.1.1: bytes=56 Sequence=4 ttl=254 time=80 ms
    Reply from 172.16.1.1: bytes=56 Sequence=5 ttl=254 time=30 ms

  --- 172.16.1.1 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 30/52/80 ms

If the router doesn’t not receive the update during 180 seconds Age Time, it changes Flag to RG and starts counting Garbage-collect time (120 sec):

[R1]display rip 1 route
 Route Flags : R - RIP
               A - Aging, G - Garbage-collect
 ----------------------------------------------------------------------------
 Peer 192.168.20.2 on Serial0/0/0
      Destination/Mask        Nexthop     Cost   Tag     Flags   Sec
     192.168.10.0/24      192.168.20.2     16    0        RG      11
       172.16.3.0/24      192.168.20.2     16    0        RG      11
       172.16.2.0/24      192.168.20.2     16    0        RG      11
       172.16.1.0/24      192.168.20.2     16    0        RG      11
       172.16.0.0/24      192.168.20.2     16    0        RG      11

After Garbage-collect time starts counting, the networks are not available any more but we can still see them in RIP routing table.

[R1]ping 172.16.1.1
  PING 172.16.1.1: 56  data bytes, press CTRL_C to break
    Request time out
    Request time out
    Request time out
    Request time out
    Request time out

  --- 172.16.1.1 ping statistics ---
    5 packet(s) transmitted
    0 packet(s) received
    100.00% packet loss

After the next 120 seconds the entries are to be deleted from RIP database. The whole process of deleting route entry, from RIP routing table, takes 300 seconds.

Of course we can modify the timers for our needs:

[R1]rip
[R1-rip-1]timers rip 10 60 40

[R1-rip-1]display rip
Public VPN-instance    
    RIP process : 1Age time : 60 sec
       Default-cost  : 0
       Summary       : Enabled
       Host-route    : Enabled
       Maximum number of balanced paths : 32
       Update time : 10 sec              Age time : 60 sec 
       Garbage-collect time : 40 sec 
       Graceful restart  : Disabled
       BFD               : Disabled
       Silent-interfaces : None 
       Default-route : Disabled
       Verify-source : Enabled
       Networks : 
       10.0.0.0           192.168.20.0   
       Configured peers             : None 
       Number of routes in database : 12
       Number of interfaces enabled : 5
       Triggered updates sent       : 16
       Number of route changes      : 30
       Number of replies to queries : 3
       Number of routes in ADV DB   : 10

  Total count for 1 process : 
       Number of routes in database : 12 
       Number of interfaces enabled : 5 
       Number of routes sendable in a periodic update : 60
       Number of routes sent in last periodic update : 14

To be honest, RIP is very seldom used but, as it is required for certification, it is worth to touch it a little bit.

It’s time to check a firewall available in eNSP simulator. Today a simple task, just configuring inter-VLAN communication on Huawei USG5500.

Let’s look at the following topology:

Configuration roadmap:

1. Configure L2 communication on the switch.
2. As the switch is L2, configure subinterfaces on the firewall and enable L3 communication between different VLANs.
3. Set IP addresses and gateways for all PCs.
4. Create 2 security zones and configure interzone packet-filterfing to control traffic between VLANs.
5. Security requirements for the network:

• PC1 in VLAN100 and PC2 in VLAN200 can communicate each other.
• PC3 in VLAN300 can access PC1 and PC2. PC1 and PC2 cannot access PC3.

L2 communication on the switch:

#
interface Ethernet0/0/1
 port link-type access
 port default vlan 100
#
interface Ethernet0/0/2
 port link-type access
 port default vlan 200
#
interface Ethernet0/0/3
 port link-type access
 port default vlan 300
#
interface GigabitEthernet0/0/1
 port link-type trunk
 port trunk allow-pass vlan 100 200 300

L3 communication on the firewall:

#
interface GigabitEthernet0/0/1.100
 vlan-type dot1q 100
 alias GigabitEthernet0/0/1.100
 ip address 10.1.1.2 255.255.255.0
#
interface GigabitEthernet0/0/1.200
 vlan-type dot1q 200
 alias GigabitEthernet0/0/1.200
 ip address 172.16.1.2 255.255.255.0
#
interface GigabitEthernet0/0/1.300
 vlan-type dot1q 300
 alias GigabitEthernet0/0/1.300
 ip address 192.168.1.2 255.255.255.0
#

Create two security zones and add subinterfaces to them based on the above requirements:

[Firewall]firewall zone name a
[Firewall-zone-a]set priority 70
[Firewall-zone-a]add interface GigabitEthernet0/0/1.100
[Firewall-zone-a] add interface GigabitEthernet0/0/1.200
[Firewall-zone-a]

[Firewall]firewall zone name b
[Firewall-zone-b]set priority 80
[Firewall-zone-b] add interface GigabitEthernet0/0/1.300
[Firewall-zone-b]

A security zone is a security concept, based on which most security policies are implemented. A security zone is a set of the networks connected by interfaces. Users on these networks have the same security attributes. USG has 4 security zones by default, which cannot be deleted and their security level cannot be changed. You can create security zones and specify their security levels according to actual networking requirements. The security level ranges from 1 to 100. The larger the value, the higher the security level.

Configure interzone packet filtering based on the above requirements:

[Firewall]policy interzone b a inbound
[Firewall-policy-interzone-b-a-inbound]policy 1
[Firewall-policy-interzone-b-a-inbound-1]  action deny
[Firewall-policy-interzone-b-a-inbound-1]  policy source 10.1.1.0 0.0.0.255
[Firewall-policy-interzone-b-a-inbound-1]  policy source 172.16.1.0 0.0.0.255
[Firewall-policy-interzone-b-a-inbound-1]  policy destination 192.168.1.0 0.0.0.255

[Firewall]policy interzone b a outbound
[Firewall-policy-interzone-b-a-outbound]policy 1
[Firewall-policy-interzone-b-a-outbound-1]  action permit
[Firewall-policy-interzone-b-a-outbound-1]  policy source 192.168.1.0 0.0.0.255

A security interzone is to describe the transmission channel of the traffic, which is the unique path between two zones.

Data flows in the interzone are directional:

• Outbound – indicates that data is transmitted from a higher security zone to a lower security zone.
• Inbound – indicates that data is transmitted from a lower security zone to a higher security zone

Verification:

PC1>ping 172.16.1.1

Ping 172.16.1.1: 32 data bytes, Press Ctrl_C to break
From 172.16.1.1: bytes=32 seq=1 ttl=127 time=62 ms
From 172.16.1.1: bytes=32 seq=2 ttl=127 time=78 ms
From 172.16.1.1: bytes=32 seq=3 ttl=127 time=47 ms
From 172.16.1.1: bytes=32 seq=4 ttl=127 time=63 ms
From 172.16.1.1: bytes=32 seq=5 ttl=127 time=62 ms

--- 172.16.1.1 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 47/62/78 ms

PC1>ping 192.168.1.1

Ping 192.168.1.1: 32 data bytes, Press Ctrl_C to break
Request timeout!
Request timeout!
Request timeout!
Request timeout!
Request timeout!

--- 192.168.1.1 ping statistics ---
  5 packet(s) transmitted
  0 packet(s) received
  100.00% packet loss

PC1>

PC2>ping 10.1.1.1

Ping 10.1.1.1: 32 data bytes, Press Ctrl_C to break
From 10.1.1.1: bytes=32 seq=1 ttl=127 time=63 ms
From 10.1.1.1: bytes=32 seq=2 ttl=127 time=62 ms
From 10.1.1.1: bytes=32 seq=3 ttl=127 time=78 ms
From 10.1.1.1: bytes=32 seq=4 ttl=127 time=63 ms
From 10.1.1.1: bytes=32 seq=5 ttl=127 time=63 ms

--- 10.1.1.1 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 62/65/78 ms

PC2>ping 192.168.1.1

Ping 192.168.1.1: 32 data bytes, Press Ctrl_C to break
Request timeout!
Request timeout!
Request timeout!
Request timeout!
Request timeout!

--- 192.168.1.1 ping statistics ---
  5 packet(s) transmitted
  0 packet(s) received
  100.00% packet loss

PC2>

PC3>ping 10.1.1.1

Ping 10.1.1.1: 32 data bytes, Press Ctrl_C to break
From 10.1.1.1: bytes=32 seq=1 ttl=127 time=78 ms
From 10.1.1.1: bytes=32 seq=2 ttl=127 time=62 ms
From 10.1.1.1: bytes=32 seq=3 ttl=127 time=46 ms
From 10.1.1.1: bytes=32 seq=4 ttl=127 time=62 ms
From 10.1.1.1: bytes=32 seq=5 ttl=127 time=78 ms

--- 10.1.1.1 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 46/65/78 ms

PC3>ping 172.16.1.1

Ping 172.16.1.1: 32 data bytes, Press Ctrl_C to break
From 172.16.1.1: bytes=32 seq=1 ttl=127 time=63 ms
From 172.16.1.1: bytes=32 seq=2 ttl=127 time=47 ms
From 172.16.1.1: bytes=32 seq=3 ttl=127 time=63 ms
From 172.16.1.1: bytes=32 seq=4 ttl=127 time=62 ms
From 172.16.1.1: bytes=32 seq=5 ttl=127 time=47 ms

--- 172.16.1.1 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 47/56/63 ms

PC3>

As you can see from the outputs, PC1 and PC2 can communicate each other but cannot access PC3. PC3 can access PC1 and PC2 which completes our task.

After long time a new version of Huawei eNSP has been released:

New features:

• Support CE6800 DC switch.
• Support any wvrp device.
• Export vrpcfg.cfg from usg5500.

This version is with a language bug. Please follow instructions described in Enterprise Forum FAQ to install and make it working.

I am still fighting with opening CE6800 switch. The rest of devices work properly.

Update…

I’ve just solved the problem with opening CE6800. It was enough to change a number of processors in Virtual Box:

 Huawei AR routers have easy and effective memory usage monitoring tool. When memory usage exceeds configured threshold, the system logs the event and generates an alarm. When memory usage falls within the alarm threshold, the system generates a clear alarm.

By default memory usage threshold is set to 90% when the memory capacity on the interface board is lower than or equal to 128MB, and 95% when the memory capacity is higher that 128MB. Memory usage threshold can be easly changed using command:

[labnario]set memory-usage threshold 75

To check memory usage alarm threshold:

[labnario]display memory-usage threshold 
 Current memory threshold of the main board is 75%.

To restore the default memory usage alarm threshold, use command:

[labnario]undo set memory-usage threshold

Be carefull when changing memory usage alarm threshold because router can frequently generate alarms when the threshold is set too low. When it is set too high, it may be to late to take appriopriate action.

Well known feature from JunOS, now implemented by Huawei in Cloud Engines switches like CE12800, CE7800, CE6800 and CE5800. This feature will be implemented in NE routers as well, starting from V8R6 software version.

We have opportunity to choose wheter changes can be saved automatically or must wait for administrator’s confirmation:

system-view

In this case, the configuration takes effect after you run the commit command (two-phase validation mode).

system-view immediately

The configuration takes effect immidiatelly after you input a command and press enter.

commit [ trial [ time ] ] [ label label ] [ description description ]

I suppose that description and label don’t require any explanation. What is trial? It enables the trial running of new functions and services without interrupting the services running on the network. Time parameter specifies the timeout period for the trial. After it expires, the configuration, in the trial period, rolls back automatically.

rollback configuration { to { commit-id commit-id | label label | file file-name } | last number-of-commits }

• Commit-id is the value the system generates automatically.
• Label and file name indicate the historical configuration state to which the system configuration is expected to roll back.
• Last specifies the number of configuration rollback points. The system will be rolled back to the state before these configuration rollback points.

Related useful commands:

display configuration candidate

It displays all uncommitted configuration.

clear configuration candidate

The uncommitted configuration is deleted.

display configuration commit list [ verbose ] [ number-of-commits | label ]
display configuration commit changes [ at commit-id | since commit-id | last number-of-commits ]
display configuration rollback result