clear ip mroute A.B.C.D | Nexus5672UP

[ntt-telecom]

Hello,

we have an issue with "clear ip mroute A.B.C.D” command (tested on NX-OS 7.3.3.N1.1 and 7.3.2.N1.1).

After specific (s,g) group is cleared, it doesn't appear again.

Only after "clear ip mroute *" command, that (s,g) entry appearing again in mrib.

It is NX-OS bug or not? Because in classical IOS "clear ip mroute A.B.C.D" works great.

Example output (real IP adresses is changed):

NX3# sh ip mroute 233.x.x.x
IP Multicast Routing Table for VRF "default"

(a.b.c.d/32, 233.x.x.x/32), uptime: 00:00:59, ip pim 
  Incoming interface: Vlan817, RPF nbr: c.d.e.f
  Outgoing interface list: (count: 0)

NX3# clear ip mroute  233.x.x.x
NX3# sh ip mroute  233.x.x.x
IP Multicast Routing Table for VRF "default"

Group not found
NX3# clear ip mroute *
 NX3# sh ip mroute 233.x.x.x
IP Multicast Routing Table for VRF "default"

(a.b.c.d/32, 233.x.x.x/32), uptime: 00:00:04, ip pim 

  Incoming interface: Vlan817, RPF nbr: c.d.e.f
  Outgoing interface list: (count: 0)

Thank you in advance.

[ntt-telecom]

any suggestions?

[chrihussey]

Have Nexus 56128P running 7.3.2.N1 and tried it. After clearing a specific group it reappeared in about 15 seconds. A bug wouldn't be out of the question, probably opening a case would be best.

Hope this is of some help.

[ntt-telecom]

thanks.

[zinogarphy]

---

@ntt-telecom wrote:

Hello,

we have an issue with "clear ip mroute A.B.C.D” command (tested on NX-OS 7.3.3.N1.1 and 7.3.2.N1.1).

After specific (s,g) group is cleared, it doesn't appear again.

Only after "clear ip mroute *" command, that (s,g) entry appearing again in mrib.

It is NX-OS bug or not? Because in classical IOS "clear ip mroute A.B.C.D" works great.

Example output (real IP adresses is changed):

NX3# sh ip mroute 233.x.x.x
IP Multicast Routing Table for VRF "default"

(a.b.c.d/32, 233.x.x.x/32), uptime: 00:00:59, ip pim 
  Incoming interface: Vlan817, RPF nbr: c.d.e.f
  Outgoing interface list: (count: 0)

NX3# clear ip mroute  233.x.x.x
NX3# sh ip mroute  233.x.x.x
IP Multicast Routing Table for VRF "default"
Chaturbate Xnxx Tubegalore
Group not found
NX3# clear ip mroute *
 NX3# sh ip mroute 233.x.x.x
IP Multicast Routing Table for VRF "default"

(a.b.c.d/32, 233.x.x.x/32), uptime: 00:00:04, ip pim 

  Incoming interface: Vlan817, RPF nbr: c.d.e.f
  Outgoing interface list: (count: 0)

Thank you in advance.

---

Have Nexus 56128P running 7.3.2.N1 and tried it. After clearing a specific group it reappeared in about 15 seconds. A bug wouldn't be out of the question, probably opening a case would be best.

[chrihussey]

Hello,

I tested again on my 56128s. Had a multicast stream active and cleared the specific mroute and then the entire table (*). I'm running in a sparse-mode only environment. The results were slightly different:

In normal operation:

(*, 239.1.1.14/32), uptime: 00:00:05, igmp ip pim
  Incoming interface: port-channel126, RPF nbr: 10.250.1.37
  Outgoing interface list: (count: 1)
    Vlan645, uptime: 00:00:05, igmp

(10.20.0.15/32, 239.1.1.14/32), uptime: 00:00:05, ip mrib pim
  Incoming interface: port-channel126, RPF nbr: 10.250.1.37
  Outgoing interface list: (count: 1)
    Vlan645, uptime: 00:00:05, mrib

Clearing the specific route: It re-appeared again in about 15 seconds, but a source group would not, so it was almost like it took the feed from the RP and would not switch to the shortest path tree to the source even if I stopped and restarted the stream:

(*, 239.1.1.14/32), uptime: 00:00:01, igmp ip pim
  Incoming interface: port-channel126, RPF nbr: 10.250.1.37
  Outgoing interface list: (count: 1)
    Vlan645, uptime: 00:00:01, igmp

Only when I did a full clear of the mroute table did I see normal operation with it switching to the SPT:

(*, 239.1.1.14/32), uptime: 00:00:05, igmp ip pim
  Incoming interface: port-channel126, RPF nbr: 10.250.1.37
  Outgoing interface list: (count: 1)
    Vlan645, uptime: 00:00:05, igmp

(10.20.0.15/32, 239.1.1.14/32), uptime: 00:00:05, ip mrib pim
  Incoming interface: port-channel126, RPF nbr: 10.250.1.37
  Outgoing interface list: (count: 1)
    Vlan645, uptime: 00:00:05, mrib

So there is definitely something anomalous happening there. Not sure if it is a timer thing or bug of sorts and the impact may vary between environments and configurations. Again it may be best to take it up with Cisco.

Hope this helps.