Pages

Sunday, June 5, 2011

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#

Friday, June 3, 2011

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#

Thursday, June 2, 2011

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




Wednesday, June 1, 2011

TCP and UDP Small Servers

TCP and UDP small server are services which runs on the router itself for some useful diagnostics.

TCP Small Servers

The TCP small servers are:
  • Echo: Echoes back whatever you type through the telnet x.x.x.x echo command.
  • Chargen: Generates a stream of ASCII data. Use the telnet x.x.x.x chargen command.
  • Discard: Throws away whatever you type. Use the telnet x.x.x.x discard command.
  • Daytime: Returns system date and time, if it is correct. It is correct if you run Network Time Protocol (NTP), or have set the date and time manually from the exec level. Use the telnet x.x.x.x daytime command.
Replace x.x.x.x with the IP address of your router. Most routers inside Cisco run the small servers.

UDP Small Servers

The UDP small servers are:
  • Echo: Echoes the payload of the datagram you send.
  • Discard: Silently pitches the datagram you send.
  • Chargen: Pitches the datagram you send, and responds with a 72-character string of ASCII characters terminated with a CR+LF.

igmp helper address

igmp helper address is used when we want to forward igmp join/leave message to another interface by specifying the ip address of the destination where we want to forward this igmp packet to.

In this example, R4 is trying to get the multicast traffic from R1. However, R3 is not a neighbor of R2. Therefore R4 cannot join the group. We need to add the igmp helper to forward this igmp join request to R2.


R2

interface FastEthernet0/1
 ip address 192.168.2.1 255.255.255.0
 ip pim sparse-dense-mode
 ip pim neighbor-filter 1
 duplex auto
 speed auto

R3
interface FastEthernet0/0
 ip address 192.168.2.2 255.255.255.0
 ip pim sparse-dense-mode
 ip igmp helper-address 192.168.2.1
 duplex auto
 speed auto
end

R4
interface FastEthernet0/0
 ip address 192.168.3.2 255.255.255.0
 ip igmp join-group 239.0.0.1
 duplex auto
 speed auto

Verify configuration

R1#ping 239.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.3.2, 132 ms