cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5096
Views
0
Helpful
26
Replies

WAN BGP Dual router/ Dual ISP routing -

Steve Coady
Level 1
Level 1

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.

 

 

 

 

 

sMc
2 Accepted Solutions

Accepted Solutions

Joseph Nelson
Level 1
Level 1

 

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:

  • You are actually advertising the 170.x.254.x/24 prefix to ISP_2? ( show ip bgp nei <peer_ip> advertised-routes)
  • ISP_2 is actually accepting the 170.x.254.x/24 prefix ( check looking glass )?

 

Can you provide the output for the two question above?

View solution in original post

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.

 

View solution in original post

26 Replies 26

Joseph Nelson
Level 1
Level 1

 

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:

  • You are actually advertising the 170.x.254.x/24 prefix to ISP_2? ( show ip bgp nei <peer_ip> advertised-routes)
  • ISP_2 is actually accepting the 170.x.254.x/24 prefix ( check looking glass )?

 

Can you provide the output for the two question above?

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

 

 

 

 

sMc

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

 

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

sMc

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.

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)

sMc

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

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

 

sMc

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

sMc

Also

 

 

Do i want to use local pref on both WAN_1 ASR and WAN_2 ASR?/

sMc

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.

I am running EIGRP between the ASR's

sMc

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:

  • What devices have EIGRP adjacencies? Just ASR<->ASR? ASR<->ASA? ASR<->Nexus7K?
  • Where and how are you using static routing? Just at ASA? How is the traffic getting to the ASA? What is the logical connectivity like between sites?

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)? 

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

 

sMc
Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco