EGP

Today I came across an old Cisco router with original IOS image. Big surprise (at least for me) when I did check what routing protocols are supported on this router:

EGP protocol

I was out of the game, or better not even yet had discover the networking games, when the EGP was still out there and available to be configured on the Cisco routers.

I hope to bring a smile on your face or some nostalgic memories when you’ll see this :)

[Solution] Speed / Duplex auto-negotiation fails between Cisco and Tandberg

In the last weeks I was working closely with a Cisco Telepresence team to identify a issue regarding poor performance of the video systems. We did find pretty quickly the issue as being the failure of auto-negotiation of Speed and Duplex on the connection between Cisco switch port and Tandberg endpoint devices.

This was the easy part. We though it will be fixed in minutes, but after a few days we did recognized that there is something we do not understand. We did change the settings everywhere to have auto-negotiation on, but we still had problems. For example with Cisco and Tandberg ports set on auto-negotiation on both sides, I’ve seen the most uncommon results:
– Cisco 1000Mbps – Tandberg 1000Mbps = negotiation 1000Mbps / Full
– Cisco 1000Mbps – Tandberg 100Mbps = negotiation 1000Mbps / Full on Cisco + 100Mbps / Full on Tandberg
– Cisco 100Mbps – Tandberg 100Mbps = negotiation 100Mbps / Half on Cisco + 100Mbps / Full on Tandberg

These are just a few of the strange results that we got. Myself as part of the network team I turn my attention to search bugs in IOS, configuration issues, faulty hardware. The Telepresence team was doing their job to search on their systems. Nothing was working.

We turn our attention to TAC engineers. They did try to simulate in a lab environment our problems, but failed. Their system were not having this kind of issue. Internet, search engines and boards could not help as well. I was about to think that we are somewhere in the Bermuda triangle and we are the only one with this kind of problem.

Then the solution came from a Cisco engineer when we least expect it. I quote from his e-mail in which he gave us some suggestion to try:

Are you aware that Tandberg endpoints running newer versions of software 
need to be rebooted before changes to speed settings take effect? 
This can sometimes cause confusion.

We stopped for a second and ask “Did we reload any Tandberg device during troubleshooting sessions?” The answer was “No”. After reload all devices, one by one, everything was working expect a few devices.

We discovered that these Tandberg devices didn’t want to auto-negotiate because of lack of a Cat6 cabling. It seems that all 8 wires need to be there and connected. So, if you have a cable that is patched to transport data and telephony for example to spare some wires, then you may be in trouble.

Why did I add this thing here? For sure it will bring some ironic smile on some faces, but I like to learn from my mistakes or from not paying close attention to some small line in the documentation. OK, if I made you laugh it’s fine, but the reason of this article is different. When I did search Internet for possible solution, I could not find anywhere a line with “reload the damn Tandberg device after you modify Speed / Duplex” settings.


[Infographic] The Journey to Cisco Certification Success

I found this great Infographic on Pinterest and I felt the need to share it though my blog. Even if not all information are 100% accurate of complete, it’s still a nice view that worth spending some minutes to check.


Fiber Optic basics

I think all network engineers touched, if not used / patched, as least one time a fiber optic patch cord. As a network engineer you might not necessarily need to understand HOW fiber optic is working. It’s there and it’s working. You just need to plug the patch cord and that that’s it.

Anyway, for interested network engineers (or geeks) like me, to understand how fiber optic works might be a fun way to spend 10 minutes of my life. Of course, to have in-deep knowledge of FO, at the level which allow you to design applications for this transport medium, you need to read a little bit more than the video above.

Disclaimer: This video is not mine and I don’t claim any rights on it. My thanks go to Jimmy Ray Purse, TechWiseTV, Networking 101 Show, Cisco and last but not least to YouTube for hosting it and let us embed this video.


BGP Conditional Advertisement

BGP Conditional Advertisement – it let the impression of a very complex task. Actually you will find it very easy to implement once you understand it.

In simple words I would say  that BGP conditional advertisement it’s a feature that let you advertise a prefix to one of your neighbors if mandatory condition is satisfied. To implement this feature you must configure at least two of the following three maps:

– Advertise-map -> this contains the selected prefixes which will be advertised if the mandatory condition is satisfied
– Exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition exist)
– Non-exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition doesn’t exist)

Let’s take an example. We have the following topology:

We have here a simple topology, with eBGP peering between R1 – R2 and R2 – R3. Each router has a Loopback interface with the following IP addresses:

R1 – L0 – 1.1.1.1 /24
R2 -L0 – 2.2.2.2 /24
R3 – L0 – 3.3.3.3 /24

These interfaces are advertised into BGP and they have full reachability:

R2#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4   100       5       4        0    0    0 00:01:27        1
10.10.23.3      4   300       2       2        0    0    0 00:00:24        0
 
R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i
 
R2#sh ip route bgp
     1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [20/0] via 10.10.12.1, 00:04:02
     3.0.0.0/24 is subnetted, 1 subnets
B       3.3.3.0 [20/0] via 10.10.23.3, 00:04:02

Task

An easy task would ask you to solve something like if 1.1.1.0 /24 is NOT in the BGP table of R2, then R2 should advertise its 2.2.2.0 /24 to R3.

Solution

Let’s analyze this request a little bit. The prefix to be advertised or not, depending of the satisfaction of the condition, is 2.2.2.0 /24. According to what I said before about the necessary “maps” for BGP conditional advertisement, this prefix will go into the “advertise-map”. R2 is the only router you need to configure to accomplish this task.

conf t
access-list 2 permit 2.2.2.0 0.0.0.255
route-map ADVERTISE permit 10
match ip address 2

OK, we have the advertisement map. What about the condition? The task request that 2.2.2.0 /24 should be advertised if 1.1.1.0 / 24 does NOT exist in the BGP table of R2. Using logical deduction we can say that “non-exist-map” is what we need to configure.

conf t
access-list 1 permit 1.1.1.1 0.0.0.255
route-map NOT-EXIST permit 10
match ip address 1

Let’s add everything together in BGP:

conf t
router bgp 200
neighbor 10.10.23.3 advertise-map ADVERTISE non-exist-map NOT-EXIST

Verification

On R2 check the BGP table:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

We have the 1.1.1.0 /24 prefix in the BGP table. According to our task, 2.2.2.0 /24 should be advertised if 1.1.1.0 /24 does NOT EXIST. By analogy, if 1.1.1.0 /24 EXIST, the 2.2.2.0 /24 should NOT be advertised. You see? It’s just a tricky words game.

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
 
Total number of prefixes 1

We advertise only one network. The 2.2.2.0 /24 is not advertised to R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.23.2                             0 200 100 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

To check that the conditional advertisement really works, stop R1 from announcing 1.1.1.0 /24 in BGP. You can just shutdown the interface.
Check if the L0 of R1 is in the routing table / BGP table of R2:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should be advertised to R3:

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
 
Total number of prefixes 1

On R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       10.10.23.2               0             0 200 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

Remember that usually in the exams, the tasks related to BGP Conditional Advertisement are more word tricks than complex. As an example, base on the above topology, resolve the following:
– If 1.1.1.0 /24 and 2.2.2.0 /24 are both in the BGP table of R2, both prefixes should be advertised to R3
– If 1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should not be advertised to R3
– If 1.1.1.0 /24 and 2.2.2.0 /24 are not in the BGP table of R2, then none of them should be advertised to R3

If you don’t understand the trick, let me know and I will explain.