Python on Nexus

If you are relying on handy "cisco" python module on your Nexus 5500 or 6K switches - stop. Cisco made considerable changes in version 7.0(1)N1(1).
Here what it looked like in 6.0(2)N2(3):
switch# python
Python 2.7.2 (default, Nov 27 2012, 17:50:33)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Loaded cisco NxOS lib!
>>> import cisco
>>> dir(cisco)
['BGPSession', 'BufferDepthMonitor', 'CLI', 'CheckPortDiscards', 'CiscoSecret', 'CiscoSocket', 'Feature', 'History', 'IPv4ACL', 'IPv6ACL', 'Interface', 'Key', 'LineParser', 'MacAddressTable', 'OSPFSession', 'Routes', 'SectionParser', 'VRF', 'Vlan', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'acl', 'bfd', 'bgp', 'buffer_depth_monitor', 'check_port_discards', 'cisco_secret', 'cisco_socket', 'cli', 'dhcp', 'eigrp', 'feature', 'get_global_vrf', 'get_valid_port', 'history', 'hsrp', 'interface', 'interface-vlan', 'key', 'lacp', 'line_parser', 'mac_address_table', 'md5sum', 'msdp', 'ospf', 'ospfv3', 'pim', 'private-vlan', 'ptp', 'rip', 'routes', 'scheduler', 'section_parser', 'set_global_vrf', 'show_queues', 'show_run', 'ssh', 'tacacs', 'telnet', 'transfer', 'udld', 'vlan', 'vpc', 'vrf', 'vrrp', 'vtp']
>>>

In 7.0(1)N1(1)
>>> import cisco
>>> dir(cisco)
['__doc__', '__name__', '__package__', 'cli', 'cli_execution_error', 'cli_syntax_error', 'clid', 'clip']

According to Cisco representative "Starting 7.0(1)N1(1), python interpreter on N6K has been modified to look like python interpreter on N7K."
WHY DID NOT THEY DO OTHER WAY AROUND: MODIFY PYTHON ON N7K TO MATCH N6K?

Stop using "ships in the night"

It seems that every month brings news of yet another overlay network. STT, OTV, VXLAN, NVGRE and may be many more I've not heard of. People often use "ships in the night" words in the same sentence referring to the fact that these overlay network know nothing about underlying physical network infrastructure. However, nowadays even the smallest sea or ocean going vessel not only knows about any ship nearby, but acutely aware of a few satellites thanks to radar and GPS systems.
So, to keep up with pace of time and advances in technologies (after all, we are in tech business) I propose  new analogy for overlay and physical networks: polar bear and penguin. Those 2 definitely do not meet in real life. I am not considering corner case like zoo.

Rant

Any vendor requiring registration in order to access online documentation should be condemned to untangle network cables for the rest of the their product life.

Very interesting and popular explanation of Shennon limit: Part 1 and Part 2.

LACP timer and what it means

LACP (IEEE 802.3ad)is protocol used to bundle several physical interfaces to form single logical channel. It has a timer which defines how often devices inter-connected via this bundle exchange LACP PDUs or control messages. Currently, this timer can be set to either "rate fast" - 1 second, or "rate normal" - 30 seconds. What is not always clear is that when you configure "lacp rate " on Cisco or "set interfaces ae1 aggregated-ether-options lacp periodic fast" on Juniper, you do not configure how often this switch will send LACP PDUs. This command means that switch where this command is applied will expect to receive LACP PDUs with this frequency from the partner on the other side of logical channel.
Here is quick test. I have Nexus5500 connected to Cat6500. Let's configure port-channel between them with one physical member interface.

Cat6500#show run interface TenGigabitEthernet 1/5
!
interface TenGigabitEthernet1/5
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 lacp rate fast
 channel-group 5 mode active

Nexus5500# show running-config interface Ethernet 1/1
!
interface Ethernet1/1
  switchport mode trunk
  channel-group 1 mode active

"lacp rate normal" is default setting on Nexus, so this command does not show up in the output, but we can confirm:

Nexus5500# show running-config interface Ethernet 1/1 all | include lacp
  lacp port-priority 32768
  lacp rate normal


Cat6500 is configured with rate fast and Nexus5500 - with rate normal. Let's see what's going on behind the scene.
On Catalyst:
Cat6500#show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
           F - Device is requesting Fast LACPDUs
           A - Device is in Active mode       P - Device is in Passive mode    

Channel group 3
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Te1/5     FA      bndl      32768         0x3       0x3     0x106       0x3F

F flags says that Cat6500 requesting fast LACP PDUs from its partner.

On Nexus it's a little bit backwards, the "show" command tells you partner status, not its own.

Nexus5500# show lacp neighbor interface port-channel 1
Flags:  S - Device is sending Slow LACPDUs F - Device is sending Fast LACPDUs
          A - Device is in Active mode       P - Device is in Passive mode
port-channel1 neighbors
Partner's information
               Partner                           Partner                            Partner
Port        System ID                      Port Number     Age         Flags
Eth1/1     20,0-13-5f-20-63-80    0x106               910         SA

            LACP Partner           Partner                     Partner
            Port Priority              Oper Key                 Port State
            32768                      0x3                         0x3f

Nexus5500 says, that its partner - Cat6500 - is sending LACP PDUs every 30 seconds.

Find MAC address for IPv4 Multicast group

When troubleshooting multicast problem I find myself checking if IGMP snooping works as intended. "show mac address-table multicast" on Cisco switches shows MAC addresses of multicast groups. Tired of converting Multicast IPs into MACs with pencil and paper, I wrote my first ever script in Python which does just that. It takes IP address of multicast group as a parameter. Although I did some testing there might be bugs, so beware.
See Cisco's white paper for explanation how the conversion is done.
 

The wait is over

Finally, in NX-OS 6.0(2) for Nexus 5000 platform Cisco implemented "default interface" command which lets you return interface to its factory default configuration. It is very-very-very useful feature in the lab environment when one has to do a lot of re-configuration and something does not work as expected simply because of left-over configuration from the previous test. 

This command has been available in IOS since 11.1 and in NX-OS for Nexus 7K since 5.1(1)

Juniper haiku

No wonder Juniper software is so bloated :).
admin@switch> show version and haiku
Hostname: switch
Model: ex4200-48t
JUNOS Base OS boot [10.4R12.1]
JUNOS Base OS Software Suite [10.4R12.1]
JUNOS Kernel Software Suite [10.4R12.1]
JUNOS Crypto Software Suite [10.4R12.1]
JUNOS Online Documentation [10.4R12.1]
JUNOS Enterprise Software Suite [10.4R12.1]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.4R12.1]
JUNOS Routing Software Suite [10.4R12.1]
JUNOS Web Management [10.4R12.1]


        Now that Zion's safe,
        can they find a better place
        to get some sweaters?

admin@switch> show version and haiku

        Juniper babies
        The next generation starts
        Gotta get more sleep

admin@switch> show version and haiku

        3am; darkness;
        Maintenance window closing.
        Safety net: rollback.

admin@switch> show version and haiku

        Shiny leather pants
        Why don't they squeak when they kick?
        Is _that_ the secret?

PACL and MAC address learning

I have unenviable task to drag legacy application to 21st century. I am talking about 80-the legacy and some of its functions do not even use IP protocols. One of the proposed solution included 2 servers with the same

IP and MAC addresses (I know, but splitting network in 2 separate VLANs was not an option) connected to different switches, but in the same VLAN. ClientA and ClientB should be able to talk to each other and server connected to the same switch as client. ServerA and ServerB should not even know about each other's existence, so they won't complain about duplicate IP address. The switches are Cisco 6500s. One of the obvious  solutions is to put Port Access Control List on either side of the inter-switch link. PACL successfully blocked the traffic between servers, but switches still learned MAC address of the blocked traffic source and placed it MAC address table. This would cause MAC address flapping on the switch every time clients send ARP query for server's MAC or when both servers need to send traffic to their clients. Why would switch need to keep MAC address of the discarded traffic? Oh, well. Another network mystery.

"private-vlan syncronize" pitfall

