Unicast reverse Path

Unicast reverse path check is used as an ingress filter to protect the network from the untrusted networks. When uRPF is enabled, the router checks the source ip address of the packet is reachable via the incoming interface. If it is not, the router will drop the packet.

Note:
uRPF should not be configured if you have the asymmetric network.

To see how this feature works, I have one simple examples to illustrate this. I have R1 - R2 - R3 connected according to the figure below.  They are in the same OSPF area. However, R2 has a static route going to 1.1.1.1 pointing to the 192.168.3.2 (R3 interface ) as opposed to going out via 192.168.1.0 network.

R2:   ip route 1.1.1.1 255.255.255.255 192.168.3.2

// we force the traffic back to 1.1.1.1/32 by going through R3 instead of R1 ( static route higher AD than OSPF) 

We will test the connectivity by PING from R1 to R2 using source IP address of 1.1.1.1. If we do not enable the uRPF check on the R2 interface, the PING is successful.

R1#ping 2.2.2.2 source lo0

Type escape sequence to abort.

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

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/56 ms

R1#

When we enable the uRPF check on the interface R2, the PING will be failed because the traffic R2 going back to R1 will use another route (via R3) instead of going to R1 directly. This violates the RPF check rule.

R2(config-if)#ip verify unicast source reachable-via rx

the ping is failed.

R1#ping 2.2.2.2 source lo0

Type escape sequence to abort.

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

Packet sent with a source address of 1.1.1.1

.....

Success rate is 0 percent (0/5)

R1#

Netflow Configuration

Netflow allow us to export traffic statistics to the remote workstation. We use this data to gain traffic performance, control, or accounting in the specific network locations.

Configure netflow

• Enable Netflow
• Interface Level : ip route-cache flow
• Export Netflow information.
• global level 
• ip flow-export destination x.x.x.x <port>
• ip flow-export source x.x.x.x

Example configuration

interface Serial0/3/0

 description T1 to remote-sites

 bandwidth 1536

 ip address 10.12.255.138 255.255.255.248

 no ip redirects

 no ip unreachables

 no ip proxy-arp

 rate-limit output access-group 191 256000 32000 48000 conform-action transmit exceed-action drop

 ip route-cache flow

 service-policy output VOIP-LLQ

ip flow-export source Loopback0

ip flow-export destination 10.12.66.82 16384

ip flow-export destination 10.12.64.36 3000

BSR Border

ip pim bsr-border 


Prevent send / receive BSR message on the interface. When this command is used, the BSR  domain will stop at the interface configured this command.

R1 ---- R2 -----R3

Before 
R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:00:04, expires: 00:02:21
R3#

After 
R2
int f0/1
description To R3
ip pim bsr-border


R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

R3#

From the example above, after we put in the command ip pim bsr-border on the interface of R2 connecting to the R3, we no longer see the RP on the R3.

Command Scheduler (KRON)

Command Scheduler allows cutomers to schedule fully-qualified EXEC mode CLI command. It consists of 2 processes. A policy list is configured containing lines of EXEC CLI commands to be run.

KRON configuration example.


kron policy-list TEST_KRON
 cli enable
 cli conf terminal
 cli int f0/1
 cli bandwidth 10000

kron occurrence TEST_KRON in 1    //  occurrence in 1 minute

 policy-list TEST_KRON

Verify configuration

show kron schedule

Router#sh kron schedule

Kron Occurrence Schedule

TEST_KRON inactive, will run again in 0 days 00:00:13

IP next-hop peer address (BGP)

In BGP routing protocol, the update from the external AS will contains the next hop address of the external hop itself. Therefore, when the router receives the update from the external AS and advertises the update to the other routers via iBGP, the other routers will see the next hop of the advertised networks via the external router IP address.  However, we can use the next-hop-self command in the BGP process at the Border router to fix the problem. But what if we cannot use the next-hop-self command? Do we have any other option?

Yes. We can use the route-map and set ip next-hop peer-address command to tell the iBGP learn router to forward the packet to its peer address instead of the external router IP address. Check the example below for more detailed explanation.

In this example, R1 advertise 10.10.10.0/24 network to R2. R2 advertises this network to R3 via BGP. However, R2 does not have the next-hop-self command configured which makes the R3 consider the R1 as the next hop address. The problem is R3 does not know how to get to R1. Therefore, R3 does not have reachability through the 10.10.10.0/24 network.


R2
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.2 remote-as 200

R3

R3#sh ip bgp
BGP table version is 2, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i10.10.10.0/24    192.168.1.1              0    100      0 100 i
R3#

We use the next-hop peer address command in the R2 which makes R3 forward the packet destined to 10.10.10.0/24 network via its peer address which in this case is R2 address.

R2

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.2 remote-as 200
 neighbor 192.168.2.2 route-map PEER-ADDRESS out

route-map PEER-ADDRESS permit 10
 set ip next-hop peer-address
!

R3

R3#sh ip bgp

BGP table version is 2, local router ID is 192.168.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i10.10.10.0/24    192.168.2.1              0    100      0 100 i

R3#

