cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
961
Views
38
Helpful
42
Replies

CCIE-Type Routing Question

lamav
Level 8
Level 8

Please view the attached drawing before you read on and you may want to leave it open to refer to it.

Anyway, here is the scoop.

The OSPF area represents our Australia network.

Routers SING and JAPAN are OSPF ASBRs that redistribute OSPF-learned routes into BGP.

Both the SING and JAPAN routers form iBGP neighborships with both FMC and ECC in the United States.

So, FMC learns OSPF Australia routes through iBGP from both SING and JAPAN.

And ECC learns OSPF Australia routes through iBGP from both SING and JAPAN, too.

Right now, both FMC and ECC routers favor the SING router as the "next hop."

The reason is that all things being equal, the SING router carries a better IGP metric into its BGP advertisements than the JAPAN router does.

So, if one does a "sh ip bgp 19.210.108.16" (this is an Australia network) in the FMC and ECC routers, they will both show that they have learned 2 routes through iBGP, one from SING and one from JAPAN, but the SING router carries an IGP (OSPF) metric of, say, 330, while the JAPAN router advertises an IGP metric of 445. Therefore, the SING route is favored, so the FMC and ECC routers place the SING-learned iBGP routes in their BGP table.

<i>ecc#sh ip bgp 19.210.108.16

BGP routing table entry for 19.210.108.16/29, version 31730939

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

2 3

Local

19.213.1.130 (metric 1466112) from 19.213.1.130 (19.213.1.130)

Origin incomplete,

42 Replies 42

lamav
Level 8
Level 8

By the way, Im sorry for this long post. I tried to make it as straight forward as possible, so as not to be tedious.

Let me thank everyone in advance for taking the time to read this over and offering solutions, suggestions and comments. I appreciate it.

Victor

I just remembered that some people may not have Visio (Jon!), so I am providing the drawing as a JPEG, too.

Thanks

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Victor,

the BGP metric comes from the OSPF metric if you have access to the routers you should verify the settings on remote routers ahors03 and arcr01.

you can check with

sh ip ospf interface on lan and serial interfaces on all four routers singh, japan, ahors03, arcr01

However, you can use local-preference in iBGP to give preference to japan routes

you can do this in a route-map applied outbond on japan itself or with route-maps applied inbound on FMC and ECC.

the attempt the customer is doing is that of changing the IGP metric to next hop by changing delay parameters to change the metric to the BGP next-hop.

lowest MED (metric) is preferred in BGP.

However, if we look at the path selection criteria

see

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

we can see that IGP metric to next hop is considered only after a tie in MED.

so here you can do the following:

use local-preference that is checked first then MED and so you can influence the choices regardless of MED values

and/or

try to fix the different MED metrics seen on singh and japan

(this can come from different settings on remote routers being OSPF metric cumulative, a different bandwidth on serial links, and/or on lan interface on remote routers can explain a difference in metrics, a different auto-reference bandwidth in the ospf process)

So the customer's idea to modify IGP metric to next hop shouldn't work unless MED are made equal before.

I would use local-preference outbound japan router (you do it once and is spread in all the AS) but I would also check all the remote routers to understand the origin of the different OSPF metrics as seen by singh and japan.

Hope to help

Giuseppe

Hi, Giuseppe:

Im not sure why you are discussing MEDs when they are not being utilized in this set up at all.

I agree that the IGP metric (not the same as "MED", by the way) is the tie breaker here and thats why SING is being preferred over JAPAN. I mention that in my original post.

I also agree with you that the client is trying to influence the eigrp path selection process to the BGP next hop (SING) by adjusting the delay. That was my suspicion, but I was a bit confused because I hadnt spoken to him -- still havent, actually.

What I am looking for are people's opinions on how they would handle the requirement to have Australia-destined traffic go through JAPAN, instead of SING. And you did that! Thanks

Anyone else?

Id love to hear from others.

Thank you

Hello Victor,

thanks for your kind rating

>> Im not sure why you are discussing MEDs when they are not being utilized in this set up at all.

MED = BGP metric

Let's examine the sh ip bgp

ecc#sh ip bgp 19.210.108.16

BGP routing table entry for 19.210.108.16/29, version 31730939

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

2 3

Local

19.213.1.130 (metric 1466112) from 19.213.1.130 (19.213.1.130)

>> Origin incomplete, metric 255, localpref 100, valid, internal, best

Local

19.213.1.154 (metric 1465856) from 19.213.1.154 (19.213.1.154)

>>Origin incomplete, metric 404, localpref 100, valid, internal

ecc#

here 255 and 404 are BGP metric values also known as MED

notice that IGP metric to next hops are the values in (..)

