BGP Metric question

Why is it that some routes received from external AS have metric of 0, while others have nothing set for metric?

thanks

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

catalinu

That is the default behavior.

Metric = MED = influence the traffic coming into your as/network , and lower value for MED is preffered.

to view all details regarding a prefix in bgp use : show ip bgp prefix

Hope that it helps..

acidsatyr

I wasn't clear enough; I know what MED is, but question is why is it that some routes do not have med set while others do?
With sh ip bgp x.x.x.x the routes that have med of 0 will say "metric 0". The ones that don't will say nothing about metric.
Is it because metric has to be explicitly set to be included?
If so in my lab i didn't explicitly do it, and some routes just don't have metric while others do.

catalinu

MED attribute is exchanged only between bgp peers/neighbors , for sure routes learned from other ebgp peers more far away , will not have a MED set , unless you have under your bgp process a default-metric specified.

Forsaken_GA

acidsatyr wrote: »

I wasn't clear enough; I know what MED is, but question is why is it that some routes do not have med set while others do?
With sh ip bgp x.x.x.x the routes that have med of 0 will say "metric 0". The ones that don't will say nothing about metric.
Is it because metric has to be explicitly set to be included?
If so in my lab i didn't explicitly do it, and some routes just don't have metric while others do.

Next time this happens, look at your IGP.

Forsaken_GA

Actually, I'll be a little less coy and explain what I mean -

Quick and dirty test setup

R1 (AS3) --EBGP-- R2 (AS1) --IGBP-- R4 (AS1)

If I'm learning prefixes on R2 from R4 via IBGP, this is what my routing table looks like on R2:

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 4 subnets
B 172.16.200.0 [200/0] via 172.16.1.2, 00:03:48
C 172.16.20.0 is directly connected, Serial0/0.201
B 172.16.10.0 [200/0] via 172.16.1.2, 00:03:48
C 172.16.1.0 is directly connected, Serial0/0.204

And this is what my bgp table looks like:

Network Next Hop Metric LocPrf Weight Path
*>i172.16.10.0/24 172.16.1.2 0 100 0 i
*>i172.16.200.0/24 172.16.1.2 0 100 0 i

This is what the BGP table looks like on R1:

Network Next Hop Metric LocPrf Weight Path
*> 172.16.10.0/24 172.16.20.2 0 1 i
*> 172.16.200.0/24 172.16.20.2 0 1 i

No metrics are set at all

Now, if I bring up OSPF between R2 and R4, this is what my routing and BGP tables look like on R2:

172.16.0.0/24 is subnetted, 4 subnets
O 172.16.200.0 [110/65] via 172.16.1.2, 00:00:06, Serial0/0.204
C 172.16.20.0 is directly connected, Serial0/0.201
O 172.16.10.0 [110/65] via 172.16.1.2, 00:00:06, Serial0/0.204
C 172.16.1.0 is directly connected, Serial0/0.204
R2#sh ip bgp
BGP table version is 7, local router ID is 172.16.20.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.10.0/24 172.16.1.2 65 32768 i
* i 172.16.1.2 0 100 0 i
*> 172.16.200.0/24 172.16.1.2 65 32768 i
* i 172.16.1.2 0 100 0 i

And this is what my bgp table looks like on R1:

Network Next Hop Metric LocPrf Weight Path
*> 172.16.10.0/24 172.16.20.2 65 0 1 i
*> 172.16.200.0/24 172.16.20.2 65 0 1 i

Now I have metrics in both tables, and those metrics are being propagated to my EBGP peer

router bgp 1
no synchronization
bgp log-neighbor-changes
network 172.16.10.0 mask 255.255.255.0
network 172.16.200.0 mask 255.255.255.0
neighbor 172.16.1.2 remote-as 1
neighbor 172.16.20.1 remote-as 3
no auto-summary

As you can see, I'm statically announcing the networks, no redistribution going on (though redistribution will also do this)

