Hi James, I also forgot to mention that we have ipf enabled on this server:
sldn2302xap:root# more /etc/ipf/ipf.conf # # $Id: ipf.conf-ib,v 1.1 2006/07/25 16:35:39 mylesst Exp $ # ##################################################################### ## ## System settings ## ## ## Stop all inbound traffic ## block in all ## ## Allow all outbound traffic, but keep state information ## pass out all keep state ## ## Allow ssh in ## pass in quick proto tcp from any to any port = 22 flags S keep state ## ## Allow ping ## pass in quick proto icmp from any to any icmp-type echo keep state ##################################################################### ## ## Application settings ## # example for incoming app traffic, replace <port> with port number #pass in quick proto tcp from any to any port <port> flags S keep state pass in quick proto tcp from any to any port = 7377 keep state # PERprisc pass in quick proto tcp from any to any port = 7439 keep state # PERprisc pass in quick proto tcp from any to any port = 24351 keep state # UBSdmzpbc # # chimera ports pass in quick proto tcp from any to any port 12199 >< 12300 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: Carey, Peter Sent: 02 March 2007 16:20 To: 'James Carlson' Cc: [email protected] Subject: RE: [networking-discuss] IGMP v3 on Solaris 10 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? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 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]