19.213.1.130 (metric 1466112)

19.213.1.154 (metric 1465856)

and that IGP metric is already greater for 19.213.1.130 and that the BGP best path choice looks at BGP metric lowest metric first as in the link I've provided

Hope to help

Giuseppe

Giuseppe:

I am going to have to differ with something you're saying.

The metric you site in the output of the "sh ip bgp" command on the ECC router as being the "BGP MED" (metric 255 and metric 404) are in fact the IGP metrics that BGP carried in its advertisements to FMC and ECC. The IGP in question is OSPF and the metrics are 255 and 404 to the destination network in Australia from SING and JAPAN, respectively. See below the output from the SING and JAPAN routers.

Also, the metric in the "( )" in the "sh ip bgp" command on the ECC router is the IGP metric within the AS for the route to SING and JAPAN. The IGP in this case is eigrp and the eigrp metric to get from ECC to SING is 1466112 and the eigrp metric to get from ECC to JAPAN is 1465856.

HTH

Victor

ecc#sh ip bgp 19.210.108.16

BGP routing table entry for 19.210.108.16/29, version 31730939

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

2 3

Local

19.213.1.130 (metric 1466112) from 19.213.1.130 (19.213.1.130)

Origin incomplete, metric 255, localpref 100, valid, internal, best

Local

19.213.1.154 (metric 1465856) from 19.213.1.154 (19.213.1.154)

Origin incomplete, metric 404, localpref 100, valid, internal

ecc#sh ip ro 19.213.1.130

Routing entry for 19.213.1.130/32

Known via "eigrp 777", distance 90, metric 1466112, type internal

Redistributing via eigrp 777

Last update from 19.213.0.1 on GigabitEthernet2/1, 3d14h ago

Routing Descriptor Blocks:

* 19.213.0.1, from 19.213.0.1, 3d14h ago, via GigabitEthernet2/1

Route metric is 1466112, traffic share count is 1

Total delay is 55010 microseconds, minimum bandwidth is 44247 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

19.213.0.9, from 19.213.0.9, 3d14h ago, via GigabitEthernet5/1

Route metric is 1466112, traffic share count is 1

Total delay is 55010 microseconds, minimum bandwidth is 44247 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

ecc#

=============================================================================================================================

SING#

SING#

SING#sh ip ro 19.210.108.16

Routing entry for 19.210.108.16/29

Known via "ospf 301", distance 110, metric 255, type intra area

Redistributing via bgp 65000

Advertised by bgp 65000 match internal external 1 & 2 nssa-external 1 & 2 route-map DENY_DEFAULT_TO_BGP

Last update from 19.210.101.186 on Serial3/1/1, 1d17h ago

Routing Descriptor Blocks:

* 19.210.101.186, from 19.211.102.65, 1d17h ago, via Serial3/1/1

Route metric is 255, traffic share count is 1

SING#

=============================================================================================================================

JAPAN#sh ip ro 19.210.108.16

Routing entry for 19.210.108.16/29

Known via "ospf 301", distance 110, metric 404, type intra area

Redistributing via bgp 65000

Advertised by bgp 65000 match internal external 1 & 2 nssa-external 1 & 2 route-map DENY_DEFAULT_TO_BGP

Last update from 19.210.51.2 on Serial4/1/1, 1d17h ago

Routing Descriptor Blocks:

* 19.210.51.2, from 19.211.102.65, 1d17h ago, via Serial4/1/1

Route metric is 404, traffic share count is 1

JAPAN#

Hello Victor,

we are saying the same things :)

rfc 1771

d) MULTI_EXIT_DISC (Type Code 4):

This is an optional non-transitive attribute that is a four

octet non-negative integer. The value of this attribute may

be used by a BGP speaker's decision process to discriminate

among multiple exit points to a neighboring autonomous

system.

Its usage is defined in 5.1.4.

and

If received over external links, the MULTI_EXIT_DISC

attribute may be propagated over internal links to other BGP speakers

within the same AS.

in your case the routes comes from OSPF to BGP with a MED BGP attribute = OSPF metric for effect of redistribution

no problem for me, how do you call it ?

BGP metric it is fine

it can only be a BGP attribute afterall.

Hope to help

Giuseppe

Giuseppe:

Fair enough. :-)

The reason why I make a distinction between a BGP MED and the IGP metric, as in this case as a result from OSPF redistribution, is that, when speaking of MEDs, I have always interpreted them as something that is deliberately configured to influence the path taken into an AS from another AS. It is true that the MED is reflected in the "metric" field of the BGP advertisement, but unless it was deliberately altered, I consider the case to be that MED is not being used and that the IGP metric is naturally occuring.

Lastly, just to be precise, the client is not trying to alter the IGP meteric/MED. He wants to influence the path that ECC and FMC take to get to the BGP next hop, which is SING. So, he is OK with keeping SING the BGP next hop/best path, but he wants to have ECC (if not FMC, too) route its traffic through JAPAN, in which case JAPAN will take the traffic and say "to hell with SING, I'll forward it to Australia myself, since I have a direct path."

SO, it seems that they want to use SING as the bait to attract the Australia-bound traffic, but then theyll alter the path ECC takes to get to SING by making a detour in JAPAN, and then have JAPAN forward the traffic to Australia directly on its own.

Makes sense? Is this a common approach?

Anyway, I dont want to digress.

I would still like to hear other people's suggestions for how to inlfluence the traffic to go through JAPAN.

Thanks

I apologize in advance if I did not understand your requirements in full, but this is not a CCIE-type scenario as you stated, but one of the hard realistic scenarios an engineer has to face in real work. When words that refer to geography (Europe, USA, Australia,etc) are used in BGP scenarios, typically some heuristic technique must be used (i.e. an approximate algorithm that works in most cases and still must be periodically reevaluated).

The detour you describe (ECC->SING->JAPAN) is not going to work so easily. For traffic to have chances to move from ECC to SING, you should keep local preferences equal. But here is the BUT: If packets make it to the SING router, they will exit from the SING router. You are trying to fool BGP, but BGP is too smart sometimes :-) BGP in the SING router will prefer the locally originated routes via redistribution (best path selection algorithm step 3: Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.) An even worse thing at SING is for SING to actually prefer the OSPF learnt routes. I just mentioned the BGP logic to make clear that changing OSPF default distance won't help without additional measures.

So, you have 2 options as I see it right now:

a) Stop the BGP algorithm at SING before step 3 of BGP best path selection (assuming you forced BGP to be the protocol of choice and not OSPF using distance command). You may consider changing the weight on routes received on SING. Weight is local to SING only, and you can set a higher value for routes received from JAPAN, while setting a low value for locally originated ones. I do not like weight parameter, but if you don't want to change your local preferences in general, this is your only choice before BGP algorithm step 3.

b) Push traffic from USA directly to JAPAN (without crossing SING). I am not analyzing this further, because it seems you want the detour to occur, probably for load balancing reasons. I know at least one case we were doing such a detour with local preferences desired to be equal, but we exploited other specific properties of our topology that do not apply in your case, and it's a story longer than your own :-) I might post it somewhere some time in the future, if I have the time to write it down!

marikakis:

Thanks for your input.

You have the scenario wrong.

The detour is not ECC to SING to JAPAN.

The traffic is already going from ECC to SING and then Australia.

The objective is to move traffic from ECC to JAPAN and Australia and get SING out of the picture.

Victor

I agree with Giuseppe on this. I would use local preference on the Japan router and this will then be sent to all IBGP peers within AS65000.

I would be interested to hear what that engineer promoting EIGRP metrics has to say though. Seems to me though that if you are using BGP you may as well make use of it's capabilities to determine routing policies.

Jon

yeah, Jon, I agree.

I mean, there are different ways to manipulate this situation. We can alter the BGP paths or manipulate the path to the existing BGP next-hop, which is what the client wants to do.

I agree with the Giuseppe, too. I would focus on changing local preference or setting the IGP metric/MED to make the JAPAN BGP peer the more favored one.

I think the issue is though if you are going to go to the trouble of running BGP in your network then you may as well use BGP to influence routing policy otherwise why bother running BGP at all.

A lot of times BGP is assumed to be needed when it isn't. Now it's not clear what else is happening in that network so it may well be that BGP is an integral part of it and maybe that's why it's running. Either way, if it's there i would use it rather than messing around with IGP metric.

Jon

Sorry if I got this scenario wrong. Still, when I read what you posted previously, I cannot undestand what you meant with the following:

SO, it seems that they want to use SING as the bait to attract the Australia-bound traffic, but then theyll alter the path ECC takes to get to SING by making a detour in JAPAN, and then have JAPAN forward the traffic to Australia directly on its own.

This pointed me to think they want to balance traffic from "anywhere" within AS6500 to JAPAN (and then Australia) over 2 paths . This can be the case if the direct link between ECC and JAPAN doesn't have enough bandwidth to handle the collective traffic to Australia. If you use local preference, a lot of traffic in the AS will use that link (e.g. from fmc). Are you sure this is what they want?

With what I suggested, traffic from fmc can go to JAPAN via SING (and then Australia), and traffic from ECC can use the direct link to JAPAN to go to Australia. This way, the direct link between ECC and JAPAN can be maintained at it's usual traffic rate.

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: