09-23-2014 08:00 AM - edited 03-04-2019 11:48 PM
Hello
I am migrating from a single Internet provider to (2) new Internet providers
Current provider is receiving (6) class "C" subnets (170.x.1.0/24 - 170.x.6.0/24) from me via static. They are then advertising my class "B" prefix network as a 170.x.0.0/16 via ibgp to their cloud and the rest of the world. I have verified this via http://bgpinspect.merit.edu
My (2) new ISP's
I am advertising my subnet (170.x.254.x/24) via BGP to both ISP's (ISP_1 and ISP_2)
No matter what I do, ISP_1 is always seen asthe path back to my company
I administratively shut down my WAN interface to ISP_1 and it still tried to come back across the ISP_1 path.
Finally the ISP_1 path disappeared and now instead of coming back across my ISP_2 path
traffic for the new subnet, (170.x.254.x/24) is being seen by the World as coming from my current ISP (170.x.0.0/16)
WHAT AM I MISSING???
Attached is a diagram of new WAN
Also included are the BGP statements for both new routers.
Solved! Go to Solution.
09-23-2014 08:28 AM
It sounds like ISP_2 does not have your 170.x.254.x/24 prefix and/or is not propagating it. ISP_2 may need to update is Inbound Route Filter for your peer.
Have you verified the following:
Can you provide the output for the two question above?
09-23-2014 08:46 AM
Enrico,
Regarding your comment:
"In any case seems me that there are some problem in your BGP config: why did you configure
neighbor 12.x.x.9 default-originate
this way you are advertising a default route to the ISP, isn't it ?"
I'm not to worried about the "default-originate" the OP has toward the ISP. Indeed it should not be there, however no ISP in the world is going to accept a default from a stub AS-- and if they did, the OPs routers would likely shutdown.
Regarding your comment:
traffic for the new subnet, (170.x.254.x/24) is being seen by the World as coming from my current ISP (170.x.0.0/16) Seems the this ISP send a better advertisement then the second ISP; if so you have to agree a different metric for you networks usually as-prepend is used ore configre an eBGP session and change the NLRI attribute advertised to this ISP.
The OP is advertising his aggregate to his current IP and more specifics to his new IPs during his migration. This way, the site stays up while he migrates subnet by subnet to the new ISPs ( that's how I read it). At any rate, this situation can occur if ISP_2 doesn't have the more-specific he's trying to announce.
09-23-2014 08:28 AM
It sounds like ISP_2 does not have your 170.x.254.x/24 prefix and/or is not propagating it. ISP_2 may need to update is Inbound Route Filter for your peer.
Have you verified the following:
Can you provide the output for the two question above?
09-23-2014 11:47 AM
Joe
Thanks for the response.
Apparently ISP_2 did have some sort of routing/config issue on their end, but they won't elaborate.
I went to this site, http://tools.pingdom.com/ping and did traceroute to 170.x.254.4. It did take the correct path.
WAN_2-ASR1002x#show ip bgp nei 50.x.x.81 advertised-routes
BGP table version is (###), local router ID is (loopback0 ip)
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 170.x.254.0/24 0.0.0.0 0 32768 i
Total number of prefixes 1
IS this the site you are talking about? http://www.bgp4.as/looking-glasses
09-23-2014 12:00 PM
Yep. That's the correct one.
Might be the ISP Engineer in me but when I'm dealing BGP, looking glasses are indispensable. As far as the "routing/config issue" ISP_2 wouldn't elaborate on...it was an inbound route filter/route-map.
Get used to it. If your a stub AS, you have to tell them that you want to announce a new prefix like an animal. If you're a transit AS ( like ISP_1/ISP_2, Level3, Tata, etc.), you use a route registry like a Proper Sir :)
Since I don't know your IP Address space, can use one of the looking glass servers to verify that your prefix is known via ISP_2? I don't want you to have a false resolve because ISP_2 did some routing trickery to make things work. Come back and post the output.
Joe
09-23-2014 12:11 PM
Joe
Router: SF-200PAUL-CORE01
Command: show ip bgp 170.x.254.4
BGP routing table entry for 170.x.254.0/24, version 260553305
BGP Bestpath: med
Paths: (2 available, best #2, table default)
Multipath: eBGP
Advertised to update-groups:
1 40
Refresh Epoch 1
174 (ISP_2 AS#) 33491 (MyAS#), (received & used)
38.122.64.5 from 38.122.64.5 (66.28.1.182)
Origin IGP, metric 2020, localpref 100, valid, external
Community: 174:21000 (peer route, learned in NA) 174:22013
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
4436 (ISP_2 AS#) 33491 (MyAS#), (received & used)
208.74.64.2 from 208.74.64.2 (208.74.64.41)
Origin IGP, metric 23, localpref 110, valid, confed-internal, best
Community: 4436:999 4436:31413
rx pathid: 0, tx pathid: 0x0
09-23-2014 12:28 PM
sMc,
Make sure you test the failover, you could very well have the same issue with ISP_1 not propagating your 170.x.254.0/24 prefix as well.
While we're on it, this HSRP based failover you have...are you sites geographically distant? Or are you in campus. The only reason I ask is because if your using HSRP between sites, it implies you are spanning a layer 2 network between your sites ( might be on your diagram, just to lazy to look).
From a design perspective, you should span the layer 2 vlan/network. You should route between your two sites. The exception you _could_ get away with is if the sites were in the same building or on the same campus.
09-23-2014 12:31 PM
Joe
The sites are approx 4 miles apart. Dark fiber connects my DMZ switches that sit behind each ASR1002x.
DEFINATELY WILL TEST FAILOVER!
Question
The following is from an ISP perspective (PER)? Should I reverse the logic since I am coming from CER :
Suppose the following:
• RS1 connected to ISP_1
• RS2 connected to ISP_2
• RS1 and RS2 have iBGP connection
Then
• On RS1, incoming route-map for ISP_1 peer should increase local preference
• On RS2, incoming route-map for ISP_2 peer should increase local preference
• On RS1, outgoing route-map for RS2 should reset local preference (to 100)
• On RS2, outgoing route-map for RS2 should reset local preference (to 100)
09-23-2014 12:52 PM
sMc,
Oh, okay. Dark fiber is good, not active components so things like latency, loss, and jitter are bounded. In that case, works fine.
What I wrote above was from a customer perspective ( your perspective). The crux of the solution is whether or not your ASRs have an iBGP connection--it doesn't seem to be the case because you're using HSRP on the same LAN segment. If they don't run iBGP with each other, I'll need to revise the solution I gave you ( Hint: You'll end up load balancing with HSRP groups ). Otherwise, do you run an IGP between ASRs?
Joe
09-23-2014 12:58 PM
I have EIGRP runnning on ASR routers
My topology looks like:
ISP>ASR>DMZ stack?ASA5545x>(Nexus7K Distribution switch - this physical link not made yet)
WAN_1 / ISP_1 router example
router eigrp 171
network 12.a.a.16 0.0.0.7
network 170.x.254.0 0.0.0.255
passive-interface Loopback0
!
router bgp AAAAA
bgp log-neighbor-changes
network 12.a.a.16 mask 255.255.255.248
network 170.x.254.0 mask 255.255.255.0
neighbor 12.y.y.9 remote-as ####
Will have static between ASA and ASR using the HSRP address
09-23-2014 01:00 PM
Joe
Does this look like a valid config
route-map LOCALPREF permit 10
set local-preference 200
router bgp AAAAA
neighbor 12.x.x.9 route-map LOCALPREF out
09-23-2014 01:01 PM
Also
Do i want to use local pref on both WAN_1 ASR and WAN_2 ASR?/
09-23-2014 01:27 PM
You're missing a "match statement" and a prefix-list.
config t
ip prefix-list full-routes seq 5 permit 0.0.0.0/0 le 24 !!! Note, you don't want to accept more than a /24 from your ISP
end
config t
route-map LOCALPREF permit 10
match ip address prefix-list full-routes
set local-preference 200
end
config t
router bgp AAAAA
neighbor 12.x.x.9 router-map LOCALPREF in
end
The direction is inbound from your ISP. So that anything matched by the route-map "match" clause gets the "set" applied to it.
But as I said in my other comment. My original assumptions were wrong, none of this applies if you don't run iBGP between ASRs.
09-24-2014 07:38 AM
I am running EIGRP between the ASR's
09-23-2014 01:19 PM
I'd a much more detailed topology before I can talk about failover. What I described was contigent on you having an iBGP connection between the ASRs.
Minimally, I'd need to know:
I'm guessing you just took a fully redundant DMZ architecture and split that over two sites. Do you have two ASAs at either site (are they in Active/Active configuration)?
09-23-2014 02:12 PM
EIGRP is between ASR>ASA at each site and will include the Nx7k.
The switch I refer to as DMZ is now simply a 3750x switch stack(2) between the ASR and the ASA. The new switch stack at Site_1 is connected via trunk to the switch stack at Site__2. HSRP is dependent on these (2) stacks.
We want to have these switch stacks as simply a passthru, no routing.
The current Production Internet/VPN network has the following topology:
WAN router>ASA>DMZ
Most of the traffic on the current DMZ is being filtered off for a completely separate project called "Affiliates".
ASA's are ACTIVE/Standby
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: