Hi all
I have configured for anycast address for my customers Server IP address
and advertised it to internet via BGP. This customer has 10 locations
throughout the globe.
So all are advertising the same Anycast address for the Server in the
internet. So in the core Internet BGP table, this Anycast address is earned
from many AS's and each will prefer their shortest path based on the BGP
best path.
THe traffic was happily flowing. But today morning , all the traffic gets
blackholed completely from a particular APAC region and when i am
investigating the issue, i saw the ANycast address is advertised from a AS
which there are no actual servers located and i need to tell to the BGP
Core Routers and upstream ISP that do not accept this prefix from this AS.
Because they are simply advertising the prefix with best MED value and all
the traffic chooses that AS as transit and i need to find the ROGUE server
from which AS and need to give info to the Service Providers about this
ATTACK and i need to recover my traffic.
Can anyone tell how to deal with this situation? What can i do to avoid
this situation.
THere are two different OSPF instances ( Not vrf instances of OSPF ) . It
is globally configured OSPF instances. When i learn the same prefix form
two different Global OSPF instances, which one will the RIB choose to send
the packet.
I have OSPF 1 and OSPF 2 running and both are receiving the same prefix and
i want to load balance the traffic , but it always chooses only one path
R1-----------------------R2-------------------------R3
|
|
|
|
|
|
R4
So in this R1 is advertising the anycast address server IP to R2 via OSPF 1
and R3 advertising the same IP to R2 via OSPF 2. All are in the same area
.In the R2 RIB, It is always choosing the R1 to send the Server traffic and
not R3 and it affects my load balancing.
How does RIB chooses when it receives two OSPF instance routes for the same
prefix. Both are Intra area, same cost.
THanks
Blogs and organic groups at http://www.ccie.net
Received on Sat Oct 20 2012 - 14:35:20 ART
This archive was generated by hypermail 2.2.0 : Thu Nov 01 2012 - 10:53:33 ART