cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1389
Views
19
Helpful
8
Replies

BGP - Two Class C's - Not seeing them in Looking Glass

t.khan
Level 1
Level 1

Hello,

We have two class C's we are trying to advertise over two routers. The first class C x.x.x.x/24 is advertised from router 1 without any prepending. The second class C y.y.y.y/24 is advertised off of router 1 with the AS prepended twice. On router two it is flipped with x.x.x.x/24 advertised with the AS Path prepended twice and the y.y.y.y/24 advertised without prepending. This is done via route-maps. When I go to level3.com/lookingglass or the att route server, I only see the path from each respective ISP. x.x.xx/24 shows Verizon AS 701, then our AS zzz. And yipes shows their AS then ours. Am I doing something wrong? I expect to see all the paths to both our networks.

Attached is the router bgp section from both routers.

Router 1

---------------------------------------------------

router bgp zzz

no synchronization

bgp log-neighbor-changes

network x.x.x.0 mask 255.255.255.0

network y.y.y.0

neighbor <snip> remote-as 701

neighbor <snip> route-map prepend_out out

neighbor 172.16.5.2 remote-as zzz

neighbor 172.16.5.2 next-hop-self

no auto-summary

!

<snip>

!

route-map prepend_out permit 10

match ip address prepend_yipes_out

set as-path prepend zzz zzz

!

route-map prepend_out permit 20

match ip address prepend_verizon_out

!

Router 2

----------------------------------------------------

router bgp zzz

no synchronization

bgp log-neighbor-changes

network x.x.x.0 mask 255.255.255.0

network y.y.y.0

neighbor <snip> remote-as 6517

neighbor <snip> route-map prepend_out out

neighbor <snip> remote-as 6517

neighbor <snip> route-map prepend_out out

neighbor 172.16.5.1 remote-as zzz

neighbor 172.16.5.1 next-hop-self

no auto-summary

!

<snip>

!

!

route-map prepend_out permit 10

match ip address prepend_verizon_out

set as-path prepend zzz zzz

!

route-map prepend_out permit 20

match ip address prepend_yipes_out

!

The result I am looking for is that both Class C's will use the respective routers as primary, and will fail over to each other in case of a failure in that ISP.

Thanks!

1 Accepted Solution

Accepted Solutions

Tahir

It is true that when you prepend that some traffic may arrive on the backup link. Even with prepending it is possible that some providers may have a better (shorter AS path) path to you over the backup link.

For example assume that there is some provider X that is 1 AS away from Verizon. So they will see the y.y.y.y prepended and Verizon's AS in the AS path (3 ASes in the AS path). And assume that there are 4 ASes between yipes and provider X. So you advertise y.y.y.y to yipes with a single AS, yipes adds their AS, the 4 other ASes are added, so it gets to provider X with a longer AS path and they forward to you over Verizon (the backup path).

HTH

Rick

HTH

Rick

View solution in original post

8 Replies 8

Richard Burts
Hall of Fame
Hall of Fame

Tahir

I have not bothered to look carefully at the config that you posted because the behavior that you describe sounds quite normal and I believe that things are working as they should. I believe that the biggest issue is your assumption that you should see both paths to each prefix. But the nature of BGP is that if a BGP router receives 2 advertisements for a prefix, it will choose the best path and will advertise only that best path to its neighbors. So to see both paths you would have to get to the particular router where the normal advertisement and the prepenced advertisement meet.

I do not believe that you can check the effectiveness of your redundancy by checking looking glasses or route servers. I believe that you will need to fail one of the outbound links and see whether traffic then converges and flows to the other link.

HTH

Rick

HTH

Rick

Rick,

Thanks for the response. That does clear somethings up. I will give that a shot and let you know. I just assumed I would see all the paths, some prepended, some not. I was under the impression that it was possible for some traffic to arrive on the backup link as I was told that some ISP's may have a better link (or shorter) to our backup link. If that is not the case, then things just got a lot easier.

Thanks,

T

Rick,

As you may have seen in another post by me, I am in the process of getting a redundant link as well. I was under the impression that this redundant link could also be used to load balance.

For example, web clients originating from the AT&T network would come in over the AT&T circuit and web clients from the Sprint network would come in over the Sprint circuit.

Your reply seems to indicate traffic would only come in over one of the circuits until it goes down, then would failover to the other.

Could you please clarify for me? I'm getting ready to go to upper management to present redundancy and part of my presentation currently says we'd see distributed load across both circuits.

Thank you,

Denny

Denny

As you may see in my second response to Tahir, there may be SOME inbound traffic for a particular prefix over both links. It is generally not much over the backup path. So if your management would be satisfied with SOME traffic over both links, it is one thing. But most of the time when management hears "balanced" traffic they assume close to equal balance.

There is also a BIG difference between what Tahir describes and what you described in your post about BGP. Tahir says that he has 2 prefixes (both /24) which he is advertising to both providers and is prepending to manage his traffic. The situation that you describe is having address space assigned from Sprint and which they almost certainly aggregate into their larger address block when they advertise to the Internet. If you advertise your address space to AT&T then you are asking them to advertise a much smaller block to the Internet.

So if you think about web clients from Sprint and web clients from AT&T it probably would be balanced. But what proportion of traffic are they compared to web clients from all other providers?

And having written this preceeding paragraph I recognize that there is an assumption that I made about Tahir's network and perhaps we should check my assumption. I assume that Tahir has his own address space and not space assigned by Verizon and yipes. If that assumption is not correct then the same issue of aggregated addresses would come into play.

HTH

Rick

HTH

Rick

Hi Rick,

As always, your knowledge is greatly appreciated.

Thanks you,

Denny

You are welcome, please feel free to check prefix visibility with BGP Looking Glass servers as well

Tahir

It is true that when you prepend that some traffic may arrive on the backup link. Even with prepending it is possible that some providers may have a better (shorter AS path) path to you over the backup link.

For example assume that there is some provider X that is 1 AS away from Verizon. So they will see the y.y.y.y prepended and Verizon's AS in the AS path (3 ASes in the AS path). And assume that there are 4 ASes between yipes and provider X. So you advertise y.y.y.y to yipes with a single AS, yipes adds their AS, the 4 other ASes are added, so it gets to provider X with a longer AS path and they forward to you over Verizon (the backup path).

HTH

Rick

HTH

Rick

Another thought for Tahir and Denny and anyone else interested in balancing BGP/Internet traffic. Thinking about balancing traffic in BGP is more complicated than balancing traffic in dynamic Interior protocols. With BGP you use one set of tools (like prepending) to manage inbound traffic and you must use a different set of tools (like weight or local preference) for outbound traffic.

The discussion in this thread (and I believe in Denny's) has focused on inbound traffic. To achieve balancing of outbound traffic will require different analysis and different configuration to achieve balance of outbound traffic.

HTH

Rick

HTH

Rick
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:

Review Cisco Networking products for a $25 gift card