Customer with a single router and private IP subnet behind router. Requirement is to add high availability using two ISP's and BGP. Inbound services for HA would just be web servers. Public IP's are /28. My questions are:
1. For outbound connectivity what is the benefit of using BGP over IP SLA/tracking/probing? -Depends how big is this customer? How may users? whats services they use and do you need site-site connection to anywhere else or just internet access, if its minimal then i would go for basic raw internet feeds, static routing towards each isp, It will be less expensive to run, plus you would get more BW for you money.
2. For inbound connectivity how does this work exactly? Say our website is xyz.com pointed to x.x.x.x (ISP1), how would this automatically failover to ISP2 if ISP1 is down? This would normally be done with DNS load balancing, right? - As johnd2310 stated if you have PI addressing then the public address will follow you (dependent on ISP) however you still need worry about DNS regards your website, again it depends if your setup, I am assuming that you will using a public dns service from your ISP, then if so you can see if they will allow you to use DDNS and if they do then that would be a good option regards automatic failover for you web site.
DDNS does come built into some small office/home Routers & UTM devices or alternatively a piece of software can be installed on your webserver. The DDNS can be used that will actively monitor your active public address and if it changes it should update your public dns server accordingly for public name resolution.
... View more
You get a final drop because it seems that you have an asymmetrical nat issue.
PS: Please don't forget to rate and b mark as correct answer if this answered your question
EDIT: i didn't looked on your command and everyone is right, you need to put your public IP and you'll have a success result instead of rpf-check drop
... View more
Yes, configuration link is correct. I would like to shed light on few other points regarding RPID,PID and PPI RPID is enabled on the SIP trunk & SIP line of the CUCME by default and used for caller & called party info exchange. It can be disabled at global level under sip-ua mode. When RPID is enabled a)-RPID is sent in the initial INVITE to send calling party info and privacy b)-RPID is sent in 18x & 200 responses to send called party info and privacy c)-RPID is sent in mid-call UPDATEs to send new remote party info after supplementary services like call transfer & forward PPI/PAI & Privacy can be enabled at global or dial-peer level. When PPI/PAI & Privacy is enabled PPI/PAI & Privacy headers are sent in initial INVITE to send the calling party info and it’s privacy. Including these headers in initial INVITE automatically disables RPID Since PPI/PAI headers are not allowed in responses and UPDATEs, they are not used for called party info update and remote party info update after supplementary services. Hence PPI/PAI & Privacy headers does not take care of all the scenarios handled by RPID. If an INVITE request contains both PPI/PAI & RPID, PPI/PAI is given the priority
... View more