Michael F. Biniasz | 1 Sep 2006 01:18
Picon

Re: Capturing loopback traffic

Laxmi,

thank you for keeping me in the loop.

mike b.

Laxmi Prasad Botla wrote:

>Hi Phil,
>
>Thanks for the reply, I have gotten back to my clients with the time-line.
>Since my clients are insisting that we provide loop back support in our
>product, could you please suggest if there is any alternative approach to
>support Loop back in current release of Solaris 10 (with out ipnet and pf
>hooks).
>Regards,
>Laxmi
>
>-----Original Message-----
>From: Philip Kirk - Solaris Sustaining [mailto:phil.kirk@...]
>Sent: Thursday, July 27, 2006 9:03 PM
>To: Laxmi Prasad Botla
>Cc: networking-discuss@...
>Subject: Re: [networking-discuss] Capturing loopback traffic
>
>Hi Laxmi,
>
>  
>
>>Would it be possible for you to provide some rough estimates for the
(Continue reading)

Picon

Re: Capturing loopback traffic

Hi Laxmi,

Sorry I can't think of any easy supported way of doing this now. Perhaps
someone else on the list may have some suggestions.

Phil
Bernd Schemmer | 2 Sep 2006 13:03
Picon
Picon

Re: Source based routing ?

Hi,

>>Are the clients directly attached to the same network as the
>>interfaces A and B or are clients behind a router that
>>connects to the network with both A and B?

At this time they are connected to the same network; but in future there may be clients connected through a
router also.

>>Can I ask what the specific reason for wanting all traffic for
>>a specific client to use the same interface is? Normally we
>>find people using interfaces like this for redundency purposes
>>and so it can be appropriate to use IPMP or link aggregation
>>(if supported by the driver) and let Solaris do the load
>>spreading across the interfaces as required.

Example:

There's an Backup Server running on the server with multiple network cards in the same network (for example
bge0 and bge1). Some Clients of the server are important and some not.

Now we want to make sure, that theres is always enough network bandwidth for the important clients  to backup
there data. Therefor our goal is to configure bge0 to only serve the important clients; all other clients
should only connect via bge1 - even if bge0 is doing nothing. We can configure this on the clients via the IP
address of the backup server to use but we also need to make sure that the server uses the right interface to
answer the requests of the clients.

Can this be done with only one network? Or do we have to configure to different networks to get it working?

regards
(Continue reading)

Bernd Schemmer | 2 Sep 2006 13:24
Picon
Picon

Correct usage of the ifconfig option usesrc

A I understand it I can use the usesrc option of the ifconfig command and a vni interface to configure the
default source address used for a network interface with multiple IP addresses in OpenSolaris/Solaris 10.

And in my understanding to use this feature I must configure the desired IP address twice - once for the
"physical interface" (bge0, bge0:1 or something like this) and once for the vni interface.

e.g.

(bash):root <at> ferrari:/root # ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
vni0: flags=20010100c0<RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 2
        inet 192.168.178.202 netmask ffffff00
bge0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 3
        inet 192.168.178.101 netmask ffffff00 broadcast 192.168.178.255
        ether 0:c0:9f:f4:6a:3c
bge0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 192.168.178.202 netmask ffffff00 broadcast 192.168.178.255
bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 192.168.178.245 netmask ffffff00 broadcast 192.168.178.255

In this example I want to use the IP address 192.168.178.202 as default source address for outbound IP
traffic on the bge0 interface.

Now a 

ifconfig bge0 usesrc vni0

should do it.

(Continue reading)

Darren Reed | 2 Sep 2006 17:45
Picon

Re: Re: Source based routing ?

HI Bernd,

Bernd Schemmer wrote:

>Hi,
>...
>Example:
>
>There's an Backup Server running on the server with multiple network cards in the same network (for
example bge0 and bge1). Some Clients of the server are important and some not.
>
>Now we want to make sure, that theres is always enough network bandwidth for the important clients  to
backup there data. Therefor our goal is to configure bge0 to only serve the important clients; all other
clients should only connect via bge1 - even if bge0 is doing nothing. We can configure this on the clients
via the IP address of the backup server to use but we also need to make sure that the server uses the right
interface to answer the requests of the clients.
>
>Can this be done with only one network? Or do we have to configure to different networks to get it working?
>  
>

It sounds like what you really need here is access to Crossbow's
bandwidth management that is currently being developed.  You
can find more information about Crossbow at:

http://www.opensolaris.org/os/project/crossbow/

Darren

(Continue reading)

Ashish Mehta | 5 Sep 2006 18:37
Picon

Re: Correct usage of the ifconfig option usesrc

