pdk
@captiveaire.com
| reply to pdk
Re: [HELP] Prepending AS path in Multihomed setup
Also if Sprintlink was NOT announcing the route, then how would traffic ever fail over when our TWC link was down, which it does. I believe the reason you weren't seeing the route was because our sprintlink was down at that time, per my previous post. I see two routes as of right now and my TWC link is preferred........ |
|
aryoba
Premium,MVM
join:2002-08-22
1 edit | reply to pdk
Yeah, I notice that your IP address and stuff is easier to find when you post as anon instead of registered account ... 
But that's off topic and I don't want to go further ... 
Now, pdk; have you got a chance to pick a looking glass and see if your AS # is announced as supposed to? |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| reply to pdk
said by pdk :
Also if Sprintlink was NOT announcing the route, then how would traffic ever fail over when our TWC link was down, which it does. I believe the reason you weren't seeing the route was because our sprintlink was down at that time, per my previous post. I see two routes as of right now and my TWC link is preferred........
You're really not answering any questions about your config... The most basic being, are you announcing routes yourself via BGP or is each ISP doing it on your behalf? Config snippets would help.
As to privacy, well, whois is a simple tool that most anyone in this forum should be familiar with. |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| reply to carp
said by carp  :You sound uninformed about solving it with DNS, Radware, etc. Works like a charm in many situations. Quite the contrary. No matter what box you use for DNS load-balancing you are still relying on DNS, which I understand quite well. I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services. |
|
pdk
@captiveaire.com
| reply to sporkme
Our ISP is doing it on our behalf. What other config snippets do you need. I thought I copied all my BGP config info in my original post. Do you see our two routes advertised as of now?
my domain is in TINY italic letters under my name, didn't realize it was there sorry, was wondering how it was so easy for everyone to know who i was  |
|
pdk
@captiveaire.com | reply to pdk
I did pick a looking glass, for what my limited knowledge tells me it looks fine, i don't understand why it doesn't return to the preferred route of TWC once the conneciton is restored. |
|
jwhitecs
Premium
join:2006-10-11
| reply to pdk
you left your public AS# in the original post.
neighbor 10.10.10.3 remote-as 32913
-still only 1 path
route-server>show ip bgp regexp _32913$
BGP table version is 2745442, local router ID is 12.0.1.28
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 204.120.207.0 12.123.13.241 0 7018 3356 11426 32913 i
* 12.123.29.249 0 7018 3356 11426 32913 i
* 12.123.145.124 0 7018 3356 11426 32913 i
* 12.123.5.240 0 7018 3356 11426 32913 i
* 12.123.37.250 0 7018 3356 11426 32913 i
* 12.123.21.243 0 7018 3356 11426 32913 i
* 12.123.45.252 0 7018 3356 11426 32913 i
* 12.123.142.124 0 7018 3356 11426 32913 i
* 12.123.139.124 0 7018 3356 11426 32913 i
* 12.123.133.124 0 7018 3356 11426 32913 i
* 12.123.134.124 0 7018 3356 11426 32913 i
* 12.123.33.249 0 7018 3356 11426 32913 i
* 12.123.25.245 0 7018 3356 11426 32913 i
* 12.123.17.244 0 7018 3356 11426 32913 i
*> 12.123.1.236 0 7018 1668 11426 32913 i
* 12.123.41.250 0 7018 1668 11426 32913 i
* 12.123.137.124 0 7018 1668 11426 32913 i
* 12.123.9.241 0 7018 1668 11426 32913 i |
|
pdk
@captiveaire.com
| Query: bgp
Address: 204.120.207.0
BGP routing table entry for 204.120.207.0/24, version 93798026
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
66.178.0.2 66.178.0.3 66.178.0.4 66.178.0.5 66.178.0.6 66.178.0.7 66.178.0.11
66.178.0.12 66.178.0.14 66.178.0.16 66.178.0.17 66.178.0.18 66.178.0.23
66.178.0.24
6461 1668 11426 32913, (Received from a RR-client), (received & used)
66.178.0.2 (metric 2) from 66.178.0.2 (66.178.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 16422:666
701 3356 11426 32913
157.130.47.117 from 157.130.47.117 (137.39.3.146)
Origin IGP, localpref 100, valid, external, best
Community: 16422:666
701 3356 11426 32913, (received-only)
157.130.47.117 from 157.130.47.117 (137.39.3.146)
Origin IGP, localpref 100, valid, external |
|
rolande
Certifiable
Premium,Mod
join:2002-05-24
Powell, OH
clubs:
Host:
Linksys
AT&T Midwest
| reply to sporkme
said by sporkme :I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services. Really? I'd be interested to know what the scenarios were where you encountered the issues. The only issue I am aware of is primarily the 0 TTL issue with broken versions of BIND. Alternatively, if you are providing active/active geographic load balancing via DNS, you can run into issues with any clients using a provider's DNS that is serviced via Anycast.
In any case, we are talking about failover here. Failover should take place rarely for which the actual number of clients who might be impacted would be quite negligible anyway. So the argument can go either way fairly easily.
I have leveraged both 3DNS and the GSS product for global load balancing since 2002 in a couple of extremely high profile financial hosting environments serving literally millions of customers around the world. I have yet to be engaged in a troubleshooting call during a failover event, which app owners seem to incur on a regular basis for testing and DR events, where a user's DNS response was cached and stuck to the "offline" facility. I have witnessed the 0 TTL phenomenon on many occasions, not of my own doing, and I have seen Anycast client DNS cause out of state issues with applications. I'd love to know the issues you have experienced with "broken" DNS servers.
In the end, if a client has broken DNS, there isn't much you can do about it and it is not your responsibility, in any case. You build your own environment to support the standards. If others have issues because they are non-compliant, then it is up to them to resolve the problem.
--
Ignorance is temporary...stupidity lasts forever!
»www.thewaystation.com/
»blog.thewaystation.com/ |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| reply to pdk
said by pdk :
Our ISP is doing it on our behalf. What other config snippets do you need. I thought I copied all my BGP config info in my original post.
Ooops. Sorry, I'm blind.
Anyhow, at this point I see two paths from the looking glass I'm diddling. I don't take full routes from my upstreams anymore. |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| reply to rolande
said by rolande :said by sporkme :I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services. Really? I'd be interested to know what the scenarios were where you encountered the issues. I've not seen it with load balancing since I don't do that, but I've certainly seen misbehaving caching nameservers hold something much longer than the specified TTL. I have no idea what software said nameservers were running, my assumption was that it was not either BIND or DJBDNS... |
|
rolande
Certifiable
Premium,Mod
join:2002-05-24
Powell, OH
clubs:
Host:
Linksys
AT&T Midwest
| As an entity providing a hosted service, you can not take on the responsibility of "broken" client DNS servers. As long as you are obeying the standard, it is up to them to resolve their problem.
What if the customer decided it was in their best interest to provide extended BGP dampening? If your routes flap in BGP, you get blackholed from the customer for a period of time. This is the exact same situation and you can not be responsible for a broken configuration on the client's end.
Application layer failover is not a bad thing. It is actually better for us networking types because it takes the responsibility of resiliency off our shoulders.
--
Ignorance is temporary...stupidity lasts forever!
»www.thewaystation.com/
»blog.thewaystation.com/ |
|
jwhitecs
Premium
join:2006-10-11
| reply to pdk
So assuming your Sprint connection is currently up TWC AS11426 is announcing a /24 and Sprint AS1239 is announcing a /16 aggregate. So for inbound traffic to you its always going to take the longest match prefix which would be TWC (when both are up). As far as the outbound traffic leaving your AS it looks like you are learning a default route (0.0.0.0/0) from both TWC and Sprint so in that case the Local Preference can be set to give preference to one default over the other and when one goes away the other takes over. The highest local preference will be preferred. Both are set to 100 by default so you could set the Sprint peer local preference to 50 to always prefer TWC peer for outbound traffic exiting the AS.
route-server>show ip bgp 204.120.207.0 255.255.0.0 longer-prefixes
BGP table version is 3083298, local router ID is 12.0.1.28
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 204.120.0.0/16 12.123.13.241 0 7018 1239 i
* 204.120.207.0 12.123.13.241 0 7018 3356 11426 32913 i |
|
pdk
@rr.com
| Well outgoing i am not worried about. I control that completely with our firewall. The only reason I use BGP is to control the path of incoming traffic. Like you said, right now the way its configured TWC should be the preferred route it both are up, however, whichever link comes up first is the one that is preferred. If i were to shutdown both routers, turn on only my sprint, wait 5 minutes then turn on my TWC, sprint would be the preferred route and remain that way until i rebooted my sprint router. |
|
bartem01
join:2000-11-01
Brooklyn, NY
| reply to pdk
Try match on the acl in your route map and you need
route-map localonly permit 20
after your permit 10.
You can do on your secondary router:
ip access-list standard set-as-prepend
permit 10.10.10.0 0.0.0.255
exit
route-map localonly permit 10
match ip address set-as-prepend
set as-path prepend 300 300 300
exit
route-map localonly permit 20
Also make sure your secondary ISP grants metrics from you. |
|
jwhitecs
Premium
join:2006-10-11
| reply to pdk
Yeah pdk that makes no sense. Since the prefixes being announced are not the same (a /24 and a /16) from your two providers the BGP metrics wont matter cause there not considered equivalent routes for the same prefix.
BGP (any routing protocol for that matter)is always going to take the longest match prefix first before bgp metrics are ever used. Longer prefixes are always preferred over shorter ones when forwarding a packet. I was under the impression that your class C was announced as a /24 from both of your providers which in that case BGP decision process would come into play. |
|
PDK
@captiveaire.com | Oh no, /24 is being announced from both providers. What gave you the idea either was announcing a /16, where did you see that? |
|
jwhitecs
Premium
join:2006-10-11
| route-server>show ip bgp 204.120.0.0 255.255.0.0 longer-prefixes
BGP table version is 2261631429, local router ID is 64.135.5.58
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 204.120.0.0/16 64.135.0.1 0 13645 3356 1239 i *******/16 from Sprint*******
* 204.120.1.0 64.135.0.1 0 13645 4323 17293 14860 i
* 204.120.2.0 64.135.0.1 0 13645 3356 1239 18692 i
* 204.120.16.0/20 64.135.0.1 0 13645 7018 25615 21747 30032 i
* 204.120.34.0 64.135.0.1 0 13645 3356 1239 7066 i
* 204.120.36.0/22 64.135.0.1 0 13645 3356 7385 6488 i
* 204.120.80.0/20 64.135.0.1 0 13645 1785 i
* 204.120.138.0 64.135.0.1 0 13645 7018 32455 i
* 204.120.140.0/22 64.135.0.1 0 13645 3356 1239 11398 3704 i
* 204.120.160.0 64.135.0.1 0 13645 6539 19092 21947 18614 i
* 204.120.161.0 64.135.0.1 0 13645 6539 19092 21947 18614 i
* 204.120.162.0 64.135.0.1 0 13645 6539 19092 21947 18614 i
* 204.120.163.0 64.135.0.1 0 13645 6539 19092 21947 18614 i
* 204.120.182.0 64.135.0.1 0 13645 33739 i
* 204.120.192.0 64.135.0.1 0 13645 3356 1239 26909 i
* 204.120.193.0 64.135.0.1 0 13645 3356 1239 26909 i
* 204.120.194.0 64.135.0.1 0 13645 7132 26909 26909 26909 i
* 204.120.195.0 64.135.0.1 0 13645 7132 26909 26909 26909 i
* 204.120.196.0 64.135.0.1 0 13645 7132 26909 i
* 204.120.197.0 64.135.0.1 0 13645 7132 26909 26909 26909 i
* 204.120.198.0 64.135.0.1 0 13645 7132 26909 i
* 204.120.199.0 64.135.0.1 0 13645 7132 26909 i
* 204.120.206.0 64.135.0.1 0 13645 3356 1239 27548 i
* 204.120.207.0 64.135.0.1 0 13645 3356 11426 32913 i *****/24 from TWC***** |
|
jwhitecs
Premium
join:2006-10-11 | reply to PDK
I've checked several route-servers around from various ISP's and they all show the same as above. 1 /16 aggregate and 1 /24. Were are you seeing 2 /24's |
|
Covenant
Premium,MVM
join:2003-07-01
England
| reply to pdk
There is another way to do this but it all depends on your configuration as regards how you are learning the network "10.10.10.0/24" which you are advertising out to AS400 and AS500.
If you are learning the network via an IGP or eBGP from another host internal from the two CEs mentioned above, it will be tricky to do this without prepends but possible.
To accomplish this, we will use the not widely known IOS BGP feature of non-exist maps. (As jwhitecs pointed out, it is called BGP Conditional Advertisement and not non-exist map. That is what I use to describe it to customers at design meetings at work so apologies if it wasn't exactly correct. Nothing else technically, in this post is incorrect so its all semantics).
Basically, on the backup router, we will use this feature so as NOT to advertise the prefix out unless it detects a missing prefix which will cause it to advertise all routes out. Once the prefix is present again, it will stop advertising out the route.
Essentially on the backup router, we will setup a prefix-list to match for the default route coming in:
Then, an AS path list will be created matching for AS path 500 at the beginning of the AS path which is the AS peer for R1:
Then a route-map created to amalgamate the two together:
Next, we need to create a prefix list and route-map for the subnets we want to advertise when the prefix we are looking for (0.0.0.0/0) and as path (^500) are not present (created in the route-map above):
Then the route-map to tie this prefix-list to it:
Then for your AS400 PE on router 2, remove the route-map with the prepends and add the route-map with the non-exist map:
You might want to test this in a maintenance window/lab first and you will also have to look at route-dampening between the two routers (1 and 2) to minimise a flapping cct chances of causing route-dampening to be enabled on the ISP's PEs and Ps by the constant withdrawal of your prefixes and then advertisement.
That should cure your issue of a "stuck" backup route being present as the primary route in the ISP's RIB.
--
A word to the wise ain't necessary, it's the stupid ones who need the advice! |
|
