Hacking Cisco

Hacking Cisco - Content List

2011-12-05T15:00:00.000Z

Disclaimer

The author of the posts will not assume any liability or responsibility to any person or entity with respect to loss or damages incurred from information contained in this blog. Any resemblance to some other training materials and/or CCIE exam is completely coincidental.
Full information: http://hackingcisco.blogspot.com/2011/01/cisco-going-pro.html

Blog Version 0.1 (draft)

The journey of a thousand miles begins with one step.

Last Update:

December 5th 2011
Lab 166 - Multicast Helper-Map
Lab 167 - PIM BiDir

A quick jump to ...

OSPF | EIGRP | RIPv2 | BGP | Multicast

The List of Cisco Mini-Labs

**** OSPF ****

Lab 001 - OSPF Point-to-Point Mode
Lab 001 - OSPF Point-to-Point Mode - Solution
Lab 002 - OSPF in Broadcast Networks
Lab 003 - OSPF in NBMA Networks
Lab 004 - OSPF in Point-to-Multipoint
Lab 005 - OSPF in Point-to-Multipoint Non-broadcast
Lab 006 - OSPF Multi-Area Network
Lab 007 - OSPF Authentication
Lab 008 - OSPF Filtering with Distribute-List
Lab 009 - OSPF Filtering with Route-Map
Lab 010 - OSPF Filtering with Distance
Lab 011 - OSPF Filtering with Area Range
Lab 012 - OSPF Filtering with Area Filter-List
Lab 013 - OSPF LSA Flood Filtering
Lab 014 - OSPF Stub Area
Lab 015 - OSPF Totally Stubby Area
Lab 016 - OSPF NSSA Area LSA7-to-5 Translation
Lab 017 - OSPF NSSA Totally Stub Area
Lab 018 - OSPF FA Suppression in Translated Type-5 LSAs
Lab 019 - OSPF External Prefix Filtering
Lab 020 - OSPF Path Influencing Using Cost
Lab 021 - OSPF Path Influencing Using Bandwidth
Lab 022 - OSPF Path Influencing Using Neighbor Cost
Lab 023 - OSPF Changing Auto-Cost Reference-Bandwidth
Lab 024 - OSPF Virtual Link Example 1
Lab 025 - OSPF Virtual Link Example 2
Lab 026 - OSPF Virtual Link Example 3
Lab 027 - OSPF Path Selection with Transit Capability
Lab 028 - OSPF Stub Router Advertisement
Lab 029 - OSPF Reducing LSA Flooding
Lab 030 - OSPF On Demand Circuits
Lab 031 - OSPF Default Routing
Lab 032 - OSPF Conditional Default Routing
Lab 033 - OSPF Conditional Default Routing with IP SLA
Lab 034 - OSPF Discard Route
Lab 035 - OSPF Resource Management
Lab 036 - OSPF Timers
Lab 037 - OSPF Other Features

**** EIGRP ****

**** RIPv2 ****

Lab 063 - RIPv2 Split-Horizon
Lab 064 - RIPv2 Default Routing
Lab 065 - RIPv2 Conditional Default Routing Advertisement
Lab 066 - RIPv2 Conditional Default Routing with IP SLA
Lab 067 - RIPv2 Send and Receive Versions
Lab 068 - RIPv2 Filtering with Standard ACL
Lab 069 - RIPv2 Filtering with Extended ACL
Lab 070 - RIPv2 Filtering with Passive-Interface
Lab 071 - RIPv2 Filtering with AD
Lab 072 - RIPv2 Metric Manipulation with Offset-List
Lab 073 - RIPv2 Auto-Summary
Lab 074 - RIPv2 Manual Summarization
Lab 075 - RIPv2 Broadcast Updates
Lab 076 - RIPv2 Unicast Updates
Lab 077 - RIPv2 Triggered Updates
Lab 078 - RIPv2 Source Update Validation
Lab 079 - RIPv2 Authentication
Lab 080 - RIPv2 Timers

**** BGP ****

**** Multicast ****

Lab 143 - PIM Dense-Mode
Lab 144 - PIM Sparse-Mode
Lab 145 - PIM RPF Failure

Lab 146 - PIM RPF Failure 2
Lab 147 - Cisco Auto-RP
Lab 148 - Cisco Auto-RP Multiple RPs
Lab 149 - Auto-RP Filtering
Lab 150 - Auto-RP Listener
Lab 151 - PIM RP Election
Lab 152 - PIM Accept RP
Lab 153 - PIM Accept Register
Lab 154 - Auto-RP Scope Limiting
Lab 155 - Multicast Traffic Boundary
Lab 156 - PIM NBMA
Lab 157 - PIM Bootstrap Router
Lab 158 - BSR with Multiple RPs
Lab 159 - BSR Propagation Filtering
Lab 160 - Multicast Stub Routing
Lab 161 - Source Specific Multicast
Lab 162 - Anycast RP
Lab 163 - IGMP Filtering
Lab 164 - IGMP Timers
Lab 165 - Multicast Rate Limiting
Lab 166 - Multicast Helper-Map
Lab 167 - PIM BiDir

Cisco Fundamentals Study:

http://ciscoiseasy.blogspot.com

My Youtube channel:

http://www.youtube.com/jrcomputerlabs

News on Twitter:

http://twitter.com/jarek_rek

Lab 167 - PIM BiDir

2011-12-05T13:05:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. IP Multicast routing is enabled on all devices.

Task 1

Configure a solution for Video Conferencing software using 225.5.5.5 group address. R1 should be the distribution point of this single shared tree.

Solution

Task 1

Configure a solution for Video Conferencing software using 225.5.5.5 group address. R1 should be the distribution point of this single shared tree.

R1 Configuration:

!

ip pim bidir-enable 

!

ip access-list standard MULTICAST_225.5.5.5
 permit 225.5.5.5
!

ip pim rp-candidate Loopback101 group-list MULTICAST_225.5.5.5 bidir

!

ip pim bsr-candidate Loopback101 0

!

All Other Devices Configuration:

!

ip pim bidir-enable 

!

Verification:

IGMP join-group on S1, S2, R6. Ping from R1 to 225.5.5.5 is getting response. Example of mroute table on R5 for the group:

Pic. 2 - Mroute Table on R5.

Note!

DF Election
On every network segment and point-to-point link, all PIM routers participate in a procedure called DF election. The procedure selects one router as the DF for every RP of bidirectional groups. This router is responsible for forwarding multicast packets received on that network upstream to the RP.

The DF election is based on unicast routing metrics and uses the same tie-break rules employed by PIM assert processes. The router with the most preferred unicast routing metric to the RP becomes the DF. Use of this method ensures that only one copy of every packet will be sent to the RP, even if there are parallel equal cost paths to the RP.

A DF is selected for every RP of bidirectional groups. As a result, multiple routers may be elected as DF on any network segment, one for each RP. In addition, any particular router may be elected as DF on more than one interface.

source:
http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbipim.html

Lab 166 - Multicast Helper Map

2011-12-05T11:05:00.001Z

Prerequisites: CCNP level skills.

Personal Note!
OMG, it is already December! What happened to all previous months?! Did I doze off or something? Nah! It was the work.

All the work and no play (or study) make J a dull boy.
All the work and no play (or study) make J a dull boy.
All the work and no play (or study) make J a dull boy.
All the work and ...

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. IP Multicast routing is enabled on all devices.

Task 1

Configure multicast sparse mode between R1 and R2 on WAN link. R1 should be configured as RP.

Task 2
An application on VLAN 26 will broadcast UDP traffic to port 30000. Configure routers in such a way as to allow this broadcast to be converted into multicast 239.1.1.1 address on the WAN link between R1 and R2. This traffic should be converted back into broadcast on VLAN 14.

Solution

Task 1

Configure multicast sparse mode between R1 and R2 on WAN link. R1 should be configured as RP.

R1 Configuration:

!

ip pim rp-address 172.16.101.1

!

interface Loopback101
 ip address 172.16.101.1 255.255.255.255
 ip pim sparse-mode

!

interface Serial0/0.125 multipoint
 ip address 10.1.125.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-multipoint
 snmp trap link-status
 frame-relay map ip 10.1.125.1 102
 frame-relay map ip 10.1.125.5 105 broadcast
 frame-relay map ip 10.1.125.2 102 broadcast

!

R2 Configuration:

!

ip pim rp-address 172.16.101.1

!

interface Serial0/0
 ip address 10.1.125.2 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 clock rate 2000000
 frame-relay map ip 10.1.125.5 201
 frame-relay map ip 10.1.125.1 201 broadcast
 frame-relay map ip 10.1.125.2 201
 no frame-relay inverse-arp

!

interface FastEthernet0/1
 ip address 10.1.26.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

Note!

For the Task 2 configuration to work (broadcast on Fa0/1 of R2), the multicast has to be enabled on Fa0/1 interface of R2.

Task 2

An application on VLAN 26 will broadcast UDP traffic to port 30000. Configure routers in such a way as to allow this broadcast to be converted into multicast 239.1.1.1 address on the WAN link between R1 and R2. This traffic should be converted back into broadcast on VLAN 14.

R1 Configuration:

!

ip access-list extended UDP30000
 permit udp any any eq 30000
 permit udp any any eq domain
!

ip forward-protocol udp 30000

!

interface FastEthernet0/0
 ip address 10.1.14.1 255.255.255.0
 ip broadcast-address 10.1.14.255
 ip directed-broadcast
 speed 100
 full-duplex
!

interface Serial0/0.125 multipoint
 ip address 10.1.125.1 255.255.255.0
 ip pim sparse-mode
 ip multicast helper-map 239.1.1.1 10.1.14.255 UDP30000

!

NOTE!
ACL entry with UDP 53 port (domain) was added only for testing purposes here.

R2 Configuration:

!

ip forward-protocol udp 30000

!

ip access-list extended UDP30000
 permit udp any any eq 30000
 permit udp any any eq domain
!

interface FastEthernet0/1
 ip address 10.1.26.2 255.255.255.0
 ip multicast helper-map broadcast 239.1.1.1 UDP30000
 speed 100
 full-duplex

!

NOTE!

ACL entry with UDP 53 port (domain) was added only for testing purposes here.
Verification:

On R6 I have enabled ip domain-lookup and mistyped the command in the privilege mode to create UDP broadcast port 53. On R4 I have created an access-list enabled debug ip packet using it to see if R1 is sending broadcast. The results are below.

R4 Configuration:

!

access-list 100 permit udp any 10.1.14.255 0.0.0.0

!

R4#debug ip packet detail 100

Pic. 2 - R2 Forwards Broadcast as Multicast.

Pic. 3 - Debug IP Packet on R4.

Lab 165 - Multicast Rate Limiting

2011-11-18T15:00:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram.

Task 1

Configure R3 so that it limits the overall multicast traffic (the aggregate rate) to 5 Mbps out its F0/0 interface. The same interface should limit the traffic to IP 224.1.1.1 to 256 Kbps for every multicast traffic source to this group.

Solution

Task 1

R3 Configuration:

!

ip access-list standard LIMIT_256
 permit 224.1.1.1

!

interface FastEthernet0/0
 ip address 10.1.30.3 255.255.255.0
 ip pim sparse-mode
 ip multicast rate-limit out group-list LIMIT_256 256
 ip multicast rate-limit out 5000
 speed 100
 full-duplex

!

Notice!
If the command 'ip multicast rate-limit' is used without a destination (and possibly source address) access-list, it limits the aggreate traffic. In case ACL is defined, it limits the traffic to a given value per source. This means, that if there are two senders to 224.1.1.1 (here), the aggregate traffic is 2 x 256 Kbps.

Verification:

S2 Configuration:

!

interface Vlan30
 ip address 10.1.30.12 255.255.255.0
 ip igmp join-group 224.1.1.1

!

