Re: [Vyatta-users] bgp not using advertised next-hop
I think I'm ok for now. I made the changes to the file, and coped them to /root and then in rc.local I put in a few lines to copy and overwrite the files and wanrouter restart. Thans again for the research. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Dec 3, 2007, at 12:38 PM, Robyn Orosz wrote: > 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
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 y
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.
Re: [Vyatta-users] bgp not using advertised next-hop
I'll give that a try here shortly. I had a really hard time getting my DS3 card to work properly in VC 2 and 2.2 but that could have been due to the XO circuit I was using at the time (I never did get it to work). If I can't get it to work this way, then I will have to take a good hard look at rolling back to 2.2. Thanks for the research, I'll let you know how it goes. -- 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 >
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
Re: [Vyatta-users] bgp not using advertised next-hop
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 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:
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 {
> }
>
Re: [Vyatta-users] bgp not using advertised next-hop
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
}
}
}
}
}
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:
}
}
user vyatta {
authentication {
encrypted-password:
}
}
}
package {
rep
Re: [Vyatta-users] bgp not using advertised next-hop
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
>>> }
>>> }
>>> }
>>> }
>>> }
>>> 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:
>>> }
>>> }
>>> user vyatta {
>>> authentication {
>>> encrypted-password:
>>> }
>>> }
>>> }
>>> 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 StateVer Msg Rx Msg Tx Update Rx
>>> Update Tx
>>> --- -- ---- -- -- -
>>> -
>>> 64.211.X.336745 ESTAB415
Re: [Vyatta-users] bgp not using advertised next-hop
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
>>}
>>}
>>}
>>}
>>}
>>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:
>>}
>>}
>>user vyatta {
>>authentication {
>>encrypted-password:
>>}
>>}
>>}
>>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 StateVer Msg Rx Msg Tx Update Rx
>> Update Tx
>> --- -- ---- -- -- -
>> -
>> 64.211.X.336745 ESTAB415 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.3364.211.X.196 100 6745 i
>> *>
Re: [Vyatta-users] bgp not using advertised next-hop
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 00 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:
> }
> }
> user vyatta {
> authentication {
> encrypted-password:
> }
> }
> }
> 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 StateVer Msg Rx Msg Tx Update Rx
> Update Tx
> --- -- ---- -- -- -
> -
> 64.211.X.336745 ESTAB415 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.3364.211.X.196 100 6745 i
> *> 64.211.X.196/32 64.211.X.3364.211.X.196 100 6745 i
> *> 206.132.X.32/28 64.211.X.3364.211.X.196 100 6745 i
> *> 206.132.X.48/32 64.211.X.3364.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.3364.211.X.196 6745 i
> *> 64.211.X.196/32 64.211.X.3364.211.X.196 6745 i
> *> 206.132.X.32/28 64.211.X.3364.211.X.196 6745 i
> *> 206.132.X.48/32 64.211.X.3364.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
