All things related to multicast

["Richard Mavrogeanes" <>]

Title: Re: Cisco IPv4 Multicast Issue

VBrick has never "intentionally" send non-standard SAP messages, but we do use some the SDP fields in novel ways. I think the question is about the keyword in the SDP, and in 2004 the firmware was changed so that the field was not empty.  Of course, not everyone upgrades, and there are thousands of VBricks out there still running with early versions of the code (some even with 1.0!).

Regards,

Rich

-----Original Message-----
From: Bill Owens []
Sent: Thursday, March 23, 2006 2:16 PM
To: Michael Forrest
Cc:
Subject: Re: Cisco IPv4 Multicast Issue

On Thu, Mar 23, 2006 at 04:21:07PM -0000, Michael Forrest wrote:
>
> Has anyone seen the following issue with Cisco router running ipv4
> multicast?
>
> The log messages just seem to be full of the following msg:-
>
> Mar 20 16:05:38 door.erg.abdn.ac.uk 299: *Mar 16 06:39:31.369 UTC:
> %MROUTE-6-UNSUPPORTED_SAP_FORMAT: Received unsupported format SAP
> message from (129.116.74.139)

Interesting. VBrick has for some time sent an intentionally non-standard SAP message, as explained a while ago on this list:

>Subject: RE: Question on SAP advertisements from VBrick 
>Date: Sun, 16 Jun 2002 22:57:44 -0400                    
>From: "Richard Mavrogeanes" <>           
>To: <>, <>   
>                                                            
>Mark,                                                        
>                                                                         
>The answer is very simple:  we support MPEG-2 transport streams and
>cisco's product is not compatible with the VBrick for MPEG-2.  We make
>some effort
to
>prevent the SAP from showing up in cisco's manager to help prevent a
>viewer
from
>thinking they can see it.

I forget what part of the announcement is munged, but it is enough to keep a standards-compliant application from displaying the VBrick-generated announcements. And in Ethereal, they show up as a 'malformed packet'.

But this particular machine is sending something else. Ethereal picks it up, but this is as far as it gets decoding it:

User Datagram Protocol, Src Port: mxxrlogin (1035), Dst Port: sapv1 (9875)
    Source port: mxxrlogin (1035)
    Destination port: sapv1 (9875)
    Length: 840
    Checksum: 0x0216 [correct]
Session Announcement Protocol
    Flags: 0x21
        001. .... = Version Number: SAPv1 or later (1)
        ...0 .... = Address Type: IPv4
        .... 0... = Reserved: Not set
        .... .0.. = Message Type: Announcement
        .... ..0. = Encryption Bit: Payload not encrypted
        .... ...1 = Compression Bit: Payload compressed
    Authentication Length: 0
    Message Identifier Hash: 0xd6bf
    Originating Source: 129.116.74.136
    The rest of the packet is compressed

Never seen that before, and I don't know which (if any) tools support it, but it is apparently in the standard. Might guess that Cisco hasn't implemented that hook in their SAP listener. . .

> The MFIB (multicast forwarding information base) seems to have a
> memory
leak
> and eventually consumes all the memory available on the router. The
> router becomes inaccessible on the console and over the network and
> requires a power cycle to recover. Although strangely enough, still
> seems to be functional (if just unaccessible).

Now that's a much bigger problem. Do you know whether the two issues are related? Are you able to run the router for a while without having it listen to SAP traffic?

Bill.

---------------------------
Rich Mavrogeanes
Founder & CTO
VBrick Systems, Inc.
direct: 1-203-303-0200
fax: 1-203-265-6750
http://www.vbrick.com
"Building Vision Across Your Network"®