Re: [Vyatta-users] bgp not using advertised next-hop
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
Re: [Vyatta-users] bgp not using advertised next-hop
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 00
eth5
64.211.X.196 8.17.X.1 255.255.255.255 UGH 0 00
eth5
64.211.X.32 8.17.X.1 255.255.255.252 UG0 00
eth5
8.17.X.0 0.0.0.0 255.255.255.248 U 0 00
eth5
206.132.X.32 8.17.X.1 255.255.255.240 UG0 00
eth5
0.0.0.0 8.17.X.1 0.0.0.0 UG1 00
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 UH0 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
}
}
}
}
Re: [Vyatta-users] bgp not using advertised next-hop
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 00 eth5 64.211.X.196 8.17.X.1 255.255.255.255 UGH 0 00 eth5 64.211.X.32 8.17.X.1 255.255.255.252 UG0 00 eth5 8.17.X.0 0.0.0.0 255.255.255.248 U 0 00 eth5 206.132.X.32 8.17.X.1 255.255.255.240 UG0 00 eth5 0.0.0.0 8.17.X.1 0.0.0.0 UG1 00 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 UH0 0 0 wan0.1 Is being added as a host route. This is happening because we're now using pppd for PPP and MLPPP
Re: [Vyatta-users] bgp not using advertised next-hop
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 00 eth5 64.211.X.196 8.17.X.1 255.255.255.255 UGH 0 00 eth5 64.211.X.32 8.17.X.1 255.255.255.252 UG0 00 eth5 8.17.X.0
