Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Blue

CCIE-Type Routing Question

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
Blue

Re: CCIE-Type Routing Question

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

Blue

Re: CCIE-Type Routing Question

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

Thanks

Hall of Fame Super Silver

Re: CCIE-Type Routing Question

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

Blue

Re: CCIE-Type Routing Question

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

Hall of Fame Super Silver

Re: CCIE-Type Routing Question

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

Blue

Re: CCIE-Type Routing Question

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#

Hall of Fame Super Silver

Re: CCIE-Type Routing Question

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

Blue

Re: CCIE-Type Routing Question

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

Re: CCIE-Type Routing Question

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!

Blue

Re: CCIE-Type Routing Question

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.

Hall of Fame Super Blue

Re: CCIE-Type Routing Question

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

Blue

Re: CCIE-Type Routing Question

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.

Hall of Fame Super Blue

Re: CCIE-Type Routing Question

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

Re: CCIE-Type Routing Question

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.

Hall of Fame Super Silver

Re: CCIE-Type Routing Question

Hello Jon,

playing with IGP metrics should always be the last resort.

Besides this, I think it doesn't work in this case without also changing the BGP attributes of the route:

the current situation of the displayed route shows that the best route has the lowest BGP metric and it is chosen even if the EIGRP metric to BGP next hop is higher then that of the other route.

This happens for the sequence of criteria used by BGP for path selection.

So changing EIGRP metric is useless in this specific case without other actions on BGP.

Hope to help

Giuseppe

Re: CCIE-Type Routing Question

If I am wrong, then the scenario is simple enough to be handled with the local preference, as is the usual in such cases. Ask the engineer why local preference does not solve its issue and starts thinking of wild things.

Ok, the more I read this, the more I am thinking I might be right. Engineer tries to attract some traffic to JAPAN from ECC, but doesn't want all traffic in the AS to use the direct link, so he starts playing with the EIGRP metrics, instead of playing a bit with BGP on SING, because packets that reach SING have to go out SING as I said before. A little work on SING can stop traffic from exiting via SING, as I described previously (SING2 might also need some work to avoid a loop).

Hall of Fame Super Blue

Re: CCIE-Type Routing Question

Giuseppe

"playing with IGP metrics should always be the last resort"

I totally agree. Was there something i wrote that suggested otherwise because i thought i was suggesting the same as you ie. use local preference.

Jon

Re: CCIE-Type Routing Question

Most people don't play with metrics for fun because they lead to confusing and unscalable setups. It looks like this guy is in a last resort situation (load balancing internally issues are not uncommon) and might actually make it in the end. All this guy needs for load balancing to work is to reset the MEDs to zero. Then best path selection algorithm will go further down, and the lowest IGP metric to the BGP next hop from each router in the AS will be used to balance the traffic, so is close to a solution that will distribute traffic over the links to Australia. When someone suggests the weird, try not think they don't know what they are doing.

Blue

Re: CCIE-Type Routing Question

Giuseppe:

"Besides this, I think it doesn't work in this case without also changing the BGP attributes of the route:

the current situation of the displayed route shows that the best route has the lowest BGP metric and it is chosen even if the EIGRP metric to BGP next hop is higher then that of the other route."

I think you are confusing the issue. The client is not trying to influence the BGP selection process. The client is satisfied with leaving the SING router as the BGP next-hop for ECC and FMC to reach Australia. What the client is trying to change is the eigrp route from the FMC and ECC routers to the SING router, and that has nothing to do with the Australia IGP metrics that the SING router is advertising.

Hall of Fame Super Blue

Re: CCIE-Type Routing Question

I'm confused now :-).

My understanding was that FMC & ECC have IBGP routes to the Australian networks which have been redistributed from OSPF.

So what i think Giuseppe is saying is that it doesn't matter what you do to the EIGRP metrics, FMC & ECC will choose the best path from the IBGP routes. The best path is SING and that is the one they will use.

Now i thought the question was how to make FMC & ECC see JAPAN as the best route and the answer is local pref. This is by far the cleanest solution to the problem and i would have thought the most logical for anybody else coming along later to understand.

Having FMC & ECC see SING as the best route but sending the traffic via JAPAN so that JAPAN sends the traffic is just overcomplicating things. If you were the next network administrator coming along that would not be an obvious solution to the initial problem.

The other point i was making is if the client wants to mess around with metrics why bother with BGP at all. Just run OSPF on all routers and then influence the OSPF metrics directly.

Maybe i'm missing something here and as Maria pointed out it's not that i'm assuming the engineer proposing the EIGRP solution doesn't know what he is doing. He may have a very good reason for what he is proposing. It's just not obvious at the moment.

Jon

Blue

Re: CCIE-Type Routing Question

"My understanding was that FMC & ECC have IBGP routes to the Australian networks which have been redistributed from OSPF."

Correct.

"So what i think Giuseppe is saying is that it doesn't matter what you do to the EIGRP metrics, FMC & ECC will choose the best path from the IBGP routes. The best path is SING and that is the one they will use."

Correct, although I think Giuseppe was saying something else. I think he is under the impression that the purpose the client has of changing the eigrp delay metric on the ECC and JAPAN routers is to affect the selection of the BGP next-hop, which of course is completely wrong. They are not trying to do that at all. The IGP metric they want to change is the EIGRP delay so that ECC and FMC take a route through JAPAN on their way to SING, which of course they never reach because JAPAN is going to send the traffic directly over to Australia itself. If that's not what he means, then he is correct, too. Sorry, Giuseppe, your foreign English throws me off sometimes. :-)

"Now i thought the question was how to make FMC & ECC see JAPAN as the best route and the answer is local pref. This is by far the cleanest solution to the problem and i would have thought the most logical for anybody else coming along later to understand."

Correct, once again. And I agree 100%.

"Having FMC & ECC see SING as the best route but sending the traffic via JAPAN so that JAPAN sends the traffic is just overcomplicating things. If you were the next network administrator coming along that would not be an obvious solution to the initial problem."

Correct and I agree. I would not take this approach. I would take the more direct approach of making JAPAN the next-hop router by manilpulating the BGP attributes (local pref, etc).

"The other point i was making is if the client wants to mess around with metrics why bother with BGP at all. Just run OSPF on all routers and then influence the OSPF metrics directly."

I agree and understood your point.

"Maybe i'm missing something here and as Maria pointed out it's not that i'm assuming the engineer proposing the EIGRP solution doesn't know what he is doing. He may have a very good reason for what he is proposing. It's just not obvious at the moment."

You are not missing anything, given what I have told you, which is all I know atthis moment.

You are not confused but right on target.

Victor

Re: CCIE-Type Routing Question

Victor,

I am not the type of person that insists on something just so my own solution is the selected one (and so I get the points in this case)! I am more practical than this, and I only care if an issue is resolved, no matter who does it! I was actually very busy last night, but still decided to respond, because I thought I might help.

You have not still responded in my previous post about what using SING as "bait" and "detour" mean. If those were the words of the client, then the client might be trying to tell you something here. This sounds to me as if some traffic to Australia is the 'mouse', SING is the 'cheese' and detour is the path via SING2 to JAPAN. The mouse goes to the cheese, and instead of trapping and killing it, you reroute the mouse to go out of the house (AS) through the JAPAN door to live in Australia! This metaphor is so cute, I think I am going to cry in the end if I am wrong :-)

This issue is either very simple and can be solved with local preference us others have suggested from the beginning or is not.

If it is not, I have already provided guidelines. It is common for one type of traffic change to affect other links. This network was using the SING path to go to Australia. When they switched the traffic to go via JAPAN (probably with local preference), they might have noticed the direct link between ECC and JAPAN got overloaded. It is very hard doing traffic engineering using local preference, because it causes a lot of traffic to go in one direction only. If IGP metric to BGP next-hop is used (after reseting the MEDs to zero or make them equal), you could have some type of closest exit routing (and you can overcome altogether the exit via SING, by turning traffic to go via SING2 to JAPAN).

Kind Regards,

M.

Re: CCIE-Type Routing Question

Note also, that setting local preference will cause traffic to Australia through SING router (which may have other sources of traffic for Australia via other of its interfaces), will choose to go to Australia via JAPAN, and will not use the direct link it has with Australia (which might not be a desired thing to happen). Unless OSPF steps in and fixes this.

Jon, maybe my phrase "don't know what they are doing" sounded somewhat rude, but written speech has those type of issues. I know how helpful all of you are. I meant that when someone tries to do weird things, those things might point to the problem at hand. Sometimes clients provide little information or if they are engineers assume you will understand what they are getting at by using jargon. And such issues are a little bit of a chess backtracking procedure: if this is their move now, what was the situation in the chessboard before they made this last move?

Also, when I said previously that client does "wild things", in the same sentence I said to ask why local preference does not resolve its issue, so there I assume client probably already did that and saw something bad happening, so tries to seek consultancy, because from this point the case is not trivial.

Re: CCIE-Type Routing Question

One last probability is the following: There is not a problem with the bandwidth utilization of any links in the AS after setting local preference, but some traffic that reaches SING via some of its interfaces (e.g. from SING2 to SING in the case SING2 does not have full routing, I am not even sure if SING2 runs BGP at all from the diagram) keeps exiting via SING. OSPF might be the reason for this and changing the administrative distance for OSPF or BGP on SING might solve this. This is a more normal scenario than the one I was thinking up to now. It also explains a bit why the client is trying to attract traffic towards JAPAN by changing EIGRP metrics. Some type of traffic might keep exiting via SING even after setting local preference.

Re: CCIE-Type Routing Question

If this is the case, then the mouse story changes a bit and becomes: mouse comes from SING2 (SING2 might just have some default towards SING) to cheese (i.e. SING) and needs to be diverted towards FMC and run a circle to exit via the JAPAN door.

Blue

Re: CCIE-Type Routing Question

Mari:

Easy there, young lady! I appreciate your efforts. I didnt respond to you because I was in the middle of an in-depth discussion with Giuseppe and Jon, which can actually help you understand exactly whats going on if you read it.

Im not even going to attempt to unravel your mouse, cheese and house analogy. Sorry, but it is way too complicated for a simpleton, like me. :-)

I think we may have beat this topic to death by now. I will talk to the client to try to unravel his logic and see if he is making any sense.

Thanks, folks!

Victor

Re: CCIE-Type Routing Question

Victor,

I am almost 32 now and not sure if this is very young! :-) I have read the posts again and I won't mention the load balancing scenario again, although it is not an unrealistic requirement for the future if the JAPAN link to Australia starts experiencing similar issues as the SING link to Australia. In such a case, resetting the MEDs and using closest exit routing using IGP metrics might be a solution, so keep that in mind for future reference. In the ISP environment I was working in the past such issues were very common, so be prepared because this network is not very much different in logic as potential segment of an ISP network.

Typically, an engineer who has BGP configured in various countries and in more than say 2 routers, has to know BGP better than an engineer who only has 1-2 BGP connections in a single router towards its upstream(s). Local preference is the first thing an engineer that works with BGP learns to manipulate traffic. Such an engineer might get frustrated if the consultant that is giving them advice suggests the typical solution, because it might have been the very first thing that crossed their minds as well and they called for help to hear something more.

From my experience, there are particular phrases in client information that are key to see the solution, even if non-technical terms are used, so a consultant has to notice all the details to avoid frustrating the client and be prepared for various potential issues and solutions to give to the client directly or be prepared to ask the client the right questions. In this case I might went too far with my imagination, but you asked for more opinions in the first place, and I wanted to inform about potential issues. Clients sometimes might know their networks so well, that they don't bother to mention important details, because in their heads they are taking them for granted, and speak as if you knew their networks from day one and you can figure what they need now without expicit stating. I might have overestimated the client's knowledge in this case, but I have seen underestimation of others leading to worse results (i.e. we would not call our consultants anymore, because we knew they would suggest something we did 10 steps before).

In the end, it is always good to hear that problems are less hard than expected and typical solutions can be used. There is a well know saying that suggests to keep things simple, and I try to follow that. Whatever I might imagine, I don't put to practice for no good reason.

Kind Regards,

Maria

Re: CCIE-Type Routing Question

If you look back in this conversation, you will see all I was trying to do was to through some ideas before client responds, so you are more prepared and client keeps calling you in the future. I could just wait for the client to respond and wash the dishes instead like a good lady! :-)

Re: CCIE-Type Routing Question

Victor,

In another case you opened, I see that you are now making the MEDs equal. It would be nice to hear what happened in this case and why for future reference when you are done with this and you have more time, not only for all of us, but also because a conversation (although admittedly long) that has the specific title you chose in the first place is expected to be considered interesting for many people. :-)

Kind Regards,

Maria

209
Views
38
Helpful
42
Replies