[ixpmanager] AS-SET Is not Working

Shahab Vahabzadeh me at shahabv.com
Mon Apr 20 06:58:50 IST 2020


Nick,
I think I find the problem, Customer AS Number (AS43754) must be inside
AS-SET?!
They (and Me) thought that only AS numbers behind customers must be there.
Maybe you can AND it in your queries, Customer AS Number + AS-SET.
Thanks

On Mon, Apr 20, 2020 at 10:25 AM Shahab Vahabzadeh <me at shahabv.com> wrote:

> Nick,
> Our IRRDB source for all customers is RIPE.
> Thanks
>
> On Mon, Apr 20, 2020 at 10:23 AM Shahab Vahabzadeh <me at shahabv.com> wrote:
>
>> Dear Nick,
>> Now for customer Asiatech (AS43754) we have IPv4 and IPv6 Peering Macro
>> which is AS-ASIATECH.
>> And also as I check the ripe database there is a valid route object for
>> 185.141.213.0/24 with AS43754 itself.
>> So why is there an error for this prefix?
>> Thanks
>>
>> On Sun, Apr 19, 2020 at 1:53 PM Nick Hilliard (INEX) <nick at inex.ie>
>> wrote:
>>
>>> Shahab Vahabzadeh wrote on 19/04/2020 08:34:
>>> > You are right but what is your idea about this prefix:
>>> 185.141.213.0/24  ?
>>> > There is a route object in ripe with AS43754 and this AS belongs to
>>> the
>>> > customer himself.
>>> > But again it's filter with two tag: Prefix Filtered, Origin AS Filtered
>>>
>>> The list of IRRDB prefixes is built using the "IPv4 Peering Macro" and
>>> "IRRDB Source" in the Customer profile.
>>>
>>> If the "IPv4 Peering Macro" field is blank, then it uses the AS.
>>>
>>> The artisan irrdb:update-prefix-db command uses the bgpq3 command to
>>> populate the local database using the peering macro and the source list.
>>>
>>> The first thing to do is check the information that's going into the
>>> local database.
>>>
>>> -  you need to check that the "IPv4 Peering Macro" is set to what the
>>> customer specifies
>>>
>>> -  make sure the irrdb source looks correct.  Probably it should be set
>>> to "RIPE".
>>>
>>> -  you need to make sure that there is a route: object in the IRRDB for
>>> the prefix that you're checking.
>>>
>>> You can find out what bgpq3 thinks by calling it directly using the
>>> parameters specified in IXP Manager, e.g. if you've set the as-set to be
>>> blank, it will use the AS itself:
>>>
>>> > % bgpq3 -S RIPE AS43754 | grep 185.141.213.0/24
>>> > ip prefix-list NN permit 185.141.213.0/24
>>> > %
>>>
>>> This means that there's a route: object in the RIPE IRRDB, which is a
>>> good start.
>>>
>>> The next thing would be to check the AS-SET that you're using in IXP
>>> Manager for this customer, along with the IRRDB source list:
>>>
>>> > % bgpq3 -S "<IRRDB source list>" <IPv4 peering macro> | grep
>>> 185.141.213.0/24
>>>
>>> If this comes up blank, then you've identified that the problem is that
>>> you're using the wrong IRRDB source, the wrong AS set or else that the
>>> customer hasn't configured their AS set properly.
>>>
>>> Nick
>>>
>>>
>>
>> --
>>
>> Cheers, Shahab
>>
>
>
> --
>
> Cheers, Shahab
>


-- 

Cheers, Shahab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20200420/07f118b4/attachment-0001.htm>


More information about the ixpmanager mailing list