03-10-2009 07:31 PM - edited 03-04-2019 03:53 AM
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,
03-10-2009 09:13 PM
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
03-10-2009 09:20 PM
03-11-2009 02:16 AM
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
03-11-2009 07:03 AM
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
03-11-2009 07:25 AM
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
03-11-2009 08:21 AM
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#
03-11-2009 08:32 AM
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
03-11-2009 09:40 AM
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
03-11-2009 11:55 AM
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!
03-11-2009 12:04 PM
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.
03-11-2009 12:27 PM
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
03-11-2009 12:46 PM
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.
03-11-2009 12:52 PM
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
03-11-2009 01:29 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide