Re: [networking-discuss] IGMP v3 on Solaris 10

Fri, 02 Mar 2007 13:57:11 -0800 

Hi Peter,
This issue has been reported by a few customers in the past. In all the cases that I have analysed, the problem was fixed by upgrading the firmware of the switch. This appears to be a known problem in some of the cisco switches. 


What I found in the snoop files that I analysed in all those cases is 
that the switch does not understand IGMP version 3 reports.  I assume 
that the switch is not version 3 capable.  But, when it sends an IGMP 
query, it has 12 bytes in it.  Even though this 12 byte query will be 
interpreted as a valid query by all the IGMP version 2 hosts (such as 
Solaris 8 and 9), solaris 10 will interpret this as Version 3 query as 
per RFC  3376.  So, solaris 10 host will keep sending version 3 reports 
which the switch does not understand.  This is not a problem with 
Solaris 10.  The switch has to be modified.  CISCO has a new firmware 
which will resolve this problem.



In some cases, I have seen that the switch does not send the query at 
all (in the snoops that I have seen).  Solaris 10, then will keep on 
sending IGMP version 3 reports and the switch does not understand it.



For Solaris 10 to send membership reports in version 2, it has to get 
query in version 2 as per rfc 3376.  Refer to section 7.1 of this RFC.



You may refer to a recent case (Radiance case#10970294) that we resolved 
recently.


I haven't looked at your data yet, but I hope that this information helps.

Viswa



[EMAIL PROTECTED] wrote:


Hi James,

Thanks for your quick response. We expected to see the behaviour you
describe for IGMP but we did not see the host respond to the IGMP v2

query. 

The setup we have here is router=> switch=> firewall => switch => host. 
There are other hosts on the same subnet that work. The port of the

switch is set to the same as the others 100 Full Duplex. We connect to
the LSE (London Stock Exchange) via their routers that are sited on our
premises that are set to IGMP v2.

We were not sending the output to a file at the time but here's a
fragment of what we saw at the time:

139.149.66.23 -> 233.115.135.82 IGMP v2 membership report
139.149.66.18 -> 239.99.1.66  IGMP v2 membership report
139.149.66.18 -> 239.99.1.67  IGMP v2 membership report
139.149.66.18 -> 239.99.1.68  IGMP v2 membership report
139.149.66.18 -> 239.99.1.69  IGMP v2 membership report
139.149.66.18 -> 239.99.1.70  IGMP v2 membership report
139.149.66.18 -> 239.99.1.71  IGMP v2 membership report
139.149.66.18 -> 239.99.1.72  IGMP v2 membership report
139.149.66.18 -> 239.99.1.73  IGMP v2 membership report
139.149.66.18 -> 239.99.1.74  IGMP v2 membership report
139.149.66.18 -> 239.99.1.75  IGMP v2 membership report
139.149.66.18 -> 239.99.1.76  IGMP v2 membership report
139.149.66.18 -> 239.99.1.77  IGMP v2 membership report
139.149.66.18 -> 239.99.1.78  IGMP v2 membership report
139.149.66.18 -> 239.99.1.79  IGMP v2 membership report
139.149.66.18 -> 239.99.1.80  IGMP v2 membership report
139.149.66.18 -> 239.99.1.81  IGMP v2 membership report
139.149.66.18 -> 239.99.1.82  IGMP v2 membership report
139.149.66.18 -> 239.99.1.83  IGMP v2 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report          <= This
is the Sol 10 server responding on IGMPv3
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
sldn2302xap -> 224.0.0.22   IGMP v3 membership report
139.149.66.1 -> 224.0.0.1    IGMP v2 membership query          <= Here's
the firewall sending the query but no ack
139.149.66.32 -> 233.115.135.16 IGMP v2 membership report
139.149.66.32 -> 233.115.135.17 IGMP v2 membership report
139.149.66.5 -> 233.115.135.86 IGMP v2 membership report
139.149.66.5 -> 233.115.135.87 IGMP v2 membership report
139.149.66.18 -> 239.99.1.1   IGMP v2 membership report
139.149.66.18 -> 239.99.1.2   IGMP v2 membership report
139.149.66.18 -> 239.99.1.3   IGMP v2 membership report
139.149.66.18 -> 239.99.1.4   IGMP v2 membership report
139.149.66.18 -> 239.99.1.5   IGMP v2 membership report
139.149.66.18 -> 239.99.1.6   IGMP v2 membership report
139.149.66.18 -> 239.99.1.7   IGMP v2 membership report
139.149.66.18 -> 239.99.1.8   IGMP v2 membership report
139.149.66.18 -> 239.99.1.9   IGMP v2 membership report
139.149.66.18 -> 239.99.1.10  IGMP v2 membership report
139.149.66.18 -> 239.99.1.11  IGMP v2 membership report
139.149.66.18 -> 239.99.1.12  IGMP v2 membership report
139.149.66.35 -> 233.115.135.1 IGMP v2 membership report
139.149.66.18 -> 239.99.1.13  IGMP v2 membership report
139.149.66.35 -> 233.115.135.2 IGMP v2 membership report
139.149.66.18 -> 239.99.1.14  IGMP v2 membership report


At startup our software trys to join multicast groups 233.115.135.1,
233.115.135.3, 233.115.135.4

We have about another 6 solaris servers all working on this market
(SETS) but are on Solaris 8.

The address 139.149.66.1 is the firewall's virtual IP connecting the
VLAN on which our servers connect. As you can see the IGMP v2 membership
query is going out correctly to 224.0.0.1 (all hosts) from the firewall

and a number of servers respond on IGMP v2 but not the Sol 10 server. 


However the membership report going back is NOT for IGMP v2 but for IGMP
v3.


sldn2302xap% netstat -g
Group Memberships: IPv4
Interface Group                RefCnt
--------- -------------------- ------
lo0       224.0.0.1                 1
bge1      224.0.0.1                 1
bge1:1    224.0.0.1                 1
ce0       224.0.0.1                 1

netstat -s  (IGMP only)

IGMP:
        56 messages received
         0 messages received with too few bytes
         0 messages received with bad checksum
         0 membership queries received
         0 membership queries received with invalid field(s)
         0 membership reports received
         0 membership reports received with invalid field(s)
         0 membership reports received for groups to which we belong
        56 membership reports sent

The stats above show that the host is not recognising the IGMPv2
queries, assuming this is working since the count for "membership
queries received" is zero.

We have IPMP setup on all our servers, including this Solaris 10 server.
I did "ifconfig down" the "inactive" interface and "logical" interface
but with no change in behaviour.


sldn2302xap:root# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1

       inet 127.0.0.1 netmask ff000000 
bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index

2
       inet 139.149.66.20 netmask ffffff80 broadcast 139.149.66.127
       groupname sldn2302xap

       ether 0:14:4f:4b:58:b6 
bge1:1:

flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 2
       inet 139.149.66.21 netmask ffffff80 broadcast 139.149.66.127
ce0:
flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER
,STANDBY,INACTIVE> mtu 1500 index 3
       inet 139.149.66.22 netmask ffffff80 broadcast 139.149.66.127
       groupname sldn2302xap

       ether 0:14:4f:41:fb:b0 


Are there any bugs or configurations that may explain why this server

appears to respond with IGMPv3. 



Peter Carey

Market Links Implementation Team

1 Broadgate, London 
Email:  [EMAIL PROTECTED]

Direct: +44 207 567 2112
Mobile: +44 776 496 2750
-----Original Message-----

From: James Carlson [mailto:[EMAIL PROTECTED] 
Sent: 02 March 2007 14:38

To: Carey, Peter
Cc: [email protected]
Subject: Re: [networking-discuss] IGMP v3 on Solaris 10

Peter Carey writes:

 


How do I force Solaris 10 to use IGMP v2 ? The router is set to use 
IGMP v2 and its not ours to change. Therefore I need to set our 
Solaris 10 server to use IGMP v2 since by default it uses IGMP v3.
   



Solaris 10 conforms to the standards.  Per the standards (see RFC 3376
section 7), hosts and routers speak their highest known version by
default.  If Solaris (as a host) sees an IGMPv2 or IGMPv1 query on an
interface, then it knows that there's an IGMPv2 or IGMPv1 router on that
interface, and it switches down to that version.

It's all automatic.  It's not _supposed_ to be "tuned" or need to be
modified by hand.  (But see CR 6482459.)

Asking about switching the version number implies that either you've got
broken peers that don't speak IGMPv2 correctly (and that should be
repaired), or that you're encountering some sort of bug in Solaris where
the compatibility switch isn't happening.  Is either the case?
Do you have snoop traces showing the problem?


 


------------------------------------------------------------------------


Visit our website at http://www.ubs.com


This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.



E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.

UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.

UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.

------------------------------------------------------------------------

_______________________________________________
networking-discuss mailing list
[email protected]



_______________________________________________
networking-discuss mailing list
[email protected]






















					Reply via email to