Useful information for those who think or want to pass Huawei certification. A session about HCIE certification process and exam contents by Nigel Roy.

To understand how PIM DM works, just look at control messages generated.

Let’s take topology from the last lab:

After PIM DM is configured on interfaces between neighbors, both devices periodically send HELLO messages to each other, to discover neighbors and maintain the neighbor relationship:

Jul  4 2014 13:16:44.940.2-08:00 SwitchA PIM/7/NBR:(public net): PIM ver 2 HEL se
nding 150.1.1.2 -> 224.0.0.13 on Vlanif300  (P012213)
Jul  4 2014 13:16:44.940.3-08:00 SwitchA PIM/7/NBR:(public net): Option: 1, lengt
h: 2 (P012260)
Jul  4 2014 13:16:44.940.4-08:00 SwitchA PIM/7/NBR:(public net): Holdtime: 105 (P
012278)
Jul  4 2014 13:16:44.940.5-08:00 SwitchA PIM/7/NBR:(public net): Option: 19, leng
th: 4 (P012260)
Jul  4 2014 13:16:44.940.6-08:00 SwitchA PIM/7/NBR:(public net): DR priority: 1 (
P012324)
Jul  4 2014 13:16:44.940.7-08:00 SwitchA PIM/7/NBR:(public net): Option: 20, leng
th: 4 (P012260)
Jul  4 2014 13:16:44.940.8-08:00 SwitchA PIM/7/NBR:(public net): GenID: 0X9FBFC09
E (P012343)
Jul  4 2014 13:16:44.940.9-08:00 SwitchA PIM/7/NBR:(public net): Option: 2, lengt
h: 4 (P012260)
Jul  4 2014 13:16:44.940.10-08:00 SwitchA PIM/7/NBR:(public net): Tbit: unset  (P
012300)
Jul  4 2014 13:16:44.940.11-08:00 SwitchA PIM/7/NBR:(public net): Lan delay: 500 
(P012303)
Jul  4 2014 13:16:44.940.12-08:00 SwitchA PIM/7/NBR:(public net): Override interv
al: 2500 (P012306)
Jul  4 2014 13:16:44.940.13-08:00 SwitchA PIM/7/NBR:(public net): Option: 21, len
gth: 4 (P012260)
Jul  4 2014 13:16:44.940.14-08:00 SwitchA PIM/7/NBR:(public net): Version: 1 (P01
2365)
Jul  4 2014 13:16:44.940.15-08:00 SwitchA PIM/7/NBR:(public net): Refresh interva
l: 60 (P012368)
Jul  4 2014 13:16:44.940.16-08:00 SwitchA PIM/7/NBR:(public net): Reserved: 00000

A PIM device must first receive HELLO message from its neighbor before it can receive multicast packets, to create multicast routing entries and maintain the MDT.

Once the PIM neighbor relationship is established, multicast source floods multicast data to all routers on the network. PIM DM assumes that at least one multicast group member exists on each subnet. That’s why all routers receive multicast data. Then PIM DM prunes brunches that don’t have multicast receivers and forward traffic only to brunches that require to receive multicast data. In such case JOIN/PRUNE message is sent by PIM router that doesn’t need multicast traffic.

Jul  4 2014 12:57:44.250.1-08:00 SwitchB PIM/7/JP:(public net): PIM ver 2 JP  rec
eiving 150.1.1.2 -> 224.0.0.13 on Vlanif300  (P012998)
Jul  4 2014 12:57:44.250.2-08:00 SwitchB PIM/7/JP:(public net): Upstream 150.1.1.
1, Groups 1, Holdtime 210 (P013002)
Jul  4 2014 12:57:44.250.3-08:00 SwitchB PIM/7/JP:(public net): Group: 225.1.1.1/
32 --- 0 join 1 prune (P013011)
Jul  4 2014 12:57:44.250.4-08:00 SwitchB PIM/7/JP:(public net): Prune: 10.10.10.1
00/32  (P013021)

At the same time network brunches send JOIN/PRUNE messages to receive multicast data. Format of this message is the same like PRUNE message.

Jul  7 2014 12:24:19.300.3-08:00 SwitchA PIM/7/JP:(public net): PIM ver 2 JP  sen
ding 150.1.1.2 -> 224.0.0.13 on Vlanif300  (P012933)
Jul  7 2014 12:24:19.300.4-08:00 SwitchA PIM/7/JP:(public net): Upstream 150.1.1.
1, Groups 1, Holdtime 0 (P012939)
Jul  7 2014 12:24:19.300.5-08:00 SwitchA PIM/7/JP:(public net): Group: 225.1.1.1/
32 --- 1 join 0 prune (P012949)
Jul  7 2014 12:24:19.300.6-08:00 SwitchA PIM/7/JP:(public net): Join: 10.10.10.10
0/32  (P012959)

In PIM DM network, to avoid that the interface restores forwarding because the prune timer times out, the first hop router, nearest to the source, periodically triggers STATE-REFRESH messages:

Jul  7 2014 12:39:31.530.1-08:00 SwitchA PIM/7/SRM:(public net): PIM ver 2 SRM re
ceiving 150.1.1.1 -> 224.0.0.13 on Vlanif300  (D191471)
Jul  7 2014 12:39:31.530.2-08:00 SwitchA PIM/7/SRM:(public net): Group address: 2
25.1.1.1/32 flags: 00000000 (D191476)
Jul  7 2014 12:39:31.530.3-08:00 SwitchA PIM/7/SRM:(public net): Source address: 
10.10.10.100 (D191481)
Jul  7 2014 12:39:31.530.4-08:00 SwitchA PIM/7/SRM:(public net): Originator addre
ss: 150.1.1.1 (D191485)
Jul  7 2014 12:39:31.530.5-08:00 SwitchA PIM/7/SRM:(public net): preference: 0 me
tric: 0 mask length: 24  (D191514)
Jul  7 2014 12:39:31.530.6-08:00 SwitchA PIM/7/SRM:(public net): ttl: 255 prune i
ndicator: set prune now: unset assert override: set  (D191518)
Jul  7 2014 12:39:31.530.7-08:00 SwitchA PIM/7/SRM:(public net): interval: 60 (D1
91524)

Once a receiver wants to join multicast group, it sends IGMP report to upstream device:

Jul  7 2014 13:32:45.290.1-08:00 SwitchA IGMP/7/EVENT:(S,G) creation event receiv
ed for (10.10.10.100/32, 225.1.1.1/32). (G01985)
Jul  7 2014 13:32:45.290.2-08:00 SwitchA IGMP/7/EVENT:No state in global MRT. Not
 merging downstream for (10.10.10.100/32, 225.1.1.1/32) on interface Vlanif300(15
0.1.1.2). (G011016)
Jul  7 2014 13:32:50.650.1-08:00 SwitchA IGMP/7/REPORT:Received v2 report for gro
up 225.1.1.1 on interface Vlanif400(10.10.30.1) (G082859)
Jul  7 2014 13:32:50.650.2-08:00 SwitchA IGMP/7/EVENT:Creating group(225.1.1.1) f
or interface Vlanif400(10.10.30.1) (G014427)
Jul  7 2014 13:32:50.650.3-08:00 SwitchA IGMP/7/TIMER:Enqueue group(225.1.1.1) on
 interface Vlanif400(10.10.30.1) in group_calq. (G016648)

After PIM router receives the report message from the host, it sends a GRAFT message through the upstream interface of the related (S, G) entry, if the router is not on the SPT (shortest path tree). Upstream device responds with GRAFT-ACK message and restores the forwarding status of the downstream interface connected to requesting device.

Jul  4 2014 12:55:53.950.1-08:00 SwitchA PIM/7/JP:(public net): PIM ver 2 GFT sen
ding 150.1.1.2 -> 150.1.1.1 on Vlanif300  (P012933)
Jul  4 2014 12:55:53.950.2-08:00 SwitchA PIM/7/JP:(public net): Upstream 150.1.1.
1, Groups 1, Holdtime 0 (P012939)
Jul  4 2014 12:55:53.950.3-08:00 SwitchA PIM/7/JP:(public net): Group: 225.1.1.1/
32 --- 1 join 0 prune (P012949)
Jul  4 2014 12:55:53.950.4-08:00 SwitchA PIM/7/JP:(public net): Join: 10.10.10.10
0/32  (P012959)
Jul  4 2014 12:55:53.960.1-08:00 SwitchA PIM/7/JP:(public net): PIM ver 2 GAK rec
eiving 150.1.1.1 -> 150.1.1.2 on Vlanif300  (P012933)
Jul  4 2014 12:55:53.960.2-08:00 SwitchA PIM/7/JP:(public net): Upstream 150.1.1.
2, Groups 1, Holdtime 0 (P012939)
Jul  4 2014 12:55:53.960.3-08:00 SwitchA PIM/7/JP:(public net): Group: 225.1.1.1/
32 --- 1 join 0 prune (P012949)
Jul  4 2014 12:55:53.960.4-08:00 SwitchA PIM/7/JP:(public net): Join: 10.10.10.10
0/32  (P012959)

PIM-DM employs GRAFT to implement fast data forwarding and enable new group members to rapidly receive multicast data.

In case of our receiver is connected to both PIM routers in our topology, in the shared network segment, the PIM device receives (S, G) packet from the downstream interface of the (S, G) or (*, G) entry. It means that other forwarders exist in the network segment. That’s why PIM device sends an ASSERT message through the downstream interface to take part in the election. The router that fails the election, stops forwarding multicast data through the downstream interface:

Jul  4 2014 15:59:43.910.2-08:00 SwitchB PIM/7/ASSERT:(public net): Fsm:assert, c
urrent state: winner received event: 10 for (10.10.10.100,225.1.1.1) on interface
 Vlanif400 (D02701)

Using debugging command and Wireshark on eNSP you can simply check how PIM DM works. You can find messages’ types, default parameters and so on. I chose only control messages, generated by PIM routers, here in this post.

NAP is a Huawei proprietary protocol, which implements remote configuration in Layer 3 networks. It allows to log into an unconfigured device from a directly connected device. It is very simple and can be really helpful, when implementing new devices. NAP establishes a temporary neighbor relationship between configured and unconfigured devices. Both must be directly connected through a physical link. When NAP relationship is established, telnet can be done to the unconfigured device.

NAP relationship can be established in two different ways:

• Automatically – using IP addresses allocated by the system
• Statically – using IP addresses allocated by the administrator.

NAP cannot be used on interfaces, configured with commands affecting the IP address configuration or IP packet forwarding, such as commands related to VPNs or Ethernet trunks.

How to use NAP? Let’s assume that we have two switches as in the picture below:

Automatic NAP

Automatic NAP uses IP addresses allocated from the 10.167.253.0/24 address pool. Only one command is required to be able to telnet to unconfigured device:

<labnarioSW1>sys
Enter system view, return user view with Ctrl+Z.
[labnarioSW1]int g0/0/1
[labnarioSW1-GigabitEthernet0/0/1]nap port master
[labnarioSW1-GigabitEthernet0/0/1]quit

[labnarioSW1]dis nap status
 Slave port status         : Enable
 Nap IP-pool/Mask          : 10.167.253.0/24
[labnarioSW1-GigabitEthernet0/0/1]

[labnarioSW1-GigabitEthernet0/0/1]dis nap interface
------------------------------------------------------
 NAP master port list 
 Port count           : 1
------------------------------------------------------
 Port property                           : Master
 Current status                          : IP-ASSIGNED
 Local port                              : GigabitEthernet0/0/1
 Peer port                               : GigabitEthernet0/0/1
 Local IP                                : 10.167.253.1
 Peer IP                                 : 10.167.253.2
 Hello time                              : 3s
 Linked time                             : 00:00:22
------------------------------------------------------
 NAP slave port list  
 Port count           : 0
------------------------------------------------------

When addresses are already assigned, telnet can be done using the following command (note that this is the interface configuration view):

[labnarioSW1-GigabitEthernet0/0/1]nap login neighbor
Trying 10.167.253.2 ...
Press CTRL+K to abort
Connected to 10.167.253.2 ...

Info: The max number of VTY users is 10, and the number of current VTY users on line is 1.

Please Press ENTER.

<Huawei>sys
[Huawei]undo nap slave enable

Static NAP

Static NAP configuration requires additional command, where IP addresses assignment can be defined:

[labnarioSW1]int g0/0/1
[labnarioSW1-GigabitEthernet0/0/1]nap port master
[labnarioSW1-GigabitEthernet0/0/1]nap ip-address local 192.168.1.1 peer 192.168.1.2 24 
Are you sure to continue?[Y/N]y
[labnarioSW1-GigabitEthernet0/0/1]

[labnarioSW1]dis nap status
 Slave port status         : Enable
 Nap IP-pool/Mask          : 10.167.253.0/24

[labnarioSW1-GigabitEthernet0/0/1]dis nap interface
------------------------------------------------------
 NAP master port list 
 Port count           : 1
------------------------------------------------------
 Port property                           : Master
 Current status                          : IP-ASSIGNED
 Local port                              : GigabitEthernet0/0/1
 Peer port                               : GigabitEthernet0/0/1
 Local IP                                : 192.168.1.1
 Peer IP                                 : 192.168.1.2
 Hello time                              : 3s
 Linked time                             : 00:02:21
------------------------------------------------------
 NAP slave port list  
 Port count           : 0
------------------------------------------------------

[labnarioSW1-GigabitEthernet0/0/1]nap login neighbor
Trying 192.168.1.2 ...
Press CTRL+K to abort
Connected to 192.168.1.2 ...

Info: The max number of VTY users is 10, and the number of current VTY users on line is 1.

Please Press ENTER.

<Huawei>sys
[Huawei]undo nap slave enable

For troubleshooting use a debugging command:

<labnarioSW1>debugging nap

1. Configure IP addresses based on the above topology (omitted).
2. Use OSPF to assure connectivity between switches.
3. Enable multicast on both switches.
4. Enable PIM DM on all interfaces.
5. Address of multicast group G: 225.1.1.1.
6. Address of multicast group S: 10.10.10.100.

OSPF configuration:

[SwitchA]dis current-configuration configuration ospf
#
ospf 1
 area 0.0.0.0
  network 10.10.30.0 0.0.0.255
  network 150.1.1.0 0.0.0.3
#
[SwitchB]display current-configuration configuration ospf
#
ospf 1
 area 0.0.0.0
  network 10.10.10.0 0.0.0.255
  network 10.10.20.0 0.0.0.255
  network 150.1.1.0 0.0.0.3
#

Although PIM is intra-domain multicast routing protocol, RPF check is always performed based on IGP, in our case OSPF. Every problem in OSPF causes a problem in the multicast.

Enable multicast on both switches:

[SwitchA]multicast routing-enable

[SwitchB]multicast routing-enable

Enable PIM DM on each interface:

[SwitchA]dis cur int Vlanif 
#
interface Vlanif300
 ip address 150.1.1.2 255.255.255.252
 pim dm
#
interface Vlanif400
 ip address 10.10.30.1 255.255.255.0
 pim dm
 igmp enable

[SwitchB]dis cur int Vlanif 
#
interface Vlanif100
 ip address 10.10.10.1 255.255.255.0
 pim dm
 igmp enable
#
interface Vlanif200
 ip address 10.10.20.1 255.255.255.0
 pim dm
 igmp enable
#
interface Vlanif300
 ip address 150.1.1.1 255.255.255.252
 pim dm
#

As you can see from the above output, except PIM DM protocol, IGMP has been configured at the interfaces towards receivers. What is IGMP? This is Internet Group Management Protocol that manages IPv4 multicast members. In short, IGMP needs to be enabled on hosts and on switches. Through IGMP, a multicast L3 device knows whether there is a multicast group member, on the network segment to which an interface of the switch is connected.

