But for that I need a route that is advertised only from Main router. Since both Main and backup router advertises the same routes, would be possible to generate a fake route from Main Router only if the bgp session is established?
I don't really understand your request, hence my answer is a more generic BGP answer:
In general, in an active-passive scenario (BGP peer 1 is primary for ingress and egress traffic, BGP peer 2 is backup), all IP prefixes are advertised to both BGP peers at the same time. To perform traffic engineering, there are BGP attributes like local preference, as-path prepending and MED. In addition, the BGP peers may support BGP communities for further traffic engineering. With these attributes, in normal cases, you can define very well where your traffic shall come in and where it shall go out.
BGP should never announce any fake routes, it can only announce prefixes which are present in the local routing table.
These attributes don't always work. Backup peer keeps sending me some percentage of traffic. The only attribute that's works is split the prefix in more specifics one. But I can't do that. So the conditional export can work. If there is not a concept of fake routes maybe rib groups will do it. Just more complex to configure.
In the cited use case the filter advertise only if routes is not in inet0 router table. But when primary bgp falls down wouldn'be the inet0 be replaced with the routes from secondary peer anyway? Same import filter since inbound routes are the same. In this case the routes always exists and will advertise to secondary peer in any case. I think we need another table. So how would be the best way to handle some routes and copy to another table like inet0.test?
setted a route with TEST-COMM and that do the trick:
set policy-options policy-statement TEST-import term a from instance master
set policy-options policy-statement TEST-import term a from protocol bgp
set policy-options policy-statement TEST-import term a from community TEST-COMM
set policy-options policy-statement TEST-import term a then accept
set policy-options policy-statement TEST-import term b then reject
set routing-instances TESTE instance-type virtual-router
set routing-instances TESTE routing-options instance-import TEST-import
Unfortunately this is one example of lacking documentation for JUNOS scenarios which are quite useful to know.
Fortunately, for other vendor's OS there are examples on the Internet how to achieve this. As you already mentioned, to check from which BGP peer your Router receives the IP prefix mentioned in the policy, inbound BGP communities are the right way. Just google for "BGP Conditional Advertisement" to get some examples for another major vendor's OS.