Tag: BGP
Categories
MUM 2019 presentation on BGP
For those of you not able to attend the US MUM presentation here is my presentation slides in PDF for my BGP session. 200 meg download.
Categories
Cisco VRF route leaking…on purpose
Become a Patron to see this content
Unlock with Patreon
“I can feel it calling in the lab tonight…oh Lord”
Some of you will get that reference.
Look for some lab tutorials coming soon. Some of these will be for Patreon only subscribers, and some will be public. Make sure to subscribe to Patreon on the linjk below.
It’s official. Day 1, last presentation of the day. https://mum.mikrotik.com/2019/US/info/EN
https://thenetworkcollective.com/2018/11/st-bgp-optimal-route-reflection/
Categories
BGP Monitoring RFC 7854
https://tools.ietf.org/html/rfc7854
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.
Categories
What is a BGP Confederation?
In network routing, BGP confederation is a method to use Border Gateway Protocol (BGP) to subdivide a single autonomous system (AS) into multiple internal sub-AS’s, yet still advertise as a single AS to external peers. This is done to reduce the number of entries in the iBGP routing table. If you are familiar with breaking OSPF domains up into areas, BGP confederations are not that much different, at least from a conceptual view.
And, much like OSPF areas, confederations were born when routers had less CPU and less ram than they do in today’s modern networks. MPLS has superseded the need for confederations in many cases. I have seen organizations, who have different policies and different admins break up their larger networks into confederations. This allows each group to go their own directions with routing policies and such.
if you want to read the RFC:https://tools.ietf.org/html/rfc5065
Categories
UBNT EDGEMAX 1.10.3 update route flushing
From UBNT:
New features:
Offloading – Add CLI commands to disable flow-table flushing in offloading engine when routing table changes: set system offload ipv4 disable-flow-flushing-upon-fib-changes set system offload ipv6 disable-flow-flushing-upon-fib-changes
Discussed here
Prior to 1.10.3 firmware flow-table in offloading engine was always flushed when route was updated in linux routing table. Flow flushing ensured that offloading engine got routing updates instantly but it wasted a lot of CPU time and decreased performance if routing table was constantly updated for (instance in Full BGP, big OSPF or flapping PPPoE interface scenarios)
In 1.10.3 firmware by default disable-flow-flushing-upon-fib-changes is not set which means that flow table in offloading engine is always flushed upon routing table changes same way as it used to be in previous firmware.
If you have Full-BGP table or large OSPF network they you are advised to set disable-flow-flushing-upon-fib-changes this will ensure less CPU-load and increase max throughput.
Important note for multi-WAN environments – if nexthop interface of default-gateway changes and disable-flow-flushing-upon-fib-changes is set then it will take up to flow-lifetime seconds before all existing offloaded flows switch to new nexthop interface (up to 12 seconds by default).
Offloading – Add CLI command to modify flow-lifetime in offloading engine (expressed in seconds):
set system offload flow-lifetime 24Prior to 1.10.3 firmware flow-lifetime parameter was hardcoded and was not synchronized between different ER platforms: 12 seconds on ER-Lite/ER-Poe, 6 seconds on ER/ER-pro/ER-4/ER-6 and 3 seconds on ER-Infinity.
In 1.10.3 firmware default value of flow-lifetime is set to 12 seconds for all ER platforms and now it can be modified. By modifying flow-lifetime parameter you control how much traffic skips from offloading engine into linux network stack.
If you increase flow-lifetime then:
a) Offloaded IP flows will expire less frequently and less packets will be forwarded to linux
b) CPU load will decrease and max throughput will increase
c) if disable-flow-flushing-upon-fib-changes parameter is set then it will take more time for offloading engine to detect changes in routing table
If you decrease flow-lifetime then:
a) Offloaded IP flows will expire more frequently and more packets will be forwarded to linux
b) CPU load will increase and max throughput will decrease
c) if disable-flow-flushing-upon-fib-changes parameter is set then it will take less time for offloading engine to detect changes in routing table
Offloading – add CLI command to show flows in offloading engine: show ubnt offload flows Offloading – add CLI command to show offloading engine statistics: show ubnt offload statistics
Enhancements and bug fixes:
LDP – fixed regression in 1.10.0 when LDP configuration failed. Discussed here LoadBalancing – fixed regression in 1.10.1 when LoadBalancing failed to recover if WAN interface lost&restored link in 3 second interval. Discussed here DHCP – fixed bug when DHCP server configuration failed to commit with networks other than /8, /16, and /24. Discussed here TrafficControl – fixed regression in 1.10.0 when “command not found” output was printed when running “show traffic-control …” commands. Discussed here
I am starting an ongoing series involving a semi-static set of devices. These will involve different tutorials on things such as OSPF, cambium configuration, vlans, and other topics. Below is the general topology I will use for this lab network. As things progress I will be able to swap different manufacturers and device models into this scenario without changing the overall topology. We may add a device or two here and there, but overall this basic setup will remain the same. This will allow you to see how different things are configured in the same environment without changing the overall scheme too much.
We will start with very basic steps. How to login to the router, how to set an IP address, then we will move to setting up a wireless bridge between the two routers. Once we have that done we will move onto setting up OSPF to enable dynamic routing. After that the topics are open. I have things like BGP planned, and some other things. If there is anything you would like to see please let me know.
You must be logged in to post a comment.