Bootcamp with Narbik – Day 4 Comments

B

Narbik focused on BGP throughout day 4.  One of Narbik’s lecturing distinctives is that he explains the “why” of something before he explains the “how”.  In other words, he didn’t stand up there and say “We all know that iBGP peers are expected to be full mesh, but what options can we use to avoid the full mesh requirement?”  Yes, he got to that point eventually, but he started off explaining the evolution of the BGP protocol, the issues that designers were facing, decisions that were made along the way that may have solved an immediate issue but didn’t scale as the Internet grew, and then what was done to address scalability.  Only then did he get into the mechanics of it all.

Important to Narbik is that his students understand the original purpose of the command they are configuring.  His logic is that if you understand WHY a particular feature exists, it won’t be as hard as it might otherwise be to configure a seemingly obscure lab task.  Now, Narbik has a way of pushing the boundaries of a technology, too.  He can take a command and use it in a way that’s beyond its original intention to accomplish what he describes as “double-0-seven” stuff.  But he makes sure you have a good understanding of it all first.

Here are a few miscellaneous notes I jotted down over the course of the day.

  • A default route cannot be used to establish a BGP peer.  In other words, for a BGP adjacency to form, there must be a specific route in the routing table for the BGP neighbor you need to reach.
  • Next-hop-self is only effective on AS border routers, not on iBGP to iBGP.  I’ve run into this in lab exercises, and never understood why next-hop-self sometimes worked and sometimes didn’t.
  • “show ip bgp comm x” will display all routers on a router tagged with community “x”.
  • When you have a “match” and a “set” in a route-map, don’t forget to include a catch-all route-map entry at the bottom for a permit if needed.
  • “bgp bestpath as-path ignore” is a hidden command. This command overrides as-path in bestpath algorithm. This is a hidden because disabling as-path is generally a really bad idea – it can cause routing loops.
  • “bgp bestpath med missing-as-worst”. If the advertised route does not have a med assigned, assume the med value to be the highest possible, i.e. the worst possible.
  • Order of attributes/bestpath selection.
    • Weight
    • Local-pref
    • Network
    • AS-path
    • Origin
    • Med
    • eBGP over iBGP
    • If routes are internal:
      • If max-paths > 1, choose IGP with the lowest metric to the destination next-hop
      • If metrics match, oldest route.
    • If routes are external
      • Oldest route.
      • If bgp bestpath compare router-id, lowest RID.
      • If RIDs match, lowest IP address.
  • “debug ip policy” allows you to see what packets matched or didn’t match a PBR route-map and where the packet was forwarded as a result.

4 comments

  • Hi Ethan,

    Great to hear that you are enjoying yourself!

    I have been following your blog and numerous others for some time now.

    I am going to be taking my CCIE R&S written in the next couple of weeks and it seems strange that some of the commands/highlights which you (and others) post in your blogs I take as gospel, in terms of preparation for the IE written. A few weeks back I remember reading that you had posted that x No. of blogs since you started out on the IE path and that although you didn’t have the time if you was to reread some of your old posts you might learn a thing or two!

    From what I can gather the IE Lab requires a different mindset than the approach taken towards the written? Given your time again (heh, have we not been here before!) would you have started supplementing your lab studies earlier with re-reads of your IE written notes/elective study material?

    Good luck to you all on Narbicks’ Bootcamp, keep up the very informative posts.

    Regards,

    FredBloggs

  • Ethan,
    Thanks for the BGP tip. I labbed this up and you and Narbik are correct. Below is the bgp message when you try to peer via default routes on both routers. Interestingly if you add a specific route on one of the bgp peers the peer will come up even with the other not having a specific route.

    *Mar 1 00:48:24.187: BGP: 101.101.101.101 active open failed – no route to peer, open active delayed 31154ms (35000ms max, 28% jitter)
    R1#sh ip bgp

    Here is the config
    router bgp 1
    no synchronization
    bgp log-neighbor-changes
    neighbor 101.101.101.101 remote-as 5
    neighbor 101.101.101.101 ebgp-multihop 255
    neighbor 101.101.101.101 update-source Loopback999
    no auto-summary
    !
    ip route 0.0.0.0 0.0.0.0 Serial1/1

    R3 in the middle has specific routes to both routers.

    router bgp 5
    no synchronization
    bgp router-id 5.5.5.5
    bgp log-neighbor-changes
    neighbor 9.9.9.9 remote-as 1
    neighbor 9.9.9.9 ebgp-multihop 255
    neighbor 9.9.9.9 update-source Loopback101
    no auto-summary
    !
    ip route 0.0.0.0 0.0.0.0 4.4.4.3
    !

  • There is an interesting corollary to the “next-hop” thing. As you have implied, the default for an EBGP peering is “next-hop-self”, whereas the default for an IBGP peering is “next-hop-unchanged”. You can change to the other one by specifying so in the neighbor peering commands.

    BUT … even if you do a next-hop-self for a route-reflector-client, then it is ineffective on the reflected routes. In other words, you cannot get the route-reflector to insert its own address as next-hop, even with next-hop-self.

    I got caught out with that in a lab just last week.

  • AARGHHHH!! I was trying to get two routers, connected to a switch by access links (not trunks), to come up as BGP neighbors. I had GOLR routes on them. I was wanting to use loopback interfaces too. The two routers wouldn’t form because I didn’t have specific static routes on each that directed to the others’ loopback interfaces!!

    I spent all day trying to get this working. Thanks for that tip about BGP not working with GOLR routes. Once I put the specific routes in place, the two became neighbors.

    Sometimes this can be soooo frustrating!! Please keep pushing out the advice. I’m not an expert yet (but I’m not a beginner either) it’s just that I’m less experienced with BGP, route-maps, etc.

    I’m trying to figure out how to take the remotely triggered black-hole filtering idea and twist it to redirect packets to a sink-hole instead. I’m further along with this now. Thank you :)

By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.

Newsletter