All things related to multicast

[Michael Forrest <>]

Well i've just switched off the ip sap listen, so will see if the  
router stays up (as per Stig and Caren's suggestion).

It appears as tho the %MROUTE-6-UNSUPPORTED_SAP_FORMAT messages have  
stopped now, so the router isnt listening to the SAP announcements.  
Oddly enough, the same v4 multicast config running on a very old 4500  
running 12.2 had no probs.

The MFIB memory usage still seems to be climbing at the same rate  
tho, but will wait and see if the router ends up in same unusable  
state within a day or so.

Cheers for all the help and suggestions :-)

-Michael

On 23 Mar 2006, at 19:15, Bill Owens wrote:

> 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.