RIPV2 Update Filtering - Offset List,Passive Interface,Administrative Distance,Distribute-List

You can filter RIP updates using various methods and I am going to demonstrate four of them. We will use the topology displayed in figure 1 below. I have auto-summary disabled and running version2. All filtering will take place on R4.

Figure 1

Routing Table Before Any Filtering:

R4#show ip routeed static route

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:07, FastEthernet0/0
     100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       100.100.100.0/24 [120/1] via 192.168.100.2, 00:00:07, FastEthernet0/0
R       100.0.0.0/8 is possibly down,
          routing via 192.168.100.2, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0
 
Offset List: Lets mark 100.100.100.0/24 invalid by setting an offset of 15. We could of configured 16 as well. I went with 15 since we are already adding 1 hop count by default so it gives us 16.

1. Create an ACL to identify which routes should be filtered.
1.  access-list 1 permit 100.100.100.0 0.0.0.255
2.  Configure the offset-list under the rip process
1. router rip
2.  offset-list 1 in 15

From the debug below we can see that we are successful in preventing the route from making it into the routing table. Rip will only advertise routes that are in the routing table.

R4#debug ip rip
RIP protocol debugging is on
R4#
*Mar  1 00:37:36.811: RIP: received v2 update from 192.168.100.2 on FastEthernet0/0
*Mar  1 00:37:36.815:      100.100.100.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
*Mar  1 00:37:36.815:      200.200.200.0/24 via 0.0.0.0 in 1 hops
*Mar  1 00:37:37.659: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.100.1)
*Mar  1 00:37:37.659: RIP: build update entries - suppressing null update

Passive Interface: Lets enable passive interface default on R4 F0/0.

1. Configure passive-interface default under the rip process
1. router rip
2. passive-interface default

From the debug below we can see that we are successful in preventing R4 from advertising routes to R5.(Compare the Debug From the previous Example). However, R5 can advertise routes to R4.

*Mar  1 00:47:45.955: RIP: received v2 update from 192.168.100.2 on FastEthernet0/0
*Mar  1 00:47:45.955:      100.100.100.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
*Mar  1 00:47:45.959:      200.200.200.0/24 via 0.0.0.0 in 1 hops

Administrative Distance:  Lets increase the Administrative distance for subnet 100.100.100.0/24

1. Create an ACL to identify which routes should be filtered.
1.  access-list 1 permit 100.100.100.0 0.0.0.255
2.  Configure the distance value under the rip process
1. router rip
2.  distance 200 192.168.100.2 0.0.0.0 1 (The way to read this is apply admin distance 200 for any  routes in access-list 1 coming from 192.168.100.2).

We can see the update was succesfull from the following show ip route output. If you wanted to you can set the admin distance to 255(inaccessible) and the route will never get into the routing table (RIB).

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:17, FastEthernet0/0
     100.0.0.0/24 is subnetted, 1 subnets
R       100.100.100.0 [200/1] via 192.168.100.2, 00:00:17, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0
R4#

distribute-list: Lets filter 100.100.100.0/24 from the routing table.

1. Create a prefix-list to identify which routes we want to only allow in.
1.  ip prefix-list filter_rip permit 200.200.200.0/24
2.  Configure the distribute-list under the rip process
1. router rip
2.  distribute-list prefix filter_rip in

 We can see the update was succesfull from the following show ip route output. We can also confirm
 that we are filtering routes inbound via show ip protocols.

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:06, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0

R4#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is (prefix-list) filter_rip
  Sending updates every 30 seconds, next due in 13 seconds

CCNP TO CCIE

Its been sometime since I last updated the Blog and Now I am going to try and update the blog on a weekly basis. I have passed all three CCNP Routing & Switching Exams. I am officially CCNP Certified. I am now working on my CCIE. I need to update the title of the blog :-).

Cisco FIB VS RIB

Routing Information Base (RIB)

The Routing Information Base RIB is the location in which all IP Routing information is stored. The RIB is not specific to any routing protocol, rather, it is the repository where all the routing protocols place all of their routes. Routes are inserted into the RIB whenever a routing protocol running on the router learns a new route. When a destination becomes unreachable, the route is first marked unusable and later removed from the RIB as per the specifications of the routing protocol they were learned from. It is important to note that the RIB is NOT used for forwarding IP datagrams, nor is it advertised to the rest of the networks to which the router is attached. A Cisco router's RIB will contain filtered routes; however, these will never make it to the "Forwarding Information Base", which contains yet a different set of routes.

 CEF Disabled:

*Mar  1 01:11:40.003: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
*Mar  1 01:11:40.003: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:40.059: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
*Mar  1 01:11:40.063: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:40.087: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
 