Ping from S3 (RP) to 224.1.1.1 and the mroute table on R3 below:

Pic. 2 - R3 Limits the Traffic.

S4 Configuration:

!

interface Vlan30
 ip address 10.1.30.14 255.255.255.0
 ip igmp join-group 224.10.10.10

!

Ping from S3 to 224.10.10.10. R3 mroute table below:

Pic. 3 - R3 Limits the Traffic.

IP Multicast rate-limit

source: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_igmps.html#wp1045300

Lab 164 - IGMP Timers

2011-11-18T12:46:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram.

Task 1

On the multicast segment (VLAN 25), there is only one client wishing to receive multicast traffic. Configure R2 and R5 in such a way that they would stop sending multicast traffic immediately upon receiving IGMP Leave message from this client (default 2.5 seconds).

Task 2
Configure the backup querier on VLAN 25 to assume the querier role if it did not hear the query message in 60 seconds (default time is two times the query interval: 120 seconds). Membership query packets should be sent every 15 seconds (default: 60 seconds) by both R2 and R5.

Task 3
R2 and R5 should force their multicast clients to respond to group query with the group report in maximum 5 seconds (default 10 seconds).

Solution

Task 1

R2 configuration:

!

ip access-list standard ALL_MULTICAST_GROUPS
 permit 224.0.0.0 15.255.255.255
!

interface FastEthernet0/0
 ip address 10.1.25.2 255.255.255.0
 ip pim sparse-mode
 ip igmp immediate-leave group-list ALL_MULTICAST_GROUPS
 speed 100
 full-duplex

!

R5 Configuration:

!

ip access-list standard ALL_MULTICAST_GROUPS
 permit 224.0.0.0 15.255.255.255
!

interface FastEthernet0/0
 ip address 10.1.25.5 255.255.255.0
 ip pim sparse-mode
 ip igmp immediate-leave group-list ALL_MULTICAST_GROUPS
 speed 100
 full-duplex
!

Task 2

Configure the backup querier on VLAN 25 to assume the querier role if it did not hear the query message in 60 seconds (default time is two times the query interval: 120 seconds). Membership query packets should be sent every 15 seconds (default: 60 seconds) by both R2 and R5.

Note!

The querier for multicast is elected based on the lowest IP address on the link (here it has to be R2).

Pic. 2 - DR (designated querier).

R2 configuration:

!

interface FastEthernet0/0
 ip address 10.1.25.2 255.255.255.0
 ip pim sparse-mode
 ip igmp immediate-leave group-list ALL_MULTICAST_GROUPS
 ip igmp query-interval 15
 speed 100
 full-duplex
! 

R5 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.25.5 255.255.255.0
 ip pim sparse-mode
 ip igmp query-interval 15
 ip igmp querier-timeout 60
 speed 100
 full-duplex

!

Task 3
R2 and R5 should force their multicast clients to respond to group query with the group report in maximum 5 seconds (default 10 seconds).

R2 configuration:

!

interface FastEthernet0/0
 ip address 10.1.25.2 255.255.255.0
 ip pim sparse-mode
 ip igmp query-max-response-time 5
 ip igmp immediate-leave group-list ALL_MULTICAST_GROUPS
 ip igmp query-interval 15
 speed 100
 full-duplex

!

R5 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.25.5 255.255.255.0
 ip pim sparse-mode
 ip igmp query-max-response-time 5
 ip igmp query-interval 15
 ip igmp querier-timeout 60
 speed 100
 full-duplex

!

IGMP Commands
source: http://www.cisco.com/en/US/docs/ios/12_3t/ip_mcast/command/reference/ip3_i1gt.html

Lab 163 - IGMP Filtering

2011-11-18T11:57:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram.

Task 1

In order to prevent IGMP DoS attacks do not allow R3 to accept more than 10 IGMP states that can be joined to a router from IGMP on its Fa0/0 interface. Also, configure filtering so that R3 allows multicast clients only from the group 224.1.1.0/24.

Solution

Task 1
In order to prevent IGMP DoS attacks do not allow R3 to accept more than 10 IGMP states that can be joined to a router from IGMP on its Fa0/0 interface. Also, configure filtering so that R3 allows multicast clients only from the group 224.1.1.0/24.

R3 Configuration:

!

access-list 1 permit 224.1.1.0 0.0.0.255 

!

interface FastEthernet0/0
 ip address 10.1.30.3 255.255.255.0
 ip pim sparse-mode
 ip igmp access-group 1
 ip igmp limit 10
 speed 100
 full-duplex

!

Note!
The 'ip igmp limit' command can be used either globally or on per interface basis.

Verification:

Pic. 2 - R3 Fa0/0 IGMP Limit.

S2 Configuration :

!

interface Vlan30
 ip address 10.1.30.12 255.255.255.0
 ip igmp join-group 224.1.1.1
 ip igmp join-group 224.1.1.2
 ip igmp join-group 224.3.3.3

!

Note!

There are three multicast group joins. The third one is not allowed as per the ACL 1 on R3 (224.3.3.3). It does not get registered.

Pic. 3 - Multicast Groups Registered on R3.

IGMP State Limit

source: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_igmps.html#wp1045300

Lab 162 - Anycast RP

2011-11-18T09:51:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol as well as multicast routing. Also, IP PIM Sparse-Mode on VLANs 133 and 143 is enabled.

Task 1

Configure R3 and R4 as RPs for all multicast groups. Ensure that clients choose the closest RP while joining multicast groups (lowest OSPF metric). In case of failure of the closest RP they must be able to use the other one. You are allowed to create extra loopback interface with IP address: 172.16.34.34/32.

Solution

Task 1
Configure R3 and R4 as RPs for all multicast groups. Ensure that clients choose the closest RP while joining multicast groups (lowest OSPF metric). In case of failure of the closest RP they must be able to use the other one. You are allowed to create extra loopback interface with IP address: 172.16.34.34/32.

R3 Configuration:

!

interface Loopback103
 ip address 172.16.103.1 255.255.255.255

 ip ospf 1 area 0

!

interface Loopback34
 ip address 172.16.34.34 255.255.255.255
 ip ospf 1 area 0
!

ip pim rp-address 172.16.34.34
ip msdp peer 172.16.104.1 connect-source Loopback103
ip msdp originator-id Loopback103

!

R4 Configuration:

!

interface Loopback104
 ip address 172.16.104.1 255.255.255.255

 ip ospf 1 area 0 

!

interface Loopback34
 ip address 172.16.34.34 255.255.255.255
 ip ospf 1 area 0
!

ip pim rp-address 172.16.34.34
ip msdp peer 172.16.103.1 connect-source Loopback104
ip msdp originator-id Loopback104

!

S3 Configuration:

!

ip pim rp-address 172.16.34.34

!

Verification:

Pic. 2 - MSDP Peer Session.

Lab 161 - Source Specific Multicast

2011-11-18T08:09:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol as well as multicast routing.

Task 1

Enable PIM Sparse Mode between R2 and R5 on FastEthernet link.

Task 2
Make sure that users on VLAN 26 can receive multicast traffic sent to 232.26.26.26 only from the source of 172.16.105.5 (R5 Loopback105). Verify your solution.

Solution

Task 1

Enable PIM Sparse Mode between R2 and R5 on FastEthernet link.

R2 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.25.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

interface FastEthernet0/1
 ip address 10.1.26.2 255.255.255.0
 ip pim sparse-mode
 ip igmp version 3
 speed 100
 full-duplex 

!

Note!
Since the Task 2 stipulates that Source Specific Multicast must be used, IGMP v3 hast to be configured on F0/1 interface.

R5 Configuration:

!
interface Loopback105
 ip address 172.16.105.1 255.255.255.128
 ip pim sparse-mode
! 

interface FastEthernet0/0
 ip address 10.1.25.5 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

Task 2
Ensure that users on VLAN 26 can receive multicast traffic sent to 232.26.26.26 only from the source of 172.16.105.5 (R5 Loopback105). Verify your solution.

R2 and R5 Configuration:

!

ip pim ssm default

!

R6 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.26.6 255.255.255.0
 ip igmp join-group 232.26.26.26 source 172.16.105.1
 ip igmp version 3
 speed 100
 full-duplex

!

Verification:

Pic. 2 - Mroute Entry on R2.

Pic. 3 - R2 and R3 Mroute Table.

Pic. 4 - Ping Test.

Note!
Apart from a classic multicast (Any Source Multicast), the Source Specific Multicast method allows clients to choose the source of multicast feed. It requires IGMP version 3 though. SSM builds SPT tree and does not require RP to operate. The command 'ip pim ssm' with the keyword 'default' uses the range 232.0.0.0/8 addresses. The syntax is as follows:

Pic. 5 - IP PIM SSM Command.

source: http://www.cisco.com/en/US/docs/ios/12_2/ipmulti/command/reference/1rfmult2.html#wp1060386

Lab 160 - Multicast Stub Routing

2011-11-14T17:15:00.001Z

Prerequisites: CCNP level skills.

Personal Note!
Other dimensions and universes which existence we sense, took a more tangible form a few days ago. My friend, artist, who goes by the name Valcari, seems to live in many of them at the same time. He is no longer the same person I have known for ages. Not better, not worse ... just different. Evolution?

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol as well as multicast routing.

Task 1

R1 is to be the RP for all multicast groups. VLAN 26 clients will join the group 224.26.26.26. R4 is going to be server for the group 224.26.26.26.

Task 2
Configure R1 and R2 in such a way that they do not form PIM adjacency over Frame-Relay cloud, but IGMP join messages must be sent to R1 and the multicast traffic from from VLAN 14 should be sent via WAN connection to the clients in VLAN 26.

Solution

Task 1

R1 is to be the RP for all multicast groups. VLAN 26 clients will join the group 224.26.26.26. R4 is going to be server for the group 224.26.26.26.

R1 Configuration:

interface Loopback101
ip address 172.16.101.1 255.255.255.255
ip pim sparse-mode

interface FastEthernet0/0
ip address 10.1.14.1 255.255.255.0
ip pim sparse-mode
speed 100
full-duplex
!

interface Serial0/0.125 multipoint
ip address 10.1.125.1 255.255.255.0
ip pim dense-mode
ip ospf network point-to-multipoint
snmp trap link-status
frame-relay map ip 10.1.125.1 102
frame-relay map ip 10.1.125.5 105 broadcast
frame-relay map ip 10.1.125.2 102 broadcast
!

ip pim rp-address 172.16.101.1

R4 Configuration:

!

 interface FastEthernet0/0
 ip address 10.1.14.4 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!

ip pim rp-address 172.16.101.1

!

Note!
At this stage R1 configuration is not complete yet. I use 'dense-mode' on Serial0/0.125 interface, otherwise the multicast traffic would not be sent down to R2. In the next task, I will allow R2 to send the IGMP join-message to be sent towards R1.

Task 2

Configure R1 and R2 in such a way that they do not form PIM adjacency over Frame-Relay cloud, but IGMP join messages must be sent to R1 and the multicast traffic from from VLAN 14 should be sent via WAN connection to the clients in VLAN 26.

R1 Configuration:

!

access-list 1 deny   10.1.125.2
access-list 1 permit any
!

interface Serial0/0.125 multipoint
 ip address 10.1.125.1 255.255.255.0
 ip pim neighbor-filter 1
 ip pim dense-mode
 ip ospf network point-to-multipoint
 snmp trap link-status
 frame-relay map ip 10.1.125.1 102
 frame-relay map ip 10.1.125.5 105 broadcast
 frame-relay map ip 10.1.125.2 102 broadcast

!

Note!
The ACL will make it impossible for R2 to form PIM adjacency over FR link.

R2 Configuration:

!

interface FastEthernet0/1
 ip address 10.1.26.2 255.255.255.0
 ip pim dense-mode
 ip igmp helper-address 10.1.125.1

 ip igmp join-group 224.26.26.26
 speed 100
 full-duplex

