PIM BSR

Note: 

The BSR sends mapping messages to 224.0.0.13 (all-PIM-routers). This does notrequire dense mode support or a known RP

Sample Configuraiton

Task:

• Configure R1 loopback 0 as a  multicast source of 239.1.1.1 group
• R2 uses PIM BSR to announce RP.
• R3 will be 239.1.1.1 receiver

Configuration

R2
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

R3

interface FastEthernet0/0

 ip address 192.168.2.2 255.255.255.0

 ip pim sparse-mode

 ip igmp join-group 239.1.1.1

 duplex auto

 speed auto

end

Verify Configuration

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

  RP 2.2.2.2 (?), v2

    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150

         Uptime: 00:05:27, expires: 00:02:20

R3#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:03:25/00:02:55, RP 2.2.2.2, flags: SJPCL

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

(*, 224.0.1.40), 00:09:36/00:01:57, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Sparse, 00:09:36/00:01:57

R1#ping 239.1.1.1 source loopback 0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

Reply to request 0 from 192.168.2.2, 144 ms

Reply to request 0 from 192.168.2.2, 468 ms

R1#

Multicast Auto-RP

Auto-RP uses 2 multicast addresses to advertise the RP and the mapping information which are 224.0.1.39 and 224.0.1.40. It is operating in a sparse mode. However, there is a issue in the sense that all PIM routers need to join these 2 multicast groups in order to receive the RP announcement information. We encounter this problem by this followings.

1. PIM sparse-dense mode : in this mode the router will act as if it is in dense mode at first. Then it moves back to sparse mode. Therefore, it will learn the 224.0.1.39 and 224.0.1.40 when it is in dense mode.
2. Autorp-listener: This command will be configured at the global configuration. It allows only 2 multicast group which are 224.0.1.39 and 224.0.140 to to flood out to all PIM routers. It helps increase efficiency then flooding all multicast group to all routers at once like PIM sparse-dense mode does.

Example Configuration

Explanation

• Multicast source of 239.1.1.1 is located at R1 loopback interface with source address of 1.1.1.1
• Configure Auto-RP at R2 with RP announce at 2.2.2.2
• Configure the mapping agent at R2.
• R3 is a receiver of 239.1.1.1 multicast group.

Configuration

R2
ip pim send-rp-announce Loopback0 scope 5
ip pim send-rp-discovery scope 5
!

R3
ip multicast-routing

interface FastEthernet0/0

 ip address 192.168.2.2 255.255.255.0

 ip igmp join-group 239.1.1.1

 duplex auto

 speed auto

!

Debug output

*Mar  1 00:32:00.015: PIM(0): check pim_rp_announce 1

*Mar  1 00:32:00.015: PIM(0): send rp announce

*Mar  1 00:32:14.283: PIM(0): Send RP-reachability for 239.1.1.1 on FastEthernet0/1

*Mar  1 00:32:24.083: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1

*Mar  1 00:32:28.999: PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 192.168.2.2, to us

*Mar  1 00:32:29.003: PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set

*Mar  1 00:32:29.003: PIM(0): Update FastEthernet0/1/192.168.2.2 to (*, 239.1.1.1), Forward state, by PIM *G Join

Verify

R3

show ip mroute

(*, 239.1.1.1), 00:30:14/00:02:25, RP 2.2.2.2, flags: SP

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

When R3 joined the 239.1.1.1 multicast group

R3 Join 239.1.1.1

ip igmp join-group 239.1.1.1

(*, 239.1.1.1), 00:25:13/00:02:27, RP 2.2.2.2, flags: SJPCL

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

R3 received the traffic from R1 lo0 (multicast source)

R3#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:26:20/stopped, RP 2.2.2.2, flags: SJPCL

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

(1.1.1.1, 239.1.1.1), 00:00:16/00:02:48, flags: PLTX

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

(192.168.1.1, 239.1.1.1), 00:00:16/00:02:48, flags: PLTX

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

(*, 224.0.1.39), 00:34:11/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Sparse-Dense, 00:34:11/00:00:00

(2.2.2.2, 224.0.1.39), 00:00:53/00:02:06, flags: PTX

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

  Outgoing interface list: Null

(*, 224.0.1.40), 00:35:42/stopped, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Sparse-Dense, 00:35:42/00:00:00

(192.168.2.1, 224.0.1.40), 00:30:12/00:02:37, flags: PLT

  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0

  Outgoing interface list: Null

OSPF tunnel recursive routing issue

Core Issue

If the tunnel interface learns that the best path to the tunnel destination is through the tunnel itself, the interface shuts down temporarily.

Resolution

To avoid recursive routing problems, keep passenger and transport network routing information disjointed with one of these methods:

• Use a different Autonomous System (AS) number or tag.
• Use a different routing protocol.
• Use static routes to override the first hop, but watch for routing loops. For more information, refer to the Special Considerations section of Configuring Logical Interfaces.

Example Scenario

Configuration Plan 


Tunnel specification
Tunnel source: Loopback interface (10.1.1.1/24)
Tunnel destination :  10.1.2.1/24
Tunnel ip address : 172.16.1.1/24




Before Tunnel created
R1 has static default route sending out to R2. Therefore, destination tunnel (10.1.2.1/24) is reachable though static route.

R1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, Loopback0

C    192.168.1.0/24 is directly connected, FastEthernet0/0

R    192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:02, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 192.168.1.2

However, when we configure the tunnel interface between R1 and R2 with the tunnel source and destination as stated above. The destination tunnel is now reachable through the tunnel itself instead of through static route. 

After tunnel configuration

R1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets

C       172.16.1.0 is directly connected, Tunnel0

     10.0.0.0/24 is subnetted, 2 subnets

O       10.1.2.0 [110/11112] via 172.16.1.2, 00:00:02, Tunnel0

C       10.1.1.0 is directly connected, Loopback0

C    192.168.1.0/24 is directly connected, FastEthernet0/0

R    192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:05, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 192.168.1.2

From the core issue above which stated that 

"If the tunnel interface learns that the best path to the tunnel destination is through the tunnel itself, the interface shuts down temporarily."

At this time the tunnel interface learns the path to the tunnel destination through the tunnel interface itself. (172.16.1.2 = tunnel interface ). Therefore, it create the tunnel recursive routing issue as shown below that the tunnel interface will be temporary disable.

01:11:39: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:11:48: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:11:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down
01:12:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:12:58: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:12:59: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down

OSPF authentication

Sample command of the OSPF md5 authentiation


Configuration


R1
interface serial 0/0
ip ospf message-digest-key 1 md5 PASSWORD

router ospf 10
area 0 authentication message-digest

BGP Outbound Route Filtering (BGP ORF)

ORF is the feature to allow the receiver router to tell sender what routes it wants. In fact, it works in the same manner of the filter list on the sender to allow advertising specific routes to receiver. However, the ORF is useful in the sense that we do not have to modify the configuration in the sender. This will very helpful when talking about PE and CE. 

In this scenario, R1 has 192.168.x.0/24 network in its routing table. Without route filtering, R1 will advertise all of its routes to R2. However, in this case, R2 only want 192.168.4.0/24, 192.168.5.0/24 and 192.168.6.0/24 from R1.  We will use ORF to accomplish this task.

When No Filter prefix, R1 advertised all of 192.168.x.0/24 network to R2 as shown in the show ip bgp command.

R1

R1#sh ip bgp

BGP table version is 7, local router ID is 192.168.6.1

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

*> 192.168.1.0      0.0.0.0                  0         32768 i

*> 192.168.2.0      0.0.0.0                  0         32768 i

*> 192.168.3.0      0.0.0.0                  0         32768 i

*> 192.168.4.0      0.0.0.0                  0         32768 i

*> 192.168.5.0      0.0.0.0                  0         32768 i

*> 192.168.6.0      0.0.0.0                  0         32768 i

Configuration

R1

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 network 192.168.1.0

 network 192.168.2.0

 network 192.168.3.0

 network 192.168.4.0

 network 192.168.5.0

 network 192.168.6.0

 neighbor 10.10.1.2 remote-as 200
// receive ORF capability from R2

 neighbor 10.10.1.2 capability orf prefix-list receive

R2

ip prefix-list Block-1-3 seq 5 deny 192.168.0.0/22 ge 24 le 24

ip prefix-list Block-1-3 seq 10 permit 0.0.0.0/0 le 32

router bgp 200

 no synchronization

 bgp log-neighbor-changes

 neighbor 10.10.1.1 remote-as 100
// Send ORF capability to R1

 neighbor 10.10.1.1 capability orf prefix-list send

 neighbor 10.10.1.1 prefix-list Block-1-3 in

 no auto-summary

Verify configuration

R1#sh ip bgp neighbors 10.10.1.2 advertised-routes

BGP table version is 7, local router ID is 192.168.6.1

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

*> 192.168.4.0      0.0.0.0                  0         32768 i

*> 192.168.5.0      0.0.0.0                  0         32768 i

*> 192.168.6.0      0.0.0.0                  0         32768 i

Total number of prefixes 3

R1#

Now, R1 only advertise 192.168.4.0/24, 192.168.5.0/24 and 192.168.6.0/24 to R2

R2#sh ip bgp

BGP table version is 34, local router ID is 10.10.1.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

*> 192.168.4.0      10.10.1.1                0             0 100 i

*> 192.168.5.0      10.10.1.1                0             0 100 i

*> 192.168.6.0      10.10.1.1                0             0 100 i

BGP unequal BW Load sharing

To enable bgp multipath, we use the command under router bgp : maximum-path x. However, the way router sends the traffic is 1:1 load sharing and it does not depend on the link bandwidth. If we need the router to do an unequal load sharing according to the bandwidth between the multipath, bgp dmzlink-bw command is required.

In this example, we have 2 links between R1 and R2. The MED of 192.168.x.x prefixes has equal MED. However, the bandwidth of each link is not equal. 1000kbps and 100kbps as shown in the figure.

Here is the routing table of R2.

R2# sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.4.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.5.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

     10.0.0.0/24 is subnetted, 2 subnets

C       10.10.1.0 is directly connected, FastEthernet0/0

C       10.10.2.0 is directly connected, FastEthernet0/1

B    192.168.6.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.1.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.2.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.3.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

R2#

We can see from the routing table of R2 that R2 has 2 routes to reach 192.168.x.0/24. But the way R2 sends out packets is 1:1 load sharing although the bandwidth of each link is not equal. The requirement is to do a unequal cost load sharing between R1 and R2. Therefore, we need to enable dmzlink-bw feature on router R2.

Configuration

R2

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 bgp dmzlink-bw
 neighbor 10.10.1.1 remote-as 100
 neighbor 10.10.1.1 dmzlink-bw
 neighbor 10.10.2.1 remote-as 100
 neighbor 10.10.2.1 dmzlink-bw
 maximum-paths 3
 no auto-summary
 !
 address-family nsap
  maximum-paths 3
  no synchronization
 exit-address-family

R2#ping 192.168.6.0

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/175/256 ms

Verify Configuration

R2#sh ip bgp 192.168.6.0

BGP routing table entry for 192.168.6.0/24, version 23

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

Multipath: eBGP

  Advertised to update-groups:

        1

  100

    10.10.2.1 from 10.10.2.1 (192.168.6.1)

      Origin IGP, metric 0, localpref 100, valid, external, multipath

      DMZ-Link Bw 1 kbytes

  100

    10.10.1.1 from 10.10.1.1 (192.168.6.1)

      Origin IGP, metric 0, localpref 100, valid, external, multipath, best

      DMZ-Link Bw 1250 kbytes

R2#

R2#sh ip route 192.168.6.0

Routing entry for 192.168.6.0/24

  Known via "bgp 200", distance 20, metric 0

  Tag 100, type external

  Last update from 10.10.1.1 00:02:31 ago

  Routing Descriptor Blocks:

  * 10.10.2.1, from 10.10.2.1, 00:02:31 ago

      Route metric is 0, traffic share count is 10

      AS Hops 1

      Route tag 100

    10.10.1.1, from 10.10.1.1, 00:02:31 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 100

We can see in the result of show ip route 192.168.6.0 that traffic share of 2 links is not equal and the proportion of the traffic is according to the link bandwidth which is 1:10. So, the dmzlink-bw was successfully configured.!

Routing Loop (Redistribution)

Routing loop might occur when doing mutual redistribution between routing protocols. Therefore, to help prevent the routing loop, we need to filter routes from being learned by its neighbors. Route-map is the most powerful tools we can use to accomplish this preventing routes redistribute back to the original domain.

Example.

We need to filter route from redistribute back to the original domain eg., preventing EIGRP route from being redistribute back to EIGRP domain from OSPF and RIP. In this scenario. we will use route-map to do this.

To order to fully prevent the route redistribution back which may cause the loop, we require to configure route-map for all routing domain and all direction. See Configuration below.

Configuration


 R1
// deny OSPF learned route redistributed back to OSPF
route-map EIGRP->OSPF deny 10
 match tag 300


// Allow RIP learned route redistributed to OSPF
route-map EIGRP->OSPF permit 20
 match tag 100

// Allow the rest of routes (EIGRP) redistributed to OSPF and set tag 200
route-map EIGRP->OSPF permit 30
 set tag 200


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


// deny EIGRP learned route redistributed back to EIGRP
route-map OSPF->EIGRP deny 10
 match tag 200

// Allow RIP learned route redistributed to EIGRP
route-map OSPF->EIGRP permit 20
 match tag 100

// Allow the rest of routes (OSPF) redistributed to EIGRP and set tag 300
route-map OSPF->EIGRP permit 30
 set tag 300
!

Redistribution

router eigrp 1

 redistribute ospf 1 metric 1000 10 255 1 1500 route-map OSPF->EIGRP

 auto-summary

!

router ospf 1

 log-adjacency-changes

 redistribute eigrp 1 subnets route-map EIGRP->OSPF

R2

route-map EIGRP->RIP deny 10

 match tag 100

route-map EIGRP->RIP permit 20

 match tag 300

route-map EIGRP->RIP permit 30

 set tag 200

route-map RIP->EIGRP deny 10

 match tag 200

route-map RIP->EIGRP permit 20

 match tag 300

route-map RIP->EIGRP permit 30

 set tag 100

Redistribution

router eigrp 1

 redistribute rip metric 1000 10 255 1 1500 route-map RIP->EIGRP

 auto-summary

!

router rip

 version 2

 redistribute eigrp 1 subnets route-map EIGRP->RIP

 R1

route-map EIGRP->OSPF deny 10

 match tag 300

route-map EIGRP->OSPF permit 20

 match tag 100

route-map EIGRP->OSPF permit 30

 set tag 200

route-map OSPF->EIGRP deny 10

 match tag 200

route-map OSPF->EIGRP permit 20

 match tag 100

route-map OSPF->EIGRP permit 30

 set tag 300

!

Redistribution

router eigrp 1

 redistribute ospf 1 metric 1000 10 255 1 1500 route-map OSPF->EIGRP

 auto-summary

!

router ospf 1

 log-adjacency-changes

 redistribute eigrp 1 subnets route-map EIGRP->OSPF

R3

route-map OSPF->RIP deny 10

 match tag 100

route-map OSPF->RIP permit 20

 match tag 200

route-map OSPF->RIP permit 30

 set tag 300

route-map RIP->OSPF deny 10

 match tag 300

route-map RIP->OSPF permit 20

 match tag 200

route-map RIP->OSPF permit 30

 set tag 100

Redistribution

router ospf 1

 redistribute rip subnets route-map RIP->OSPF

 auto-summary

!

router rip

 redistribute ospf 1 metric 3 route-map OSPF-RIP

Note from IPExpect (Redistribution)

Note about Problem in Redistribution

• When redistribution OSPF in to BGP, by default, BGP only accepts internal routes not external type 1 or type 3
• Beware of the metric used by RIP
• Watch for the administrative distance prolems especially since IGRP has a lower distance than OSPF
• Redistributing in to RIP require a metric or default-metric or it may get set to 16
• Always filter routes when doing redistribution

When Redistributing from on protocol to another 

• Each protocol has its own rules
• The path redistributed must be RIB best path
• The path redistributed must be in the routing table
• Connected routes always win.
• Results may or may not be expected

Metric

• You must set metric in RIP
• You must set metric in EIGRP except for Connected, Static to interface
• OSPF metric is 20 (for BGP is 1 )
• BGP has no metric, but origin is incomplete.

Redistribution Oddities

• Route map configuration allows.
• match ip address 
• match ip next-hop
• match interface ( of IP next hop)
• and others
• Conditional redistribution can occur.
• Redistribute from RIP to OSPF only if the next hop is 'x' (where /x/ may be the less-preffered RIP path)

MPLS Sample Configuration

MPLS network


<explanation will be added later on>

Configuration
Download
http://ge.tt/3DhIfuz

PE1


VRF configuration

ip vrf cust_1
 rd 1:1
 route-target export 1:100
 route-target import 1:100
!

EIGRP between PE1 and CE1


router eigrp 1
 auto-summary
 !
 address-family ipv4 vrf cust_1
  redistribute bgp 1 metric 10000 100 100 1 1500
  network 192.168.1.0
  auto-summary
  autonomous-system 1
 exit-address-family

MP-BGP (VPNv4-MPLS) configuration
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family ipv4
  neighbor 3.3.3.3 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf cust_1
  redistribute eigrp 1
  neighbor 3.3.3.3 remote-as 1
  neighbor 3.3.3.3 activate
  no synchronization
 exit-address-family
!

Verification


Customer routing table


CE1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       1.1.1.0/24 is directly connected, Loopback0
D       1.0.0.0/8 is a summary, 00:28:44, Null0
D    4.0.0.0/8 [90/435200] via 192.168.1.2, 00:05:42, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/307200] via 192.168.1.2, 00:05:42, FastEthernet0/0

CE2#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    1.0.0.0/8 [90/435200] via 192.168.2.1, 00:06:02, FastEthernet0/0

     4.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       4.4.4.0/24 is directly connected, Loopback0

D       4.0.0.0/8 is a summary, 00:13:46, Null0

D    192.168.1.0/24 [90/307200] via 192.168.2.1, 00:06:02, FastEthernet0/0

C    192.168.2.0/24 is directly connected, FastEthernet0/0

CE2#

Provider edge routing table

Routing table

PE1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/11] via 10.1.1.2, 00:11:19, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, FastEthernet0/1

PE1#

VRF routing table

PE1#sh ip route vrf cust_1

Routing Table: cust_1

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    1.0.0.0/8 [90/409600] via 192.168.1.1, 00:12:52, FastEthernet0/0

B    4.0.0.0/8 [200/409600] via 3.3.3.3, 00:07:29

C    192.168.1.0/24 is directly connected, FastEthernet0/0

B    192.168.2.0/24 [200/0] via 3.3.3.3, 00:07:30

PE1#

MPLS tagging VPNv4


* Normally, there are 2 MPLS tags. However, in this scenario, there is an implicit null on the outer layer so it will pop out left only VPN tag.

PE1#sh ip cef vrf cust_1 192.168.2.0

192.168.2.0/24, version 12, epoch 0, cached adjacency 10.1.1.2

0 packets, 0 bytes

  tag information set

    local tag: VPN-route-head

    fast tag rewrite with Fa0/1, 10.1.1.2, tags imposed: {18}

  via 3.3.3.3, 0 dependencies, recursive

    next hop 10.1.1.2, FastEthernet0/1 via 3.3.3.3/32

    valid cached adjacency

    tag rewrite with Fa0/1, 10.1.1.2, tags imposed: {18}

HSRP, VRRP, GLBP

Network Information 

HSRP

• Multicast : 224.0.0.2
• MAC : 0000.0c07.acXX
• UDP : 1985

Configuration 

standby <group> ip x.x.x.x

standby <group> preempt

standby <group> track <object ID> decrement <number>

standby <group> priority

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

VRRP

• Multicast : 224.0.0.18
• MAC  :  0000.5e00.01XX
• IP protocol : 112

Configuration

vrrp <group> priority 

vrrp <group> ip <Gateway>

vrrp <group> track <object ID> decrement <number>

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

GLBP

• Multicast : 224.0.0.102
• UDP 3222

Configuration

glbp <group> ip <Gateway>

glbp <group> load-balancing round-robin

glbp <group> weighting  <number> lower <number> upper <number> 

//Threshold  If it fails the weight will drop below <number> and state will be standby

glbp <group> weighting track <object ID>

GLBP

GLBP provides load balancing over multiple routers (gateways) using a single virtual IP addressand multiple virtual MAC addresses. Each host is configured with the same virtual IP address, and all routers in the virtual router group participate in forwarding packets. GLBP members communicate between each other through hello messages sent every 3 seconds to the multicast address 224.0.0.102, User Datagram Protocol (UDP) port 3222 (source and destination).



GLBP uses a weighting scheme to determine the forwarding capacity of each router in the GLBP group. The weighting assigned to a router in the GLBP group determines whether it will forward packets and, if so, the proportion of hosts in the LAN for which it will forward packets. Thresholds can be set to disable forwarding when the weighting falls below a certain value, and when it rises above another threshold, forwarding is automatically reenabled.