Forwarding Information Base (FIB)

Cisco routers build a Forwarding Information Base (FIB) which contains all the routes that could potentially be advertised to all neighboring routers within the next set of announcements. This is also the same set of routes used to forward IP datagrams. On Cisco routers with a distributed forwarding architecture and which have Distributed Cisco Express Forwarding (DCEF) enabled, a copy of the FIB will be 'compiled' and downloaded to the applicable line-cards or modules. This offloads a large portion of the routing load from the main CPU and increases the overall traffic load that can be sustained by the router.

 CEF Enabled:

*Mar  1 01:11:28.735: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via FIB
*Mar  1 01:11:28.735: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:28.755: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via FIB
*Mar  1 01:11:28.755: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending

MPLS Neighbor Security

I am going to show you how to implement LDP security between neighbors.  These are computed as MD5 Signatures.

Lets verify how our neighborship currently looks on R2 AKA the (P) router. We see have two diffrent neighbors.  Lets set a password for each.

R2#show mpls ldp neighbor
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 1.1.1.1.646 - 2.2.2.2.48828
        State: Oper; Msgs sent/rcvd: 8/8; Downstream
        Up time: 00:00:07
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.1
        Addresses bound to peer LDP Ident:
          192.168.100.1   1.1.1.1
    Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 4.4.4.4.23134 - 2.2.2.2.646
        State: Oper; Msgs sent/rcvd: 8/8; Downstream
        Up time: 00:00:06
        LDP discovery sources:
          GigabitEthernet2/0, Src IP addr: 192.168.104.1
        Addresses bound to peer LDP Ident:
          192.168.104.1   4.4.4.4

R2(config)#mpls ldp neighbor 1.1.1.1 password joel
R2(config)#mpls ldp neighbor 4.4.4.4 password joel

Now we will need to do the same on R1 and R4 but lets not do it yet. I am going to clear the LDP neighborship to see what errors are generated since we have not made any changes on R1 and R4.

R2#clear mpls ldp neighbor *
R2#
*Mar 18 22:27:26.395: %LDP-5-CLEAR_NBRS: Clear LDP neighbors (*) by console
*Mar 18 22:27:26.455: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (3) is DOWN (User cleared session manually)
*Mar 18 22:27:26.471: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is DOWN (User cleared session manually)
R2#

We can see from the alert below that we are not getting an MD5 from either neighbor 4.4.4.4 or 1.1.1.1. If they had a password set but it was incorrect it would say something alongs the line as it was invalid.

R2#
*Mar 18 22:27:43.707: %TCP-6-BADAUTH: No MD5 digest from 4.4.4.4(35699) to 2.2.2.2(646) tableid - 0
*Mar 18 22:27:44.055: %TCP-6-BADAUTH: No MD5 digest from 1.1.1.1(646) to 2.2.2.2(45946) tableid - 0

Now lets configure R1 and R4.

R1(config)#mpls ldp neighbor 2.2.2.2 password joel
R1(config)#end
R1#
*Mar 18 22:30:03.471: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar 18 22:30:13.451: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP

R4(config)#mpls ldp neighbor 2.2.2.2 password joel
R4(config)#end
R4#
*Mar 18 22:31:05.403: %SYS-5-CONFIG_I: Configured from console by console
R4#
*Mar 18 22:31:17.335: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
R4#

We are all done now.

Building an MPLS VPN Extranet/Intranet

I spent the past two days researching and building the MPLS VPN network below. It sure was fun and a great refresher.  Below you will find details of what is required and some verification output.
You also should check out the following PDF link from NIL,the packet life link and the Cisco Video on building MPLS vpn's. I watched the video and its all relevant information.

Introduction to MPLS VPN [Webcast]

MPLS VPN Cheat Sheet

Creating an MPLS VPN - PacketLife

My goal with this post was not to provide you with all the commands but rather a guide. I find that when configurations are provided, you don't retain as well as if you had to research it. If you want the configs, put a comment in with your email address and I will send them over.

 

Building the MPLS Core:

1. Create loopback interfaces on R1,R2 and R4.
2. On R1,R2 and R4 you need to enable OSPF as your transport mechanisms for your loopback interfaces and the interconnects (Point to Point Interfaces) between the switches. Put them all in Area 0.
3. Enable mpls ip globally and on the interconnects between R1,R2 and R4. Also you want to hard set the LDP router id for LDP with the following command, mpls ldp router-id Loopback0.  Hard set it on R1 and R4 as well.
4. keep in mind that you will use the loopback interface for BGP peering between the PE devices.

Verifications:

