[AusNOG] Vyatta - Accepting /24 from Customer and advertising to upstream

Sun Jul 27 08:52:52 EST 2014

Hi Nick,

  Fair enough - although output from commands Daniel has shown (not sure 
if on-list or not) shows the received-routes from his downstream 
customer as learning the prefix, but not forwarding it on.

  My last suggestion to him was to clear the bgp session to his 
upstream. He does not have soft-reconfig outbound on so it would require 
a full outbound clear.

  I'll bow out from here - as my Vyatta knowledge is extremely limited.

Thanks,
Joe

On 27/07/14 08:48, Nick Pratley wrote:
> Hi Joe,
>
> It wasn't sending to his upstreams as he was not receiving it from the 
> peer.
>
> The only time Vyatta won't send routes is the case of iBGP, but you 
> just tell it to be a route-reflector-client that that fixes that.
>
> Daniel, I would also turn off the redistribute connected, and set 
> static routes to blackhole for each of the prefixes you are 
> originating. This way you can use VLSM and properly subnet your ranges.
>
> Sent from my iPhone
>
> On 27 Jul 2014, at 8:40 am, Joseph Goldman <joe at apcs.com.au 
> <mailto:joe at apcs.com.au>> wrote:
>
> Hi Nick,
>
>  I'm not a Vyatta user but have done a bit of reading in an attempt to 
> help Daniel.
>
>  I couldn't find reference to Vyatta redistributing BGP (no 
> redistribute syntax for bgp), so unless its implied 100% of the time, 
> it reads as if it doesnt redistribute BGP into BGP (or always does). 
> Every other routing OS i have used you've had to explicitly state it. 
> I'd be interested to know the true story with Vyatta. In any case I 
> advised Daniel to add the network statement in an attempt to check the 
> advertised-routes to his upstream, to see if his router is even trying 
> to send the prefix up (which it wasn't).
>
> Thanks,
> Joe
>
> On 27/07/14 08:24, Nick Pratley wrote:
>> Couple things wrong
>>
>> Remove network statement for that range as it's being advertised to 
>> you,  you are not originating it.
>>
>> Remove export prefix list on that peer
>>
>> Create prefix list import-downstream with that prefix as the allowed 
>> route and apply to the neighbor prefix-list import
>>
>> Soft reset bgp on the neighbor and that should do it.
>>
>> Sent from my iPhone
>>
>> On 27 Jul 2014, at 6:54 am, Damien Gardner Jnr <rendrag at rendrag.net 
>> <mailto:rendrag at rendrag.net>> wrote:
>>
>> I'm sure someone who knows 100% will reply when they all wake up by 
>> two things to try..
>>
>> 1) on neighbor 103.18.204.242, there's no prefix-list import. I'm not 
>> sure whether this will just accept *everything* (this is bad mmmkay), 
>> or whether it will accept nothing at all.. Would be best to add a 
>> prefix list to accept the /24 from the customer.
>>
>> Though you can check this by doing:
>> show ip bgp neighbors 103.18.204.242 received-routes
>>
>> (Note misspelling of neighbours, this throws me every time!)
>>
>> And see if you're receiving the route
>>
>> I'd also check if you're sending the route on to your upstream.
>>
>> aka
>>
>> show ip bgp neighbors 1.0.4.73 advertised-routes
>>
>> 2) Have you told your upstream about the new prefix (and supplied 
>> them with your customer's LoA), and have they confirmed that they and 
>> all their upstreams are accepting it via you? If not, they're not 
>> going to accept it from you (unless they're a bit dodgy..).
>>
>> Two things to check on anyway :)
>>
>> Regards,
>> Damien
>>
>>
>>
>> On 26 July 2014 22:37, Daniel Watson <Daniel at glovine.com.au 
>> <mailto:Daniel at glovine.com.au>> wrote:
>>
>>     Hi Guys
>>
>>     We are accepting 203.27.101.0/24 <http://203.27.101.0/24> via
>>     AS133196 to our router
>>
>>     We are trying to advertise this router that we are getting on our
>>     BGP session to 133196 over to our upstream provider at 1.0.4.73 &
>>     1.0.4.74
>>
>>     However our upstream provider are not getting those routes from us
>>
>>     I have uploaded a sample of our configuration to
>>     http://glovine.com.au/daniel/melbourne.txt
>>     <http://glovine.com.au/daniel/melbourne.txt>
>>
>>     Can anybody point out the issue with 203.27.101.0/24
>>     <http://203.27.101.0/24> sending upstream?   First time newbie
>>     doing this part :D
>>
>>     Regards,
>>
>>     Daniel Watson
>>
>>     Network Administrator / Network Operations Manager
>>
>>     E Daniel at GloVine.com.au <mailto:Daniel at GloVine.com.au>
>>
>>     W www.GloVine.com.au <http://www.GloVine.com.au>
>>
>>
>>     _______________________________________________
>>     AusNOG mailing list
>>     AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>>     http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>>
>> -- 
>>
>> Damien Gardner Jnr
>> VK2TDG. Dip EE. GradIEAust
>> rendrag at rendrag.net <mailto:rendrag at rendrag.net> - 
>> http://www.rendrag.net/_
>> _--
>> We rode on the winds of the rising storm,
>>  We ran to the sounds of thunder.
>> We danced among the lightning bolts,
>>  and tore the world asunder
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140727/b3576f71/attachment.html>