zebra OSPF + redistributing static
Hi I use zebra OSPFD to connect to my OSPF network. The router have 4 ethernet adapters, with diferrent subnets on them. Only one interface is connected to ospf network. So, I use "redistribute connected" option in ospf. I have such strange situation: Routes, that are distributed with "redistribute connected" are recalculated on other OSPF routers in the same area every minute. Why this is happened? Zebra - 0.92a, FreeBSD - 4.4-RELEASE. Thanks, Vladimir Girnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: zebra OSPF + redistributing static
On Thu, Jan 03, 2002 at 10:54:37AM +0200, Girnet Vladimir wrote: > Hi > > I use zebra OSPFD to connect to my OSPF network. The router have 4 ethernet > adapters, with diferrent subnets on them. > Only one interface is connected to ospf network. So, I use "redistribute > connected" option in ospf. > > I have such strange situation: Routes, that are distributed with > "redistribute connected" are recalculated on other OSPF routers in the same > area every minute. Hiya Vladimir, You should ask this question on the zebra mailing list. Take a stroll over to their web site (http://www.zebra.org) for its address. Joe msg04617/pgp0.pgp Description: PGP signature
Re: USB ethernet problem
On Wed, 2 Jan 2002, Thomas Zenker wrote: > Hi Mike, > > back from holidays... > > because this is now discussed in different threads, on -stable and > on -net, I will try to recapitulate what has happened and keep this > on -net "USB ethernet problem". > > The performance problems apeared after updating my test system from > 4.3 to 4.4 with Netgear EA101 USB/ethernet adaptor (kue driver). > Performance dropped by a factor of 10 or more. The server in all > cases was 4.4. After testing different slowstart flightsizes and > send/recv buffer sizes with ttcp the findings were, that mostly the > recvspace reduced to 16K (as in 4.3) recovered the performance. See > also my message to -stable from 2001/12/14. The usb host controller > on this system is a VIA 83C572 (UHCI). > > Now going to the final embedded hardware, the suprise was a hanging > usb driver. The strange thing is, this does not happen while testing > with ttcp, but only if the data is written to disk. The following > kernel messages are printed: > > usb0: host controller process error > usb0: host controller halted > kue0: watchdog timeout > kue0: usb error on tx: TIMEOUT > > this comes from uhci_intr() in dev/usb/uhci.c. Aparently the > usb0-messages reflect a hw status register!? This happens very > quickly with 4.4 (it is impossible to install over usb/ethernet), > but I have seen it today for the first time with 4.3 also. The usb > host controller is UHCI Intel 82371AB/EB (PIIX4). Well, since you've been able to isolate this as the cause, there's no need to run any more tcp tests with varying servers. Try changing hz, as I mentioned in the e-mail I just sent to you guys. Also, try running ttcp while seperately creating disk load (through a disk benchmark or something.) Meanwhile, watch systat -vm and see if the interrupt counts show you anything interesting. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
netgraph kernel panic
Hi, FreeBSD 4.5-PRERELEASE (as of a few days ago) is crashing consistently when I try to initiate a PPTP connection to with mpd-netgraph 3.3 (from ports). mpd ups the interface happily: mpd: [vpn] IPCP: rec'd Configure Ack #3 link 0 (Ack- Sent) mpd: IPADDR a.b.c.d mpd: [vpn] IPCP: state change Ack-Sent --> Opened mpd: [vpn] IPCP: LayerUp mpd: a.b.c.d -> a.b.c.e mpd: [vpn] IFACE: Up event mpd: [vpn] exec: /sbin/ifconfig ng0 a.b.c.d a.b.c.e netmask 0x -link0 mpd: [vpn] exec: /sbin/route add a.b.0.0 a.b.c.e -netmask 0x mpd: [vpn] IFACE: Up event ...then crashes immediately afterward with "fatal trap 12: page fault while in kernel mode". I saved the kernel core file. The panic looks like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x70 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01ca6b8 stack pointer = 0x10:0xc03f1d58 frame pointer = 0x10:0xc03f1d7c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0303f72 stack pointer = 0x10:0xc03f1b2c frame pointer = 0x10:0xc03f1b40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 24s The stack trace looks like this: #0 0xc01c78c2 in dumpsys () #1 0xc01c76e3 in boot () #2 0xc01c7ab8 in poweroff_wait () #3 0xc036c4c6 in trap_fatal () #4 0xc036c199 in trap_pfault () #5 0xc036bd83 in trap () #6 0xc0303f72 in mfs_strategy () #7 0xc01ecc6a in bwrite () #8 0xc01f2286 in vop_stdbwrite () #9 0xc01f20e1 in vop_defaultop () #10 0xc01ecfba in bawrite () #11 0xc01ffcd0 in spec_fsync () #12 0xc0303e2a in mfs_fsync () #13 0xc03022ff in ffs_sync () #14 0xc01f703b in sync () #15 0xc01c7496 in boot () #16 0xc01c7ab8 in poweroff_wait () #17 0xc036c4c6 in trap_fatal () #18 0xc036c199 in trap_pfault () #19 0xc036bd83 in trap () #20 0xc01ca6b8 in tsleep () #21 0xc01e7c75 in sb_lock () #22 0xc01e5698 in sosend () #23 0xc0225201 in ng_ksocket_rcvdata () #24 0xc021ef71 in ng_send_data () #25 0xc022c4e3 in ng_pptpgre_xmit () #26 0xc022c04c in ng_pptpgre_rcvdata () #27 0xc021ef71 in ng_send_data () #28 0xc0228638 in ng_ppp_output () #29 0xc0228186 in ng_ppp_rcvdata () #30 0xc021ef71 in ng_send_data () #31 0xc0221f26 in ng_bpf_rcvdata () #32 0xc021ef71 in ng_send_data () #33 0xc0224085 in ng_iface_output () #34 0xc02376df in ip_output () #35 0xc02390d6 in rip_output () #36 0xc023952b in rip_send () #37 0xc01e5bb3 in sosend () #38 0xc0225201 in ng_ksocket_rcvdata () #39 0xc021ef71 in ng_send_data () #40 0xc022c4e3 in ng_pptpgre_xmit () #41 0xc022cb24 in ng_pptpgre_send_ack_timeout () #42 0xc01cd515 in softclock () The kernel I'm running has all the NETGRAPH options from LINT compiled in (minus NETGRAPH_MPPC_COMPRESSION, which was commented out). I'd appreciate any help. (And have other data...my mpd configuration, etc. I don't have a full symbol table, though...my system didn't quite match up with what the Developer's Handbook said to expect. /sys/compile and /usr/sys/compile have only an empty ".keepit" after doing the "make buildkernel" / "make installkernel" thing. I did compile with the DEBUG=-g line uncommented in my kernel config file. Thanks a lot, Scott Lamb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netgraph kernel panic
Scott Lamb writes:
> FreeBSD 4.5-PRERELEASE (as of a few days ago) is crashing consistently
> when I try to initiate a PPTP connection to with mpd-netgraph 3.3 (from
> ports).
This is due to a problem caused by the peer's "outside" PPTP IP address
(the one from mpd.links) being equal to its "inside" IP address (the
one from "set ipcp ranges ...").
Make those different and it should stop crashing. Also, apply
the patch below to prevent it from happening again.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: ipcp.c
===
RCS file: /home/cvs/archie/mpd/src/ipcp.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ipcp.c 2001/04/12 17:03:31 1.2
+++ ipcp.c 2001/12/16 03:47:25 1.3
@@ -19,6 +19,7 @@
#include "custom.h"
#include "msg.h"
#include "ngfunc.h"
+#include "pptp.h"
#include
#include
@@ -607,7 +608,7 @@
switch (mode) {
case MODE_REQ:
if (!IpAddrInRange(&ipcp->conf.peer_allow, *ip) || !ip->s_addr) {
- if (ipcp->peer_addr.s_addr == 0)
+nak_ip:if (ipcp->peer_addr.s_addr == 0)
Log(LG_IPCP, (" %s", "no IP address available for peer!"));
if (Enabled(&ipcp->conf.options, IPCP_CONF_PRETENDIP)) {
Log(LG_IPCP, (" pretending that %s is OK, will ignore",
@@ -620,6 +621,17 @@
Log(LG_IPCP, (" NAKing with %s", inet_ntoa(*ip)));
FsmNak(fp, opt);
break;
+ }
+ if (bund->links[0]->phys->type == &gPptpPhysType) {
+ struct in_addr pip;
+
+ lnk = bund->links[0];
+ pip = PptpGetPeerIp();
+ if (ip->s_addr == pip.s_addr) {
+ Log(LG_IPCP,
+ (" Same as PPTP IP; would cause routing loop"));
+ goto nak_ip;
+ }
}
Log(LG_IPCP, (" %s is OK", inet_ntoa(*ip)));
ipcp->peer_addr = *ip;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
PPPoE and "carrier" lost?
We just got a DSL connection and I am having a slight problem with ppp/PPPoE not recognizing a lost connection and renegotiate a new IP address. For example, if I reboot the DSL modem or unplug/plug the line back in where the remote ppp connection is lost, ppp doesn't recognize this and still associates the old IP address with tun0. Isn't PPPoE supposed to recognize a "carrier" lost? It seems to never notice when I reboot the DSL modem (or just turn it off). This is obviously not ideal if the remote ppp session ever went down. Any suggestions? This is what we have: 1) FreeBSD -stable (4.5-PRE) 2) Alcatel 1000 Ethernet DSL modem, connected to xl0 3) internal network connected to fxp0 4) my ppp.conf looks like this: DSL: set device PPPoE:xl0 # set MRU 1490 # set MTU 1490 set authname ... set authkey ... set dial set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # set cd off # set crtscts off 5) ifconfig -a looks like this: tim@gw [1:23am] ~ > ifconfig -a xl0: flags=8843 mtu 1500 ether 00:c0:4f:bf:13:4c media: Ethernet autoselect (10baseT/UTP) status: active fxp0: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0x broadcast 192.168.255.255 ether 00:d0:b7:18:f8:82 media: Ethernet autoselect (10baseT/UTP) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 ppp0: flags=8010 mtu 1500 tun0: flags=8051 mtu 1492 inet 66.165.196.231 --> 66.165.196.1 netmask 0xff00 Opened by PID 659 Thanks! Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
