Re: ifconfig down but routing still tries to use the interface's routes

nounce the connected route via BGP even though the interface was down. I haven't tested this lately. On Fri, Apr 8, 2016 at 11:15 AM, Stuart Henderson wrote: > On 2016/04/08 10:05, Doran Mori wrote: > > Could you give an example of how that it could cause a routing loop? > >

ifconfig down but routing still tries to use the interface's routes

Running 5.9. I have x.x.141.0/25 that's directly connected. With x.x.141.0/24 reachable via bgp. # route -n get x.x.141.13 route to: x.x.141.13 destination: x.x.141.0 mask: 255.255.255.128 interface: em3 if address: x.x.141.112 priority: 4 (connected) flags: # ifconfig em3

GRE tunnel with both endpoints in the same subnet

gre0: flags=9011 mtu 1476 priority: 0 groups: gre physical address inet 192.168.1.2 --> 192.168.1.1 inet 10.1.32.2 --> 10.1.32.1 netmask 0x ping replies are not seen, sniffing gre0 interface shows icmp requests dmesg shows: arpresolve: 192.168.1.1: route wit

Re: ospfd and testing link flapping

n Sat, Sep 28, 2013 at 12:58 AM, Sebastian Benoit wrote: > > Hi, > > thanks for your bug report. > > We'll be looking into this. Please be patient though. > > /Benno > > > Doran Mori(dhm...@gmail.com) on 2013.09.25 19:10:53 -0700: > > I have an OpenBSD b

ospfd and testing link flapping

I have an OpenBSD box running 5.3 with multiple nics. When I ifconfig down one of the transit links ospfd adds another route instead of changing because the route is marked down in the kernel. When I ifconfig up the link the original route and new one are both installed in the routing table now. I

Mysterious dynamic route appearance

Serious divide by zero going on in my head. Need some helps. To reproduce on OpenBSD 4.6: openbsd box A em0 <> em0 openbsd box B (lo1 192.168.13.1/32) boxA# ifconfig em0 192.168.0.1/24 boxB# ifconfig em0 192.168.0.2/24 boxB# ifconfig lo1 192.168.13.1/32 boxA# route add 192.168.13.0/24 192.1

Re: bgpd help!!

On Tue, Dec 15, 2009 at 5:25 PM, Stuart Henderson wrote: > On 2009-12-16, Doran Mori wrote: >> Have you tried looking at the filter rules in bgpd.conf(5)? >> >> Off the top of my head something like: >> deny to { AS 65xxx } > > the OP is probably looking for

Re: bgpd help!!

Have you tried looking at the filter rules in bgpd.conf(5)? Off the top of my head something like: deny to { AS 65xxx } dmo

Re: No RTF_UP after route change to an interface that is up

> This is not correct and expains why you had to change radix_mpath.c. > If you change the rt_priority you must rebalance the dupedkey list so that > the order remains correct. It is also only necessary when the ifp changes. > So here is what I came up with that is totaly untested and maybe wrong a

Re: kernel route states and passing ~RTF_UP-routed traffic through working routes

Having stuck my head into the kernel routing code for a few weeks now I thought I would take a look at this problem since it partially affects what I'm trying to do. I don't think it's good idea to delete the downed routes. You'll need something to add the statics back when the interface comes ba

Re: No RTF_UP after route change to an interface that is up

I was wrong. I just looked at rtalloc_mpath in the multipath code and realized what I touched is probably going to break this now. Should I be flipping RTF_MPATH flags when I'm flipping RTF_UP flags? dmo

Re: No RTF_UP after route change to an interface that is up

I missed handling RTM_CHANGES with my changes. BTW I just finished testing what wasn't working right with my ospfd setup before and now everything is working properly. Yipee! dmo Index: rtsock.c === RCS file: /cvs/src/sys/net/rtsock

Re: add example -ifp usage to route man page

> hi. i've talked to claudio a bit about this, and i think it's not gonna > go in. the man page is fairly clear that ifp is the interface name, and > -ifa its address. if you look closely you'll see that, for better or for > worse, the whole page is written in that style. i'm not sure that the > te

Re: No RTF_UP after route change to an interface that is up

I finished the patch dealing with both RTF_UP and RTP_DOWN. I've tested as best as I could. I'm not currently using ECMP but I don't think anything I've touched would have changed how that works. Forgive me if I'm not going about things the right way. This is my first attempt at hacking on the

add example -ifp usage to route man page

Sorry I'm not man enough...err savvy enough to know the man page ways to write the needed lingo. Could somebody update the man page for route with the following gist: In a change or add command where the destination and gateway are not suf- ficient to specify the route, the -ifp or -ifa

Re: No RTF_UP after route change to an interface that is up

Here's the patch for making the RTF_UP show up properly when changing a gateway from/to an up/down link. --- /usr/src/sys/net/rtsock.c Tue Dec 1 00:36:58 2009 +++ rtsock.cMon Dec 7 23:36:20 2009 @@ -641,6 +641,19 @@ report: } } +

No RTF_UP after route change to an interface that is up

Hello, I'm running OpenBSD 4.6-current Dec 1. Given that you have a host or a network that you can reach from two different interfaces from OpenBSD. #netstat -rn -f inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 192.168.10.100 192.1

More than 2 RTM_IFINFOs for ifconfig down/up

Hello misc, I'm running OpenBSD 4.6-current Dec 1. #ifconfig em0 down #route monitor got message of size 208 on Sun Dec 6 00:49:46 2009 RTM_IFINFO: iface status change: len 208, if# 1, name: em0, link: active, flags: Note UP flag is removed but RUNNING flag is still there. Not sure if that mat