Let's say you need to configure Private VLAN on Cisco Nexus switch with MSTP. You create new VLAN, make it isolated and map it to primary VLAN. Your newly created VLAN is automatically mapped to MST0 and if your primary happened to be in any other MST instance there is a possibility that your primary and secondary VLANs ended up with different L2 paths. As a bonus, you get
annoying message "These secondary vlans are not mapped to the same instance as their primary" every time you run "show spanning-tree configuration". Not a big deal, but things like these irritate me. Not to worry, "private-vlan syncronize" under "spanning-tree mst configuration" will automatically map all secondary VLANs to the same MST instance as primary VLAN. The moment it's done, you MST digest changes and boom, you have brand new MST region and STP convergence on top of it. So, either pick exiting VLAN mapped to the same instance and convert to secondary community or isolated VLAN, or have all your VLANs mapped to MST0 and use other methods to load-share traffic between transit links.
I know what you are thinking. No, I did it in the lab, so you won't have to.

How complex systems fail

A must read paper for every system architect. Also recording of the talk given at Velocity conference by Richard Cook. The main take-away for me is: don't build reliable system, build resilient system.

Port-security side effect

I discovered interesting side effect of configuring port-security which can prevent its deployment in certain circumstances. Let's have a look. Here is part of pertaining interface configuration:

 switchport port-security maximum 20
 switchport port-security
 switchport port-security aging time 1440
 switchport port-security violation restrict
 switchport port-security aging type inactivity

You can find explanations of what each command does here.

switch# show port-security interface gi 0/45
Port Security                      : Enabled
Port Status                          : Secure-up
Violation Mode                  : Restrict
Aging Time                        : 1440 mins
Aging Type                        : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 20
Total MAC Addresses              : 1
Configured MAC Addresses    : 0
Sticky MAC Addresses            : 0
Last Source Address:Vlan        : abcd.ef12.3456:1234
Security Violation Count          : 0

In case you were wondering, the MAC address above is completely made up, but it associated with "floating" IP assigned to active device in cluster. Let's see what happens when active IP has to be moved to other device in cluster due to fail-over:

port_security-2-psecure_violation: security violation occurred, caused by mac address abcd.ef12.3456 on port gigabitethernet0/46.
Oops. Even though port-security configuration allows to learn up to 20 MAC addresses and there are no MAC addresses on Gi0/46, we got port-security violation. Why? Let's see debug port-security:


 PSECURE: psecure_add_addr_check: Found duplicate mac-address abcd.ef12.3456, It is already secured on Gi0/45
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address abcd.ef12.3456 on port GigabitEthernet0/46.
PSECURE: Security violation, TrapCount:346
PSECURE: Read:2830, Write:2831
PSECURE: swidb = GigabitEthernet0/46 mac_addr = abcd.ef12.3456 vlanid = 1234
PSECURE: Adding abcd.ef12.3456 as dynamic on port Gi0/46 for vlan 1234
PSECURE: Violation/duplicate detected upon receiving abcd.ef12.3456 on vlan 1234: port_num_addrs 1 port_max_addrs 20 vlan_addr_ct 1: vlan_addr_max 20 total_addrs 4: max_total_addrs 6144

Port-security violation happened because MAC address has not been deleted from original port yet, hence "duplicate mac-address" message. To mitigate, but not completely alleviate the problem, we can reduce aging timer to 1 minute minimum. It still means that in case of fail-over, the floating IP address will not be accessible for another minute, which could be 1 minute too long.

Nexus: peer-switch and STP Bridge ID