The GLBP group weighting can be automatically adjusted by tracking the state of an interface within the router. If a tracked interface goes down, the GLBP group weighting is reduced by a specified value. Different interfaces can be tracked to decrement the GLBP weighting by varying 

GLBP states:

For a virtual gateway the state can be one of the following:

1. Disabled: Indicates that the virtual IP address has not been configured or learned yet, but other GLBP configuration exists.
2. Initial: The virtual IP address has been configured or learned but virtual gateway configuration is not complete. An interface must be up and configured to route IP, and an interface IP address must be configured.
3. Listen: Virtual gateway is receiving hello packets and is ready to change to the “speak” state if the active or standby virtual gateway becomes unavailable.
4. Speak: Virtual gateway is attempting to become the active or standby virtual gateway.
5. Standby: Indicates that the gateway is next in line to be the active virtual gateway (AVG).
6. Active: Indicates that this gateway is the AVG, and that it is responsible for responding to Address Resolution Protocol (ARP) requests for the virtual IP address

 Ref :: 
http://www.ciscozine.com/2008/11/18/configuring-redundancy-with-glbp/


Example 

Configuration


R1
interface FastEthernet0/0
 ip address 192.168.1.252 255.255.255.0
 duplex auto
 speed auto
 glbp 1 ip 192.168.1.254
 glbp 1 priority 150
 glbp 1 preempt
end

R2
interface FastEthernet0/0
 ip address 192.168.1.253 255.255.255.0
 duplex auto
 speed auto
 glbp 1 ip 192.168.1.254
 glbp 1 preempt

Verify Configuration

R1#show glbp

FastEthernet0/0 - Group 1

  State is Active

    2 state changes, last state change 00:04:26

  Virtual IP address is 192.168.1.254

  Hello time 3 sec, hold time 10 sec

    Next hello sent in 0.392 secs

  Redirect time 600 sec, forwarder timeout 14400 sec

  Preemption enabled, min delay 0 sec

  Active is local

  Standby is 192.168.1.253, priority 100 (expires in 8.344 sec)

  Priority 150 (configured)

  Weighting 100 (default 100), thresholds: lower 1, upper 100

  Load balancing: round-robin

  Group members:

    c201.0548.0000 (192.168.1.253)

    c203.0548.0000 (192.168.1.252) local

  There are 2 forwarders (1 active)

  Forwarder 1

    State is Active

      1 state change, last state change 00:04:16

    MAC address is 0007.b400.0101 (default)

    Owner ID is c203.0548.0000

    Redirection enabled

    Preemption enabled, min delay 30 sec

    Active is local, weighting 100

  Forwarder 2

    State is Listen

    MAC address is 0007.b400.0102 (learnt)

    Owner ID is c201.0548.0000

    Redirection enabled, 597.444 sec remaining (maximum 600 sec)

    Time to live: 14397.444 sec (maximum 14400 sec)

    Preemption enabled, min delay 30 sec

    Active is 192.168.1.253 (primary), weighting 100 (expires in 7.440 sec)

Debug 

R1#debug ip udp

UDP packet debugging is on

R1#

*Mar  1 00:15:18.187: UDP: rcvd src=192.168.1.253(3222), dst=224.0.0.102(3222), length=68

*Mar  1 00:15:21.175: UDP: rcvd src=192.168.1.253(3222), dst=224.0.0.102(3222), length=68

*Mar  1 00:15:24.203: UDP: rcvd src=192.168.1.253(3222), dst=224.0.0.102(3222), length=68

*Mar  1 00:15:27.179: UDP: rcvd src=192.168.1.253(3222), dst=224.0.0.102(3222), length=68

BGP dampening

Instability in the BGP domain causes BGP router send the routing updates to its BGP peers. Every time BGP router receives an update it re-calculate its best path. Due to BGP router contains a large number of routes in its routing table, the router need to use a lot of CPU resource and memory to calculate it. If there is a route flap in the network, it will make it worse since router needs to do a recalculation for many times.


Dampening is the feature in Cisco IOS preventing BGP router calculates a large number of routes updates when the route flap. BGP process assigns a penalty to the route each time it flaps. When the penalty exceeds the limit, the route is dampened. It will not accept or announce any routing update from other peer. The penalty decays at the half life rate.


BGP dampening command.


bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]

Example

router bgp 10

bgp dampening 30 1500 10000 120