Hello ,
One of our customers wants to advertise their own IPv4 and ASN we are the only upstream provider that they have, want to know how can we advertise their subnet and ASN, our upstream provider asked us to register our ASN as AS-SET in the whois database and the same is done, what do we need to do at our end to advertise their network and ASN now
Thanks for the help
Nothing much really. Set up peering to your customer and all routes from the client will be readvertised to upstream provider. If you have routing filters to upstream provider you will have to accept client’s prefix.
I wonder how your customer got a global ASN with only one upstream provider…
Your ISP has requested that you register this connectivity in the routing registry.
Check with your RIR (ARIN/RIPE/AFRNIC/APNIC/LACNIC) for details on how to do this.
Basically, it’s something that makes it possible for a BGP-speaking organization to see that it is legitimate that your customer’s IP addresses appear to route through you.
I can only speak about the RIPE region. At the moment, you need at least 2 “peer ASNs” (does not matter if downstream, upstream, peer) to get an ASN (required by policy). At the moment, RIPE does not check that.
Btw, i would recommend you to use community based filtering, if you have downstream networks.
Haha - I almost said the same thing, but decided that since the downstream customer here is single-homed, why open a can of worms? 
If he will have only this one downstream, no presence at any IXP, …, then I think “static” filtering will be fine.
But let’s say, he (AS A) is connecting to an IXP. His downstream (AS B) decides to temporary announce his prefix (let’s say 192.0.2.0/24) to another upstream (may be temporary) and not to announce it to AS A. AS A receives the prefix and as the outbound filter to the IXP permits this prefix, he would be leaking the prefix received from his upstream to the IXP.
Unfortunately there are lots of networks which are not checking the origin of a route (peer, ixp, transit), but statically permit the prefixes. That’s the reason why I always recommend some sort of community based filtering.
Agreed 100% - this is completely necessary if the customer’s route can possibly re-enter your ASN via one of your transit / peering connections.
OP - if you wish to include community filtering in your configuration, here is a high-level explanation of what you need to do:
on the in-filter applied to your customer(s), include a rule with action=passthrough, BGP-action=set communities=xxxx:yyyyy
This rule needs to be earlier in the filter chain than any rules which actually match the customer’s allowed prefixes.
(you can optionally just put the BGP-action onto the same rules, but if you ever need to change your communities, it’s a lot less work to change only one rule)
xxxxx should be your ASN, and yyyy should be some special code which means “learned from a customer”
You may choose anything you like as yyyy - but it must be consistent throughout your network.
Then on the out-filter on all of your upstream/peering connections, you will require that this community xxxx:yyyy is present on your cusomters’ prefixes in order to allow them to be advertised.
so basically we discussed with registrar and found that it could be done with AS-SET route set which they created for our customer and now its working
Also in India the restriction of 2 ASNs is there we just have to give undertaking to them for paperwork not actually be linked to them, 