BGP between Cisco Nexus and Fortigate

It is not uncommon to find that different vendors have slightly different implementations when it comes to standards technologies that should work seamless.

I recently came across a BGP capability negotiation problem between a Nexus 7000 and a client Fortigate. Today’s post is not teaching about any new technologies, but instead showing the troubleshooting methodology I used to find the problem.

The setup is simple. A Nexus 7000 and a Fortigate connected via nexus layer2 hosting infrastructure, to peer with BGP.
At face value the eBGP session between Nexus 7000 and the Fortigate never came up:

N7K# sh ip bgp summary | i 10.5.0.20
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.5.0.20   4 65123     190     190        0    0    0 0:12:30  Idle

The first steps should verify the obvious.

Configuration! This check should included checking the ASNs, the peering IP addresses, source-interfaces and passwords matching.

Continue reading “BGP between Cisco Nexus and Fortigate” →

Low Memory Handling

Memory problems on routers is nothing new. It is generally less of a problem in current day, but is still seen from time to time.

BGP is capable of handling large amount of routes and in comparison to other routing protocols, BGP can be a big memory hog. BGP peering devices, especially full internet peering devices, require larger amounts of memory to store all the BGP routes. Thus it’s not uncommon to see a BGP router run out of memory when a certain route count limit is exceeded.

A router running out of memory, commonly called Low Memory, is always a bad thing. The result of low memory problems may vary from the router crashing, to routing processes being shut down or if you lucky enough erratic behavior causing route flaps and instability in your network. None which is desired.

Low memory can be caused by any of the following:

Partial physical memory failure.
Software memory bugs.
Applications not releasing used memory chunks.
Incorrect configuration.
Insufficient memory allocation to a Nexus VDC.

Continue reading “Low Memory Handling” →

Troubleshooting BGP

The new focus is of the R&S exam is troubleshooting. And for some reason this is seen as a new topic to study and as a result feared. It is vital to understand why troubleshooting was added to the lab, and why it will possibly be added to other tracks. Anybody can apply vanilla configs, provided it is done without error, in the correct order, and by avoiding the question pitfalls.

Troubleshooting was introduced by Cisco to give the CCIE certification that edge it needs to seperate the guys that really understand the technologies and those that just learned to configure labs. Troubleshooting is thus NOT a new section! If you understand know each technology, understand its it building blocks, processes and states, troubleshooting should be nothing ‘new’.

That said, once you understand the work, drafting a troubleshooting methodology per technology should be fairly straight forward. A detailed troubleshooting approach is included in each chapter of the Routing-Bits Handbooks.

(Note ‘{ }’ curl-brackets indicate replaceable values, the rest is regex)

Troubleshooting BGP session start-up problems

1- Are you seeing the expected neighbors in a NON ‘idle’ or ‘active’ state?
#sh ip bgp summary

2- Is a sourced telnet to the neighbor address working?
#telnet {peer-ip} 179 /source {src-int-ip}

3- Confirm if the configuration is correct and matching to neighbors configuration?
#sh run | b router bgp

4- If eBGP, is the neighbor directly connected? (Should be 1 hop in the trace)
4.1- If not directly connected is multihop configured?
#trace {peer-ip} source {src-int-ip} #sh run | i {peer-ip}.*ebgp-multihop

Continue reading “Troubleshooting BGP” →

Output 101 : BGP AFI/SAFI

When BGP peers set up their session between them, they send an OPEN message possibly containing optional parameters.

One optional parameter is capabilities. Possible capabilities are Multiprotocol extensions, route refresh, outbound route filtering (ORF), and so on. When the BGP peers exchange the Multiprotocol extension capability, they exchange AFI and SAFI numbers and thus identify what the other BGP speaker is capable of.

IPv6 in BGP is implementated via Multi-Protocol BGP (MPBGP) (RFC 2283), as is MPLS and VPN’s through two new attributes: MP_UNREACH_NLRI and MP_REACH_NLRI. The first two values in these two attributes contain the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).

AFI	Meaning
1	IPv4
2	IPv6

SAFI	Meaning
1	Unicast
2	Multicast
3	Unicast and multicast
4	MPLS Label
128	MPLS-labeled VPN

Continue reading “Output 101 : BGP AFI/SAFI” →

R&S Quick Notes – BGP

BGP

When using Communities, don’t forget “neighbor send-community”
Know your attributes and the direction which applied, when to used what.
“aggregate address” needs a more specific prefix in the BGP table for aggregate to be advertised.
Synchronization issue has 3 solutions, 1- Load BGP on all transit routers, 2- GRE tunnel, 3- Redistribution BGP>IGP.
“no bgp nexthop trigger” – Disables next-hop tracking between scanner intervals.
“no bgp fast-ext-fallover” – Force the router to wait for the dead-timer to expire, before generating notification messages , when a connected peer goes down.
“neighbor fall-over” – Will check neighbor connenctivity between scanner intervals, aka BGP Fast Peering.
Only the Holdtime is sent in update-msg. Two neighbors will use the lowest holdtime and then calculate the keepalive from that.
Know your Regular Expressions
Know the difference between Peer-Groups and Peer-Templates

BGP Conditional Route Advertisement

Assume the following scenario:

asn1

BOB’s network 136.1.29.0/24 resides in AS-300.

For what ever reason, AS-300 needs all traffic to Prefix-A (136.1.29.0/24) to come via ASN-200 only, but in the event of link failure between AS-200 and AS-300 traffic are allowed to come in from AS-100. With the normal BGP attributes you can do this really quickly.

Hypothetically, lets assume for a second that AS-100 has a weight set, preferring the direct link to AS-300 for all prefixes learned from AS-300. And AS-100 is not cooperating with your request, nor is interested to make any changes in their AS. How can you influence AS-100’s decision, to prefer the route learned via AS-200.

There is a nice and not-so-nice to way to do this.

Continue reading “BGP Conditional Route Advertisement” →

Clearing BGP Sessions

There are a couple ways, some more recommended than others, to reset or clear a BGP session between two neighbors.

The Cisco IOS Software Command Summary lists the following circumstances under which you must reset a BGP connection, for changes to take effect:

Additions or changes to BGP-related access lists
Changes to BGP-related weights
Changes to BGP-related distribution lists
Changes to the BGP-related timer’s specifications
Changes to the BGP administrative distance
Changes to BGP-related route maps

Traditional clearing of BGP session (aka Hard Reset)

Tears down the BGP session with all Neighbors, a specific neighbor or peer group.
A new session is re-established within 30-60 seconds, depending.
Processing of the full Internet table can take a really long time.
This is almost NEVER recommended on production networks, due the disruptive behaviour.

router#clear ip bgp {* | neighbor ip | peer-group}

Continue reading “Clearing BGP Sessions” →

Output-101: BGP-3-NOTIFICATION

Error log:

%BGP-3-NOTIFICATION:received from neighbor 196.7.8.9 2/2 (peer in wrong as) 2 bytes 0064

Explanation:

The Obvious is true, a wrong ASN is configured, but there is more detail here. “2 bytes 0064” : the 0064 is the received ASN in HEX, ie 0x0064 in HEX = 100 decimal.

The local router is expecting Neighbor 196.7.8.9 to come from a specific ASN, not ASN 100. Have a look at the “neighbor {IP} remote-as” command to confirm it is set correctly. If confederations are used, make sure your confederation-id is correct between the two EBGP peers.