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.


Free Streaming CCNA Voice Bootcamp from INE

I got today a newsletter from INE announcing a freebie. You have it below. Enjoy!

Free Streaming of our NEW
CCNA Voice Bootcamp Course!

FOR A LIMITED TIME until March 31st, 2012, get FREE streaming
of the NEW CCNA Voice Bootcamp Course with CCIEx2 #14073
Mark Snow when you become a member with INE!
Registration today for free!

The CCNA Voice class is an ultimate all-in-one solution for engineers pursuing the Cisco Certified Network Associate Voice (CCNA Voice) certification. This Video-on-Demand course includes over 25 hours of instructor-led content that will fully prepare you for the latest Cisco 640-461 ICOMM v8 certification exam. Please note that per Cisco CCNA Voice certification requirements, you need to have already met the pre-requisite of having a valid regular CCNA (Routing & Switching) status. View this course on your desktop computer, iPhone®, iPad® or other .mov video file format compatible devices. Learn more »

Click Here to register for your free account with INE to receive your FREE access to the ALL NEW CCNA Voice Bootcamp Course!

Cisco NX-OS Malformed IP Packet Denial of Service Vulnerability

Summary

Cisco NX-OS Software is affected by a denial of service (DoS) vulnerability that could cause Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software to reload when the IP stack processes a malformed IP packet.

Vulnerable Products

Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software are affected by this vulnerability. The vulnerability is in the operating system’s IP stack; therefore, any feature that makes use of the services that are offered by the IP stack to process IP packets is affected.

Cisco NX-OS Software versions prior to the First Fixed Release version are affected. Refer to the Software Versions and Fixes section for details regarding fixed versions.

To determine the version of Cisco NX-OS Software that is running on a Cisco Nexus switch, administrators can log in to the device and issue the show version command to display the system banner.

Products Confirmed Not Vulnerable

Cisco NX-OS Software for products other than the Cisco Nexus 1000v, 5000, and 7000 Series Switches is not affected by this vulnerability. In particular, the following products that run Cisco NX-OS Software are not affected:

Cisco Nexus 2000 Series Switches
Cisco Nexus 3000 Series Switches
Cisco Nexus 4000 Series Switches
Unified Computing System (UCS)
Cisco MDS 9000 Series Multilayer Switches

No other Cisco products are currently known to be affected by this vulnerability.

This advisory is available at the following link:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120215-nxos