Re: High ping latency using two ethernet under FreeBSD 4.11 ...
> Testing my network, I just noticed the following: > > --- 200.46.204.1 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max/stddev = 399.664/407.119/420.315/8.267 ms > > --- 200.46.208.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev = 373.045/409.266/453.402/33.280 ms > > 400ms to my default router seems a wee bit high ... > > I'm suspecting that it has to do with: > > Mar 15 01:13:28 neptune last message repeated 10 times > Mar 15 01:13:28 neptune /kernel: arp: 200.46.204.1 is on em0 but got reply > from 00:0b:bf:42:a8:06 on em1 > Mar 15 01:13:28 neptune /kernel: arp: 200.46.208.1 is on em1 but got reply > from 00:0b:bf:42:a8:06 on em0 > > In order to provide network redundancy, and simplify our scripting, with > have one network bound to one ethernet port, and the other network bound > to the second one on the same machine ... > > I'm plugging everything into a Cisco 2924 ... is there some way, either on > the FreeBSD side, or Cisco, of 'cleaning this up'? Try ng_fec. It works ok with 2950, not sure about 2924 though. > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High ping latency using two ethernet under FreeBSD 4.11 ...
On Tue, 15 Mar 2005, dima wrote: I'm plugging everything into a Cisco 2924 ... is there some way, either on the FreeBSD side, or Cisco, of 'cleaning this up'? Try ng_fec. It works ok with 2950, not sure about 2924 though. man page is a bit short ... what exactly is ng_fec, and how does it affect things? For instance, do I start configuring an 'ifconfig fec0' device instead of my usual fxp0? or, does everything pretty much stay the same except running that extra daemon/command? any docs other then the man pages that I should read through? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: High ping latency using two ethernet under FreeBSD 4.11 ...
> On Tue, 15 Mar 2005, dima wrote: > >>> I'm plugging everything into a Cisco 2924 ... is there some way, either on >>> the FreeBSD side, or Cisco, of 'cleaning this up'? >> >> Try ng_fec. It works ok with 2950, not sure about 2924 though. > > man page is a bit short ... what exactly is ng_fec, and how does it affect > things? ng_fec is the NetGraph module which implements Cisco FastEtherChannel technology. This actually means you have 1 virtual interface fec0 representing 2 or more physical interfaces. The load balancing scheme can be assigned by a Catalyst, but low-end models like 2950 and 3550 can only balance traffic based on the least significant bit(s) of MAC-address. > > For instance, do I start configuring an 'ifconfig fec0' device instead of > my usual fxp0? or, does everything pretty much stay the same except > running that extra daemon/command? Here comes the basic setup employed at my site: $ cat /etc/rc.local /sbin/ifconfig bge0 media 100BaseTX mediaopt full-duplex up /sbin/ifconfig bge1 media 100BaseTX mediaopt full-duplex up /usr/sbin/ngctl -f /var/fec0.conf /sbin/ifconfig fec0 inet x.x.x.x netmask 255.255.255.224 up /sbin/route add default x.x.x.x $ cat /var/fec0.conf mkpeer fec dummy fec msg fec0: add_iface "bge0" msg fec0: add_iface "bge1" msg fec0: set_mode_inet > > any docs other then the man pages that I should read through? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High ping latency using two ethernet under FreeBSD 4.11 ...
It's the case of incorrect configuration. Equal mac addresses must not exist in different ports on the same vlan on catalyst switches. They may cause problems like: http://www.ciscotaccc.com/lanswitching/showcase?case=K19174025 and, consequently, high latency. MGF> Testing my network, I just noticed the following: MGF> --- 200.46.204.1 ping statistics --- MGF> 4 packets transmitted, 4 packets received, 0% packet loss MGF> round-trip min/avg/max/stddev = 399.664/407.119/420.315/8.267 ms MGF> --- 200.46.208.1 ping statistics --- MGF> 3 packets transmitted, 3 packets received, 0% packet loss MGF> round-trip min/avg/max/stddev = 373.045/409.266/453.402/33.280 ms MGF> 400ms to my default router seems a wee bit high ... MGF> I'm suspecting that it has to do with: MGF> Mar 15 01:13:28 neptune last message repeated 10 times MGF> Mar 15 01:13:28 neptune /kernel: arp: 200.46.204.1 is on MGF> em0 but got reply from 00:0b:bf:42:a8:06 on em1 MGF> Mar 15 01:13:28 neptune /kernel: arp: 200.46.208.1 is on MGF> em1 but got reply from 00:0b:bf:42:a8:06 on em0 MGF> In order to provide network redundancy, and simplify our scripting, with MGF> have one network bound to one ethernet port, and the other network bound MGF> to the second one on the same machine ... MGF> I'm plugging everything into a Cisco 2924 ... is there some way, either on MGF> the FreeBSD side, or Cisco, of 'cleaning this up'? MGF> MGF> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) MGF> Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 MGF> ___ MGF> freebsd-net@freebsd.org mailing list MGF> http://lists.freebsd.org/mailman/listinfo/freebsd-net MGF> To unsubscribe, send any mail to MGF> "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: High ping latency using two ethernet under FreeBSD 4.11 ...
On Tue, 15 Mar 2005, dima wrote: This actually means you have 1 virtual interface fec0 representing 2 or more physical interfaces. The load balancing scheme can be assigned by a Catalyst, but low-end models like 2950 and 3550 can only balance traffic based on the least significant bit(s) of MAC-address. 'k, definitely not what I'm looking for then ... unless I'm missing something with how alias's work? Right now, I have 2 C-classes, but theyy are assigned to the interface 'on the fly' ... so, I could have something like: 200.46.204.10 200.46.208.254 200.46.208.251 200.46.204.5 and then, after being up 15 days, might need to add yet another: 200.46.208.244 now, my understanding (which may be wrong) is that when aliasing the IPs onto the interface, they pretty much need to be 'bundled' ... if: ifconfig fxp0 inet 200.46.204.2 netmask 255.255.255.0 (base server) ifconfig fxp0 alias 200.46.204.10 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.204.5 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.208.254 netmask 255.255.255.0 ifconfig fxp0 alias 200.46.208.251 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.208.244 netmask 255.255.255.255 so, I could add another 200.46.208.* to the interface, but wouldn't be able to add another 200.46.204.* to it, at least not without erasing all IPs and rebuilding the list ... If this isn't correct, please feel free to correct me ... what I'd love to be able to do is: ifconfig fxp0 inet 200.46.204.2 netmask 255.255.255.0 (base server) ifconfig fxp1 alias 200.46.208.2 netmask 255.255.255.0 (base server again) ifconfig fxp0 alias 200.46.204.10 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.204.5 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.208.254 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.208.251 netmask 255.255.255.255 ifconfig fxp0 alias 200.46.208.244 netmask 255.255.255.255 but didn't think this was doable ... So, right now, I'm using both fxp0 and fxp1, with fxp0 handling the 200.46.204.* C-class, and fxp1 handling the 200.46.208.* C-class, so that I can easily add/remove as required ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High ping latency using two ethernet under FreeBSD 4.11 ...
On Tue, 15 Mar 2005, Nikolay Kryukov wrote: It's the case of incorrect configuration. Equal mac addresses must not exist in different ports on the same vlan on catalyst switches. They may cause problems like: 'k, now I'm confused ... I hadn't noticed that, but how is it that they are 'equal'? I take it that 00:0b:bf:42:a8:06 is the MAC on the switch itself, since that machines MAC addresses are: ether 00:07:e9:05:1b:2e ether 00:07:e9:05:1b:2f does the cisco switch 'share' a mac across all ports? http://www.ciscotaccc.com/lanswitching/showcase?case=K19174025 and, consequently, high latency. MGF> Testing my network, I just noticed the following: MGF> --- 200.46.204.1 ping statistics --- MGF> 4 packets transmitted, 4 packets received, 0% packet loss MGF> round-trip min/avg/max/stddev = 399.664/407.119/420.315/8.267 ms MGF> --- 200.46.208.1 ping statistics --- MGF> 3 packets transmitted, 3 packets received, 0% packet loss MGF> round-trip min/avg/max/stddev = 373.045/409.266/453.402/33.280 ms MGF> 400ms to my default router seems a wee bit high ... MGF> I'm suspecting that it has to do with: MGF> Mar 15 01:13:28 neptune last message repeated 10 times MGF> Mar 15 01:13:28 neptune /kernel: arp: 200.46.204.1 is on MGF> em0 but got reply from 00:0b:bf:42:a8:06 on em1 MGF> Mar 15 01:13:28 neptune /kernel: arp: 200.46.208.1 is on MGF> em1 but got reply from 00:0b:bf:42:a8:06 on em0 MGF> In order to provide network redundancy, and simplify our scripting, with MGF> have one network bound to one ethernet port, and the other network bound MGF> to the second one on the same machine ... MGF> I'm plugging everything into a Cisco 2924 ... is there some way, either on MGF> the FreeBSD side, or Cisco, of 'cleaning this up'? MGF> MGF> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) MGF> Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 MGF> ___ MGF> freebsd-net@freebsd.org mailing list MGF> http://lists.freebsd.org/mailman/listinfo/freebsd-net MGF> To unsubscribe, send any mail to MGF> "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: > Julian Elischer wrote: > > Jeff wrote: > >> I'm not sure what you mean by in band. The IP address of the > >> BMC is assigned via the bios and is different from what the OS > >> later assigns. With imiptool we can turn on/powercycle/monitor > >> via the BMC assigned address up until the point where the kernel > >> loads. Once it does, the BMC no longer responds. This doesn't > >> happen with the two linux distros we've tried it on. Wtih both, > >> including SuSE, we can still query/control via the BMC using > >> ipmitool. It seems to be some sort of driver issue to me. I > >> find it confusing that the NIC is shared between the BMC and the > >> OS, but I guess that's just how it's done. Perhaps the bsd > >> broadcomm driver is simply blocking this somehow... > > > > you have to assign it the same address! > > that's not the way it's supposed to work, afaik. it'd be silly to > tie the BMC address and the OS assigned address together. you give > the BMC an ip address via a little program that comes from IBM and > this address is independent of the ip address that whatever os you > use on the system assigns to the nic. the redbook that Jung-uk > sent a link for shows this process if you're interested. I believe you are correct. If you have the same IP address, the packet reaches host OS and (I think) it must be discarded by OS. IPMI spec. is very verbose but I found very simple explanation here: http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html 'IPMI messages are encapsulated in Remote Management Control Protocol packets. RMCP is a UDP-based protocol that uses port 623 for remote system control when the system is in a pre-os or os-absent state. RMCP can also use port 664 for secure traffic.' FYI, IPMI v2.0 defines extended RMCP, so called RMCP+. > like i said earlier, having different ip addresses (the BMC's being > in private address space) works fine with the linux kernel... Just out of my curiosity, are you using bcm or tg3 driver on Linux? Thanks, Jung-uk Kim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
so i poked through the broadcom driver code for linux (http://www.broadcom.com/drivers/downloaddrivers.php) and found quite a few mentions of ASF/IPMI in the code. a little research shows that the Alert Standard Forum (ASF) defines the Remote Management Control Packet (RMCP) used in IPMI-over-LAN. see the readme for ipmitool: http://cvs.sourceforge.net/viewcvs.py/ipmitool/ipmitool/README?rev=1.2&view=markup the readme also says the address of the bmc must be the same as that of the system (as someone mentioned earlier), but i've found this not to be the case on other platforms. it makes a lot of sense to not tie the two addresses together. a change in ip unfortunateley, i'm no driver coder or i'd attempt a patch... Michael Vince wrote: Just out of interest has any one got serial console to work with this IPMI stuff? I was looking at regular 9pin serial alternatives since Dell machines normally only have 1 serial port and I prefer 2. Regards, Mike Bruce M Simpson wrote: On Mon, Mar 14, 2005 at 04:26:16PM -0800, Jeff wrote: I don't think it's the case of the OS turning off the NIC. We can access/monitor/control the chassis via the BMC fine through the bios assigned IP address when the computer is off, and when it is booting, but lose control when the kernel loads (the bios assigned ip address is, of course, different from what OS assigns). It seems odd to me how the BMC shares the NIC, but maybe this is normal...I'm new to IPMI. I can only speak for looking at the Intel gigabit chip datasheets and our em(4) driver somewhat, but there are registers which control the 'pass through' which IPMI uses. It could be that the bge driver is unaware of the registers Broadcom added to support IPMI. In this case we'd need to find out what they are and teach the driver not to meddle with them. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Jung-uk Kim wrote: On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: Julian Elischer wrote: Jeff wrote: I'm not sure what you mean by in band. The IP address of the BMC is assigned via the bios and is different from what the OS later assigns. With imiptool we can turn on/powercycle/monitor via the BMC assigned address up until the point where the kernel loads. Once it does, the BMC no longer responds. This doesn't happen with the two linux distros we've tried it on. Wtih both, including SuSE, we can still query/control via the BMC using ipmitool. It seems to be some sort of driver issue to me. I find it confusing that the NIC is shared between the BMC and the OS, but I guess that's just how it's done. Perhaps the bsd broadcomm driver is simply blocking this somehow... you have to assign it the same address! that's not the way it's supposed to work, afaik. it'd be silly to tie the BMC address and the OS assigned address together. you give the BMC an ip address via a little program that comes from IBM and this address is independent of the ip address that whatever os you use on the system assigns to the nic. the redbook that Jung-uk sent a link for shows this process if you're interested. I believe you are correct. If you have the same IP address, the packet reaches host OS and (I think) it must be discarded by OS. IPMI spec. is very verbose but I found very simple explanation here: http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html 'IPMI messages are encapsulated in Remote Management Control Protocol packets. RMCP is a UDP-based protocol that uses port 623 for remote system control when the system is in a pre-os or os-absent state. RMCP can also use port 664 for secure traffic.' FYI, IPMI v2.0 defines extended RMCP, so called RMCP+. like i said earlier, having different ip addresses (the BMC's being in private address space) works fine with the linux kernel... Just out of my curiosity, are you using bcm or tg3 driver on Linux? Thanks, Jung-uk Kim the tg3, according to lsmod. it looks like the bcm and the tg3 share common code (tigon3.c is included in the bcm source)... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: High ping latency using two ethernet under FreeBSD 4.11 ...
> On Tue, 15 Mar 2005, dima wrote: > > This actually means you have 1 virtual interface fec0 representing 2 or > > more physical interfaces. The load balancing scheme can be assigned by a > > Catalyst, but low-end models like 2950 and 3550 can only balance traffic > > based on the least significant bit(s) of MAC-address. > > 'k, definitely not what I'm looking for then ... unless I'm missing > something with how alias's work? > > Right now, I have 2 C-classes, but theyy are assigned to the interface 'on > the fly' ... so, I could have something like: > > 200.46.204.10 > 200.46.208.254 > 200.46.208.251 > 200.46.204.5 > > and then, after being up 15 days, might need to add yet another: > > 200.46.208.244 > > now, my understanding (which may be wrong) is that when aliasing the IPs > onto the interface, they pretty much need to be 'bundled' ... if: > > ifconfig fxp0 inet 200.46.204.2 netmask 255.255.255.0 (base server) > ifconfig fxp0 alias 200.46.204.10 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.204.5 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.208.254 netmask 255.255.255.0 > ifconfig fxp0 alias 200.46.208.251 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.208.244 netmask 255.255.255.255 > > so, I could add another 200.46.208.* to the interface, but wouldn't be > able to add another 200.46.204.* to it, at least not without erasing all > IPs and rebuilding the list ... > > If this isn't correct, please feel free to correct me ... what I'd love to > be able to do is: > > ifconfig fxp0 inet 200.46.204.2 netmask 255.255.255.0 (base server) > ifconfig fxp1 alias 200.46.208.2 netmask 255.255.255.0 (base server again) > ifconfig fxp0 alias 200.46.204.10 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.204.5 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.208.254 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.208.251 netmask 255.255.255.255 > ifconfig fxp0 alias 200.46.208.244 netmask 255.255.255.255 > > but didn't think this was doable ... Why not: ifconfig fxp0 inet 200.46.204.2/24 ifconfig fxp0 inet 200.46.208.2/24 alias ifconfig fxp0 inet 200.46.204.10/32 alias ifconfig fxp0 inet 200.46.204.5/32 alias ifconfig fxp0 inet 200.46.208.254/32 alias ifconfig fxp0 inet 200.46.208.251/32 alias ifconfig fxp0 inet 200.46.208.244/32 alias so on ? With the only fxp0 interface You can freely add or delete all /32 addresses while not 200.46.204.2 and 200.46.208.2 > So, right now, I'm using both fxp0 and fxp1, with fxp0 handling the > 200.46.204.* C-class, and fxp1 handling the 200.46.208.* C-class, so that > I can easily add/remove as required ... > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: High ping latency using two ethernet under FreeBSD 4.11 ...
On Tue, 15 Mar 2005 [EMAIL PROTECTED] wrote: but didn't think this was doable ... Why not: ifconfig fxp0 inet 200.46.204.2/24 ifconfig fxp0 inet 200.46.208.2/24 alias ifconfig fxp0 inet 200.46.204.10/32 alias ifconfig fxp0 inet 200.46.204.5/32 alias ifconfig fxp0 inet 200.46.208.254/32 alias ifconfig fxp0 inet 200.46.208.251/32 alias ifconfig fxp0 inet 200.46.208.244/32 alias so on ? With the only fxp0 interface Great ... I have a new server going down next week that I'll try out the ng_fec stuff with, and the above, then ... thanks ... You can freely add or delete all /32 addresses while not 200.46.204.2 and 200.46.208.2 That's cool, since those IPs are just for the base server itself, and never get removed ... Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Jeff Behl wrote: Michael Vince wrote: Just out of interest has any one got serial console to work with this IPMI stuff? I was looking at regular 9pin serial alternatives since Dell machines normally only have 1 serial port and I prefer 2. yep, we've gotten this to work, but again only with linux. it looks just like you're seeing it over the serial port...pretty click. i'm sure it'd work with bsd just as well if we could get to the bmc after the kernel loads... Using intel boards and the intel client (under linux emulation), I have done serial port redirection. slow but it works .. you can do BIOS stuff, bootloader and kernel console stuff. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Jung-uk Kim wrote: On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: Julian Elischer wrote: Jeff wrote: I'm not sure what you mean by in band. The IP address of the BMC is assigned via the bios and is different from what the OS later assigns. With imiptool we can turn on/powercycle/monitor via the BMC assigned address up until the point where the kernel loads. Once it does, the BMC no longer responds. This doesn't happen with the two linux distros we've tried it on. Wtih both, including SuSE, we can still query/control via the BMC using ipmitool. It seems to be some sort of driver issue to me. I find it confusing that the NIC is shared between the BMC and the OS, but I guess that's just how it's done. Perhaps the bsd broadcomm driver is simply blocking this somehow... you have to assign it the same address! that's not the way it's supposed to work, afaik. it'd be silly to tie the BMC address and the OS assigned address together. you give the BMC an ip address via a little program that comes from IBM and this address is independent of the ip address that whatever os you use on the system assigns to the nic. the redbook that Jung-uk sent a link for shows this process if you're interested. I believe you are correct. If you have the same IP address, the packet reaches host OS and (I think) it must be discarded by OS. IPMI spec. is very verbose but I found very simple explanation here: I simply have a firewall rule throwing those away. We have a Class -C full of those machines and if I had to duplicate the addresses I'd need 2. http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html 'IPMI messages are encapsulated in Remote Management Control Protocol packets. RMCP is a UDP-based protocol that uses port 623 for remote system control when the system is in a pre-os or os-absent state. RMCP can also use port 664 for secure traffic.' FYI, IPMI v2.0 defines extended RMCP, so called RMCP+. like i said earlier, having different ip addresses (the BMC's being in private address space) works fine with the linux kernel... Just out of my curiosity, are you using bcm or tg3 driver on Linux? Thanks, Jung-uk Kim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Julian Elischer wrote: Jung-uk Kim wrote: On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: Julian Elischer wrote: Jeff wrote: I'm not sure what you mean by in band. The IP address of the BMC is assigned via the bios and is different from what the OS later assigns. With imiptool we can turn on/powercycle/monitor via the BMC assigned address up until the point where the kernel loads. Once it does, the BMC no longer responds. This doesn't happen with the two linux distros we've tried it on. Wtih both, including SuSE, we can still query/control via the BMC using ipmitool. It seems to be some sort of driver issue to me. I find it confusing that the NIC is shared between the BMC and the OS, but I guess that's just how it's done. Perhaps the bsd broadcomm driver is simply blocking this somehow... you have to assign it the same address! that's not the way it's supposed to work, afaik. it'd be silly to tie the BMC address and the OS assigned address together. you give the BMC an ip address via a little program that comes from IBM and this address is independent of the ip address that whatever os you use on the system assigns to the nic. the redbook that Jung-uk sent a link for shows this process if you're interested. I believe you are correct. If you have the same IP address, the packet reaches host OS and (I think) it must be discarded by OS. IPMI spec. is very verbose but I found very simple explanation here: I simply have a firewall rule throwing those away. We have a Class -C full of those machines and if I had to duplicate the addresses I'd need 2. we've been assigning private addresses to the BMCs making them only reachable via a local admin host... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: High ping latency using two ethernet under FreeBSD 4.11 ...
On Tue, 15 Mar 2005, dima wrote: ng_fec is the NetGraph module which implements Cisco FastEtherChannel technology. This actually means you have 1 virtual interface fec0 representing 2 or more physical interfaces. The load balancing scheme can be assigned by a Catalyst, but low-end models like 2950 and 3550 can only balance traffic based on the least significant bit(s) of MAC-address. And this means ... ? Also, how do I confirm that my 2950 *does*, in fact, support netgraph? I see nothing in 'show version' to indicate it ... but: Cisco Internetwork Operating System Software IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA1, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Mon 12-Jul-04 08:18 by madison Image text-base: 0x8001, data-base: 0x8055C000 Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High ping latency using two ethernet under FreeBSD 4.11 ...
Marc G. Fournier wrote: On Tue, 15 Mar 2005, dima wrote: ng_fec is the NetGraph module which implements Cisco FastEtherChannel technology. This actually means you have 1 virtual interface fec0 representing 2 or more physical interfaces. The load balancing scheme can be assigned by a Catalyst, but low-end models like 2950 and 3550 can only balance traffic based on the least significant bit(s) of MAC-address. And this means ... ? Also, how do I confirm that my 2950 *does*, in fact, support netgraph? I see nothing in 'show version' to indicate it ... but: Fisrt google hit leads to this cisco doc: http://www.cisco.com/warp/public/473/4.html (yes, you can do it.. with a c2900 too) Netgraph support Cisco Fast Etherchannel, not the other way around :) -Charlie ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
On Tuesday 15 March 2005 12:42 pm, Jeff wrote: > Jung-uk Kim wrote: > >On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: > >>Julian Elischer wrote: > >>>Jeff wrote: > I'm not sure what you mean by in band. The IP address of the > BMC is assigned via the bios and is different from what the OS > later assigns. With imiptool we can turn on/powercycle/monitor > via the BMC assigned address up until the point where the > kernel loads. Once it does, the BMC no longer responds. This > doesn't happen with the two linux distros we've tried it on. > Wtih both, including SuSE, we can still query/control via the > BMC using ipmitool. It seems to be some sort of driver issue > to me. I find it confusing that the NIC is shared between the > BMC and the OS, but I guess that's just how it's done. > Perhaps the bsd broadcomm driver is simply blocking this > somehow... > >>> > >>>you have to assign it the same address! > >> > >>that's not the way it's supposed to work, afaik. it'd be silly > >> to tie the BMC address and the OS assigned address together. > >> you give the BMC an ip address via a little program that comes > >> from IBM and this address is independent of the ip address that > >> whatever os you use on the system assigns to the nic. the > >> redbook that Jung-uk sent a link for shows this process if > >> you're interested. > > > >I believe you are correct. If you have the same IP address, the > >packet reaches host OS and (I think) it must be discarded by OS. > >IPMI spec. is very verbose but I found very simple explanation > > here: > > > >http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html > > > >'IPMI messages are encapsulated in Remote Management Control > > Protocol packets. RMCP is a UDP-based protocol that uses port > > 623 for remote system control when the system is in a pre-os or > > os-absent state. RMCP can also use port 664 for secure traffic.' > > > >FYI, IPMI v2.0 defines extended RMCP, so called RMCP+. > > > >>like i said earlier, having different ip addresses (the BMC's > >> being in private address space) works fine with the linux > >> kernel... > > > >Just out of my curiosity, are you using bcm or tg3 driver on > > Linux? > > > >Thanks, > > > >Jung-uk Kim > > the tg3, according to lsmod. it looks like the bcm and the tg3 > share common code (tigon3.c is included in the bcm source)... I just glanced at bcm5700 and tg3 drivers. ;-) If my guess is correct, ASF related registers (grep -i asf *) are controlling this function. Unfortunately it doesn't seem trivial to implement something similar for bge(4). :-( Jung-uk Kim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
use of ng_fec ...
After reading up on the Cisco stuff that ng_fec is meant for, I'm curious as to whether there is a way of determining if its needed ... in my case, I have one server, two ethernets but all attaching to the same switch ... is there some way of determining if the interface(s) (on either hte FreeBSD box, or the Cisco switch) is "overly busy", that load balancing would be beneficial? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Setup of jail bound to lo0
Hi,
I need to have some jails configured, sharing single IP address (IPv6
is a no-no for the time being:). Therefore I came up with an idea of
binding them all to lo0 and assigning subsequent IP aliases as the
addresses. The requirement for the jails is to let them to receive
(the easy part) and *send* packets to the outside.
The jails cannot directly access the Internet as they cannot bind to
the external IP address of course. Some translation needs to be made,
I think. After wrestling with ipfw/ipf/pf for a couple of hours I
don't have a working solution.
My last attempt to get outside from the jail with ipfw was:
# ipfw add 200 divert natd log tcp from 127.0.0.2 to 127.0.0.2 222 in via lo0
and for natd:
redirect_port tcp 192.168.153.2:22 127.0.0.2:222
I get this log from natd:
In {default} [TCP] [TCP] 127.0.0.2:53057 -> 127.0.0.2:301 aliased to
[TCP] 127.0.0.2:53057 -> 192.168.153.2:22
Which obviously doesn't work. I've tried to add alias IP, but then it
stops the natd `rule' matching.
Net Gods, help me please, /S
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Setup of jail bound to lo0
On Wed, Mar 16, 2005 at 12:27:57AM +0100, S??awek ??ak wrote: > Hi, > > I need to have some jails configured, sharing single IP address (IPv6 > is a no-no for the time being:). Therefore I came up with an idea of > binding them all to lo0 and assigning subsequent IP aliases as the > addresses. The requirement for the jails is to let them to receive > (the easy part) and *send* packets to the outside. > > Which obviously doesn't work. I've tried to add alias IP, but then it > stops the natd `rule' matching. Hmm. This was working for me under 4.9-RELEASE: # prep/launch (build kernel with optionsIPFIREWALL optionsIPDIVERT ) # useful environment setenv JAIL_IF vr0 setenv JAIL_IP 192.168.0.1 setenv TESTJAIL /var/minjail ifconfig $JAIL_IF alias $JAIL_IP # spin up a private NAT sysctl net.inet.ip.forwarding=1 sysctl jail.set_hostname_allowed=0 ipfw add 50 divert natd all from any to any via $JAIL_IF /sbin/natd -n $JAIL_IF -log -unregistered_only # spin up the jail jail $TESTJAIL testhostname $JAIL_IP /bin/sh > Net Gods, help me please, /S > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems stopping pptp...
Sten Daniel Sørsdal wrote: Eric Schuele wrote: Alt Shift V closes the connection sudo killall -TERM ppp Have you ever tried -HUP (Hangup) ? Thank you for responding. Sorry I did not get back to you sooner, I was out of town. Yes, I have tried it... same result. Seems to me I must be doing things wrong here. And oddly, no one has responded with a solution. Odd in the sense that I would assume I am not the only one to ever have to stop a VPN connection. I had figured this to be a no brainer and that someone would immediately set me straight. All the docs/web pages/mail archives I can find all discuss starting the VPN...nothing mentions stopping. Well, that's not entirely true. I found a one entry that said to control-C it and another that said to send it a -TERM. both however produce .core on my machine. Something must be wrong. Just hoping someone can point it out. -Eric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
