Quick BGP Challenge

Change the origin of the received routes from R3 so they are preferred.

good lab, will take a look and respond soon.

jason_lunde

Does it have to be bgp related (i.e. attributes). I can think of some bgp ways, and non-bgp ways. does it matter?

I didn't specify, but I'm really looking for BGP modifications.

Turgon's idea is one way. There are a ton more.

My first though was Turgon's idea, but you can also use a route-map to set MED.

WRKNonCCNP

Prepend AS hops to the 192.168.1.0/24 prefix received from R2 to make it less preferred than the path through R3.

AS Path prepending and MED will not work for this task, well it will work for traffic inbound to AS 100. But, Those BGP attributes are for traffic returning to R1, not leaving R1.

The task says not to use local pref and Weight, so I am assuming that the OP wants an answer on how traffic will leave AS 100 and take R3 to 192.168.1.0/24.

i have a few ideas that may involve conditional advertisements. gonna lab it up real fast and I'll post back.

CCIEWANNABE wrote: »

AS Path prepending and MED will not work for this task, well it will work for traffic inbound to AS 100. But, Those BGP attributes are for traffic returning to R1, not leaving R1.

The task says not to use local pref and Weight, so I am assuming that the OP wants an answer on how traffic will leave AS 100 and take R3 to 192.168.1.0/24.

i have a few ideas that may involve conditional advertisements. gonna lab it up real fast and I'll post back.

The question states to have R1 choose the route through R3. If you use an inbound route-map on R1 to set the MED lower from R3 then it will choose that path. Why do you say that wouldn't work?

CCIEWANNABE wrote: »

AS Path prepending and MED will not work for this task, well it will work for traffic inbound to AS 100. But, Those BGP attributes are for traffic returning to R1, not leaving R1.

The task says not to use local pref and Weight, so I am assuming that the OP wants an answer on how traffic will leave AS 100 and take R3 to 192.168.1.0/24.

i have a few ideas that may involve conditional advertisements. gonna lab it up real fast and I'll post back.

You're thinking too inside the box, lol.

If you set a route-map on R1 applied to R2 or R3 inbound, you can do a lot of the same tricks you would do outbound on R2 or R3.

ColbyG wrote: »

I didn't specify, but I'm really looking for BGP modifications.

Turgon's idea is one way. There are a ton more.

Many ways to skin a cat. For the IE always look at the simple way first and rule in/out accordingly. Cost community isn't an option as the peer is iBGP. There are various options available but if it meets requirements keep it simple! Playing with attributes opens up all kinds of possibilities.

yeah, i guess you can use MED and AS Path Prepend on R1 inbound.

Good thinking on that one guys. I don't know what i was thinking :]

Also, you can filter 192.168.1.0/24 inbound on R1 by using a prefix list which deny's the inbound route from R2 under the bgp neighbor statement.

Turgon wrote: »

There are various options available but if it meets requirements keep it simple! Playing with attributes opens up all kinds of possibilities.

+1 for this comment...

Awesome playing with some of the things that BGP can do.... however... more often than not the simplest solution is always the best....

Without LP or Weight.... (I hate using weight...).... Prepends,MED or Origin manipulation are definitely some of the best solutions....

Conditional route advertisement via advertise-maps\no-advertise-maps would be a nasty little option if you wanted to go down that route.....

Obviously the simplest answer which accomplishes the goal is the best...

But the point of things like these are to get us all to think outside of the box and get an even better graps of the fundamentals.

If you guys aren't interested I won't post more of them. After the last one I thought there would be interest.

APA wrote: »

+1 for this comment...

Awesome playing with some of the things that BGP can do.... however... more often than not the simplest solution is always the best....

Without LP or Weight.... (I hate using weight...).... Prepends,MED or Origin manipulation are definitely some of the best solutions....

Conditional route advertisement via advertise-maps\no-advertise-maps would be a nasty little option if you wanted to go down that route.....

I'm not making the connection with an advertise/no advertise map. Could you elaborate on how that'd work here?

ColbyG wrote: »

Obviously the simplest answer which accomplishes the goal is the best...

But the point of things like these are to get us all to think outside of the box and get an even better graps of the fundamentals.

If you guys aren't interested I won't post more of them. After the last one I thought there would be interest.

Post more. Always good to exercise the brain. It is good to point out this is for fun, not actually trying to find the perfect production answer.

ColbyG wrote: »

Obviously the simplest answer which accomplishes the goal is the best...

But the point of things like these are to get us all to think outside of the box and get an even better graps of the fundamentals.

If you guys aren't interested I won't post more of them. After the last one I thought there would be interest.

I think you should post more of these. It encourages people to get out of their books and use the knowhow to solve a problem collectively. That's a good thing.

haha... I left out half of my sentence there....

It should say...

If wanting to have a symmetric path so that traffic to R1 would also use the path via R3....Conditional route advertisement via advertise-maps\no-advertise-maps would be a nasty little option if you wanted to go down that route.....

Its not that we aren't interested dude....... just most of us are use to coming up with quick solutions to everyday issues...... hence why we have come up with the 'fundamental solutions' so far....

What other options have you come up with?

Off the top of my head without labbing.... you could also...

- set metric-type on inbound...thus using the IGP metric as MED instead of statically setting the MED yourself on inbound, this would then allow you to manipulate IGP costs to tailor your needs.

- Without BGP changes could use policy-based routing to direct traffic for 192.168.1.0 over the path via R3... however this would be a convoluted setup, but still a valid option.

Also +1 for posting more of these challenges....

I'm still not getting how the conditional advertisements would work here. We're talking about configuration on R1 only. Also, I'm a bit confused about the IGP metric suggestion. IGPs don't really come into play here, that I can see.

My solutions:

-Set MED on R1 for incoming updates from R2 or R3.
-My favorite: Change the next hop to something unreachable on R1 for incoming updates from R3.
-Set the origin on R1 for incoming updates from R2 or R3.
-Prepend R1's own AS on updates coming from R3, causing the route to be ignored.
-Prepend on R1 for incoming updates from R3, causing R2's route to be preferred.

Those are the ways I thought of before posting. People have come up with other interesting solutions.

You can also set the next hop to R3 on updates from R2 for the desired network.

Yea, someone else mentioned that to me. It's brilliant.

ColbyG wrote: »

I'm still not getting how the conditional advertisements would work here. We're talking about configuration on R1 only. Also, I'm a bit confused about the IGP metric suggestion. IGPs don't really come into play here, that I can see.

1) I was talking about making the return traffic use only the R3 path via conditional ads... slightly off topic...

2) 'set metric-type internal' = I have used it on outbound route annoucements and works a treat.... - but ignore this... quite clearly I am daydreaming over here.... as you wouldn't be running an IGP between the eBGP neighbors.... so its a fruitless exercise setting on inbound...

BTW - Your original question implies that you still want to receive the inbound route from R2 but prefer to use R3 at all times... some of your solutions hard-set routes from R2 to be unreachable therefore losing route visibility via R3 would blackhole traffic to 192.168.1.0/24.

Yep I like networkers last solution.... next-hop hacks are an engineers best friend... however for reasons stated above can cause issues if R3 went missing....

Hmmz....... now this has got me thinking about some other funky methods to make this happen...

APA wrote: »

BTW - Your original question implies that you still want to receive the inbound route from R2 but prefer to use R3 at all times... some of your solutions hard-set routes from R2 to be unreachable therefore losing route visibility via R3 would blackhole traffic to 192.168.1.0/24.

Yea, the goal was the install the route from R3 with no mention of failover to R2 in the event of R3 becoming unavailable. I should have been more specific and said the route from R2 never needs to be used or something like that.

Though you could probably rig some IP SLA stuff to conditionally change R3's next hop, where it would accept the route unchanged in event that R2 was unreachable. That gets a bit silly though, lol.

ColbyG wrote: »

Yea, the goal was the install the route from R3 with no mention of failover to R2 in the event of R3 becoming unavailable. I should have been more specific and said the route from R2 never needs to be used or something like that.

Though you could probably rig some IP SLA stuff to conditionally change R3's next hop, where it would accept the route unchanged in event that R2 was unreachable. That gets a bit silly though, lol.

Not as silly as shutting down the R1 interface to R2. That would work but would be really silly

That's crazy talk!

Forsaken_GA

I see I'm a little late to this party....

Within the rules, I'd just PBR traffic to that subnet out of the interface going to R3. It's the next simplest method that doesn't increase the complexity too terribly much.

If I was implementing a situation where I needed R3 as the preferred path in the real world, I'd use a route map to set the route from R3 to a higher local pref, which is what I imagine everyone else would do, which is why you made it against the rules hehe

ColbyG wrote: »

I didn't specify, but I'm really looking for BGP

cough
sneeze

prefix list filtering anyone?