Hi Aubrey,

I'll find out from Rick, the developer here who works with the serial 
integration, if there is a preferred method for scripting this.  I'll 
reply back to this list when I speak with him.  I would just copy the 
files into /etc/wanpipe and run a wanrouter restart on boot.  You should 
remove them from the config if you do this.

As far as a permanent solution, Rick tells me that PPPD will not create 
routes with prefixes other than /32.  I'm thinking the solution right 
now is to only use PPPD for MLPPP and continue to use the Sangoma driver 
for PPP w/o MLPPP.  I'm sure they (the developers) will think of 
something.  To help get the "thinking" started, I've bumped up the 
priority on the bug.

So for now, Rick doesn't have a better solution than the one I gave 
you.  Sorry :-(

-Robyn

Aubrey Wells wrote:
> That worked perfectly. All my routes point to the correct place and 
> BGP doesn't hate me now. :-)
>
> Let me know if you figure out a more permanent solution, but this will 
> work for now. I'm assuming I need to remove all the serial config from 
> vyatta to keep my changes to the configs from being overwritten? Or 
> will I need to script out some sed commands and restart wanrouter from 
> rc.local on boot regardless of what's in the vyatta config?
>
>
>
> ------------------
> Aubrey Wells
> Senior Engineer
> Shelton | Johns Technology Group
> A Vyatta Ready Partner
> www.sheltonjohns.com
>
>
>
>
> On Nov 30, 2007, at 5:05 PM, Robyn Orosz wrote:
>
>> Hi Aubrey,
>>
>> Thanks for trying that and I'm sorry it still didn't resolve the issue.
>> This problem does not exist in pre-VC3 versions.  With your
>> configuration as it is, everything should work fine in 2.2.  If you need
>> to use VC3, you can kill the pppd process and reconfigure the Sangoma
>> driver to run PPP.  I'm still looking into another way to manipulate
>> pppd so that it will accept a netmask value but if you'd like to try the
>> Sangoma workaround you'll need to:
>>
>> 1. Edit the /etc/wanpipe/wanpipe1.conf file:
>>
>> change:
>>     wan0.1 = wanpipe1, 0, TTY, tty, wan0.tty
>>        to
>>    wan0.1 = wanpipe1, 1, WANPIPE, ppp, wan0.ppp
>>
>> then change:
>>    [wan1.tty]
>>       to
>>    [wan0.ppp]
>>    PAP = NO
>>    CHAP = NO
>>
>> 2. Edit the /etc/wanpipe/interfaces/wan0.1 file:
>>
>> It should be empty so you'll need to add:
>>    DEVICE=wan0.1
>>    IPADDR=64.211.X.34
>>    NETMASK=255.255.255.252
>>    POINTOPOINT=64.211.X.33
>>    ONBOOT=yes
>>
>> 3. Then run a 'wanrouter restart'
>>
>> I tested this here and it worked for me by bringing the wan0.1 /30 route
>> into the xorp routing table.
>>
>> If you do decide to use VC3 and run ppp via the Sangoma driver, all of
>> the above will need to be scripted so it will be re-added on boot.
>>
>> I know this is not the best workaround but give it a try if you're up to
>> it and I'll still see if I can come up with anything better in the mean
>> time.
>>
>> Thanks,
>>
>> Robyn
>>
>>
>> Aubrey Wells wrote:
>>> Adding it from the shell gets the /30 into the system routing table,
>>> but not into vyatta's routing table, so my bgp routes still don't
>>> work, and creating any static routes doesnt work from within vyatta.
>>> I'm going to try recreating the bgp routes from the command line and
>>> see if I can at least get the traffic flowing.
>>>
>>> ------------------
>>> Aubrey Wells
>>> Senior Engineer
>>> Shelton | Johns Technology Group
>>> A Vyatta Ready Partner
>>> www.sheltonjohns.com
>>>
>>>
>>>
>>>
>>> On Nov 30, 2007, at 2:20 PM, Robyn Orosz wrote:
>>>
>>>> Hi Aubrey,
>>>>
>>>> I cannot get any of the pppd 'netmask' parameters to take effect.  
>>>> We'll
>>>> definitely look into that.  In the mean time, can you try adding a 
>>>> route
>>>> instead of changing the netmask via ifconfig:
>>>>
>>>> route add -net 64.211.X.32 netmask 255.255.255.252 wan0.1
>>>>
>>>> We have recursive routing enabled in VC3 and that's why the next-hops
>>>> for your routes are being translated to the default route 
>>>> next-hop.  The
>>>> eBGP next-hop is considered recursive because it's a host route (not
>>>> directly connected).  Without the recursive routing enabled, I'm 
>>>> pretty
>>>> sure your BGP session would not even come up which is what is 
>>>> indicated
>>>> in comment #2 in bug 2332.  Also, since recursive routing is 
>>>> enabled, if
>>>> I add a similar route (above) via the CLI, it adds it in as a static
>>>> recursive route so instead translates the next-hop to the default 
>>>> route
>>>> value.
>>>>
>>>> Anyway, let me know if just adding the route via the bash shell 
>>>> does any
>>>> good.
>>>>
>>>> Thanks again,
>>>>
>>>> Robyn
>>>>
>>>> Robyn Orosz wrote:
>>>>> This worked for me here but I have control over the other side (it's
>>>>> just another Vyatta with another Sangoma card in it).  I am assuming
>>>>> the
>>>>> other side of your connection is a provider of some sort?  I'll 
>>>>> see if
>>>>> there is another way to do this without disrupting your connection.
>>>>>
>>>>>
>>>>> Aubrey Wells wrote:
>>>>>
>>>>>> I have to partially take that back. When I did the manual ip change,
>>>>>> it took the wan0.1 vif down and it didn't come back up. That's why I
>>>>>> lost the other side.
>>>>>>
>>>>>>
>>>>>> ------------------
>>>>>> Aubrey Wells
>>>>>> Senior Engineer
>>>>>> Shelton | Johns Technology Group
>>>>>> A Vyatta Ready Partner
>>>>>> www.sheltonjohns.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Nov 30, 2007, at 11:20 AM, Aubrey Wells wrote:
>>>>>>
>>>>>>
>>>>>>> I'm using VC3. I tried the workaround and it didnt work. The 
>>>>>>> network
>>>>>>> is in the routing table now, but its defined as going out eth5
>>>>>>> instead
>>>>>>> of wan0.1 and my routes are still hosed. Also, now I can't see the
>>>>>>> other side of the DS3 since the system is trying to source 
>>>>>>> 64.211.X.
>>>>>>> 32/30 out of eth5. :-(
>>>>>>>
>>>>>>> vyatta:~# ifconfig wan0.1 64.211.X.34 netmask 255.255.255.252
>>>>>>> vyatta:~# route -n
>>>>>>> Kernel IP routing table
>>>>>>> Destination     Gateway         Genmask         Flags Metric Ref
>>>>>>> Use Iface
>>>>>>> 206.132.X.48  8.17.X.1       255.255.255.255 UGH   0      
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> 64.211.X.196  8.17.X.1       255.255.255.255 UGH   0      
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> 64.211.X.32   8.17.X.1       255.255.255.252 UG    0      
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> 8.17.X.0       0.0.0.0         255.255.255.248 U     0
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> 206.132.X.32  8.17.X.1       255.255.255.240 UG    0      
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> 0.0.0.0         8.17.X.1       0.0.0.0         UG    1
>>>>>>> 0        0
>>>>>>> eth5
>>>>>>> vyatta:~#
>>>>>>>
>>>>>>> ------------------
>>>>>>> Aubrey Wells
>>>>>>> Senior Engineer
>>>>>>> Shelton | Johns Technology Group
>>>>>>> 404.478.2790
>>>>>>> Support: [EMAIL PROTECTED]
>>>>>>> www.sheltonjohns.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Nov 30, 2007, at 11:10 AM, Robyn Orosz wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Aubrey,
>>>>>>>>
>>>>>>>> Are you using VC3 or supported beta?  I'm pretty sure the 
>>>>>>>> problem is
>>>>>>>> that:
>>>>>>>>
>>>>>>>> 64.211.X.33   0.0.0.0         255.255.255.255 UH    0      0
>>>>>>>> 0 wan0.1
>>>>>>>>
>>>>>>>> Is being added as a host route.  This is happening because 
>>>>>>>> we're now
>>>>>>>> using pppd for PPP and MLPPP connections and pppd adds the remote
>>>>>>>> peer
>>>>>>>> as a /32 to the routing table.  There's an open bug on this:
>>>>>>>>
>>>>>>>> https://bugzilla.vyatta.com/show_bug.cgi?id=2332
>>>>>>>>
>>>>>>>> I'm still trying to figure out if there is a way to make pppd add
>>>>>>>> a /
>>>>>>>> 30
>>>>>>>> route rather than a /32.  Try this workaround and let me know 
>>>>>>>> if it
>>>>>>>> works for you:
>>>>>>>>
>>>>>>>> ifconfig wan0.1 64.211.X.34 netmask 255.255.255.252
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>>
>>>>>>>> Robyn
>>>>>>>>
>>>>>>>> Aubrey Wells wrote:
>>>>>>>>
>>>>>>>>> OFR hates me today. :-(
>>>>>>>>>
>>>>>>>>> I have a new router with a DS3 in it running bgp over the ds3.
>>>>>>>>> everything looks good except that all my bgp routes are being
>>>>>>>>> inserted
>>>>>>>>> into the routing table with a next-hop of the default route,
>>>>>>>>> instead
>>>>>>>>> of the received next-hop form bgp. Any idea what's going on? I've
>>>>>>>>> rebooted a few times, removed and readded the peer, etc but I'm
>>>>>>>>> stumped.
>>>>>>>>>
>>>>>>>>> Relevant info below:
>>>>>>>>>
>>>>>>>>> ## vyatta config ##
>>>>>>>>> [EMAIL PROTECTED]> show configuration
>>>>>>>>> protocols {
>>>>>>>>>     bgp {
>>>>>>>>>         bgp-id: 64.211.X.34
>>>>>>>>>         local-as: 65000
>>>>>>>>>         peer "64.211.X.33" {
>>>>>>>>>             local-ip: 64.211.X.34
>>>>>>>>>             as: 6745
>>>>>>>>>             next-hop: 64.211.X.34
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>     static {
>>>>>>>>>         route 0.0.0.0/0 {
>>>>>>>>>             next-hop: 8.17.X.1
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>> policy {
>>>>>>>>> }
>>>>>>>>> interfaces {
>>>>>>>>>     loopback lo {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth0 {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth1 {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth2 {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth3 {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth4 {
>>>>>>>>>     }
>>>>>>>>>     ethernet eth5 {
>>>>>>>>>         address 8.17.X.2 {
>>>>>>>>>             prefix-length: 29
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>     serial wan0 {
>>>>>>>>>         encapsulation: "ppp"
>>>>>>>>>         t3-options {
>>>>>>>>>         }
>>>>>>>>>         ppp {
>>>>>>>>>             vif 1 {
>>>>>>>>>                 address {
>>>>>>>>>                     local-address: 64.211.X.34
>>>>>>>>>                     prefix-length: 30
>>>>>>>>>                     remote-address: 64.211.X.33
>>>>>>>>>                 }
>>>>>>>>>             }
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>> service {
>>>>>>>>>     ssh {
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>> firewall {
>>>>>>>>> }
>>>>>>>>> system {
>>>>>>>>>     name-server 8.17.X.41
>>>>>>>>>     name-server 8.17.X.42
>>>>>>>>>     ntp-server "69.59.150.135"
>>>>>>>>>     login {
>>>>>>>>>         user root {
>>>>>>>>>             authentication {
>>>>>>>>>                 encrypted-password: <md5 pwd>
>>>>>>>>>             }
>>>>>>>>>         }
>>>>>>>>>         user vyatta {
>>>>>>>>>             authentication {
>>>>>>>>>                 encrypted-password: <md5 pwd>
>>>>>>>>>             }
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>     package {
>>>>>>>>>         repository community {
>>>>>>>>>             component: "main"
>>>>>>>>>             url: "http://archive.vyatta.com/vyatta";
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> --More-- (END)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ## show bgp peers output ##
>>>>>>>>>
>>>>>>>>> [EMAIL PROTECTED]> show bgp peers
>>>>>>>>>
>>>>>>>>> Peer IP          AS     State    Ver  Msg Rx     Msg Tx  
>>>>>>>>> Update Rx
>>>>>>>>> Update Tx
>>>>>>>>> -------          --     -----    ---  ------     ------  
>>>>>>>>> ---------
>>>>>>>>> ---------
>>>>>>>>> 64.211.X.33    6745   ESTAB    4    15         13      
>>>>>>>>> 2          0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ## show bgp routes output ##
>>>>>>>>>
>>>>>>>>> [EMAIL PROTECTED]> show bgp routes
>>>>>>>>> Status Codes: * valid route, > best route
>>>>>>>>> Origin Codes: i IGP, e EGP, ? incomplete
>>>>>>>>>
>>>>>>>>> Prefix             Nexthop          BGP-ID           MED LP  AS-
>>>>>>>>> Path
>>>>>>>>> ------             -------          ------           --- ---
>>>>>>>>> -------
>>>>>>>>> *> 64.211.X.32/30   64.211.X.33    64.211.X.196       100 6745 i
>>>>>>>>> *> 64.211.X.196/32  64.211.X.33    64.211.X.196       100 6745 i
>>>>>>>>> *> 206.132.X.32/28  64.211.X.33    64.211.X.196       100 6745 i
>>>>>>>>> *> 206.132.X.48/32  64.211.X.33    64.211.X.196       100 6745 i
>>>>>>>>> [EMAIL PROTECTED]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ## show bgp neighbor-routes ##
>>>>>>>>>
>>>>>>>>> [EMAIL PROTECTED]> show bgp neighbor-routes
>>>>>>>>> Status Codes: * valid route, > best route
>>>>>>>>> Origin Codes: i IGP, e EGP, ? incomplete
>>>>>>>>>
>>>>>>>>> Prefix             Nexthop          BGP-ID           MED LP  AS-
>>>>>>>>> Path
>>>>>>>>> ------             -------          ------           --- ---
>>>>>>>>> -------
>>>>>>>>> *> 64.211.X.32/30   64.211.X.33    64.211.X.196           6745 i
>>>>>>>>> *> 64.211.X.196/32  64.211.X.33    64.211.X.196           6745 i
>>>>>>>>> *> 206.132.X.32/28  64.211.X.33    64.211.X.196           6745 i
>>>>>>>>> *> 206.132.X.48/32  64.211.X.33    64.211.X.196           6745 i
>>>>>>>>> [EMAIL PROTECTED]>
>>>>>>>>>
>>>>>>>>> ## show route ##
>>>>>>>>>
>>>>>>>>> [EMAIL PROTECTED]> show route
>>>>>>>>> Routes: 7/7, Paths: 7/7
>>>>>>>>> 0.0.0.0/0 [static(1)] > to 8.17.X.1 via eth5
>>>>>>>>> 8.17.X.0/29 [connected(0)] > to 8.17.X.2 via eth5
>>>>>>>>> 64.211.X.32/30 [ebgp(0)] > to 8.17.X.1 via eth5
>>>>>>>>> 64.211.X.196/32 [ebgp(0)] > to 8.17.X.1 via eth5
>>>>>>>>> 127.0.0.0/8 [connected(0)] > to 127.0.0.1 via lo
>>>>>>>>> 206.132.X.32/28 [ebgp(0)] > to 8.17.X.1 via eth5
>>>>>>>>> 206.132.X.48/32 [ebgp(0)] > to 8.17.X.1 via eth5
>>>>>>>>>
>>>>>>>>> [EMAIL PROTECTED]>
>>>>>>>>>
>>>>>>>>> ## route -n from unix shell ##
>>>>>>>>> vyatta:~# route -n
>>>>>>>>> Kernel IP routing table
>>>>>>>>> Destination     Gateway         Genmask         Flags Metric Ref
>>>>>>>>> Use Iface
>>>>>>>>> 206.132.X.48  8.17.X.1       255.255.255.255 UGH   0      0
>>>>>>>>> 0 eth5
>>>>>>>>> 64.211.X.33   0.0.0.0         255.255.255.255 UH    0
>>>>>>>>> 0        0
>>>>>>>>> wan0.1
>>>>>>>>> 64.211.X.196  8.17.X.1       255.255.255.255 UGH   0      0
>>>>>>>>> 0 eth5
>>>>>>>>> 64.211.X.32   8.17.X.1       255.255.255.252 UG    0      0
>>>>>>>>> 0 eth5
>>>>>>>>> 8.17.X.0       0.0.0.0         255.255.255.248 U     0
>>>>>>>>> 0        0
>>>>>>>>> eth5
>>>>>>>>> 206.132.X.32  8.17.X.1       255.255.255.240 UG    0      0
>>>>>>>>> 0 eth5
>>>>>>>>> 0.0.0.0         8.17.X.1       0.0.0.0         UG    1
>>>>>>>>> 0        0
>>>>>>>>> eth5
>>>>>>>>> vyatta:~#
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>> *
>>>>>>>>> *------------------*
>>>>>>>>> *Aubrey Wells*
>>>>>>>>> /Senior Engineer/
>>>>>>>>> Shelton | Johns Technology Group
>>>>>>>>> A Vyatta Ready Partner
>>>>>>>>> www.sheltonjohns.com <http://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
>>>
>> _______________________________________________
>> 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

Reply via email to