R2#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               2.2.2.2/32         1     LOOP  0/0
Gi2/0        1     0               192.168.104.2/24   1     P2P   1/1
Gi0/0        1     0               192.168.100.2/24   1     P2P   1/1

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:38    192.168.104.1   GigabitEthernet2/0
1.1.1.1           0   FULL/  -        00:00:31    192.168.100.1   GigabitEthernet0/0
R2#

R2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet0/0     Yes (ldp)     No       No  No     Yes
GigabitEthernet2/0     Yes (ldp)     No       No  No     Yes

R2#show mpls ldp neighbor
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 1.1.1.1.646 - 2.2.2.2.44858
        State: Oper; Msgs sent/rcvd: 135/136; Downstream
        Up time: 01:51:40
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.1
        Addresses bound to peer LDP Ident:
          192.168.100.1   1.1.1.1

Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 4.4.4.4.56543 - 2.2.2.2.646
        State: Oper; Msgs sent/rcvd: 136/136; Downstream
        Up time: 01:51:24
        LDP discovery sources:
          GigabitEthernet2/0, Src IP addr: 192.168.104.1
        Addresses bound to peer LDP Ident:
          192.168.104.1   4.4.4.4
R2#

Keep in mind that the P router is not going to be aware of any customer routes. It will label switch the traffic. Most of the configurations will be on the PE devices and CE.

Building the PE Configurations for R1:

1. Configure VRF's, Route Distinguisher, and Route-Targets.
2. Configure MPLS globally and on Interfaces facing the P router.
3. Configure CE facing interfaces to be part of a VRF.
4. Configure IBGP peering between PE Devices to Exchange vpnv4 routes.
5. Configure CE to PE routing protocol(RIP,EIGRP,OSPF or BGP).

Verifications:
R1#show ip vrf detail
VRF corp (VRF Id = 1); default RD 100:1; default VPNID <not set>
  Interfaces:
    Fa3/0
VRF Table ID = 1
  Export VPN route-target communities
    RT:100:1
  Import VPN route-target communities
    RT:100:1
  No import route-map
  No global export route-map
  No export route-map
  VRF label distribution protocol: not configured
  VRF label allocation mode: per-prefix

VRF das (VRF Id = 2); default RD 102:1; default VPNID <not set>
  Interfaces:
    Gi1/0
VRF Table ID = 2
  Export VPN route-target communities
    RT:102:1
  Import VPN route-target communities
    RT:102:1
  No import route-map
  No global export route-map
  No export route-map
  VRF label distribution protocol: not configured
  VRF label allocation mode: per-prefix


R1#show ip vrf
  Name                             Default RD          Interfaces
  corp                             100:1               Fa3/0
  das                              102:1               Gi1/0

R1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet0/0     Yes (ldp)     No       No  No     Yes
R1#

R1#show mpls ldp neighbor
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0
        TCP connection: 2.2.2.2.44858 - 1.1.1.1.646
        State: Oper; Msgs sent/rcvd: 150/148; Downstream
        Up time: 02:03:41
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.2
        Addresses bound to peer LDP Ident:
          192.168.100.2   2.2.2.2         192.168.104.2

R1#show ip bgp vpnv4 all summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 19, main routing table version 19
9 network entries using 1404 bytes of memory
14 path entries using 1120 bytes of memory
10/6 BGP path/bestpath attribute entries using 1440 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
3 BGP extended community entries using 104 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4116 total bytes of memory
BGP activity 9/0 prefixes, 14/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4                100     150     151               19        0    0         02:04:16        6
192.168.103.1   4          200     142     142               19        0    0         02:05:06        2
R1#

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:32    192.168.100.2   GigabitEthernet0/0
7.7.7.7           1   FULL/BDR        00:00:30    192.168.250.1   GigabitEthernet1/0
R1#

Building CE configurations for R3:

Enable EBGP peering between the CE and PE
Update BGP Network statements to reflect any routes you want sent via the MPLS

Verifications:
R3#show ip bgp
BGP table version is 7, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  5.5.5.5/32       192.168.103.2                          0 100 300 i
 *>  100.100.100.0/24 0.0.0.0                  0         32768 i
 r>  192.168.103.0/30 192.168.103.2            0             0 100 ?
 *>  200.200.200.0    0.0.0.0                  0         32768 i

R3#show ip bgp summary
BGP router identifier 200.200.200.1, local AS number 200
BGP table version is 7, main routing table version 7
4 network entries using 576 bytes of memory
4 path entries using 320 bytes of memory
3/3 BGP path/bestpath attribute entries using 408 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1352 total bytes of memory
BGP activity 5/1 prefixes, 5/1 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.103.2   4          100     147     147        7    0    0 02:09:38        2
R3#

R5#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        unassigned      YES NVRAM  administratively down down
GigabitEthernet1/0     192.168.120.1   YES NVRAM  up                    up
FastEthernet2/0        unassigned      YES unset  administratively down down
FastEthernet2/1        unassigned      YES unset  administratively down down
Loopback5              5.5.5.5         YES NVRAM  up                    up
Loopback200            unassigned      YES unset  up                    up
R5#

R3#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        unassigned      YES NVRAM  administratively down down
GigabitEthernet1/0     unassigned      YES NVRAM  up                    up
FastEthernet2/0        192.168.103.1   YES NVRAM  up                    up
FastEthernet2/1        unassigned      YES NVRAM  administratively down down
Loopback100            100.100.100.1   YES NVRAM  up                    up
Loopback200            200.200.200.1   YES NVRAM  up                    up

R3#ping 5.5.5.5 source loopback 200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 200.200.200.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/119/164 ms
R3#

Upgrade Cisco NX-OS For Cisco Nexus 3000 Series Switch

Step 1:
Copy the files onto the device: You can use TFTP, FTP or SCP. I like SCP because its way faster then then TFTP. Download a free copy of Solar Winds SCP.

copy scp://admin@192.168.100.1/n3000-uk9.5.0.3.U3.2.bin bootflash:
copy scp://admin@192.168.100.1/n3000-uk9-kickstart.5.0.3.U3.2.bin bootflash:

Step 2:
Confirm the files are are in the directory you specified: You also don't need to run an MD5 check because that is part of the install all option.

switch# dir
        638    Jun 18 19:37:32 2012  license_FOC1536R01A_4.lic
      49152    Feb 26 18:24:48 2013  lost+found/
       3166    Feb 26 18:02:57 2013  mts.log
   25439232    Jun 18 19:31:49 2012  n3000-uk9-kickstart.5.0.3.U2.2b.bin
   25439744    Feb 26 19:00:08 2013  n3000-uk9-kickstart.5.0.3.U3.2.bin
   93751392    Jun 18 19:32:32 2012  n3000-uk9.5.0.3.U2.2b.bin
  126502986    Feb 26 18:59:16 2013  n3000-uk9.5.0.3.U3.2.bin
       4096    Jan 29 19:35:08 2010  vdc_2/
       4096    Jan 29 19:35:08 2010  vdc_3/
       4096    Jan 29 19:35:08 2010  vdc_4/

Step 3:
Select which images to install and from what directory:

install all kickstart bootflash:///n3000-uk9-kickstart.5.0.3.U3.2.bin system bootflash:///n3000-uk9.5.0.3.U3.2.bin


switch# install all kickstart bootflash:///n3000-uk9-kickstart.5.0.3.U3.2.bin system bootflash:///n3000-uk9.5.0.3.U3.2.bin
Installer is forced disruptive

Verifying image bootflash:/n3000-uk9-kickstart.5.0.3.U3.2.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS

Verifying image bootflash:/n3000-uk9.5.0.3.U3.2.bin for boot variable "system".
[####################] 100% -- SUCCESS

Verifying image type.
[####################] 100% -- SUCCESS

Extracting "system" version from image bootflash:/n3000-uk9.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Extracting "kickstart" version from image bootflash:/n3000-uk9-kickstart.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Extracting "bios" version from image bootflash:/n3000-uk9.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Performing module support checks.
[####################] 100% -- SUCCESS

Notifying services about system upgrade.
[####################] 100% -- SUCCESS



Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes      disruptive         reset  ISSU not supported



Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            5.0(3)U2(2b)             5.0(3)U3(2)           yes
     1   kickstart            5.0(3)U2(2b)             5.0(3)U3(2)           yes
     1        bios      v1.2.0(08/29/2011)      v1.2.0(08/29/2011)            no
     1   power-seq                    v5.1                    v5.1            no



Step 4: You will be prompted to reboot. Select Yes.

ISSU is not supported on this platform!!
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  [n] y

ISSU is not supported on this platform!!
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  [n] y

Install is in progress, please wait.

Performing runtime checks.
[####################] 100% -- SUCCESS

Setting boot variables.
[####################] 100% -- SUCCESS

Performing configuration copy.
[####################] 100% -- SUCCESS

Finishing the upgrade, switch will reboot in 10 seconds.
switch#

Step 5:  Issue a show version to confirm the NX-OS version once it comes back from the reboot.

Troubleshooting High CPU due to Multicast

Great Video on Troubleshooting High CPU due to Multicast. This video is geared toward IOS and not NX-OS.

https://supportforums.cisco.com/community/netpro/network-infrastructure/switching/blog/2012/12/12/troubleshooting-high-cpu-due-to-multicast