Unicast Reverse Path Forwarding – Strict Mode

Unicast Reverse Path Forwarding – Strict Mode

Unicast Reverse Path Forwarding (Unicast RPF) in Strict Mode is a network security tool designed for use at the edge of a service-provider network.

Strict Mode vs Loose Mode

Strict mode verifies that the source address of an IPv4 packet both exists in the routing table and is reachable by a path through the input interface before forwarding a packet.

Loose mode verifies only that the source IPv4 address exists in the routing table.

More info here:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/srpf_gsr.html

http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html

Filed Under: Security Tagged With: ,

BGP Syncronization

BGP Syncronization Rule

With synchronization enabled, BGP will not advertise routes to an EBGP speaker unless that route is also known via the IGP protocol.

If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly

For more info on this top refer to the BGP Case Study over at cisco.com

Filed Under: BGP Tagged With:

BGP Update Source

If you have started to look at BGP you will very soon come across the BGP command update-source. This command tells BGP which interface to source the BGP packets out of. The short demo below will highlight the problem.

BGP update-source

I have a very simple setup with 2 routers connected with a serial interface and an ethernet interface

Step 1:

I have setup BGP and set the the neighbor statements on each router to point to the ethernet address.

R1#sh run | beg router bgp
router bgp 1
no synchronization
bgp router-id 10.0.0.3
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 1

R2#sh run | beg router bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 1

BGP comes up fine
R2#sh ip bgp summary
BGP router identifier 10.0.0.2, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4     1      24      24        1    0    0 00:20:15        0

However if we now setup ip addresses on the Serial interfaces and then change the neighbor statement on R1 to try and peer to the Serial address while the neighbor statement on R2 is trying to peer with the ethernet interface the BGP neighborship will fail.

As the router is receiving a BGP request on an interface that is not configured to to receive a reply on.

*Mar  1 06:43:13.138: BGP: 10.0.0.2 open active, local address 10.0.0.1
*Mar  1 06:43:13.146: BGP: 10.0.0.2 open failed: Connection refused by remote host, open active delayed 200ms (850ms max, 87% jitter)

To fix this we need to use the command neighbor update-source

This tells BGP to send the update out the other interface and thus R2 will receive the BGP request on the interface it is expecting to hear on and the BGP relationship will come up.

R1

router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 31.0.0.1 remote-as 1
neighbor 31.0.0.1 update-source Serial0/0

R1#
*Mar  1 06:49:11.430: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Up
R1#
R1#

Now because we are telling the router to source the BGP packets out of serial interface the BGP neighborship comes up.

More info here

http://www.cisco.com/en/US/docs/ios/11_3/np1/configuration/guide/1cbgp.html

Filed Under: BGP