Reading Greg Ferro‘s regular entries to his Network Dictionary, I’m reminded that I occasionally get accused of making up my own terminology. Sometimes though, there’s not a nice clean way to describe the thing you want to describe and when it’s an idea you need to convey frequently, you’re bound to end up with some kind of shorthand.
So here’s my terminology confession for the day.
To Prop Up a Route
Usage
“You’ll need to advertise that prefix in your IGP in order to prop up the BGP route.”
Explanation
When you configure a BGP network statement, it doesn’t actually generate that particular NLRI unless there’s also an exactly matching prefix in the forwarding table, presumably either learned through a dynamic routing protocol or configured as a static route. You need that non-BGP route present in order to support the generation of the BGP NLRI, right? The (let’s say dynamically learned) route “props up” the BGP route. It supports it. It’s the thing that holds the BGP NLRI in place. If you lose the supporting route, the BGP NLRI is withdrawn – it falls down. And so, the idea that one route ‘props up’ another one was born, and the phrase fell comfortably into my lexicon and got used frequently, as it was a common problem that people were not making sure the NLRI they wanted to generate in BGP was actually being learned from somewhere first.
Hence, “you’ll need to make sure you advertise that subnet in OSPF in order to prop up the BGP route” or “It’s not being advertised in BGP because there’s nothing to prop it up.”
Look, it worked for me, ok?
Leave a Reply