!

interface Serial0/0
 ip address 10.1.125.2 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 clock rate 2000000
 frame-relay map ip 10.1.125.5 201
 frame-relay map ip 10.1.125.1 201 broadcast
 frame-relay map ip 10.1.125.2 201
 no frame-relay inverse-arp

!

Note!
IP igmp helper address is going to forward IGMP join messages received on VLAN 26 interface up to R1.

Verification:

Pic. 2 - PIM Enabled Interface on R2.

Pic. 3 - R2 Recognizes R1 as PIM Neighbor.

Pic. 4 - R1 Does Not Create Adjacency with R2.

Pic. 5 - R1 Receives IGMP Join Message

Forwarded by R2.

Pic. 6 - Multicast Traffic.

Lab 159 - BSR Propagation Filtering

2011-11-12T14:53:00.001Z

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol as well as multicast routing.

IP PIM Sparse Mode has been enabled on VLANs: 14, 30, 133, 143.

Task 1

Configure R1 as the RP and BSR candidate for all multicast groups. Use the most stable interface to accomplish the task.

Task 2
Ensure that R3 does not receive information about RP.

Solution

Task 1

Configure R1 as the RP and BSR candidate for all multicast groups. Use the most stable interface to accomplish the task.

R1 Configuration:

!

interface Loopback101
 ip address 172.16.101.1 255.255.255.255
 ip pim sparse-mode
!

ip pim bsr-candidate Loopback101 0
ip pim rp-candidate Loopback101

!

Verification:

Pic. 2 - RP Information on R3.

Note!
Without filtering, R3 receives information about RP.

Task 2
Ensure that R3 does not receive information about RP.
S3 Configuration:

!

interface Vlan133
 ip address 10.1.133.10 255.255.255.0
 ip pim bsr-border
 ip pim sparse-mode

!

Verification:

Pic. 3 - RP information on R3.

The previous information about RP slowly expires. R3 loses information about RP.

Lab 158 - BSR with Multiple RPs

2011-11-10T21:40:00.000Z

Prerequisites: CCNP level skills.

Personal Note!
1:23 in the morning. Full moon makes the mind wander ...

Ying and Yang, day and night, one and zero ... so much of this dichotomy.
Perhaps if you were good in the first half of your life, in the second you should ... find something interesting ... (LOL).

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol as well as multicast routing.

Task 1

Enable PIM Sparse mode on VLANs: 14, 30, 133, 144. Do not enable PIM protocol on VLAN interfaces of S2 and S4.

Task 2
Configure R1 and R4 as RP candidates for all multicast groups. S3 should disseminate RP-set information. Configure hash-mask-length so that the load on RPs is evenly distributed with groups of four multicast addresses as shown below:

Group 1: 224.1.1.0, 224.1.1.1, 224.1.1.2, 224.1.1.3 given to one RP.
Group 2: 224.1.1.4, 224.1.1.5, 224.1.1.6, 224.1.1.7 given to another RP.
Group 3: 224.1.1.8, 224.1.1.9, 224.1.1.10, 224.1.1.11 given to the first RP.
etc.

Solution

Task 1

Enable PIM Sparse mode on VLANs: 14, 30, 133, 144. Do not enable PIM protocol on VLAN interfaces of S2 and S4.

R1 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.14.1 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

R3 Configuraiton:

!

interface FastEthernet0/0
 ip address 10.1.30.3 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

interface FastEthernet0/1
 ip address 10.1.133.3 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

R4 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.14.4 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!

interface FastEthernet0/1
 ip address 10.1.143.4 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

S3 Configuration:

!

interface Vlan133
 ip address 10.1.133.10 255.255.255.0
 ip pim sparse-mode
!

interface Vlan143
 ip address 10.1.143.10 255.255.255.0
 ip pim sparse-mode

!

Task 2
Configure R1 and R4 as RP candidates for all multicast groups. S3 should disseminate RP-set information. Configure hash-mask-length so that the load on RPs is evenly distributed with groups of four multicast addresses as shown below:

Group 1: 224.1.1.0, 224.1.1.1, 224.1.1.2, 224.1.1.3 given to one RP.
Group 2: 224.1.1.4, 224.1.1.5, 224.1.1.6, 224.1.1.7 given to another RP.
Group 3: 224.1.1.8 224.1.1.9, 224.1.1.10, 224.1.1.11 given to the first RP.
etc.

S3 Configuration:

!

interface Loopback107
 ip address 172.16.107.1 255.255.255.255
 ip pim sparse-mode 

!

ip pim bsr-candidate Loopback107 30

!

R1 Configuration:

!

interface Loopback101
 ip address 172.16.101.1 255.255.255.255
 ip pim sparse-mode
!

ip pim rp-candidate Loopback101

!

R4 Configuration:

!

interface Loopback104
 ip address 172.16.104.1 255.255.255.255
 ip pim sparse-mode
!

ip pim rp-candidate Loopback104

!

Verification:

S2 Configuration:

!

interface Vlan30
 ip address 10.1.30.12 255.255.255.0
 ip igmp join-group 224.1.1.0
 ip igmp join-group 224.1.1.1
 ip igmp join-group 224.1.1.2
 ip igmp join-group 224.1.1.3

S4 Configuration:

!

interface Vlan30
 ip address 10.1.30.14 255.255.255.0
 ip igmp join-group 224.1.1.4
 ip igmp join-group 224.1.1.5
 ip igmp join-group 224.1.1.6
 ip igmp join-group 224.1.1.7

!

Pic. 2 - RP (R1) Mapping.

Pic. 3 - RP (R4) Mapping.

Note!
The highest hash value denotes the RP for the group.

R1 (172.16.101.1) is the RP for groups:

224.1.1.0
224.1.1.1
224.1.1.2
224.1.1.3

R2 is RP for the groups:

224.1.1.4
224.1.1.5
224.1.1.6
224.1.1.7

Lab 157 - PIM Bootstrap Router

2011-11-09T20:29:00.003Z

Prerequisites: CCNP level skills.

Personal Note!
Finding things out is a real pleasure ... Time to continue to get the buzz before all these memories drown in oblivion ...

Topology

Pic. 1 - Topology Diagram.

Note!
Routers and switches are already configured as per the topology diagram. All devices use OSPF area 0 as their routing protocol.

Task 1

Enable PIM Sparse mode on the following interfaces:

R1 - Fa0/0
R1 - S0/0.125
R2 - Fa0/0
R2 - Fa0/1
R2 - S0/0
R4 - Fa0/0
R5 - Fa0/0
R5 - S0/0

Task 2
Configure R2 to be BSR and R5 to be RP. Use the most stable interface on R2 and R5 to accomplish the task.

Task 3
Use R4 to simulate multicast server sending packets to 224.46.46.46. Users on VLAN 26 should receive this multicast feed. Verify your solution.

Solution

Task 1

Enable PIM Sparse mode on the following interfaces:

R1 - Fa0/0
R1 - S0/0.125
R2 - Fa0/0
R2 - Fa0/1
R2 - S0/0
R4 - Fa0/0
R5 - Fa0/0
R5 - S0/0

R1 Configuration:

!

ip multicast-routing

!

interface FastEthernet0/0
 ip address 10.1.14.1 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

interface Serial0/0.125 multipoint
 ip address 10.1.125.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-multipoint
 snmp trap link-status
 frame-relay map ip 10.1.125.2 102 broadcast
 frame-relay map ip 10.1.125.5 105 broadcast
 frame-relay map ip 10.1.125.1 102
!

R2 Configuration:

!

ip multicast-routing 

!

interface FastEthernet0/0
 ip address 10.1.25.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!

interface FastEthernet0/1
 ip address 10.1.26.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!

interface Serial0/0
 ip address 10.1.125.2 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 clock rate 2000000
 frame-relay map ip 10.1.125.2 201
 frame-relay map ip 10.1.125.1 201 broadcast
 frame-relay map ip 10.1.125.5 201
 no frame-relay inverse-arp
!

R4 Configuration:

!

ip multicast-routing

!

interface FastEthernet0/0
 ip address 10.1.14.4 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!

R5 Configuration:

!

ip multicast-routing 

!

interface FastEthernet0/0
 ip address 10.1.25.5 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

!

interface Serial0/0
 ip address 10.1.125.5 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 clock rate 2000000
 frame-relay map ip 10.1.125.1 501 broadcast
 frame-relay map ip 10.1.125.2 501
 frame-relay map ip 10.1.125.5 501
! 

Verification:

Pic.2 - PIM Neighbors of R1.

Pic. 3 - PIM Neighbors of R2.

Task 2

Configure R2 to be BSR and R5 to be RP. Use the most stable interface on R2 and R5 to accomplish the task.

R2 Configuration:

!

interface Loopback102
 ip address 172.16.102.1 255.255.255.255
 ip pim sparse-mode
!

ip pim bsr-candidate Loopback102 0

!

R5 Configuration:

!

interface Loopback105
 ip address 172.16.105.1 255.255.255.128
 ip pim sparse-mode
!

ip pim rp-candidate Loopback105

!

Verification:

Pic. 4 - RP Information on R4.

Pic. 5 - RP Information on R5.

Note!

The RP candidate uses default priority 0 (Cisco implementation, whereas the standard uses 192, max. 255). RP with the LOWEST priority (0) is preferred.
http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1055223

In PIMv2, a BSR is the equivalent of Mapping Agent used in Auto-RP. BSR default priority is 0 (0-255). Candidate with the HIGHEST priority is preferred if multiple BSR candidates exist.

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1053348

BSR does NOT elect the best RP. The group range to RP mapping is only distributed distributed to routers and they choose the best one for a group.

This information is disseminated on a hop-by-hop basis.

Task 3

Use R4 to simulate multicast server sending packets to 224.46.46.46. Users on VLAN 26 should receive this multicast feed. Verify your solution.

R6 Configuration:

!

interface FastEthernet0/0
 ip address 10.1.26.6 255.255.255.0
 ip igmp join-group 224.46.46.46
 speed 100
 full-duplex

!

Verification:

Pic. 6 - Mroute Table on R2.

Pic. 7 - Mroute Table on R5.

Note!
R5 is the RP for all multicast groups. In the output the RPF nbr 0.0.0.0 implies this fact. The (*,G) entries show up in the client-to-RP path as expected).

Pic. 8 - Ping (server feed) from R4 results.

Lab 156 - PIM NBMA

2011-06-16T19:37:00.002+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode!

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

R5 has been configured to be the RP/MA for all multicast groups in this topology (auto-rp is used). R2's Et0/0 must emulate the client of multicast group 224.24.24.24. R4 must stream packets to this group. Make sure the client receives this traffic.

Solution

Task 1

R5 has been configured to be RP/MA for all multicast groups in this topology (auto-rp is used). R2's Et0/0 must emulate the client of multicast group 224.24.24.24. R4 must stream packets to this group. Make sure the client receives this traffic.

R2 Configuration

!

interface Ethernet0/0
 ip address 10.1.2.2 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 224.24.24.24

!

Verification:

Pic. 2 - (*, G) for 224.24.24.24 Registered.

Ping from R4 to 224.24.24.24 does not work now.

Pic. 3 - Ping from R6.

However, the (S, G) entry shows in RP (multicast sender). The problem is that multicast reaching R1's S1/0 cannot be sent back out S1/0.

Pic. 4 - Mroute Table in R1.

Note!

R1 cannot send multicast back out the interface it received this feed. However, using PIM Sparse Mode we can accomplish this using PIM NBMA. This mode can reflect the traffic back out the same interface it received the traffic. In addition to this it will send the multicast only out the circuits which have the clients registered for the group. For example, if R6 sends the traffic towards R2 (group registered there), and R3 did not register the group, R1 sends the multicast packets out of all its circuits in hub-and-spoke FR topology (towards R2 and R3). With PIM NBMA turned on, only circuits that registered the clients, will receive the feed.

R1 Configuration:

!

interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim nbma-mode
 ip pim sparse-mode
 encapsulation frame-relay
 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.3 103 broadcast
 frame-relay map ip 10.1.123.2 102 broadcast
 no frame-relay inverse-arp

!

Ping from R4 to 224.24.24 succeeds now.

Verification:

Pic. 5 - Ping from R4.

Pic. 6 - Mroute Table in R1.

Lab 155 - Multicast Traffic Boundary

2011-06-13T21:24:00.003+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode!

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure R5 so that it does not send the administratively scoped multicast address space towards R6.

Solution

Task 1
Configure R5 so that it does not send the administratively scoped multicast address space towards R6.

R5 Configuration:

!

access-list 1 deny   239.0.0.0 0.255.255.255
access-list 1 permit any

!

interface Ethernet0/0
 ip address 10.1.56.5 255.255.255.0
 ip pim sparse-mode
 ip multicast boundary 1

!

Note!
Administratively scoped multicast range is: 239.0.0.0/8.

Note!
Read the whole description of the command usage:
http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_03.html#wp1071517

Lab 154 - Auto-RP Scope Limiting

2011-06-13T20:42:00.000+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode!

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
R1 is the RP and MA in the multicast domain. Ensure that R1 does not become RP and MA beyond the domain pictured in the topology diagram (pic. 1).

Solution

Task 1

R1 is the RP and MA in the multicast domain. Ensure that R1 does not become RP and MA beyond the domain pictured in the topology diagram (pic. 1).

R1 Configuration:

!

ip pim send-rp-announce Loopback0 scope 2
ip pim send-rp-discovery Loopback0 scope 2

!

Note!
By limiting the TTL of the RP/MA announcements to two hops, routers beyond R6 and R4 will not receive the these messages.

Lab 153 - PIM Accept Register

2011-06-12T13:56:00.002+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
R1 is the RP and MA in the multicast domain. Configure R1 so it allows all multicast group registration only if it sourced by 10.1.234.4. All other sources should be denied.

Solution

Task 1

R1 is the RP and MA in the multicast domain. Configure R1 so it allows all multicast group registration (multicast stream) only if it sourced by 10.1.234.4 (server). All other sources should be denied.

R1 Configuration:

!

ip access-list extended ALLOWED_SOURCES
 permit ip host 10.1.234.4 224.0.0.0 15.255.255.255
!

ip pim accept-register list ALLOWED_SOURCES

Verification:

Pic. 2 - R3's Group Registration Attempt

(Server Address 10.1.123.3.).

R1 (RP) refuses to register the multicast source 10.1.234.3

Lab 152 - PIM Accept RP

2011-06-12T12:58:00.002+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Based on the previous lab (Lab 151), R1 is the RP and MA (Mapping Agent) for all groups. As per your boss request, you must configure R2 and R3 so that routers should register (*, G) entries only for the group 224.40.40.40 and can be destined for 172.16.101.1 (RP).This group cannot be registered with any other RP.

Solution

Task 1

Based on the previous lab (Lab 151), R1 is the RP and MA (Mapping Agent) for all groups. As per your boss request, you must configure R2 and R3 so that routers should register (*, G) entries only for the group 224.40.40.40 and can be destined for 172.16.101.1 (RP). This group cannot be registered with any other RP.

R2 Configuration:

!

access-list 10 permit 224.40.40.40

!

ip pim accept-rp 172.16.101.1 10

!

R3 Configuration:

!

access-list 10 permit 224.40.40.40

!

ip pim accept-rp 172.16.101.1 10

!

Verification:

Pic. 2 - Another Group Registration.

After R4 have joined the 224.64.64.64, R1 (RP) does not have the group registered. It has been pruned on R2 (PIM DR).

Pic. 3 - R2 (PIM DR) Prunes the Join Message.

R2 does not build the 'register message' and the group has not been registered with RP.

Lab 151 - PIM DR Election

2011-06-12T12:12:00.002+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse Mode.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
All routers in the topology run PIM Sparse Mode. Configure R1 as both the RP and the Mapping Agent for all multicast groups. Use Auto-RP to disseminate this information. Do not change the PIM Mode (Sparse Mode). RP should advertise itself as RP every 10 seconds.

Task 2
Configure R4's Et0/0 interface to join the group 224.40.40.40. Ensure that R2 registers the group with the RP.

Solution

Task 1

All routers in the topology run PIM Sparse Mode. Configure R1 as both the RP and the Mapping Agent for all multicast groups. Use Auto-RP to disseminate this information. Do not change the PIM Mode (Sparse Mode). RP should advertise itself as RP every 10 seconds.

All Routers Configuration:

!

ip pim autorp listener

!

R1 Configuration:

!

interface Loopback0
 ip address 172.16.101.1 255.255.255.0
 ip pim sparse-mode
!

ip pim send-rp-announce Loopback0 scope 16 interval 10 
ip pim send-rp-discovery Loopback0 scope 16 interval 10

!

Task 2

Configure R4's Et0/0 interface to join the group 224.40.40.40. Ensure that R2 registers the group with RP.

Before configuring the 'igmp join-group' let's see which router is the DR on the subnet.

Pic. 1 - DR on 10.1.234.0/24

Note!
Since all routers have the same priority (p=1), the highest IP address (here: R4) has been elected to be PIM DR on this segment. DR is responsible for registering multicast clients/multicast feed with RP (group/multicast traffic registration). Unlike OSPF's DR, the PIM DR role is preemptive.

R2 Configuration:

!

interface Ethernet0/0
 ip address 10.1.234.2 255.255.255.0
 ip pim dr-priority 50
 ip pim sparse-mode

!

Pic. 3 - R2 Becomes PIM DR.

R2 is the PIM DR now. It registers the group 224.40.40.40 with RP (look below).

Pic 4 - R2's Group Registration.

Lab 150 - Auto-RP Listener

2011-06-10T12:25:00.000+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse-Dense!

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
All routers in the topology run PIM Sparse Mode. Configure R1 as RP for all multicast group and R2 as the Mapping Agent. Do not change the PIM mode to accomplish this.

Solution

Task 1

All routers in the topology run PIM Sparse Mode. Configure R1 as RP for all multicast group and R2 as the Mapping Agent. Do not change the PIM mode to accomplish this.

Note!
The problem I'm going to run into is that in order for a router to advertise itself as the RP candidate, it needs to know which router is RP (none available at the moment) since Auto-RP uses multicast address 224.0.1.39 to announce it. Also, the Mapping Agent must register the group 224.0.0.40 with RP in order to announce which device is RP. One solution to this problem is to use PIM Sparse-Dense Mode. But the lab stipulates, that PIM Sparse Mode currently configured cannot be changed.

Another solution is to use Auto-RP Listener option on all routers in the multicast domain. This feature, allows the RP candidate and the Mapping Agent advertise these two groups out the PIM Sparse Mode interfaces as Dense Mode.

R1 Configuration:

!

interface Loopback0
 ip address 172.16.101.1 255.255.255.0
 ip pim sparse-mode
!
ip pim autorp listener
!
ip pim send-rp-announce loopback0 scope 16

!

R2 Configuration:

!

interface Loopback0
 ip address 172.16.102.2 255.255.255.0
 ip pim sparse-mode

!

ip pim autorp listener

!

 ip pim send-rp-discovery loopback0 scope 16

!

All Other Routers:

!

ip pim autorp listener

!

Verification:

Pic. 2 - RP Information on R6.

All routers learn which device is RP.

Lab 149 - Auto-RP Filtering

2011-06-10T08:49:00.001+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All transit interfaces have been configured as Sparse-Dense-Mode.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Using Auto-RP, configure R1 to be RP candidate for the multicast group 224.10.10.10. R5 must be elected as the Mapping Agent. Ensure that no other router can become RP candidate for any other multicast group in the network.

Solution

Task 1
Using Auto-RP, configure R1 to be RP candidate for the multicast group 224.10.10.10. R5 must be elected as the Mapping Agent. Ensure that no other router can become RP candidate for any other multicast group in the network.

R1 Configuration:

!

interface Loopback0
 ip address 172.16.101.1 255.255.255.0
 ip pim sparse-dense-mode

!

access-list 1 permit 224.10.10.10

!

ip pim send-rp-announce loopback0 scope 16 group-list 1
!

R5 Configuration:

!

interface Loopback0
 ip address 172.16.105.5 255.255.255.0
 ip pim sparse-dense-mode

!

ip pim send-rp-discovery loopback0 scope 16

!

ip pim rp-announce-filter rp-list R1_RP group-list MULTICAST_GROUPS

!
ip pim rp-announce-filter rp-list ROUGE_RPS group-list ALL_MULTICAST_GROUPS  

!

ip access-list standard R1_RP
 permit 172.16.101.1
!

ip access-list standard MULTICAST_GROUPS
 permit 224.10.10.10
!

ip access-list standard ROUGE_RPS
 deny   172.16.101.1
 permit any
!

ip access-list standard ALL_MULTICAST_GROUPS
 deny   224.0.0.0 15.255.255.255
!

Verification:

Configuring R2 as a 'rouge' RP for a group 224.2.2.2, which should not be advertised by R5 (Mapping Agent).

R2 Configuration:

!

interface Loopback0
 ip address 172.16.102.2 255.255.255.0
 ip pim sparse-dense-mode
!

access-list 1 permit 224.2.2.2

!

ip pim send-rp-announce Loopback0 scope 16 group-list 1

!

Pic. 2 -Debug PIM Auto-RP on R5 (Mapping Agent).

Rouge RP has been filtered out.

Note!

"Use this command with caution (ip pim rp-announce-filter rp-list - JR). RPs that are matched by rp-list (allowed by a permit statement) have their multicast groups filtered by group-list. RPs that are denied (either by an explicit or implicit deny) are not subject to the filtering of their multicast groups and are "blindly" accepted as candidate RPs for all of their groups. In other words, only RPs that are permitted by rp-list have their multicast-groups filtered by group-list. All other RPs are accepted without examination".

source: http://www.cisco.com/en/US/tech/tk828/technologies_configuration_example09186a00801cb923.shtml#filter

Lab 148 - Cisco Auto-RP Multple RPs

2011-06-06T11:51:00.004+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing. All interfaces have been configured as Sparse-Dense-Mode.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
The routers in the topology run multicast routing. The transit interfaces use sparse-dense-mode. In order to split the RP's load in half, configure R2 to advertise its loopback as the candidate RP for groups for groups 224.0.0.0 - 231.255.255.255. Configure R3 to advertise its loopback as the candidate RP for groups 232.0.0.0.0 - 239.255.255.255. R4 should be their Mapping Agent.

Solution

Task 1

The routers in the topology run multicast routing. The transit interfaces use sparse-dense-mode. In order to split the RP's load in half, configure R2 to advertise its loopback as the candidate RP for groups for groups 224.0.0.0 - 231.255.255.255. Configure R3 to advertise its loopback as the candidate RP for groups 232.0.0.0.0 - 239.255.255.255. R4 should be their Mapping Agent.

R2 Configuration:

!

interface Loopback0
 ip address 172.16.102.2 255.255.255.0
 ip pim sparse-dense-mode
!

access-list 1 permit 224.0.0.0 7.255.255.255 

!

ip pim send-rp-announce loopback0 scope 16 group-list 1

!

R3 Configuration:

!

interface Loopback0
 ip address 172.16.103.3 255.255.255.0
 ip pim sparse-dense-mode
!

access-list 1 permit 232.0.0.0 7.255.255.255 

!

ip pim send-rp-announce loopback0 scope 16 group-list 1

!

R4 Configuration:

!

interface Loopback0
 ip address 172.16.104.4 255.255.255.0
 ip pim sparse-dense-mode

!

ip pim send-rp-discovery loopback0 scope 16

!

Verification:

Pic. 2 - RP Mapping.

Pic. 3 - R2's RP Announcement.

Pic. 4 - R3's RP Announcement.

Lab 147 - Cisco Auto-RP

2011-06-06T10:33:00.004+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure PIM on all router's transit interfaces in the topology diagram (pic.1) allowing Cisco Auto-RP. R1's Loopback should be advertised as RP candidate for the groups 224.6.6.0 - 224.6.6.255. R5's Loopback should be advertised as the Mapping Agent. Auto-RP advertisements should be sent every 10 seconds. Ensure, that routers do not use PIM Dense-Mode for the unknown groups.

Solution

Task 1

Configure PIM on all router's transit interfaces in the topology diagram (pic.1) allowing Cisco Auto-RP. R1's Loopback should be advertised as RP candidate for the groups 224.6.6.0 - 224.6.6.255. R5's Loopback should be advertised as the Mapping Agent. Auto-RP advertisements should be sent every 10 seconds. Ensure, that the routers do not use PIM Dense-Mode for the unknown groups.

All Transit Interfaces:

!

ip pim sparse-dense-mode 

!

All PIM-Sparse-Dense-Mode Routers

!

no ip pim dm-fallback 

!

Note!
PIM Sparse-Dense-Mode is used to resolve the problem of advertising a router as the RP candidate. Auto-RP uses two multicast addresses:

224.0.1.39 - Cisco-RP-Announce
224.0.1.40 - Cisco-RP-Discover

In order to advertise itself as a RP, the router must know which router is RP first to register 224.0.1.39 group (its multicast announcement). Since, there is no RP elected yet, the candidate RP cannot register itself and announce itself as RP. Sparse-Dense-Mode solves this vicious circle. The groups 224.0.1.39 and 224.0.1.40 are flooded as the Dense-Mode since the RP is not know for these groups. The caveat with the Sparse-Dense-Mode is that the groups not registered will also be treated as Dense-Mode flooding all subnets. To prevent this from happening the 'no ip pim dm-fallback' command is used.

R1 Configuration:

!

interface Loopback0
 ip address 172.16.101.1 255.255.255.0
 ip pim sparse-dense-mode

access-list 1 permit 224.6.6.0 0.0.0.255

ip pim send-rp-announce Loopback0 scope 16 group-list 1 interval 10

R5 Configuration:

!

interface Loopback0
 ip address 172.16.105.5 255.255.255.0
 ip pim sparse-dense-mode
!

access-list 1 permit 224.6.6.0 0.0.0.255

!

ip pim send-rp-discovery loopback0 scope 16 interval 10

!

Note!
Both the candidate RP and Mapping Agent, must have their loopback enabled for any PIM mode.

Verification (on all routers: here R6 only):

Pic. 2 - R6's Auto-RP Info.

R6 Configuration:

!

interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-dense-mode
 ip igmp join-group 224.6.6.6

!

Pic. 3 - Ping Test.

Pic. 4 - RP Announcements.

Lab 146 - PIM RPF Failure 2

