Sounds like we have the same issue then. Do your routes show up
correctly in the system routing table? What kind of hardware are you
using? I'm running a dell 1950 with dual dual-core 3.0 Xeons and 8
gig of ram. No PCI cards, all onboard broadcom NICs.
------------------
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
404.478.2790
www.sheltonjohns.com
On Nov 6, 2007, at 5:58 AM, David Pearce wrote:
> I have found that VC3 is very fussy about adding routes. Changing an
> interface and deleting the node followed by recreating it with new
> settings leads to no routing table entries for me.
> I have found that the only way to get a correct table is to start
> from a
> clean format
>
> David
>
> Aubrey Wells 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
>>
>>
>
> _______________________________________________
> 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