Now R3 see the next hop address via R2. We can test the connectivity through this network now.

R3#ping 10.10.10.1

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/34/108 ms

R3#

BGP Cluster ID Loop Prevention

A router reflector cluster normally has a single route reflector. To avoid a single point of failure, you can configure a cluster with more than one route reflector. In case we have more than one RR in the group, we will establish the cluster of RRs. All RRs in the cluster are in the same cluster -ID.

Route-Reflector (RR) has an algorithm to prevent the update from the other RRs. It will not accept the update that has the same Cluster-ID as itself in order to prevent the loop in BGP. Below is the example of how the loop prevention works.

Example 

We have 2 scenarios as followings

• R1 and R2 are in the same cluster and have the same Cluster ID which is 111.111.111.111
• R1 and R2 are in the different cluster. R1 has cluster ID of 111.111.111.111 and R2 has a cluster ID of 222.222.222.222

Here is the example of the 1st scenario. ( same cluster ID)

R1
router bgp 100
 no synchronization
 bgp cluster-id 111.111.111.111
 bgp log-neighbor-changes
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.2 next-hop-self
 neighbor 192.168.2.2 remote-as 100
 neighbor 192.168.2.2 route-reflector-client
 neighbor 192.168.2.2 next-hop-self
 neighbor 192.168.4.2 remote-as 100
 neighbor 192.168.4.2 route-reflector-client
 neighbor 192.168.4.2 next-hop-self
 no auto-summary
R1#

R2

R2#sh run | sec bgp

router bgp 100

 no synchronization

 bgp cluster-id 111.111.111.111

 bgp log-neighbor-changes

 network 20.20.20.20 mask 255.255.255.255

 neighbor 192.168.1.1 remote-as 100

 neighbor 192.168.1.1 next-hop-self

 neighbor 192.168.3.2 remote-as 100

 neighbor 192.168.3.2 route-reflector-client

 neighbor 192.168.3.2 next-hop-self

 no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 11, local router ID is 20.20.20.20

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i3.3.3.3/32       192.168.3.2              0    100      0 i

*> 20.20.20.20/32   0.0.0.0                  0         32768 i

R2(config-router)#

From the bgp table shown, R2 do not have the 50.50.50.50/32 and 40.40.40.40/32 in its BGP table, the reason is these networks have the same cluster-id with the R2. Due to the loop prevention mechanism, R2 will not accept these networks.

********************

R2

router bgp 100

 no synchronization

 bgp cluster-id 222.222.222.222

 bgp log-neighbor-changes

 network 20.20.20.20 mask 255.255.255.255

 neighbor 192.168.1.1 remote-as 100

 neighbor 192.168.1.1 next-hop-self

 neighbor 192.168.3.2 remote-as 100

 neighbor 192.168.3.2 route-reflector-client

 neighbor 192.168.3.2 next-hop-self

 no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 13, local router ID is 20.20.20.20

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

* i3.3.3.3/32       192.168.2.2              0    100      0 i

*>i                 192.168.3.2              0    100      0 i

*> 20.20.20.20/32   0.0.0.0                  0         32768 i

*>i40.40.40.40/32   192.168.4.2              0    100      0 i

*>i50.50.50.50/32   192.168.4.2              0    100      0 i

R2(config-router)#

Now, we have changed the cluster ID of R2 to 222.222.222.222. At this time R1 and R2 have a different Cluster-ID. Therefore, R2 will accept the bgp update from R1 and it has the 40.40.40.40/32 and 50.50.50.50/32 networks in its bgp table.

Verification

R3#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 11

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

  Not advertised to any peer

  Local

    192.168.4.2 (metric 74) from 192.168.3.1 (20.20.20.20)

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

      Originator: 4.4.4.4, Cluster list: 222.222.222.222, 111.111.111.111

  Local

    192.168.4.2 (metric 74) from 192.168.2.1 (1.1.1.1)

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

      Originator: 4.4.4.4, Cluster list: 111.111.111.111

R3#

R2#

R2#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 13

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

  Advertised to update-groups:

        2

  Local

    192.168.4.2 (metric 74) from 192.168.1.1 (1.1.1.1)

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

      Originator: 4.4.4.4, Cluster list: 111.111.111.111

R2#

Remote SPAN

Remote SPAN (RSPAN) allows you to monitor source ports spread all over a switched network, not only locally on a switch with SPAN.  The traffic monitored by SPAN, instead of being

directly copied to the destination port, is flooded into a special RSPAN VLAN. The destination port can then be located anywhere in this RSPAN VLAN (there can even be several destination ports).

In this example, we are trying to monitor port f0/7 of SW1 and want to send all SPAN traffic to SW3 port f0/9 which has network analyzer connected to it.  Due to the fact that we do not have capture traffic locally, we need to use RSPAN. Therefore we created VLAN 99 to serve as a remote SPAN VLAN.

Below is the sample configuration

SW1

monitor session 10 source interface Fa0/7

monitor session 10 destination remote vlan 99

SW3

monitor session 10 destination interface Fa0/10

monitor session 10 source remote vlan 99