2011-06-05T18:16:00.002+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
All routers have PIM Dense enabled on all their interfaces except for subnet (use R6's Et0/0). 10.1.51.0/24. The multicast clients on subnet 10.1.56.0/24 join 224.6.6.6 group. Ensure that multicast clients can receive feed from 10.1.234.0/24 (R4).

Solution

Task 1

All routers have PIM Dense enabled on all their interfaces except for subnet 10.1.51.0/24. The multicast clients on subnet 10.1.56.0/24 will join 224.6.6.6 group (use R6's Et0/0). Ensure that multicast clients can receive feed from 10.1.234.0/24 (R4).

R6 Configuration:

!

interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim dense-mode
 ip igmp join-group 224.6.6.6

Verification:

Pic. 2 - Feed from R4 towards 224.6.6.6.

The feed does not reach the subnet 10.1.56.0/24. The reason is the Reverse Path Forwarding check failure according to IGP routing between R1 and R5. Like in the previous lab, where reaching RP is a subject to RPF check, here R1 picks the path through 10.1.51.0/24 to reach 10.1.56.0/24. These interfaces are not PIM enabled.

Pic. 3 - R1's Routing Table.

The RPF check fails since the multicast traffic arrives on R5's Et0/1 interface instead of Se1/0.

Pic. 4 - R5's RPF Check Failure.

Pic. 5 - R5's IOL List.

In order to correct the problem, static mroute must be configured on R5.

R5 Configuration:

!

ip mroute 10.1.234.0 255.255.255.0 10.1.15.1 

Pic. 6 - Multicast Feed Works.

Note!

Cisco's PIM based multicast traffic as well as the reachability towards RP (Sparse-Mode), are the subject to RPF check.

Lab 145 - PIM RPF Failure

2011-06-05T14:51:00.001+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure multicast domain using the topology diagram. The multicast clients on subnet 10.1.234.0/24 will join 224.4.4.4 group. Ensure that multicast traffic is distributed to the clients which join the group explicitly. Do not enable multicast on 10.1.51.0/24 subnet. R5 should become RP in the multicast domain.

Task 2
Configure R4's Et0/0 to join the group 224.4.4.4. On R6 use ping to verify if R4 receives the multicast traffic.

Solution

Task 1

Configure multicast domain using the topology diagram. The multicast clients on subnet 10.1.234.0/24 will join 224.4.4.4 group. Ensure that multicast traffic is distributed to the clients which join the group explicitly. Do not enable multicast on 10.1.51.0/24 subnet. R5 should become the RP in the multicast domain.

R1 Configuration:

!

ip multicast-routing 

!

ip pim rp-address 172.16.105.5

!

interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp

!

interface Serial1/1
 ip address 10.1.15.1 255.255.255.0
 ip pim sparse-mode
 serial restart-delay 0

!

R2 Configuration:

!

ip multicast-routing
!

ip pim rp-address 172.16.105.5

!

interface Ethernet0/0
 ip address 10.1.234.2 255.255.255.0
 ip pim dr-priority 20
 ip pim sparse-mode

!

interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp

!

Note!
The 'ip pim dr-priority 20' is configured so R2 sends the pim join message on behalf of 10.1.234.0/24 subnet. R4 becomes multicast DR by default. I have found that if R4 joins the group, it does not want to send the register message at the same time. That's why I make R2 the DR for this subnet.

R3 Configuration:

!

ip multicast-routing
!

ip pim rp-address 172.16.105.5

!

interface Ethernet0/0
 ip address 10.1.234.3 255.255.255.0
 ip pim sparse-mode
!

interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp

!

R4 Configuration:

!

ip multicast-routing
!

ip pim rp-address 172.16.105.5

!

interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim sparse-mode

!

R5 Configuration:

!

ip multicast-routing
!

ip pim rp-address 172.16.105.5

!

interface Ethernet0/0
 ip address 10.1.56.5 255.255.255.0
 ip pim sparse-mode
!

interface Serial1/0
 ip address 10.1.15.5 255.255.255.0
 ip pim sparse-mode
 serial restart-delay 0

!

R6 Configuration:

!

ip multicast-routing
!

ip pim rp-address 172.16.105.5

!

interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-mode

!

Verification:
The 'show ip pim interface' and 'show ip pim neighbor' commands show proper output.

Task 2

Configure R4's Et0/0 to join the group 224.4.4.4. On R6 use ping to verify if R4 receives the multicast traffic.

R4 Configuration:

!

interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 224.4.4.4

!

Note!
The problem here, is that for R1 to reach the RP (172.16.105.5) the best path is through Ethernet (10.1.51.0/24). These interfaces are not enabled for PIM. As a result of this, the PIM join message will not reach the RP and the group is not going to be registered.

Verification:

Pic. 2 - R2 (DR) Multicast Routing Table.

Pic. 3 - R5 (RP) Does Not Register 224.4.4.4

The reason for not sending the group register message is that R1's routing table points towards RP out its Et0/0 rather than Se1/1. But Eth0/0 is not enabled for multicast.

In order to solve the problem, I must force R1's multicast protocol into believing that connection towards 172.16.105.5 out its s1/1 interface is better than given by the EIGRP protocol.

R1 Configuration:

!

ip mroute 172.16.105.5 255.255.255.255 10.1.15.5

!

Pic. 4 - R5 (RP) Registers 224.4.4.4 Group.

Pic. 5 - Ping Test.

Lab 144 - PIM Sparse-Mode

2011-05-29T17:09:00.000+01:00

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Multicast server is located on 10.1.234.0/24 subnet. It sends the multicast stream using 224.4.4.4 address. Enable multicast on all routers so that. R1 should be the Rendezvous Point (RP) in this network.

Solution

Task 1

Multicast server is located on 10.1.234.0/24 subnet. It sends the multicast stream using 224.4.4.4 address. Enable multicast on all routers so that R1 should be the Rendezvous Point (RP) in this network.

All routers:

!

ip pim rp-address 172.16.101.1

!

All routers similar to R1 below (all interfaces are sparse-mode)!

R1 Configuration:

!

interface Ethernet0/0
 ip address 10.1.51.1 255.255.255.0
 ip pim sparse-mode
!

interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.3 103 broadcast
 frame-relay map ip 10.1.123.2 102 broadcast
 no frame-relay inverse-arp

!

interface Serial1/1
 ip address 10.1.15.1 255.255.255.0
 ip pim sparse-mode
 serial restart-delay 0

!

Verification (here just R1, but done on all routers):

Pic. 2 - R1's Multicast-enabled Interfaces.

Pic. 3 - R's Multicast Neighbors.

All routers know which router is the RP.

Pic. 3 - Routers Recognize RP (here: just R4).

In order to simulate the client on R6 'ip igmp join-group' command is used.

R6 Configuration:

!

interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 224.4.4.4

!

R6 should register the group with RP (172.16.101.1). R5 receives the join 244.4.4.4 message and registers (*,G) entry (multicast) client. Then, DR registers this with R1 (RP).

Pic. 5 - R5's Multicast Routing Table Entry for 224.4.4.4.

Pic. 6 - RP Registers 224.4.4.4 Client.

R4 is sending the traffic towards 224.4.4.4.

Pic. 7 - Ping Test.

Lab 143 - PIM Dense-Mode

2011-05-29T12:57:00.000+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Enable EIGRP AS 100 on all routers to provide reachability between all subnets including loopbacks (172.16.10x.x/24).

Task 2
On 10.1.56.0/24 a video server has been installed. It will send traffic towards 224.5.5.5. Since almost all users will be receiving the stream use the push method to enable multicast support on all routers. Segments which do not wish to receive the video stream should prune the traffic. Verify that the multicast towards 224.5.5.5 works for the clients in 10.1.234.0/24 subnet.

Solution

Task 1
Enable EIGRP AS 100 on all routers to provide reachability between all subnets including loopbacks (172.16.10x.x/24).
R1 Configuration:

!

router eigrp 100
 network 10.1.15.1 0.0.0.0
 network 10.1.51.1 0.0.0.0
 network 10.1.123.1 0.0.0.0
 network 172.16.101.1 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.101.1
!

interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay

 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp

!

R2 Configuration:

!

router eigrp 100
 network 10.1.123.2 0.0.0.0
 network 10.1.234.2 0.0.0.0
 network 172.16.102.2 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.102.2

!

R3 Configuration:

!

router eigrp 100
 network 10.1.123.3 0.0.0.0
 network 10.1.234.3 0.0.0.0
 network 172.16.103.3 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.103.3

!

R4 Configuration:

!

router eigrp 100
 network 10.1.234.4 0.0.0.0
 network 172.16.104.4 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.104.4

!

R5 Configuration:

!

router eigrp 100
 network 10.1.15.5 0.0.0.0
 network 10.1.51.5 0.0.0.0
 network 10.1.56.5 0.0.0.0
 network 172.16.105.5 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.105.5

!

R6 Configuration:

!

router eigrp 100
 network 10.1.56.6 0.0.0.0
 network 172.16.106.6 0.0.0.0
 no auto-summary
 eigrp router-id 172.16.106.6

!

Task 2

On 10.1.56.0/24 a video server has been installed. It will send traffic towards 224.5.5.5. Since almost all users will be receiving the stream use the push method to enable multicast support on all routers. Segments which do not wish to receive the video stream should prune the traffic. Verify that the multicast towards 224.5.5.5 works for clients in 10.1.234.0/24 subnet.

R1 Configuration:

!

ip multicast-routing 

!

interface Ethernet0/0
 ip address 10.1.51.1 255.255.255.0
 ip pim dense-mode
!

interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay

 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp
!
interface Serial1/1
 ip address 10.1.15.1 255.255.255.0
 ip pim dense-mode
 serial restart-delay 0
!

R2 Configuration:

!

ip multicast-routing 

!
interface Ethernet0/0
 ip address 10.1.234.2 255.255.255.0
 ip pim dense-mode
!

interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp

!

R3 Configuration:

!

ip multicast-routing 

!

interface Ethernet0/0
 ip address 10.1.234.3 255.255.255.0
 ip pim dense-mode

!

interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp

!

R4 Configuration:

!

ip multicast-routing  

!

interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim dense-mode

!

R5 Configuration:

!

ip multicast-routing 

!

interface Ethernet0/0
 ip address 10.1.56.5 255.255.255.0
 ip pim dense-mode
!

interface Ethernet0/1
 ip address 10.1.51.5 255.255.255.0
 ip pim dense-mode
!

interface Serial1/0
 ip address 10.1.15.5 255.255.255.0
 ip pim dense-mode
 serial restart-delay 0

!

R6 Configuration:

!

ip multicast-routing 

!

interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim dense-mode

!

Verification:

Pic. 2 - R1's PIM-enabled Interfaces and Neighbors.

Pic. 3 - R2's PIM-enabled Interfaces and Neighbors.

Pic. 4 - R5's PIM-enabled Interfaces and Neighbors.

I also checked 'show ip pim neighbor' on all routers to make sure the PIM neighbor relationship has been established.

In order to verify the multicast, R6 will be my server sending ping packets towards 224.5.5.5. R4 will emulate the client to verify if it receives the traffic.

R4 Configuration:

!

interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim dense-mode
 ip igmp join-group 224.5.5.5

!

Verification:

Pic. 5 - The multicast routing table on R4.

As expected, the client has been registered since the entry (*,G) shows in the multicast routing table. Ping from R6 towards the group should work now.

Pic. 6 - Ping Test.

One ping lost due to the path optimization. While continuous pinging from R6 the multicast routing table on R5 below:

Pic. 7 - R5's Multicast Routing Table.

Note!

RPF check is always performed based on the IGP routing protocol (here: EIGRP). STP-bit, chooses the shortest path prunning less optimal EIGRP paths.

Lab 142 - BGP Timers

2011-05-21T09:03:00.000+01:00

Prerequisites: CCNP level skills.

Note!
Configuration from Lab 140.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
The BGP policy stipulates that the R5's timer to send BGP advertisements should be set to 10 seconds (default: iBGP=5 seconds, eBGP=30 seconds). Also BGP peer loss should be detected in 15 seconds (default=180 seconds). Also improve the BGP scanner operation by decreasing the default value of 60 seconds to 20 seconds.

Solution

Task 1

The BGP policy stipulates that the R5's timer to send BGP advertisements should be set to 10 seconds (default: iBGP=5 seconds, eBGP=30 seconds). Also BGP peer loss should be detected in 15 seconds (default=180 seconds). Also improve the BGP scanner operation by decreasing the default value of 60 seconds to 20 seconds.

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 bgp scan-time 20
 network 172.16.105.0 mask 255.255.255.0
 timers bgp 5 15
 neighbor 10.1.35.3 remote-as 100
 neighbor 10.1.35.3 advertisement-interval 10
 no auto-summary

!

Note!
Hello timer is set to 5 seconds following the rule 3 x keepalive = holdtime.

BGP Processes:

BGP Open - responsible for BGP session establishment.
BGP I/O - handles queuing and processing updates and keepalive packets.
BGP Scanner - responsible for conditional route advertisements, route dampening, import and export of routes into VRF (MPLS), and confirms the reachability to the NEXT_HOP (the last one is handled now by BGP next-hop tracking).
BGP Router - calculates the best path, establishes peers, sends and receives routes and interacts with RIB.

Source:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00809d16f0.shtml#understandbgp

Lab 141 - BGP Next-Hop Address Tracking

2011-05-21T08:12:00.004+01:00

Prerequisites: CCNP level skills.

Note!
Configuration from Lab 140.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure R3 in such a way that the interval between full table walks is 10 seconds (not 5 which is default).

Solution

Task 1

Configure R3 in such a way that the interval between full table walks is 10 seconds (not 5 which is default).

R3 Configuration:

!

R3#show run | s router bgp
router bgp 100
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 bgp nexthop trigger delay 10
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 100
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.102.2 remote-as 100
 neighbor 172.16.102.2 update-source Loopback0
 neighbor 172.16.104.4 remote-as 100
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary

!

Note!
The BGP Support for Next-Hop Address Tracking feature is enabled by default when a supporting Cisco IOS software image is installed. BGP next-hop address tracking is event driven. BGP prefixes are automatically tracked as peering sessions are established. Next-hop changes are rapidly reported to the BGP routing process as they are updated in the RIB. This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a bestpath calculation is run in between BGP scanner cycles, only next-hop changes are tracked and processed.

Source:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_bnht.html

Lab 140 - BGP Fast Fallover

2011-05-19T20:40:00.006+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure full mesh BGP peering according to the topology diagram (pic. 1). Make sure that all BGP sessions in AS 100 can survive a single link loss. If IGP protocol must used, OSPF should be configured. Advertise Loopbacks into BGP.

Task 2
Configure R3 in such a way so the response time of BGP to adjacency changes is improved. Use a method of detecting the loss of the peer that is not based on the interface state but is event driven such as a loss of the path to the IGP address used for peering.

Solution

Task 1

Configure full mesh BGP peering according to the topology diagram (pic. 1). Make sure that all BGP sessions in AS 100 can survive a single link loss. If IGP protocol must be used, OSPF should be configured. Advertise Loopbacks into BGP.

R1 Configuration:

!

router ospf 1
 router-id 172.16.101.1
 log-adjacency-changes
 network 10.1.13.1 0.0.0.0 area 0
 network 10.1.14.1 0.0.0.0 area 0
 network 172.16.101.1 0.0.0.0 area 0

!

router bgp 100
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes

 network 172.16.101.0 mask 255.255.255.0
 neighbor 172.16.102.2 remote-as 100
 neighbor 172.16.102.2 update-source Loopback0
 neighbor 172.16.103.3 remote-as 100
 neighbor 172.16.103.3 update-source Loopback0
 neighbor 172.16.104.4 remote-as 100
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary

!

R2 Configuration:

!

router ospf 1
 router-id 172.16.102.2
 log-adjacency-changes
 network 10.1.23.2 0.0.0.0 area 0
 network 10.1.24.2 0.0.0.0 area 0
 network 172.16.102.2 0.0.0.0 area 0

!

router bgp 100
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes

 network 172.16.102.0 mask 255.255.255.0
 neighbor 172.16.101.1 remote-as 100
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.103.3 remote-as 100
 neighbor 172.16.103.3 update-source Loopback0
 neighbor 172.16.104.4 remote-as 100
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary

R3 Configuration:

!

router ospf 1
 router-id 172.16.103.3
 log-adjacency-changes
 network 10.1.13.3 0.0.0.0 area 0
 network 10.1.23.3 0.0.0.0 area 0
 network 172.16.103.3 0.0.0.0 area 0

!

router bgp 100
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes

 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 100
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.102.2 remote-as 100
 neighbor 172.16.102.2 update-source Loopback0
 neighbor 172.16.104.4 remote-as 100
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary

!

R4 Configuration:

!

router ospf 1
 router-id 172.16.104.4
 log-adjacency-changes
 network 10.1.14.4 0.0.0.0 area 0
 network 10.1.24.4 0.0.0.0 area 0
 network 172.16.104.4 0.0.0.0 area 0

!

router bgp 100
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes

 network 172.16.104.0 mask 255.255.255.0
 neighbor 172.16.101.1 remote-as 100
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.102.2 remote-as 100
 neighbor 172.16.102.2 update-source Loopback0
 neighbor 172.16.103.3 remote-as 100
 neighbor 172.16.103.3 update-source Loopback0

!

Verification:

Pic. 2 - R1's BGP Neighbors.

Pic. 3 - R2's BGP Neighbors.

Pic. 4 - R3's BGP Neighbors.

Pic. 5 - R4's BGP Neighbors.

Task 2
Configure R3 in such a way so the response time of BGP to adjacency changes is improved. Use a method of detecting the loss of the peer that is not based on the interface state but is event driven such as a loss of the path to the IGP address used for peering.

R3 Configuration:

!

router bgp 100
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 100
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.101.1 fall-over
 neighbor 172.16.102.2 remote-as 100
 neighbor 172.16.102.2 update-source Loopback0
 neighbor 172.16.102.2 fall-over
 neighbor 172.16.104.4 remote-as 100
 neighbor 172.16.104.4 update-source Loopback0
 neighbor 172.16.104.4 fall-over
 no auto-summary

!

Verification:

Pic. 6 - BGP Fallover.

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

Lab 139 - BGP Soft Reconfiguration

2011-05-18T18:49:00.002+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure R5 in such way, that if BGP in R3 does not support 'Route Refresh' message, it can still apply inbound policy without asking R5 to re-send their BGP prefixes.

Solution

Task 1

Configure R5 in such way, that if BGP in R3 does not support 'Route Refresh' message, it can still apply inbound policy without asking R5 to re-send their BGP prefixes.

Pic. 2 - BGP Before Applying Configuration.

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 neighbor 10.1.35.3 soft-reconfiguration inbound
 no auto-summary

!

Verfication:

Pic. 3 - BGP After Applying Configuration.

Notice!
This command creates the exact copy of the BGP table. This causes high memory utilization but allows to apply inbound filtering on R5 without tearing down the session if the Route-Refresh messages are not supported on R5.

Lab 138 - BGP ORF

2011-05-18T18:47:00.002+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

R5 should filter out all class A prefixes starting with 40.x.x.x. Configure routers in such a way that changing the inbound filtering policy on R5 should force R3 to apply the right filtering preventing it from sending prefixes R5 does not wish to receive.

Solution

Task 1

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 next-hop-self  
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 next-hop-self  
 neighbor 10.1.35.5 remote-as 50
 neighbor 10.1.35.5 capability orf prefix-list receive
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 neighbor 10.1.35.3 capability orf prefix-list send
 no auto-summary

!

Verification:

Pic. 2 - Outbound Route Filtering Negotiated between R3 and R5.

Notice!
ORF has been enabled and supports prefix-lists only (as of writing this post). Now, I can apply the prefix-list based filtering as per Task 1.

Pic. 3 - BGP Table on R5 Before Filtering.

R5 Configuration:

!
ip prefix-list FILTER seq 5 deny 40.0.0.0/8 le 32
ip prefix-list FILTER seq 10 permit 0.0.0.0/0 le 32
!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 neighbor 10.1.35.3 capability orf prefix-list send
 neighbor 10.1.35.3 prefix-list FILTER in
 no auto-summary

!

Verification:

Pic. 4 - Prefix-List Applied on R5.

Now, 'clear ip bgp * in' on R5.

Lab 137 - BGP Peer Templates

2011-05-16T21:46:00.003+01:00

Prerequisites: CCNP level skills.

Note!

I have created a pdf document with OSPF Lab 1 and 2 containing a detailed lab breakdown. Check it out if want. Any feedback is most welcome.

http://www.4shared.com/document/W8lhDzNo/Hacking-Cisco-OSPF-Lab1-2-Brea.html

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

Configure authentication between R3 and R5 (use password: 'CISCO123'). Configure the BGP timers: hello=30 seconds, holdtime=90 on R3 for all its iBGP peers. R3's iBGP sessions should inherit the same password. Do not use 'neighbor <address> password' command in R3 to accomplish your goal. R1 and R2 and R5 can use this command. The configuration stipulates that iBGP current and future policy in R3 should be configured as a template.

Solution

Task 1

Configure authentication between R3 and R5 (use password: 'CISCO123'). Configure the BGP timers: hello=30 seconds, holdtime=90 in R3 for all its iBGP peers. R3's iBGP sessions should inherit the same password. Do not use 'neighbor <address> password' command on R3 to accomplish your goal. R1 and R2 and R5 can use this command. The configuration stipulates that iBGP current and future policy in R3 should be configured as a template.

R1 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.13.3 password CISCO123
 neighbor 10.1.14.4 remote-as 40
 no auto-summary

!

R2 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 123
 neighbor 10.1.23.3 password CISCO123
 neighbor 10.1.23.3 next-hop-self
 neighbor 10.1.24.4 remote-as 40
 no auto-summary

R3 Configuration:

!

router bgp 123
 template peer-policy IBGP_POLICY
  next-hop-self
 exit-peer-policy
 !
 template peer-session AUTHENTICATION
  password CISCO123
 exit-peer-session
 !
 template peer-session IBGP_ROUTERS
  remote-as 123
  timers 30 90
  inherit peer-session AUTHENTICATION
 exit-peer-session
 !
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 inherit peer-session IBGP_ROUTERS
 neighbor 10.1.13.1 inherit peer-policy IBGP_POLICY
 neighbor 10.1.23.2 inherit peer-session IBGP_ROUTERS
 neighbor 10.1.23.2 inherit peer-policy IBGP_POLICY
 neighbor 10.1.35.5 remote-as 50
 neighbor 10.1.35.5 inherit peer-session AUTHENTICATION
 no auto-summary

Verification:

Pic. R3's Neighbors.

Lab 136 - BGP Peer Groups

2011-05-16T19:51:00.002+01:00

Disclaimer

The author of the posts will not assume any liability or responsibility to any person or entity with respect to loss or damages incurred from information contained in this blog. Any resemblance to some other training materials and/or CCIE exam is completely coincidental.
Full information:
http://hackingcisco.blogspot.com/2011/01/cisco-going-pro.html

Prerequisites: CCNP level skills.

Note!

I have created a pdf document with OSPF Lab 1 and 2 containing a detailed lab breakdown. Check it out if want. Any feedback is most welcome.

http://www.4shared.com/document/W8lhDzNo/Hacking-Cisco-OSPF-Lab1-2-Brea.html

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

R3 in AS 123 is going to peer with few hundred routers running iBGP session and you will need to save its resources (CPU). Configure R3 iBGP peering in such a way that it checks the routing table only once and replicates the same update to all its iBGP peers.

Solution

Task 1

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor IBGP_ROUTERS peer-group
 neighbor IBGP_ROUTERS remote-as 123
 neighbor IBGP_ROUTERS route-reflector-client
 neighbor IBGP_ROUTERS next-hop-self
 neighbor 10.1.13.1 peer-group IBGP_ROUTERS
 neighbor 10.1.23.2 peer-group IBGP_ROUTERS
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

Verification:

Pic. 2 - BGP Peer Group.

Pic. 3 - BGP Peer Group Members Summary.

Note!
BGP Peer groups have limitations:

All neighbors that shared the same peer group configuration also had to share the same outbound routing policies.
All neighbors had to belong to the same peer group and address family. Neighbors configured in different address-families could not belong to different peer groups.

Source:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpct.html#wp1027184

(The second bullet point tries to underline the fact that you cannot mix iBGP and eBGP peers in the same peer group).

Lab 135 - BGP TTL Security

2011-05-11T21:19:00.006+01:00

Prerequisites: CCNP level skills.

Note!

I have created a pdf document with OSPF Lab 1 and 2 containing a detailed lab breakdown. Check it out if want. Any feedback is most welcome.

http://www.4shared.com/document/W8lhDzNo/Hacking-Cisco-OSPF-Lab1-2-Brea.html

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

AS 50 has been experiencing a SYN attack on TCP port 179 (BGP). In order to protect the router, configure R5 so that it accepts BGP packets only from its directly connected neighbor.

Solution

Task 1

AS 50 has been experiencing a SYN attack on TCP port 179 (BGP). In order to protect the router, configure R5 so that it accepts BGP packets only from its directly connected neighbor.
Notice!
These attacks must have their TTL higher than 1 in order to reach AS 50. Due to the volatile behavior of BGP paths, the attacker will find it very difficult or almost impossible to calculate their TTL value to be 1 when delivered to our router. The configuration must be done on both neighbors (R3 and R5).

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 next-hop-self 
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 next-hop-self 
 neighbor 10.1.35.5 remote-as 50
 neighbor 10.1.35.5 ttl-security hops 1
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 neighbor 10.1.35.3 ttl-security hops 1
 no auto-summary

!

Verification:

Pic. 2 - BGP Details on R3.

Pic. 3 - BGP Details on R5.

Lab 134 - BGP Backdoor

2011-05-11T20:44:00.003+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Pic. 1 illustrates BGP peering between the routers. All loopbacks have been advertised into BGP.

Task 2
Configure OSPF between R1 and R2 using their E0/0 interfaces. Advertise their loopbacks into OSPF. Ensure that they are advertised with /24 network mask. The traffic between them takes the shortest path (through E0/0). The only configuration allowed to accomplish this should be done in the BGP context.

Solution

Task 1

Pic. 1 illustrates BGP peering between the routers. All loopbacks have been advertised into BGP.

Pic. 2 - BGP Table on R1.

Pic. 3 - BGP Table on R2.

Pic. 4 - Traceroute.

Notice!
Traffic from R1's Loopback towards R2's loopback goes through R3.

Task 2
Configure OSPF between R1 and R2 using their E0/0 interfaces. Advertise their loopbacks into OSPF. Ensure that they are advertised with /24 network mask. The traffic between them takes the shortest path (through E0/0). The only configuration allowed to accomplish this should be done in the BGP context.

R1 Configuration:

!

interface Loopback0
 ip address 172.16.101.1 255.255.255.0
 ip ospf network point-to-point
!

router ospf 1
 router-id 172.16.101.1
 log-adjacency-changes
 network 10.1.12.1 0.0.0.0 area 0
 network 172.16.101.1 0.0.0.0 area 0

!

R2 Configuration:

!

interface Loopback0
 ip address 172.16.102.2 255.255.255.0
 ip ospf network point-to-point

!

router ospf 1
 router-id 172.16.102.2
 log-adjacency-changes
 network 10.1.12.2 0.0.0.0 area 0
 network 172.16.102.2 0.0.0.0 area 0

!

Verification:

Pic. 5 - R1' Routing Table.

Notice!
eBGP prefix (172.16.102.0/24) has the administrative distance 20 and is better than OSPF (110). Path is suboptimal.

R1 Configuration:

!

router bgp 10
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 network 172.16.102.0 mask 255.255.255.0 backdoor
 neighbor 10.1.13.3 remote-as 30
 no auto-summary

!

R2 Configuration:

!

router bgp 20
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0 backdoor
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 30
 no auto-summary

!

Verification:

Pic. 6 - R1's Routing Table.

Notice!
Now, the subnet is known via OSPF with the next hop 10.1.12.2 (out E0/0). BGP backdoor changed its eBGP administrative distance from 20 to 200.

Pic. 7 - Traceroute.

Lab 133 - BGP Dampening using Route-Map

2011-05-10T20:11:00.004+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure R1 and R2 should apply the route dampening for prefixes 40.x.x.x according to the following:

Max-Suppres=50 minutes
Suppress=2000 points
Reuse=800 points
Half-Time=10 minutes

Prefixes 44.4.x.x should use the following dampening policy:

Max-Suppres=90 minutes
Suppress=2500 points
Reuse=700 points
Half-Time=20 minutes

Solution

Task 1

Configure R1 and R2 should apply the route dampening for prefixes 40.x.x.x according to the following:

Max-Suppres=50 minutes
Suppress=3000 points
Reuse=800 points
Half-Time=15 minutes

Prefixes 44.x.x.x should use the following dampening policy:

Max-Suppres=90 minutes
Suppress=2500 points
Reuse=700 points
Half-Time=20 minutes

R1 Configuration:

!

ip prefix-list NET_40 seq 5 permit 40.0.0.0/8 le 32
!
ip prefix-list NET_44 seq 5 permit 44.0.0.0/8 le 32
!

route-map DAMPEN permit 10
 match ip address prefix-list NET_40
 set dampening 15 800 3000 50
!         
route-map DAMPEN permit 20
 match ip address prefix-list NET_44
 set dampening 20 700 2500 90
!
router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 bgp dampening route-map DAMPEN
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.14.4 remote-as 40
 no auto-summary

!

Verification:

Pic. 2 - R1 Dampening Policy.

R2 Configuration:

!

ip prefix-list NET_40 seq 5 permit 40.0.0.0/8 le 32
!
ip prefix-list NET_44 seq 5 permit 44.0.0.0/8 le 32
!

route-map DAMPEN permit 10
 match ip address prefix-list NET_40
 set dampening 15 800 3000 50
!         
route-map DAMPEN permit 20
 match ip address prefix-list NET_44
 set dampening 20 700 2500 90
!
router bgp 123
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 bgp dampening route-map DAMPEN
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 123
 neighbor 10.1.23.3 next-hop-self
 neighbor 10.1.24.4 remote-as 40
 no auto-summary

!

Verification:

Pic. 2 - R2 Dampening Policy.

Lab 132 - BGP Dampening

2011-05-10T19:33:00.005+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure R3 to use BGP dampening according to the following:

Penalty should be reduced by half after 10 minutes (default=15).
The dampened route must be reused when it reaches value of 700. (default=750).
Route should not be used when it reaches 2000 points (default=2000).
The routes that experience flaps should not be suppressed for more than 40. minutes (default=4 x half-time).

Solution

Task 1

Configure R3 to use BGP dampening according to the following:

Penalty should be reduced by half after 10 minutes (default=15).
The dampened route must be reused when it reaches value of 700. (default=750).
Route should not be used when it reaches 2000 points (default=2000).
The routes that experience flaps should not be suppressed for more than 40. minutes (default=4 x half-time).

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 bgp dampening 10 700 2000 40
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 next-hop-self 
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 next-hop-self 
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

Verification:

Pic. 2 - BGP Dampening Parameters.

Lab 131 - BGP Next-Hop using Redistribution into IGP

2011-05-09T20:08:00.002+01:00

Prerequisites: CCNP level skills.

Note!
Use the configuration from Lab 130 except for route-maps that change the next-hop.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Similarly to the lab 129 and 130, deal with the next hop on R1, R2 and R3, but do not use 'next-hop-self' or route-map to change the next-hop while advertising BGP prefixes in AS 123.

Solution

Task 1
Similarly to the lab 129 and 130, deal with the next hop on R1, R2 and R3, but do not use 'next-hop-self' or route-map to change the next-hop while advertising BGP prefixes in AS 123.

R1 Configuration:

!

router ospf 1
 router-id 172.16.101.1
 log-adjacency-changes
 redistribute connected subnets
 network 10.1.13.1 0.0.0.0 area 0

!

R2 Configuration:

!

router ospf 1
 router-id 172.16.102.2
 log-adjacency-changes
 redistribute connected subnets
 network 10.1.23.2 0.0.0.0 area 0

!

R3 Configuration:

!

router ospf 1
 router-id 172.16.103.3
 log-adjacency-changes
 redistribute connected subnets
 network 10.1.13.3 0.0.0.0 area 0
 network 10.1.23.3 0.0.0.0 area 0

!

Verification:

Pic. 2 - BGP Prefix from AS 50 on R1.

Pic. 3 - Reachability to 10.1.3.5 on R1.

Lab 130 - BGP Next-Hop using Route-map

2011-05-09T19:54:00.003+01:00

Prerequisites: CCNP level skills.

Note!
Use the configuration from Lab 129 except for 'next-hop-self' command.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Similarly to the lab 129, deal with the next hop on R1, R2 and R3, but do not use 'next-hop-self' command or redistribution into IGP.

Solution

Task 1
Similarly to the lab 129, deal with the next hop on R1, R2 and R3, but do not use 'next-hop-self' command or redistribution into IGP.
R1 Configuration:

!

route-map SET_NEXT_HOP permit 10
 set ip next-hop 10.1.13.1
!
router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.13.3 route-map SET_NEXT_HOP out
 neighbor 10.1.14.4 remote-as 40
 no auto-summary

!

Then, 'clear ip bgp * out'

Notice!
While configuring the 'set ip next-hop 10.1.13.1' we get the warning which can be ignored. We know what we're doing after all ;)

Pic. 2 - Warning.

R2 Configuration:

route-map SET_NEXT_HOP permit 10
set ip next-hop 10.1.23.2
!

router bgp 123
no synchronization
bgp router-id 172.16.102.2
bgp log-neighbor-changes
network 172.16.102.0 mask 255.255.255.0
neighbor 10.1.23.3 remote-as 123
neighbor 10.1.23.3 route-map SET_NEXT_HOP out
neighbor 10.1.24.4 remote-as 40
no auto-summary

R3 Configuration:

!

route-map SET_NEXT_HOP_R2 permit 10
 set ip next-hop 10.1.23.3
!
route-map SET_NEXT_HOP_R1 permit 10
 set ip next-hop 10.1.13.3
!
router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 route-map SET_NEXT_HOP_R1 out
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 route-map SET_NEXT_HOP_R2 out
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

Verification:
This time let's check if R1 and R2 have the best path to prefix from AS 50.

Pic. 3 - AS 50 Prefix on R1.

Pic. 3 - AS 50 Prefix on R2.

Lab 129 - BGP Next-Hop using Next-Hop-Self

2011-05-09T19:29:00.003+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure OSPF area 0 only on point-to-point links between:

R1 and R3
R2 and R3

Do not enable OSPF on links connecting AS 123 to AS 40 and AS 50!

Task 2
Configure BGP peering as per Pic. 1. Advertise all loopbacks into BGP. Make sure that R3 can reach loopbacks advertised by AS 40 and R1 and R2 can reach the loopback advertised by AS 50. Do not use route-map or redistribution into OSPF to accomplish that.

Solution

Task 1

Configure OSPF area 0 only on point-to-point links between:

R1 and R3
R2 and R3

Do not enable OSPF on links connecting AS 123 to AS 40 and AS 50!

R1 Configuration:

!

router ospf 1
 router-id 172.16.101.1
 log-adjacency-changes
 network 10.1.13.1 0.0.0.0 area 0

!

R2 Configuration:

!

router ospf 1
 router-id 172.16.102.2
 log-adjacency-changes
 network 10.1.23.2 0.0.0.0 area 0

!

R3 Configuration:

!

router ospf 1
 router-id 172.16.103.3
 log-adjacency-changes
 network 10.1.13.3 0.0.0.0 area 0
 network 10.1.23.3 0.0.0.0 area 0

!

Verification:

Pic. 2 - OSPF Neighbors on R3.

Task 2
Configure BGP peering as per Pic. 1. Advertise all loopbacks into BGP. Make sure that R3 can reach loopbacks advertised by AS 40 and R1 and R2 can reach the loopback advertised by AS 50. Do not use route-map or redistribution into OSPF to accomplish that.
R1 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.14.4 remote-as 40
 no auto-summary

!

R2 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 123
 neighbor 10.1.24.4 remote-as 40
 no auto-summary

!

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

R4 Configuration:

!

router bgp 40
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes
 network 172.16.104.0 mask 255.255.255.0
 network 172.16.144.0 mask 255.255.255.0
 redistribute connected route-map CONN_TO_BGP
 neighbor 10.1.14.1 remote-as 123
 neighbor 10.1.24.2 remote-as 123
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 no auto-summary

!

Verification:

Pic. 3 - BGP Table on R3.

Notice!

All prefixes learned from AS 40 have missing best path marker '>'. The reason is that R3 does not know how to reach the next hop for these (10.1.14.4 and 10.1.24.4). The same problem will R1 and R2 have for prefix learned from AS 50. This is due to the fact that eBGP next-hop attribute is preserved over iBGP session.

Pic. 4 - R3's Routing Table - Next Hop Addresses.

The BGP table for a specific prefix shows the problem.

Pic. 5 - Detailed BGP Prefix Information.

In order to fix this problem, the next-hop-self command can be used given the stipulations (no redistribution into OSPF, or route-map to be used).

R1 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.13.3 next-hop-self
 neighbor 10.1.14.4 remote-as 40
 no auto-summary

!

R2 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 123
 neighbor 10.1.23.3 next-hop-self
 neighbor 10.1.24.4 remote-as 40
 no auto-summary

!

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 next-hop-self
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 next-hop-self
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

Verification:

Pic. 6 - BGP Table on R3.

Lab 128 - BGP Remove-Private-AS

2011-05-08T20:52:00.002+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
R5 is connecting to their Service Provider. The company has neither their own public AS number nor their public IP addresses. For the purpose of BGP configuration AS 123 has allocated a private as number for R5 (AS 65005). Configure routers in AS 123 so this private AS number is not advertised over EBGP peerings.

Solution

Task 1
R5 is connecting to their Service Provider. The company has neither their own public AS number nor their public IP addresses. For the purpose of BGP configuration AS 123 has allocated a private as number for R5 (AS 65005). Configure routers in AS 123 so this private AS number is not advertised over EBGP peerings.

Pic. 2 - R4 Receives the Private AS number from R1 and R2.

R1 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.13.3 next-hop-self
 neighbor 10.1.14.4 remote-as 40
 neighbor 10.1.14.4 remove-private-as
 no auto-summary

!

R2 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.23.3 remote-as 123
 neighbor 10.1.23.3 next-hop-self
 neighbor 10.1.24.4 remote-as 40
 neighbor 10.1.24.4 remove-private-as
 no auto-summary

!

Pic. 3 - BGP Table on R4.

Notice!
Both R1 and R2 have removed the private AS from their advertisement sent to AS 40.

Lab 127 - BGP Allowas-In

2011-05-08T20:21:00.002+01:00

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
R4 and R5 are the edge routers of AS 45. Configure AS 123 in such a way, that the prefixes advertised by R4 are accepted by BGP table on R5 and vice versa.

Solution

Task 1
R4 and R5 are the edge routers of AS 45. Configure AS 123 in such a way, that the prefixes advertised by R4 are accepted by BGP table on R5 and vice versa.

Notice!
BGP routers use eBGP loop prevention mechanism which prompts them to check if their own AS is anywhere in the path. If so, the prefix is rejected (looped). In corner case scenarios like this, we must disable this mechanism (this may cause loops so care must be taken when configuring this).

Pic. 2 - R5's Peering with R3.

Pic. 3 - BGP Table on R5.

Pic. 4 - Update Rejected on R5.

Notice!

Output truncated (all prefixes advertised into BGP by R4 are rejected, R4 rejects the prefix advertised by R5)

R4 Configuration:

!

router bgp 45
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes
 network 172.16.104.0 mask 255.255.255.0
 network 172.16.144.0 mask 255.255.255.0
 redistribute connected route-map CONN_TO_BGP
 neighbor 10.1.14.1 remote-as 123
 neighbor 10.1.14.1 allowas-in 1
 neighbor 10.1.24.2 remote-as 123
 neighbor 10.1.24.2 allowas-in 1
 no auto-summary

!

R5 Configuration:

!

router bgp 45
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 123
 neighbor 10.1.35.3 allowas-in 1
 no auto-summary

!

Notice!
The option 'allowas-in 1' allows for its own AS (AS 45) to appear once (1) in the AS_PATH attribute. The prefixes are now accepted.

Pic. 5 - BGP Table on R5.

Lab 126 - BGP Local-AS No-prepend Dual-AS

2011-05-08T19:16:00.003+01:00

Prerequisites: CCNP level skills.

Note!
Configuration from Lab 123 must be used in this lab.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
After merging the three ASes (Lab 123/124), the administrators of AS 40 requested that AS 123 should not show in the path of the prefixes advertised by 123. They also requested that you configure R1 so that R4 can peer using either AS 123 or the previous AS 10.

Solution

Task 1

After merging the three ASes (Lab 123/124), the administrators of AS 40 requested that AS 123 should not show in the path of the prefixes advertised by 123. They also requested that you configure R1 so that R4 can peer using either AS 123 or the previous AS 10.

Pic. 2 - Current BGP Table on R4.

R1 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 123
 neighbor 10.1.13.3 next-hop-self
 neighbor 10.1.14.4 remote-as 40
 neighbor 10.1.14.4 local-as 10 no-prepend replace-as dual-as
 no auto-summary

!

After changing the configuration R4 shows the following messages:

Pic. 3 - R4 BGP Syslog.

Notice!
R4's BGP session has been torn down and re-established.

R1 has established session with R4 using its local-as (AS 40).

Pic. 4 - R1's BGP Neighbors.

R4 has established the session with AS 10 (local-as).

Pic. 5 - R4's BGP Peering.

Now, R4 can be reconfigured to establish session with R1 using its AS 123. Under a second the session with the new real AS number succeeds.

Pic. 6 - R4 Reconfigured to peer with AS 123.

Lab 125 - BGP Local-AS No-prepend Replace-AS

2011-05-08T18:43:00.003+01:00

Prerequisites: CCNP level skills.

Note!
Configuration from Lab 123 must be used in this lab.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
After merging the three ASes (Lab 123/124), the administrator of AS 50 noticed that prefixes arriving on R5 carry the AS 123 in the AS_PATH attribute. Before AS 50 configure their R5 router to peer with AS 123, the administrator asked you to remove AS 123 from the AS_PATH attribute.

Solution

Task 1

After merging the three ASes (Lab 123/124), the administrator of AS 50 noticed that prefixes arriving on R5 carry the AS 123 in the AS_PATH attribute. Before AS 50 configure their R5 router to peer with AS 123, the administrator asked you to remove AS 123 from the AS_PATH attribute.

Pic. 2 - Current BGP Table on R5.

R3 Configuration:

!

router bgp 123
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 123
 neighbor 10.1.13.1 route-reflector-client
 neighbor 10.1.13.1 next-hop-self
 neighbor 10.1.23.2 remote-as 123
 neighbor 10.1.23.2 route-reflector-client
 neighbor 10.1.23.2 next-hop-self
 neighbor 10.1.35.5 remote-as 50
 neighbor 10.1.35.5 local-as 30 no-prepend replace-as
 no auto-summary

!

Pic. 3 - R5's BGP Table.

Notice!
The option 'no-prepend' removes the local-as numbers (look at lab 124). The option 'replace-as' strips off the original AS number when updates are sent to the BGP neighbor configured to use the local-as number.