Basically, when you inject a route into BGP, it'll look at the local routing table to make sure it has a route there (otherwise it won't insert it). If there *is* a route there, it takes the metric from that route and inserts that metric into the BGP table, which it will then propagate out to it's EBGP peers. If the route is being learned through iBGP, then the metric is 0 (unless you're setting one on purpose). If I'm learning it through an IGP, then it'll have the IGP's metric. In this case, since I'm using OSPF, and OSPF has a smaller administrative distance than iBGP, the OSPF routes are what are in my local routing table, so when bgp goes to do the reachability lookup, it's using the OSPF route, and therefore, the OSPF metric. So if I'm using an IGP to establish my internal connectivity, I'm propagating metrics I probably do not mean to, and this can have consequences on my ingress traffic flow. However, the EBGP peer I'm propagating those metrics to will not propagate them out further. For example, if I bring up R3 as AS4 and peer with R1 in AS3, the bgp table looks like the following:

Network Next Hop Metric LocPrf Weight Path
*> 172.16.10.0/24 192.68.6.1 0 3 1 i
*> 172.16.200.0/24 192.68.6.1 0 3 1 i

As you can see, my networks are propagating, but not the metrics (as is proper, MED's should only be propagated between 2 AS's and no further)

I hope the novel makes sense, this is one aspect of BGP behavior that's not very well documented. It's also a good explanation of why best practice is to set your MED's on outgoing routing updates on purpose, even if you're not going to use MED to influence your ingress traffic flow

Forsaken_GA

And to get even further in depth!

You'll notice in the BGP table for R2 that after I brought up OSPF, there are two entries for each route. One set of routes is there form my bgp announcement from my peer. The other set is because I'm statically originating the routes, and it's doing the lookup for those routes locally, and finding them via OSPF. The reason it's propagating those routes is because when you originate a prefix with the network statement, it sets the weight on that router to the maximum (3276

. Since in Cisco's BGP implementation, the proprietary weight attribute is the first consideration, that automatically means it's going to be flagged as the best route. And BGP *only* propagates the best route to other peers, so the route with the metric is what gets sent.

If I removed the static network announcements from R2 and then reset the BGP session, the only routes in R2's bgp table will be the ones learned via IBGP (though they'll show RIB failure, since I already have OSPF routes in the table, and those have a lower AD). But I will then only propagate out the routes I learned via IBGP with no metrics.

Now, this works, but it's also a really bad idea, because it means that peer has to be up in order to provide reachability between my two AS's. Since the peer that's originating them is an internal peer, and since R2 is a border router, that means that if R4 goes down, I'm essentially black holed from the rest of the world, even though my border router is still up and running. Whatever goes on inside my AS shouldn't effect the view of my AS from the outside world. If I'm having internal flapping problems, the last thing I want is for my border routers to flap the routes too and cause my routes to get dampened. (and yes, with the situation I have above, that would still happen unless I took other measures, like static routes with very high AD's pointing towards Null0 for the sole purpose of making sure my border routers *always* have a route to my prefixes in it's routing table)

This is why I'll statically announce my prefixes from my border routers, and set my MED's on the outgoing routes to 0 if I'm not going to use them to influence ingress traffic.

BGP is half route propagation, and half traffic engineering, and occasionally the two step on each others toes, it's those cases you have to be careful of

You could also fix the problem by running statically originated networks (or redistributed networks) through a route-map which sets their weight to 0, which would match the IBGP weight. The iBGP route would then be selected as the best one because it has a higher local preference. I don't like doing this because again, I want my MED's to be specifically set to what I want them to. I don't want to let anything possibly influence them that I didn't consider, so I want my metric to be determined by me, and we do indeed set our MED's to 0 on the outbound at work, using communities and AS_PATH prepending to influence the ingress instead

pwg61

GREAT response Forsaken_GM. You know your shite! Would you mind if I asked you some BGP based questions? I'm new here and really don't yet know how to navigate the site.....but came across your response to this question asked. Thanks. Pete.