We have 2 ASR Running HSRP between them.
We are Running IBGP between the 2 ASR's.
We have 3 Prefix which we advertise to the ISP
ASR 2 ------------Connects to ISP 2
ASR 1------------Connects to ISP 1
Currently Traffic Flow is From FW to ASR 1 which is Active and it passes the traffic to ASR 2 then to ISP 2 and return traffic
is coming via ISP 1.
IF i do traceroute from my PC it shows below traffic flow
IF i do traceroute from BGP looking Glass i see Traffic flow to our Prefix via ISP 1
How can I verify that how many prefixes ISP 2 is allowing from our network?
what you see is normal in eBGP:
on your side you can choice the preferred path over ISP2 by any means (shortest AS path if you don't set anything).
However, this does not mean that return traffic to you will come back via ISP2.
Depending on the remote AS it can make different routing choices and your return traffic can come back via ISP1.
For example they use local preference to prefere paths coming from ISP1 even if they have longer AS paths.
Or they are doing AS path prepending over paths coming from ISP2 making them less attractive.
This does not mean that ISP2 is blocking the advertisements of your own prefixes.
However, you can verify how ISP2 treats your prefixes on their looking glass making a show ip bgp <prefix>
if this is possible look at the lines telling if the prefix is advertised to someone.
If it is ISP2 is doing its job correctly.
in BGP multihoming you have to accept asymmetrical routing as this a limit in BGP itself, you can choice your outgoing path you cannot make a remote BGP AS to choice the same AS path in reverse order.
Hope to help
In the original post @mahesh18 tells us that they have 3 prefixes which they advertise to both ISP. He does not tell us whether they are doing anything in the advertisement to make one ISP preferred over the other (prepending is the most common way to do this) or is just advertising the prefixes equally to both ISP. He also does not tell us anything about his address space. Is this provider independent addresses? Or are the addresses assigned by one of the ISP? This could have significant effect on how traffic is forwarded to his network.
Mahesh asks a very interesting (and quite subtle) question:"How can I verify that how many prefixes ISP 2 is allowing from our network?" He is not asking how many prefixes he is advertising (so show ip bgp neighbor advertised is not helpful). Giuseppe makes an interesting suggestion about the possibility of a looking glass in ISP 2. But I am not sure that will necessarily provide the right answer. If ISP 2 does have a looking glass it would show how many prefixes of Mahesh it has learned. But the looking glass does not have information about what policy might be implemented by ISP 2 on its router connecting to its upstream neighbor. There is a possibility that ISP 2 might learn 3 prefixes from Mahesh but does not advertise all 3 to its upstream neighbor. So the optimum approach would be to find a looking glass on the upstream neighbor of ISP 2.
Mahesh has opened several threads about his eBGP network in the last days.
I think he has his own public IP addresses as it is really multihomed (in other threads you could see the peer AS numbers).
If the ISP2 looking glass allows for show ip bgp <prefix> it is at least possible to verify if the three prefixes are advertised to some other AS.
the most likely reason for asymmetric routing is simply the fact that remote AS can take a different routing decision based on any of the multiple BGP best path selection parameters.
ISP2 could only summarize the customer prefixes if they are aggregable (= share first N bits), but if ISP2 would not advertise any of the three prefixes it would violate the service contract.
I agree that looking also at the ISP behind ISP2 can provide more info but it is not strictly necessary.
It is actually normal what Mahesh sees return path is not always the reverse of the upstream path.
Hope to help
I appreciate the insight about multiple threads about this network. I did not see the others and so have less information about this environment than you do and can comment only on the bit that I know. I certainly agree that the asymmetric paths that Mahesh is experiencing is quite common. And ultimately it is not something that he can control.
But he asked a question and we are trying to answer it "How can I verify that how many prefixes ISP 2 is allowing from our network?" I do not want to be overly picky but his question is not whether ISP 2 receives the 3 prefixes but is about what policy ISP 2 has implemented about his prefixes. And without knowing what the policy is on the router connecting ISP 2 to its upstream neighbor we can not really answer that question.
I had an experience with a customer that might be similar to the situation for Mahesh. The customer had 2 ISPs. They had a /24 assigned to them from ISP 1. They received permission to advertise that network to ISP 2. ISP 1 was the preferred path for them. When they tested they verified that their outbound traffic did go out via ISP 1. But they found that return traffic came back via ISP 2. So far sounds sort of like Mahesh. The issue turns out to be that they advertised their /24 to both ISP. ISP 1 aggregated that address block and advertised a much bigger block. ISP 2 advertised the /24 to the Internet. And as we all know the more specific route is always preferred. This explains their asymmetric paths. This is the reason why I was asking about the prefixes that Mahesh has.
thanks for providing a real world case that might be useful. I never had a case like that.
I apologize if my previous post looked like repeating obvious facts that you know for sure.
At this point we can only wait for Mahesh's feedback to understand what can be happening.
No need to apologize. You provided context and information about the environment that I did not know. So it was helpful. I agree that at this point we need additional information from Mahesh to be able to understand the issue.
Besides looking glass, you can check what are you announcing to them and if you announce your prefixes to both ISPs.
sh ip bgp neighbor 184.108.40.206 advertised