Can someone pls take a quick look. Customer says I am not announcing there AS number to the world.

I have statically routed there own prefix back to them.

They connect to our BGP via a public /30 we assigned to them.

They just did something that is preventing there prefix to be showing in our peering session but usually its there and I can see it being advertised to my peers. So lets just assume it is there for the moment.

My upstream providers have added there prefix to there filters.

IRR records updated on my end

What am I missing..

This is all running in one instance.

Few things you need to look at.

1. You aren't receiving any prefixes on that peering

2. If you added a static route to take the place of the learned BGP prefix from your downstream customer, you will need advertise that route in BGP via a network statement or redistribute static (preferably with a filter).

3. Post the output of the following commands

Routes received from the customer peering
Routes advertised to the upstream or upstreams
My guess is that you won't see the prefix advertised to the upstream because it hasn't been advertised in BGP or the nexthop advertised is not reachable, etc.

Everything came up once the client fixed there issue with there prefix not coming to us anymore. In the advertisements we there AS etc and in most looking glass's we see our As with there and there other provider. All seems well. I do however has this entry

PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
Custo... 0.0.0.0/0 10.195.10.1 incomplete


But as mentioned all seems to be working. They disconnect there peering form there other provider and traffic starts to flow our way after the 180 hold time expires on there other providers end..

Regards,

Everything came up once the client fixed there issue with there prefix not coming to us anymore. In the advertisements we there AS etc and in most looking glass's we see our As with there and there other provider. All seems well. I do however has this entry

PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
Custo... 0.0.0.0/0 10.195.10.1 incomplete


But as mentioned all seems to be working. They disconnect there peering form there other provider and traffic starts to flow our way after the 180 hold time expires on there other providers end..

Regards,

It looks like the customer's AS is sending a default route to you. Your input filter from the customer should be blocking anything that isn't their explicit prefix.

It's been a bit since I played with RouterOS route filters, but I seem to remember there being something unexpected in the behavior of a rule with the syntax of prefix=!x.x.x.x/m --- perhaps your filter should read more like:
1: accept prefix=x.x.x.x/24
2: deny all


EDIT: That prefix you see is what you're sending to the Customer. The NEXTHOP address 10.195.10.1 should be the IP of your router which the customer peers with. ORIGIN Incomplete means that the route was redistributed into BGP.