Hmm. I've never seen this with interfaces, but maybe it's a VIF issue.
Try setting the global log level to debug; maybe there's more information below
warning level.
And, of course, that's what support is for - they're GOOD with puzzles
like this!!
Justin
On Nov 5, 2007 9:43 PM, Aubrey Wells <[EMAIL PROTECTED]> wrote:
> It is the next hop. To give you one of the scenarios:
>
> Added 8.17.X.253 /30 to eth0 vif 1180
>
> subnet doesnt show up in vyatta's routing table (show route) but does
> show up in the system table (route -n) and I can ping the other side
> (8.17.X.254) both from within xorp and from the unix shell.
>
> So then I add a static route for 3 subnets pointing to the (directly
> connected) route of the other side of that /30 (8.17.X.254). show
> route from xorp says its next hop is my default route. show
> configuration shows that I didnt screw up i did in fact do what i
> meant to. the system routing table (route -n) says the same thing as
> the xorp table (that i configured it to be the same as the default
> route). So the route doesnt work, and what's worse, is if I try to
> delete it from the config (delete protocols static 216.32.X.0/20 next-
> hop 8.17.X.254) it tells me I cant delete a non-existant route. If I
> try to put what it thinks the route is, it says the node doesnt
> exist. I have to delete the offending line from the config file with
> vi and reboot (or load config.boot now that I know that) to get it
> back to a state where I can work with it. And this pesky line shows
> up in the log. I dont see anything interesting in any other logs that
> I know about:
>
> > Nov 4 01:49:47 vyatta xorp_fea: [ 2007/11/04 01:49:47 WARNING
> > xorp_fea FEA
> > ] Got update for address no in lib
> > feaclient tree: eth0.1180/eth0.1180/8.17.X.253
>
>
> THe other scenario:
> IP 8.17.X.113 /28 exists on eth1 vif 1192. I remove it and commit.
> Its gone out of both the system and xorp routing tables. i read it as
> 8.17.X.113 /29 and commit. It doesnt show up in the xorp table, but
> it is in the system table. I get the same log message as above and my
> system hates me for it. The route works (i can ping the other side)
> but I can't configure any services to use it. :-(
>
>
> *sigh* Any ideas?
>
> I searched bugzilla, and only came up with bug 1602, which appears to
> be the exact opposite of my issue. I'm going to try to reproduce on a
> dev box and use my subscription support to see if one of you guys can
> log in to it and poke around.
>
>
> ------------------
> Aubrey Wells
> Senior Engineer
> Shelton | Johns Technology Group
> A Vyatta Ready Partner
> www.sheltonjohns.com
>
>
>
>
>
> On Nov 6, 2007, at 12:08 AM, Justin Fletcher wrote:
>
> > No problem - I know exactly how you feel some days!
> >
> > And I'd missed the point that it didn't make into the system route
> > table, so the
> > first question I'd ask is whether the next hop you're specifying is
> > directly connected?
> > If it isn't, try using the IP address of the directly connected
> > next hop router.
> >
> > If it is, well, there's a bit more to figure out, as I've never seen
> > that behavior.
> >
> > To try a rephrase on the load config command, it'll make your running
> > configuration
> > match the configuration in the file (usually :-) )
> >
> > Justin
> >
> > On Nov 5, 2007 8:52 PM, Aubrey Wells <[EMAIL PROTECTED]> wrote:
> >>
> >> Thanks for the response - sorry for my impatience. :-)
> >>
> >> I dont mind the viewing discrepancy, its the fact that vyatta doesn't
> >> recognize the existance of the routes - so I can't do anything
> >> with them. So
> >> you're saying load config.boot should fix the problem? Will that
> >> cause any
> >> downtime while it rereads the config, or should it be seamless?
> >>
> >> Also... maybe its just because its been a really long day, but
> >> this sentence
> >> doesn't make any sense:
> >>
> >> "it'll remove everything that's not in the current configuration
> >> that's in
> >> the config file, and add the new commands from the config file."
> >>
> >> Could you possibly rephrase for me? :-)
> >>
> >>
> >>
> >> ------------------
> >> Aubrey Wells
> >> Senior Engineer
> >> Shelton | Johns Technology Group
> >>
>
> >> www.sheltonjohns.com
> >>
> >>
> >>
> >>
> >>
> >> On Nov 5, 2007, at 11:31 PM, Justin Fletcher wrote:
> >>
> >> Good questions - I think you're just seeing a synchronization issue.
> >>
> >> If you see it in the system route table ("route -n" from the Linux
> >> shell or "show route system forward" from the CLI) it's really in the
> >> system RIB as the forwarding information base is updated from the
> >> RIB.
> >> However, "show route" looks at a different table, and can be somewhat
> >> out of sync.
> >>
> >> So - if you see the route from "show route system forward" it made it
> >> into the route tables correctly - you're just seeing a viewing
> >> discrepancy issue.
> >>
> >> Also, you can load the configuration using "load config.boot" in
> >> config mode; it'll remove everything that's not in the current
> >> configuration that's in the config file, and add the new commands
> >> from
> >> the config file.
> >>
> >> Best,
> >> Justin
> >>
> >> On Nov 5, 2007 8:08 PM, Aubrey Wells <[EMAIL PROTECTED]> wrote:
> >> Anyone? :-(
> >>
> >>
> >>
> >> ------------------
> >> Aubrey Wells
> >> Senior Engineer
> >> Shelton | Johns Technology Group
> >> 404.478.2790
> >> www.sheltonjohns.com
> >>
> >>
> >>
> >>
> >>
> >> On Nov 3, 2007, at 10:16 PM, Aubrey Wells wrote:
> >>
> >>
> >> Hi,
> >> I'm having this really frustrating problem where occasionally I
> >> will add an
> >> ip/network to vyatta, or delete an ip and readd it to the same
> >> interface
> >> with a different prefix-length or move it to a different interface
> >> (with a
> >> commit in between) and vyatta will not recognize that the ip/
> >> network has
> >> been added.
> >>
> >> For instance, this evening, I was attempting to add 8.17.X.253 /30 to
> >> interface eth1 on vif 1180. If i look at the system routing table,
> >> it is
> >> added on the correct interface and traffic passes to the host on
> >> the other
> >> side. But if I do a "show route" in vyatta the subnet is not there
> >> and as
> >> such, if I try to point a static route at it, the route instead
> >> gets added
> >> to whatever my default route is. for example:
> >>
> >> set protocols static route 1.2.3.0/8 next-hop 8.17.X.254
> >>
> >> that gets added to the config file fine, but a "show route" shows
> >> it having
> >> a next hop of my default route. The system routing table does the
> >> same.
> >> Also, I cannot delete this route from the config without doing it
> >> by hand
> >> with VI and rebooting (says the route doesnt exist).
> >>
> >> Also, I tried to remove 8.17.X.113 /28 and readd it as 8.17.X.113 /
> >> 27. I
> >> removed the ip, commited, and readded it. The subnet didnt show up
> >> in the
> >> vyatta routing table after a commit but it was in the system
> >> routing table
> >> (route -n). Traffic passed just fine.
> >>
> >> When I commit those changes, I see this in the messages log:
> >>
> >> Nov 4 01:49:47 vyatta xorp_fea: [ 2007/11/04 01:49:47 WARNING
> >> xorp_fea FEA
> >> ] Got update for address no in lib
> >> feaclient tree: eth0.1180/eth0.1180/8.17.X.253
> >>
> >> Nov 4 01:49:47 vyatta xorp_fea: [ 2007/11/04 01:49:47 WARNING
> >> xorp_fea FEA
> >> ] Got update for address no in lib
> >> feaclient tree: eth1.54/eth1.54/8.17.X.113
> >>
> >> If I save the config, and reboot the box, the configuration loads
> >> up just
> >> fine and all my subnets/routes are correct. This is not a
> >> solution, as this
> >> is my core router in a fast-growing network and I cant go around
> >> rebooting
> >> it every time I add a subnet.
> >>
> >> I'm running the last VC3 beta. (I havent upgraded to VC3 release
> >> because I
> >> didnt want to reboot the box without scheduling a window.... heh)
> >>
> >> This also happened in VC2.2. I'm not 100% sure about weather or
> >> not it
> >> happens on a PHY, but I think it did, although most of my stuff is
> >> on VIFs.
> >>
> >> Please help!
> >>
> >> Oh, and is there a way to get it to dump and reload the config
> >> from scratch
> >> without rebooting? These DELL's have a horrendous POST time
> >> because of the
> >> RAID, DRAC, and BMC BIOSes that all have to load (plus the
> >> overhead of
> >> checking 8G of memory)!
> >>
> >>
> >> ------------------
> >> Aubrey Wells
> >> Senior Engineer
> >> Shelton | Johns Technology Group
> >> A Vyatta Ready Partner
> >> www.sheltonjohns.com
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Vyatta-users mailing list
> >> Vyatta-users@mailman.vyatta.com
> >> http://mailman.vyatta.com/mailman/listinfo/vyatta-users
> >>
> >> _______________________________________________
> >> Vyatta-users mailing list
> >> Vyatta-users@mailman.vyatta.com
> >> http://mailman.vyatta.com/mailman/listinfo/vyatta-users
> >>
> >>
> >>
> >>
>
>
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