Bernd Schemmer wrote:
> A I understand it I can use the usesrc option of the ifconfig command and a vni interface to configure the
default source address used for a network interface with multiple IP addresses in OpenSolaris/Solaris 10.
> 
> And in my understanding to use this feature I must configure the desired IP address twice - once for the
"physical interface" (bge0, bge0:1 or something like this) and once for the vni interface.
> 
> e.g.
> 
> (bash):root <at> ferrari:/root # ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
>         inet 127.0.0.1 netmask ff000000
> vni0: flags=20010100c0<RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 2
>         inet 192.168.178.202 netmask ffffff00
> bge0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 3
>         inet 192.168.178.101 netmask ffffff00 broadcast 192.168.178.255
>         ether 0:c0:9f:f4:6a:3c
> bge0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
>         inet 192.168.178.202 netmask ffffff00 broadcast 192.168.178.255
> bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
>         inet 192.168.178.245 netmask ffffff00 broadcast 192.168.178.255
> 
> In this example I want to use the IP address 192.168.178.202 as default source address for outbound IP
traffic on the bge0 interface.
> 
> Now a 
> 
> ifconfig bge0 usesrc vni0
> 
> should do it.
(Continue reading)

Peter Lees | 6 Sep 2006 08:02

cisco vpn client?

hi folks,

has any progress been made in persuading cisco to produce a VPN client for solaris x86 ?

any pointers to the best customer feedback options? 

thanks

p

 
This message posted from opensolaris.org
Eric Boutilier | 7 Sep 2006 03:23
Picon

Overview (rollup) of recent activity on networking-discuss

For background on what this is, see:

     http://www.opensolaris.org/jive/message.jspa?messageID=24416#24416
     http://www.opensolaris.org/jive/message.jspa?messageID=25200#25200

=============================
networking-discuss 08/16 - 08/31
=============================

Size of all threads during period:

Thread size     Topic
-----------     -----
       9       Driver for ASUS A8N-VM CSM NIC
       7       Source based routing ?
       7       Code Reviews status
       6       Announcing the CrossBow early access bits on OpenSolaris
       5       IP/TCP/UDP MIB High Level Design Doc
       5       How to grab packet counters per logical interface?
       4       ipaddrsel.conf and IPv4
       4       DHCP related changes to NWAM
       3       snoop default interface
       3       how trunking work with the other nic like vmware nic
       3       SIP Code review request [8/17/2006 - 9/1/2006]
       3       Early DHCPv6 high-level design draft
       2       Updated DHCP changes
       2       Capturing loopback traffic
       1       problem with GLDV3 bge interface
       1       ipf: two NIC, two ISPs, one web server, how to configure
       1       Solaris socket bind() behavior
(Continue reading)

Michael Kennedy | 7 Sep 2006 06:54
Gravatar

b46 Problems with Integrated e1000g NIC on Asus P4P800 MB

I'm having sporadic performance/availability issues in OpenSolaris b46 with the e1000g NIC on my Asus
P4P800 machine.  I've done a whole net-new install to upgrade from b37, which previously worked just fine,
though unfortunately through the method that I chose to upgrade I have destroyed all evidence I could post
to prove it. 

Inspecting the /var/adm/messages, I see the up/down messages repeating, and I am absolutely certain
theres nothing wrong with cables/switches.  There is also a notice about IRQ/interrupt problems when I
see the device being initialized, though I'm not certain what I can do to resolve this conflict, as none of
that is configurable via BIOS.

Any advice?  I've searched both the forums and the web via Google, and I've seen another post with the same
issue, but no one had responded.  I'm hoping someone can point my nose in the right direction.

Thanks in advance.

MK

Excerpt from /var/adm/messages:
Sep  7 00:29:47 shaolin e1000g: [ID 801593 kern.notice] NOTICE: pci8086,1019 - e1000g[0] : Adapter copper
link is down.
Sep  7 00:29:50 shaolin e1000g: [ID 801593 kern.notice] NOTICE: pci8086,1019 - e1000g[0] : Adapter
1000Mbps full duplex copper link is up.
Sep  7 00:32:29 shaolin last message repeated 3 times
Sep  7 00:32:50 shaolin e1000g: [ID 801593 kern.notice] NOTICE: pci8086,1019 - e1000g[0] : Adapter
1000Mbps full duplex copper link is up.

Excerpt from dmesg:
Sep  6 23:45:56 shaolin mac: [ID 469746 kern.info] NOTICE: e1000g0 registered
Sep  6 23:45:56 shaolin unix: [ID 954099 kern.info] NOTICE: IRQ18 is being shared by drivers with different
interrupt levels.
(Continue reading)

Dan Groves | 7 Sep 2006 16:04
Picon

Announcing Clearview build 47

Hello everyone,

On behalf of the Clearview team, I'm announcing the release of Clearview 
build 47.  This build includes the Nemo MAC type plugin and the ability 
to snoop on /dev/lo0.  It was based on ON build 47.  Pointers to the 
build and release notes for the build are at:

http://www.opensolaris.org/os/project/clearview/downloads/

If you have any problems or discover any bugs, please send mail to 
clearview-discuss@...  We'd like to keep Clearview specific 
traffic on networking-discuss@... down to a minimum. 
However, we will sentd announcements for future builds to both lists.

thanks,
Dan


Gmane