Verification (SwitchA as an example):

[SwitchA]display pim interface
 VPN-Instance: public net
 Interface           State NbrCnt HelloInt   DR-Pri     DR-Address
 Vlanif300           up    1      30         1          150.1.1.2       (local)
 Vlanif400           up    0      30         1          10.10.30.1      (local)

[SwitchA]dis pim neighbor 
 VPN-Instance: public net
 Total Number of Neighbors = 1

 Neighbor        Interface           Uptime   Expires  Dr-Priority  BFD-Session
 150.1.1.1       Vlanif300           00:57:23 00:01:22 1            N          

[SwitchA]dis igmp interface
Interface information
 Vlanif400(10.10.30.1): 
   IGMP is enabled
   Current IGMP version is 2
   IGMP state: up
   IGMP group policy: none
   IGMP limit: -
   Value of query interval for IGMP (negotiated): -
   Value of query interval for IGMP (configured): 60 s
   Value of other querier timeout for IGMP: 0 s
   Value of maximum query response time for IGMP: 10 s
   Querier for IGMP: 10.10.30.1 (this router)

Let’s start multicast source. Assume that receivers need to get information about multicast group G 225.1.1.1. When sending multicast packets to multicast group G, multicast source S 10.10.10.100 generates an SPT (shortest-path tree) through flooding and the (S, G) entries exist on both switches that are in the SPT. When a receiver joins multicast group G, an (*, G) entry is generated on the switch.

[SwitchA]dis pim routing-table
 VPN-Instance: public net
 Total 1 (*, G) entry; 1 (S, G) entry

 (*, 225.1.1.1)
     Protocol: pim-dm, Flag: WC 
     UpTime: 00:00:07
     Upstream interface: NULL
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif400
             Protocol: igmp, UpTime: 00:00:07, Expires: never

 (10.10.10.100, 225.1.1.1)
     Protocol: pim-dm, Flag: ACT 
     UpTime: 00:12:17
     Upstream interface: Vlanif300
         Upstream neighbor: 150.1.1.1
         RPF prime neighbor: 150.1.1.1
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif400
             Protocol: pim-dm, UpTime: 00:00:07, Expires:  - 


[SwitchB]dis pim routing-table 
 VPN-Instance: public net
 Total 1 (*, G) entry; 1 (S, G) entry

 (*, 225.1.1.1)
     Protocol: pim-dm, Flag: WC 
     UpTime: 00:00:30
     Upstream interface: NULL
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif200
             Protocol: igmp, UpTime: 00:00:30, Expires: never

 (10.10.10.100, 225.1.1.1)
     Protocol: pim-dm, Flag: LOC ACT 
     UpTime: 00:12:37
     Upstream interface: Vlanif100
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 2
         1: Vlanif300
             Protocol: pim-dm, UpTime: 00:00:25, Expires: never
         2: Vlanif200
             Protocol: pim-dm, UpTime: 00:00:30, Expires:  -

Let’s check whether it works, using eNSP with VLC.

As you can see this post so probably new DNS servers started working correctly.

What’s new here on labnario?

In addition to a new look, a technical forum has been published. You can write your questions, describe technical problems or just talk about everything and nothing in Hyde Park category. It depends on you if this forum meets its goal. I wouldn’t like to close it due to a little activity. As I see, such a fate befalls most technical forums on the internet. I count on your activity here on the forum. Let’s build a forum of which we can be proud of.

I’m still working to properly assign links on the blog. Most of links direct you to the old blog. It will be changed ASAP.

As it was not possible to move all posts from the old blog automatically, I had to do this manually. That’s why there is a significant probability of mistakes. If you find them, just let me know.

The old blog will not be closed. You will find it on wordpress platform.

New posts will be published only here, so be invited to sign for labnario’s newsletter. You can also build our labnario community on Facebook.

What can I say?

Enjoy the new labnario.