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

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