BGP Routing Protocol Practice Lab 01

Lab 1: MED and AS-Path Prepend

Basic configuration

R1:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0 

ip address 150.1.1.1 255.255.255.0

 no shut

!

interface Serial0/0

ip address 10.0.0.1 255.255.255.252

no shut

R2:

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Loopback192

ip address 192.1.1.1 255.255.255.0

!

interface Loopback193

ip address 193.1.1.1 255.255.255.0

!

interface Loopback194

ip address 194.1.1.1 255.255.255.0

!

interface Loopback195

ip address 195.1.1.1 255.255.255.0

!

interface Serial0/0

ip address 10.0.0.2 255.255.255.252

no shut !

interface Serial0/1

ip address 10.0.0.9 255.255.255.252

no shut

R3:

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface FastEthernet0/0 ip address 150.3.3.3 255.255.255.0 no shut

!

interface Serial0/1

ip address 10.0.0.10 255.255.255.252

no shut !

interface Serial0/2

ip address 10.0.0.13 255.255.255.252

no shut !

interface Serial0/3

ip address 10.0.0.17 255.255.255.252

no shut

R4:

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface FastEthernet0/0 ip address 150.1.1.4 255.255.255.0 no shut

!

interface Serial0/0

ip address 10.0.0.14 255.255.255.252

no shut !

interface Serial0/1

ip address 10.0.0.18 255.255.255.252

no shut

Configure BGP as illustrated in the topology. Use the Loopback 0 addresses for peering. Do NOT configure any IGPs. Instead, use static routes only. R1 should peer with R2 and R4. R2 should peer with R1 and R3. R3 should peer with R2 and R4. R4 should peer with R1 and R3.

R1(config)#ip route 2.2.2.2 255.255.255.255 serial 0/0

R1(config)#ip route 4.4.4.4 255.255.255.255 fastethernet 0/0 150.1.1.4

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 2

R1(config-router)#neighbor 2.2.2.2 update-source loopback 0

R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 3

R1(config-router)#neighbor 4.4.4.4 remote-as 4

R1(config-router)#neighbor 4.4.4.4 update-source loopback 0

R1(config-router)#neighbor 4.4.4.4 ebgp-multihop 3

R2(config)#ip route 1.1.1.1 255.255.255.255 serial 0/0

R2(config)#ip route 3.3.3.3 255.255.255.255 serial 0/1

R2(config)#router bgp 2

R2(config-router)#neighbor 1.1.1.1 remote-as 1

R2(config-router)#neighbor 1.1.1.1 update-source loopback 0

R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 3

R2(config-router)#neighbor 3.3.3.3 remote-as 3

R2(config-router)#neighbor 3.3.3.3 update-source loopback 0

R2(config-router)#neighbor 3.3.3.3 ebgp-multihop 3

R3(config)#ip route 2.2.2.2 255.255.255.255 serial 1/1

R3(config)#ip route 4.4.4.4 255.255.255.255 serial 1/2

R3(config)#ip route 4.4.4.4 255.255.255.255 serial 1/3

R3(config)#router bgp 3

R3(config-router)#neighbor 2.2.2.2 remote-as 2

R3(config-router)#neighbor 2.2.2.2 update-source loopback 0

R3(config-router)#neighbor 2.2.2.2 ebgp-multihop 3

R3(config-router)#neighbor 4.4.4.4 remote-as 4

R3(config-router)#neighbor 4.4.4.4 update-source loopback 0

R3(config-router)#neighbor 4.4.4.4 ebgp-multihop 3

R4(config)#ip route 1.1.1.1 255.255.255.255 fastethernet 0/0 150.1.1.1

R4(config)#ip route 3.3.3.3 255.255.255.255 serial 0/0

R4(config)#ip route 3.3.3.3 255.255.255.255 serial 0/1

R4(config)#router bgp 4

R4(config-router)#neighbor 1.1.1.1 remote-as 1

R4(config-router)#neighbor 1.1.1.1 update-source loopback 0

R4(config-router)#neighbor 1.1.1.1 ebgp-multihop 3

R4(config-router)#neighbor 3.3.3.3 remote-as 3

R4(config-router)#neighbor 3.3.3.3 update-source loopback 0

R4(config-router)#neighbor 3.3.3.3 ebgp-multihop 3

In order to ensure that the ORIGIN code is INCOMPLETE, you need to redistribute the LAN subnets into BGP. However, you can also use the network statement in conjunction with a route map and set the ORIGIN code within the route map.

R1(config)#route-map CONNECTED permit 10

R1(config-route-map)#match interface fastethernet 0/0

R1(config-route-map)#exit

R1(config)#route-map CONNECTED deny 20

R1(config-route-map)#exit

R1(config)#router bgp 1

R1(config-router)#redistribute connected route-map CONNECTED R1(config-router)#exit

You can verify the ORIGIN code by looking at the prefix entry in the BGP Tables. The ORIGIN code of INCOMPLETE is denoted by a question mark (?) in the output of the show ip bgp command. You can view additional detail on a per-prefix basis also when using this command

Configure BGP, so that R4 prefers the path via R3 to reach any subnet

In the output of the show ip bgp command on R4 we can see that the preferred route to reach 150.3.3.0 is via R3, however the preferred route to reach 150.2.2.0 is via R1 (the lowest routerid), also, to ensure that the subnet 150.1.1.0 will be reached via R3, configure BGP on R1 to advertise all prefixes with a longer AS-PATH to influence the path selection as follow:

R1(config)#route-map PREP permit 10

R1(config-route-map)#set as-path prepend 1 1 1 1 R1(config-route-map)#exit

R1(config)#router bgp 1

R1(config-router)#neighbor 4.4.4.4 route-map PREP out R1(config-router)#exit

Notice now the preferred path to reach both prefixes 150.3.3.0 and 150.2.2.0 is via R3 with the next-hop 3.3.3.3 because the shortest AS-PATH length:

Configure R4 so that it sends all updates to R3 with a MED of 4. Configure R2 so that it sends all updates to R3 with a MED of 2. Ensure that R3 prefers all routes with the better (lower) MED value.

Before configuring the MED let's verify the BGP RIBs on R3:

The preferred path to reach the prefix 150.1.1.0 is via R4, we should see all routes with the next-hop R2:

Let's configure MED on R3:

R4(config)#route-map MED permit 10

R4(config-route-map)#set metric 4

R4(config-route-map)#exit

R4(config)#router bgp 4

R4(config-router)#neighbor 3.3.3.3 route-map MED out

R4(config-router)#exit

R2(config)#route-map MED permit 10

R2(config-route-map)#set metric 2

R2(config-route-map)#exit

R2(config)#router bgp 2

R2(config-router)#neighbor 3.3.3.3 route-map MED out

R2(config-router)#exit

Let's verify the BGP RIBs of R3:

We have still the best path to reach 150.1.1.0 via R4 as shown by the show ip bgp command on R3 below, so the problem is not resolved even if R2 advertises the lowest MED comparing with R4.

The reason is: we met two issues in this case:

-the first issue is: by default, the MED is only compared for path received from the same AS ,in this case R3 receives two values of MED from two routers (R2 and R4) configured in different AS.

-The second issue: the MED is compared after the AS-PATH in the BGP decision process. In this case R3 will select the path via R4 as the best path to the 150.1.1.0/24 prefix because of the shorter AS-PATH length.

To override the two issues, configure the bgp always-compare-med command to avoid the first issue so always compare the MED even if MED is received from Different AS. And bgp bestpath as-path ignore command to avoid the second issue so that R3 override the BGP decision process by ignoring the step of the AS-PATH in the BGP Decision Process:

Let's configure these two commands:

R3(config)#router bgp 3

R3(config-router)#bgp bestpath as-path ignore R3(config-router)#bgp always-compare-med

We can see for the prefix 150.1.1.0 that the path with the longer AS-PATH length is preferred because the lowest MED even if the AS-PATH takes precedence over the MED in the order of the path selection in BGP:

Another way to verify all BGP RIBs with do show ip bgp, R3 prefers all routes from R2 because the lowest MED:

#BGP #LAB #CCNA #CCNP #CCIE #cisco #gns3 #solution

Cisco SD-WAN Overlay Management Protocol (OMP): A Comprehensive Guide

 Cisco SD-WAN Overlay Management Protocol (OMP): A Comprehensive Guide

Cisco SD-WAN Overlay Management Protocol (OMP): A Comprehensive Guide

Cisco SD-WAN has revolutionized modern networking by offering scalable and intelligent network management solutions. A key component that drives the Cisco SD-WAN architecture is the Overlay Management Protocol (OMP). This protocol plays a crucial role in establishing and maintaining the SD-WAN control plane, ensuring seamless communication across the network.

What is OMP in Cisco SD-WAN?

OMP is a TCP-based protocol, much like BGP, that enables communication between Cisco vEdge routers and vSmart controllers. It is responsible for managing the following critical functions:

1. Transport Locator (TLOC) Distribution:

   • Shares TLOC information across SD-WAN sites.

   • Helps in route reachability by defining WAN transport characteristics.

2. Service-Side Reachability:

   • Distributes routing information from local interfaces, static routes, and dynamic protocols like OSPF and BGP.

3. Service-Chaining Information:

   • Allows integration of security and network services such as firewalls and load balancers.

4. Security Parameters:

   • Distributes VPN labels and encryption keys for secure communication.

5. Application-Aware Routing (AAR):

   • Enables dynamic path selection based on application performance.

How OMP Works

When a vEdge router joins the SD-WAN overlay fabric, it automatically establishes an OMP peering session with the vSmart controller. The key points to remember about OMP peering are:

• Peering Uses System IPs:

  • Similar to BGP loopback peering, the OMP session is established between the System IPs of vEdge and vSmart.

  • Multiple DTLS tunnels can exist, but only one OMP session is established.

• Secure Control Connections:

  • All OMP connections are secured via DTLS encryption, ensuring data integrity.

  • Other protocols like NETCONF and SNMP also use the same encrypted tunnels.

Types of OMP Routes

OMP advertises three types of routes to the vSmart controllers, which helps in building the SD-WAN topology efficiently:

1. OMP Routes (vRoutes):

   • These routes represent local network reachability information.

   • They include attributes such as VPN, System-IP, TLOC, Site-ID, and Origin-Protocol.

2. TLOC Routes:

   • Represent WAN transport connections, uniquely identified by System-IP, Color, and Encapsulation.

   • Attributes include private/public IP addresses, preference, site ID, and tags.

3. Service Routes:

   • Advertise network services like firewalls and IDS connected to vEdges.

   • Attributes include VPN ID, Service ID, and TLOC.

Benefits of OMP in Cisco SD-WAN

• Scalability:

  • Simplifies large-scale deployments without creating excessive routing adjacencies.

• Centralized Control:

  • All routing decisions are made by vSmart controllers, reducing complexity at vEdge routers.

• Efficient Traffic Engineering:

  • Policies can be applied dynamically to optimize traffic flow and prioritize critical applications.

• Simplified Service Insertion:

  • Easily integrates additional services without manual configuration on all edge devices.

OMP Peering and Secure Connectivity

• Automatic Peer Discovery:

  • vEdges discover available vSmart controllers and initiate connections.

• Secure Encryption:

  • DTLS tunnels provide end-to-end encryption for OMP communications.

• Control Connection Redundancy:

  • Multiple DTLS connections provide redundancy but only one OMP session is established.

OMP Route Advertisements

Cisco vEdge routers advertise routes learned via:

• Connected interfaces

• Static routes

• Dynamic routing protocols (BGP, OSPF, EIGRP)

These are advertised to the vSmart controller, which then propagates them across the SD-WAN fabric.

Conclusion

Cisco SD-WAN OMP is a powerful protocol that facilitates scalable, secure, and efficient networking in large enterprises. Understanding OMP is crucial for networking professionals preparing for certifications like CCNA, CCNP, and CCIE, or for those looking to implement SD-WAN solutions in their organizations.

By mastering OMP, you can ensure optimized WAN performance, simplified network management, and secure connectivity across distributed environments.

SD-WAN OMP, Cisco SD-WAN, SD-WAN Components, CCNA, CCNP, CCIE, Cisco Training, Cisco Learning, Network Automation, vEdge, vSmart, SD-WAN Security, WAN Optimization, BGP, Routing Protocols, Network Services.

Why do we need i-BGP for the routes when we have the IGP protocols (OSPF, IS-IS) for internal communication within the AS?

 Why do we need i-BGP for the routes when we have the IGP protocols (OSPF, IS-IS) for internal communication within the AS?

IGPs like OSPF or ISIS, are link-state protocols that give us all the information of the network and allow for very interesting convergence options and traffic engineering options. Whereas, BGP knows a very limited view of the network as a whole because BGP handles very well filtering and modifying routing information.

See, the traffic in a network can be divided into 4 categories.

• Ingress: traffic arriving from outside the network, destined for hosts within the network.

• Egress: traffic originating inside the network destined for hosts outside the network.

• Internal: traffic where both the origin and destination are within the network.

• Transit: traffic where both the origin and destination are outside the network.

The IGP normally carries internal routes, so it can be used to directly route ingress and internal traffic, but what about egress and transit traffic?

There are three choices -

• Use iBGP

• Use default routes.

• Redistribute external routes into your iGP.

Redistributing the whole internet routing table into your iGP will not end well. iGPs simply are not designed to deal with hundreds of thousands of routes.

If you have only one router that connects to the outside world, then you don't need iBGP. You can simply use a default route to direct egress traffic to your border router. If you have multiple routers that connect to providers then you can still use default routes, but by doing so you lose some of the advantages of multi-homing.

So, we'll be using i-BGP because of Scalability.

Thus, iBGP is required unless you're willing to redistribute all the routes.

#ibgp #bgp #network #cisco #huawei #free #learning

 

TROUBLESHOOTING BGP/MPLS ON CISCO AND JUNIPER DEVICES

Mastering the Basics: Troubleshooting BGP/MPLS on Cisco and Juniper Devices

Introduction:
In the intricate world of networking, BGP (Border Gateway Protocol) and MPLS (Multi-Protocol Label Switching) are fundamental technologies that enable efficient, scalable, and robust communication across vast and diverse infrastructures. Understanding how to troubleshoot these protocols in Cisco and Juniper devices is essential for maintaining a smooth operational network. Today, we’ll dive into some practical tips to help you navigate common issues with these technologies.

Understanding BGP/MPLS Basics:

• BGP: As the backbone of the internet, BGP makes routing decisions based on paths, network policies, or rule sets, which allows it to be very flexible and robust. However, it can also be complex and challenging to troubleshoot.
• MPLS: MPLS enhances the flow of traffic on a network by making data forwarding decisions based on short path labels rather than long network addresses, simplifying and speeding up the process.

Common Issues and Troubleshooting Steps:
Cisco:

1. Neighbor Issues: Use show ip bgp summary to check if BGP sessions are established correctly. Look for states that might indicate problems, such as “idle” or “active”.
2. Route Advertisement Problems: The command show ip bgp neighbors <neighbor IP> advertised-routes is crucial for troubleshooting issues related to route advertisements.
3. MPLS Label Problems: Use show mpls ldp bindings and show mpls forwarding-table to troubleshoot label distribution and forwarding issues, ensuring labels are correctly assigned and used.

Juniper:

1. Session Troubleshooting: show bgp summary can help you diagnose session problems by indicating whether BGP sessions are up and how long they’ve been established.
2. Route Reception Issues: To inspect received routes, use show route receive-protocol bgp <neighbor IP>.
3. MPLS Path Troubleshooting: show mpls lsp extensive provides detailed information on the status and health of Label Switched Paths.

Advanced Troubleshooting Techniques:

• Use extensive logging and event management tools to capture data about network performance and anomalies, which is invaluable for diagnosing intermittent issues.
• Employ tools like traceroute with MPLS options (traceroute mpls on Cisco and traceroute routing-instance <instance name> on Juniper) to diagnose path selection and connectivity issues across your MPLS network.
• Engage with external resources such as BGP looking glasses and route servers to understand how your network is perceived from the outside and to troubleshoot external routing issues.

Best Practices:

• Continuous Monitoring: Implementing SNMP or NetFlow can help you keep an ongoing check on network performance and quickly pinpoint areas needing attention.
• Regular Updates and Patches: Keep your network devices updated to mitigate security risks and improve functionality.
• Knowledge Sharing: Encourage regular training sessions within your team to ensure all members are up-to-date with the latest troubleshooting techniques and tools.

Conclusion:
Troubleshooting BGP and MPLS effectively requires not only a deep understanding of the protocols but also a systematic approach to diagnosing and resolving issues. With these tips and techniques, you can enhance your network’s reliability and performance, ensuring that communication flows smoothly and efficiently.

Call to Action:
Have you encountered a tricky network issue or have additional tips to share? Comment below.

#cisco #juniper #bgp #mpls #troubleshooting