With release of NX-OS 5.2, Cisco started supporting peer-switch feature on Nexus 5K. When peer-switch is enabled, both VPC primary and secondary switches originate STP BPDUs on vPC ports and use the same designated bridge ID on vPC ports. This got me wandering what brige ID vPC primary switch uses when peer-switch is not enabled. I set up vPC switch-pair with downstream switch connected via vPC port-channel. The switches are running MST. Here is partial BPDU captured on downstream Nexus switch with command:
ethanalyzer local interface inbound-hi display-filter "stp" limit-captured-frames 20

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Multiple Spanning Tree (3)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x7c (Agreement, Forwarding, Learning, Port Role: Designated)
    Root Identifier: 8192 / 0 / 54:7f:ee:01:15:81
    Root Path Cost: 0
    Bridge Identifier: 8192 / 0 / 54:7f:ee:01:15:81
    Port identifier: 0x9063
    Message Age: 0
    Max Age: 20
    Hello Time: 2
    Forward Delay: 15
    Version 1 Length: 0
    Version 3 Length: 96
    MST Extension
        MST Config ID format selector: 0
        MST Config name: blp-mst-Region-1
        MST Config revision: 2
        MST Config digest: d7e7e4984e26acd301b955c5289031ad
        CIST Internal Root Path Cost: 0
        CIST Bridge Identifier: 8192 / 0 / 00:23:04:ee:be:01
            CIST Bridge Priority: 8192
            CIST Bridge Identifier System ID Extension: 0
            CIST Bridge Identifier System ID: 00:23:04:ee:be:01
        CIST Remaining hops: 20
        MSTID 1, Regional Root Identifier 8192 / 54:7f:ee:01:15:81
        MSTID 2, Regional Root Identifier 8192 / 54:7f:ee:01:15:81

Note "Bridge Identifier" and "CIST Bridge Identifier". They are different. The former is "vPC local system-mac" and latter is "vPC system-mac". They can be found in "show vpc role" output:

nexus-primary# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary                      
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01            
vPC system-priority             : 32667
vPC local system-mac            : 54:7f:ee:01:15:81            
vPC local role-priority         : 8192

Here we can see, that without peer-switch enabled Nexus switch uses 2 different bridge IDs in the same BPDU. Why does it do it? I reached out to Cisco and will update when I hear anything.
When peer-switch is enabled, both vPC primary and secondary switches originate BPDUs on vPC ports and "Bridge Identifier" and "CIST Bridge Identifier" are the same and equal to "vPC system-mac"

IPExpert, it's 2012.

After reading excellent sample chapter from IPExpert's "IPv4/IPv6 Multicast Operation and Troubleshooting" book I decided to pre-order it. Today I got the pdf file and was very disappointed. The content is still great, but it can only be read on the PC or MAC - no iPad, Kindle or smartphone. Now, my commute is relatively long and I do most of my reading on the bus. Not be able to read documentation on mobile device is major problem for me. If greedy Hollywood studios found a way to provide their content on mobile platforms, so should IPExpert. Especially given the fact that INE provide PDF files DRM-free. This was my first and last purchase of IPExpert product.
Update: FileOpen released iPad/iPhone app, so now I can read that PDF on my iPad.

ip accounting-list

Cisco has interface level command "ip accounting" which records number of bytes and packets passed through the router. If you want to count traffic only for specific IP address, you need to use "ip accounting-list" command. There seems to be a tiny bug in context help in 12.4(15)T14:

R2(config)#ip accounting-list 1.1.1.1 ?
  A.B.C.D  IP address mask

Note that context help says you need to enter address mask. 

R2(config)#ip accounting-list 1.1.1.1 255.255.255.255

After checking

R2(config)#do sho run | i accounting

ip accounting-list 0.0.0.0 255.255.255.255

That's not what I entered. In reality, you are supposed to enter wildcard mask, which makes more sense. Specifying ACL number or name would have made even more sense. So, let's fix it:

R2(config)#no ip accounting-list 0.0.0.0 255.255.255.255

R2(config)#ip accounting-list 1.1.1.1 0.0.0.0

R2(config)#interface fa 0/0

R2(config-if)#ip accounting

and test it. Traffic from R3 to 192.168.12.1 and 1.1.1.1 must pass through R2's Fa0/0 interface: 

R3#ping 192.168.12.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/58/120 ms

R3#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/47/88 ms

R2#sho ip account

   Source           Destination              Packets               Bytes

 192.168.23.3     1.1.1.1                          5                 500

As you can see from the output above, only pings to 1.1.1.1 got counted.

IGP: administrative distance per prefix

Routing protocol administrative distance defines route from which protocol will be placed in RIB - lower is better. However, AD can be changed via "distance" command on Cisco routers. The full syntax is:

distance ip-address wildcard-mask  [ip-standard-acl |  ip-extended-acl | access-list-name]

access-list option assumes that AD can be changed per IP subnet. Let's see how it works in RIPv2, EIGRP and OSPF.

I have very simple topology here

R1-------------------R2

Router R1 advertises 2 networks into RIP which we can see on R2:

R2#show ip route rip
R    192.168.200.0/24 [120/1] via 192.168.12.1, 00:00:11, FastEthernet0/0
R    192.168.100.0/24 [120/1] via 192.168.12.1, 00:00:11, FastEthernet0/0


Both routes have administrative distance 120 as it is default for RIP. Let's change AD for 192.168.100.0/24 R2#conf t
R2(config)#access-list 10 permit 192.168.100.0 0.0.0.255
R2(config)#router rip
R2(config-router)#distance 150 192.168.12.1 0.0.0.0 10
R2(config-router)#end

Now, we'll give it some time since RIP is notoriously slow to converge protocol and check

R2#show ip route rip
R    192.168.200.0/24 [120/1] via 192.168.12.1, 00:00:02, FastEthernet0/0
R    192.168.100.0/24 [150/1] via 192.168.12.1, 00:00:02, FastEthernet0/0

As you can see, 192.168.100.0/24 now has administrative distance 150

2. EIGRP
Now I configure EIGRP between my two routers

R2#show ip route eigrp
D    192.168.200.0/24 [90/156160] via 192.168.12.1, 00:00:13, FastEthernet0/0
D    192.168.100.0/24 [90/156160] via 192.168.12.1, 00:00:13, FastEthernet0/0

And repeat:

R2(config)#router eigrp 1
R2(config-router)#distance 150 192.168.12.1 0.0.0.0 10
R2(config-router)#end

Unlike RIP, EIGRP converges almost instantly:

R2#show ip route eigrp

D    192.168.200.0/24 [90/156160] via 192.168.12.1, 00:00:02, FastEthernet0/0

D    192.168.100.0/24 [150/156160] via 192.168.12.1, 00:00:02, FastEthernet0/0

3. OSPF

R2#show ip route ospf

O    192.168.200.0/24 [110/2] via 192.168.12.1, 00:00:17, FastEthernet0/0

O    192.168.100.0/24 [110/2] via 192.168.12.1, 00:00:17, FastEthernet0/0

In case of OSPF IP address in distance command should be router-id of OSPF neighbor from which route is learned.

R2#conf t

R2(config)#router ospf 1

R2(config-router)#distance 150 1.1.1.1 0.0.0.0 10

R2(config-router)#end

R2#sho ip route ospf

O    192.168.200.0/24 [110/2] via 192.168.12.1, 00:02:55, FastEthernet0/0

O    192.168.100.0/24 [150/2] via 192.168.12.1, 00:02:55, FastEthernet0/0

Once again, AD has changed to 150 for 192.168.100.0/24

Let's consider more complex OSPF scenario:

R2 and R3 advertise 192.168.100.0/24 and 192.168.200.0/24 to R4.

R4#sho ip route ospf | begin 192.168.200.0

O    192.168.200.0/24 [110/2] via 192.168.34.3, 00:00:10, FastEthernet0/0

                                [110/2] via 192.168.24.2, 00:00:10, FastEthernet0/1

O    192.168.100.0/24 [110/2] via 192.168.34.3, 00:00:10, FastEthernet0/0

                                [110/2] via 192.168.24.2, 00:00:10, FastEthernet0/1

Both paths are equal and R4 will use both of them by default. Now, for some hard to explain reason we want to use R3 as our primary path to 192.168.100.0/24.  It should be easy, all we need to do is to apply our access-list 10 from above to routes we receive from R2 (OSPF router-id 2.2.2.2):

R4#conf t

R4(config)#router ospf 1

R4(config-router)#distance 150 2.2.2.2 0.0.0.0 10

R4(config-router)#end

We can not use "ip ospf cost" command since it affects all routes coming via that interface. Routing check:

R4#sho ip route ospf | begin 192.168.100.0

O    192.168.100.0/24 [150/2] via 192.168.34.3, 00:15:07, FastEthernet0/0

                                [150/2] via 192.168.24.2, 00:15:07, FastEthernet0/1

Hmm, 192.168.100.0/24 still has AD of 150 for both next hops. What happened? After doing a lot of digging I found this post from Mike Timm. Cisco bug CSCeh44993 prevents modifying administrative distance per route per neighbor in OSPF. Alas, Cisco decided not to fix it and make it a feature.

IPexpert puzzle

IPexpert posted  interesting puzzle today. Here is my solution:

R2:
router ospf 1
 router-id 192.168.0.2
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
 default-information originate

R5:
router bgp 5
 no synchronization
 bgp router-id 192.168.0.5
 bgp log-neighbor-changes
 redistribute ospf 1
 neighbor 172.16.45.4 remote-as 4
 neighbor 172.16.45.4 default-originate route-map DEFAULT
 no auto-summary
!
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
route-map DEFAULT permit 10
 match ip address prefix-list DEFAULT

Now let's head to R4 and check BGP routes:

R4#sho ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 00:55:28
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/2] via 172.16.45.5, 00:55:28
B       192.168.0.5 [20/0] via 172.16.45.5, 00:55:28
B*   0.0.0.0/0 [20/0] via 172.16.45.5, 00:37:36

I am still trying to find out why OSPF would not redistribute static default route. BGP will not redistribute default route even it's in source protocol routing table. It must be loop prevention mechanism, but I can not come up with a scenario when redistributing default route as oppose to originating it can cause routing loop. Especially in OSPF, where "default-information originate" creates Type5 LSA - same type as "redistribute" command would have created:

R2#sho ip ospf database | begin Type-5
                Type-5 AS External Link States
Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         192.168.0.2     391         0x80000003 0x001F26 1

BGP network route-map command

Let's consider following simple network:

Here is related configuration
R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255

interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255 

 neighbor 192.168.12.2 remote-as 2

 neighbor 192.168.12.2 send-community both

 no auto-summary

!

ip bgp-community new-format

R2

interface FastEthernet0/0

 ip address 192.168.12.2 255.255.255.0

end

interface FastEthernet0/1

 ip address 192.168.23.2 255.255.255.0

end

router bgp 2

 no synchronization

 bgp log-neighbor-changes

 neighbor 192.168.12.1 remote-as 1

 neighbor 192.168.23.3 remote-as 3

 no auto-summary

!

ip bgp-community new-format

R3

interface FastEthernet0/0

 ip address 192.168.23.3 255.255.255.0

!

router bgp 3

 no synchronization

 bgp log-neighbor-changes

 neighbor 192.168.23.2 remote-as 2

 no auto-summary

The prefix 1.1.1.1/32 is advertised to R2 and R3:

R2#sho ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 14

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

  Advertised to update-groups:

        1

  1

    192.168.12.1 from 192.168.12.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external, best

Now, let's add community attribute to 1.1.1.1/32 prefix by using network route-map command. First, we create route-map

R1#conf t
R1(config)#route-map LOOP1
R1(config-route-map)#set community 1:100
R1(config-route-map)#exit

Second, apply this route-map to the prefix
R1(config)#router bgp 1
R1(config-router)#network 1.1.1.1 mask 255.255.255.255 route-map LOOP1

We can see on R2 that community 1:100 was indeed added to 1.1.1.1/32

R2#show ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 15

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x8A0

  Advertised to update-groups:

        1

  1

    192.168.12.1 from 192.168.12.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external, best

      Community: 1:100

So far, so good. Now I am going to try well-known community no-export, so R2 does not advertise 1.1.1.1/32 to R3

R1# conf t

R1(config)#route-map LOOP1

R1(config-route-map)#no set community 1:100

R1(config-route-map)#set community no-export

Debug output on R1 indicates that 1.1.1.1/32 is not advertised to R2

*Mar  1 02:37:19.771: BGP(0): sourced route for 1.1.1.1/32 path #0 changed (weight 32768)

*Mar  1 02:37:20.231: BGP(0): nettable_walker 1.1.1.1/32 route sourced locally

*Mar  1 02:37:20.231: BGP(0): 192.168.12.2 send unreachable 1.1.1.1/32

*Mar  1 02:37:20.231: BGP(0): 192.168.12.2 send UPDATE 1.1.1.1/32 -- unreachable

*Mar  1 02:37:20.319: BGP(0): 192.168.12.2 rcv UPDATE about 1.1.1.1/32 -- withdrawn

Sure enough:

R2#show ip bgp 1.1.1.1/32

% Network not in table

That's not what I intended. What happened? The thing is route-map key in BGP network command changes attributes BEFORE affected prefix is inserted into BGP routing table. In this case no-export community is added first, then R1 puts 1.1.1.1/32 in BGP routing table on R1, where R1 sees that this prefix can not be advertised outside its AS. To verify, let's change R1-R2 from eBGP into iBGP:

R1#sho run | sec r b

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255 route-map LOOP1

 neighbor 192.168.12.2 remote-as 1

 neighbor 192.168.12.2 send-community both

 no auto-summary

R2#sho run | sec r b

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 neighbor 192.168.12.1 remote-as 1

 neighbor 192.168.23.3 remote-as 3

 no auto-summary

R3#sho run | sec r b

router bgp 3

 no synchronization

 bgp log-neighbor-changes

 neighbor 192.168.23.2 remote-as 1

 no auto-summary

1.1.1.1/32 should appear in R2's BGP routing table:

R2#sho ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 3

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)

  Not advertised to any peer

  Local

    192.168.12.1 from 192.168.12.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      Community: no-export

Since R1 and R2 are in the same ASN, no-export community does not affect route advertisement. However,

R3#show ip bgp 1.1.1.1/32

% Network not in table

Important thing to remember is that in this case route-map changes attributes BEFORE prefix added into BGP routing table and advertised to other BGP peers.

Hidden OSPF command

I was testing some OSPF features and wanted to check routes learned via OSPF. Before going into LSA database, I checked RIB, but the output format was not what I was expecting:

           OSPF Router with ID (1.1.1.1) (Process ID 1)

    Area BACKBONE(0)

    Intra-area Route List

*   1.1.1.1/32, Intra, cost 1, area 0, Connected

      via 1.1.1.1, Loopback0

*   11.11.11.11/32, Intra, cost 1, area 0, Connected

      via 11.11.11.11, Loopback11

    Intra-area Router Path List

i 4.4.4.4 [564] via 192.168.12.2, Serial1/0.12, ABR, Area 0, SPF 11

    Inter-area Route List

*>  4.4.4.4/32, Inter, cost 565, area 0

      via 192.168.12.2, Serial1/0.12

    Area 1

    Intra-area Route List

*>  192.168.24.0/24, Intra, cost 564, area 1

      via 192.168.12.2, Serial1/0.12

So, I checked what I typed in the command line. It was "R1#sho ip ospf route" instead of "show ip route ospf". However, "route" does not show up as an option for "show ip ospf" command:

R1#sho ip ospf ?
  <1-65535>            Process ID number
  border-routers       Border and Boundary Router Information
  database             Database summary
  flood-list           Link state flood list
  interface            Interface information
  max-metric           Max-metric origination information
  mpls                 MPLS related information
  neighbor             Neighbor list
  request-list         Link state request list
  retransmission-list  Link state retransmission list
  rib                  Routing Information Base (RIB)
  sham-links           Sham link information
  statistics           Various OSPF Statistics
  summary-address      Summary-address redistribution Information
  timers               OSPF timers information
  traffic              Traffic related statistics
  virtual-links        Virtual link information
  |                    Output modifiers
 R1#sho ip ospf route ?
% Unrecognized command

I am running 12.4(15)T14 on the router. This is very useful command and output is easier to interpret than "show ip ospf database". Why does Cisco keep it hidden? 

CCIE R&S written

After getting CCIP and CCNP certifications I did not have a reason to postpone taking CCIE written exam any longer. So, I went for it last Wednesday and passed it. CCIE R&S written covers broad range of topics. All these topics are covered in depth by exams required to obtain CCIP and CCNP. If you took and passed ROUTE, SWITCH, TSHOOT, QOS, BGP and MPLS exams, CCIE R&S written looks fairly easy and does not require any additional preparations.