Multicast Routing with PIM-SM

To get a better understanding of Multicast PIM-SM routing I created a case study. In the picture below the GNS3 topology I used.

topology

I used EIGRP between the routers for full unicast connectivity. On all te routers I configured “IP multicast-routing” and on the connected interfaces I configured the “ip pim sparse-mode”. R3 serves as a Rendevouz Point (RP) and R4 serves as the Mapping Agent (MA).

First configure the full unicast connectivity. I will show one sample, the other routers are pretty straight forward.

R1
!
interface FastEthernet1/0
ip address 10.0.0.5 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/0
ip address 172.18.100.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 10
network 1.1.1.1 0.0.0.0
network 10.0.0.0 0.0.0.3
network 10.0.0.4 0.0.0.3
network 172.18.100.0 0.0.0.255
no auto-summary
eigrp router-id 1.1.1.1
!

Make sure there is full unicast connectivity from 172.18.100.254 to 192.168.157.254. Check your routing table on router R1 and use the ping command. The routing table will look like the picture blow.
R1_RT

Now that we have full unicast connectivity we can start with the multicast basics. First configure multicast routing on all the routers. This can be done with the following command: “ip mulicast-routing”. After that configure the “ip pim sparse-mode” command on all the interfaces which are participating in the multicast routing. In my topology this means all physical interfaces and the Loopback interfaces on router R3 and R4.
After this we have basic multicast connectivity.

Now it’s time to configure the Rendevous Point, but first a little explanation about PIM-SM, Rendevouz Point’s and Mapping Agents.

PIM-SM*
PIM-SM is a protocol for efficiently routing IP packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense-multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group
explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage.

Rendevouz Point*
A Rendezvous Point (RP) is used as a temporary way to connect a would-be multicast receiver to an existing shared multicast tree passing through the rendezvous point. When volume of traffic crosses a threshold, the receiver is joined to a source-specific tree, and the feed through the RP is dropped. You can think of this as obtaining copies of something through a friend who already subscribes, and when it proves useful or interesting, it’s worth the bother to become a direct subscriber.

I used auto-RP to configure a RP, so a little more about auto-RP

auto-RP
Auto-RP automatically distributes information to routers as to what the RP address is for various multicast groups. It simplifies use of multiple RP’s for different multicast group ranges. It avoids manual configuration inconsistencies, and allows for multiple RP’s acting as backups to each other. Cisco routers automatically listen for this information.

Auto-RP relies on a router designated as RP mapping agent. Potential RP’s announce themselves to the mapping agent, and it resolves any conflicts. The mapping agent then sends out the multicast group-RP mapping information to the other routers.

Mapping-Agent
The RP mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a discovery message that is sent to 224.0.1.40. These discovery messages are used by the remaining routers for their RP-to-group map. You can use one RP that also serves as the mapping agent, or you can configure multiple RPs and multiple mapping agents for redundancy purposes.

If you want to know more about the theory behind multicast routing check out the “Routing TCP/IP Volume II book written by Jeff Doyle and Jennifer DeHAven Carroll. Or check out this link: http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html

Let’s start configuring. To configure the RP on R3 use the commands as in the below configuration:

R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-announce Loopback0 scope 15
!

And configure the Mapping-Agent on router R4. RP and MA can be configured on the same router, but for the sake of the example I configure them on different routers.

R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-discovery Loopback0 scope 15
!

Basically this is all there is to make PIM-SM, RP and MA to function. To check if everthing works as expected, use the following commands:

Show ip pim rp mapping
pim rp map
As can be seen in the above picture the 224.0.0.0/4 groups are connected to the RP on router R3 and the RP is chosen via Aur0-RP

To check if there is multicast connectivity check the multicast routing table:

Show ip mroute
sh ip mrou

Now were up to the next part, how to stream a videofile over the multicast network to a multicast receiver.

In my example I used 3 virtual machines with windows 7 installed, I use VMware workstation for it. To stream the videofile I installed VLC on C1. See below the configuration I used to stream the file
C1
VLC sets the TTL default to 1. I the topology used, this won’t work because there are at least 4 hops between sender and receiver. I set the TTL to 12. Check this with a wireshark trace like in the picture below
ttl
Because I set the multicast (group)address to 239.255.255.250 on C1, check on router R1 if the correct multicast group is “created” with the “show ip igmp groups” command.
sh ip igmp grou

 

Now configure the client, as shown in the picture below

C2

And there we go! We are looking to an udp multicast videostream. To make C3 work, follow the same steps.

This is a faitly simple example of the of PIM-SM and multicast, but nevertheless it gives a perfect view of the multicast capabilities!

If you run into any trouble, there are some handy multicast troubleshooting tools like mtrace and mstat.

Mtrace is the multicast equivalent of traceroute
mtrace

The mstat command gives you an overview of the multicast path in ascii style. It shows drops, duplicates, TTL’s and delays between the nodes in the paths.
mstat

 

 

*Source of this information is http://www.cisco.com

 

Advertisements

DMVPN

One of the parts of my CCIE study is DMVPN’s. With this technique it’s very easy to built full meshed VPN networks without the need to connect every (branch) office physically with each other. DMVPN’s are built in a hub and spoke manner. Between the hub and the spoke tunnels (VPN’s) are built for connectivity. It’s also possible to connect a branch to a branch, without sendig all the traffic to the Hub, but directly to the spoke site.
To make all of this happen, DMVPN’s use a technique which is called NHRP.

NHRP*
In a computer network, the Next Hop Resolution Protocol (NHRP) is a protocol or method that can be used so that a computer sending data to another computer can learn the most direct route (the fewest number of hops to the receiving computer. If the receiving computer is in the same subnetwork, the use of NHRP will tell the sending computer that the receiving computer is local and it can send subsequent data packets directly to the receiving computer using its subnetwork address rather than its global network address. If the receiving computer is not in the same subnetwork, the use of NHRP will tell the sending computer the computer in the subnetwork whose router provides the most direct path to the receiving computer and the sender can now forward subsequent data packets to that router. In a way NHRP functions almost as a DNS server.

In the picture below the topology I used for this case study. The internetcloud is in my GNS3 configuration a router which routes the used subnets.

DMVPN

 

First configure the DMVPN hub, in my case this is router R1. I think configuring the local and external addresses a pretty forward, so I will only show the tunnel configuration.

R1 Tunnel0
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp network-id 1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

As can be seen in the above configuration there is no tunnel destination configured. Instead of this the tunnel mode is configured as “tunnel mode gre multipoint”. With this configuration it is possible to connect several branches (spokes) to the same interface.

To connect a spoke to the hub location the following configuration is necessary on the spoke router.

R2
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.0.0.1 201.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

To connect a branch office to the hub location, you have to point the tunnel to the tunnel and external address of the hub location.

To check if the connection succeeded, use the “show dmvpn” command on the hub and spoke router.

R1
show_dmvpn_R1

R2
show_dmvpn_R2

As can be seen there is DMVPN connectivity between the hub and the spoke router. Only the traffic is not encrypted yet. For that we have to configure a crypto IPSEC profile. This can be done as below, I will not discuss this part of the configuration. For this I will write a seperate blogpost.

Configure on router R1
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Configure on router R2
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Now the traffic between hub and spoke are encrypted. To check this, you can make use of wireshark. I will ping the 10.10.10.254 interface of router R1 with a source address of 192.168.1.254.

wireshark_encr

When you open one of these packets you can see that ESP is used to encypt the packet

ESP

ESP*
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity and confidentiality protection of packtes. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure. Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.

To create a spoke-to-spoke connection, let’s say between R2 and R4, only the routes necessary have to be configured on R2 and R4. In a large scale full mesh network it’s easier to use a dynamic routing protocol. But in my example I want to show it’s also possible to connect only two spoke’s instead of a totally meshed network.

Configure on R2 the route to the LAN of R4
!
ip route 192.168.2.0 255.255.255.0 10.0.0.4
!

Configure on R4 the route to the LAN of R2
!
ip route 172.18.1.o 255.255.255.0 10.0.0.2
!

If you use the “show dmvpn” command on R2 and R4, there is an extra tunnel built between spoke routers R2 and R4.

R2
show_dmvpn_R2_HS

R4
show_dmvpn_R4_HS

As can be seen in the picture above, the tunnel between R2 and R4 is a dynamic tunnel. If you remove the previously created routes, the tunnel will be terminated.

 

 

*Source is http://www.cisco.com

IPv6 Fundamentals

While learning for my CCIE exam I realized that my understanding of IPv6 was really mediocre, although it was enough to clear the CCNP and CCDP exams. But I have to level up my knowledge of IPv6 to even think of passing the CCIE exam. Besides the cisco.com website I used two books: “IPv6 Fundamentals” written by Rick Graziani and “IPv6 for Enterprise Networks” written by Shannon McFarland, Muninder Sambi, Nikhil Sharma and Sanjay Hooda.
After reading these books and reading some config guides from the cisco.com website, my understanding of IPv6 had leveled up about 10 levels.

Therefore I thought it was time to create a case study. Below is the topology I used. Of course I used my great study companion GNS3 to create and configure my case study.

IPv6 Topology

First I configured routers R1 to R3. This is the basic network, which uses OSPFv3. Below the configs of routers R1 to R3.

R1:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C001::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes

R2:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C002::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 2.2.2.2
log-adjacency-changes
!

 

R3:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::2/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 3.3.3.3
log-adjacency-changes
!

As can be seen in the configurations, IPv6 isn’t that different than IPv4. Two things to remember, first the ospf configuration is done on the interface itself. Second, the router-id in OSPFv3 is a 32-bit dotted decimal number, yes indeed a IPv4 address format.

Check out the IPv6 routing table to confirm the configuration is working:

IPv6 route table R2

 

To test ip connectivity use Ping. This works the same as in IPv4:

ping_test_R2

As can be seen in the topology overview there is an IPv6 “island” that has only IPv4 connectivity to the “main” network. Here “6to4” tunnels come in handy. To create IPv6 connectivity between the main network and the IPv6 island, we create a 6to4 tunnel on routers R1 and R4. These tunnels encapsulate IPv6 traffic into IPv4 packtes. To make this happen the following configuration on R1 and R4 are necessary:

R1:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet0/0
tunnel destination 10.10.10.2
tunnel mode ipv6ip
!
interface FastEthernet0/0
no switchport
ip address 10.10.10.1 255.255.255.252
!
ipv6 route 2001:DB8:CAFE:F001::/64 Tunnel0
ipv6 route 2001:DB8:CAFE:F002::/64 Tunnel0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes
redistribute static metric 5
!

 

R4:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet1/0
tunnel destination 10.10.10.1
tunnel mode ipv6ip
!
interface FastEthernet1/0
ip address 10.10.10.2 255.255.255.252
duplex auto
speed auto
!
ipv6 route 2001:DB8:CAFE::/48 Tunnel0
!
ipv6 router ospf 11
router-id 4.4.4.4
log-adjacency-changes
redistribute static metric 5
!

The configuration is pretty straight forward. Create the tunnel, give in source and destination (in this case the IPv4 address of the other site) and create a statis route for the subnet that has to be reached pointing to the tunnel interface.
Don’t forget to redistribute the static route into the routing protocol. This works the same for OSPFv3 as it works in IPv4 OSPF. The only down-side of a manual 6to4 tunnel is that it doesn’t scale very well in large enterprise networks.
To verify the Tunnel configuration use the “show interface tunnel 0” command:

Tunnel 0 R1

Now it is possible to ping from C1 to C5:

Ping_C1-C5

To verify that the IPv6 traffic is indeed encapsulated in an IPv4 packet use the “debug ip packet detail” command. Protocol 41 has to be present in the packet header:

debug packet

After reading the books and make some configurations, I must conclude that IPv6 isn’t that hard at all. Maybe it is even more straightforward than IPv4, because there is little need for NAT and stuff. Offcourse there are some things to get used like the link local addresses or SLAAC e.g (in a later post more about this). In my opinion it’s just a change of mindset, after doing this IPv6 is easier than IPv4!

To be fully complete below the configuration of router R5:

R5:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F002::1/64
ipv6 ospf 11 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F001::2/64
ipv6 ospf 11 area 0
!
ipv6 router ospf 11
router-id 5.5.5.5
log-adjacency-changes
!

MPLS VPN (Part 1)

A part of my CCIE study is MPLS VPN’s. This week I read some MPLS books, like “MPLS Fundamentals” and “MPLS and VPN Architectures, Volume II”. So to test my knowledge of the subject I found a useful case study online.

In the picture beneath the topolgy is shown:

MPLS VPN

Goal of this case study is to ping from Workstation “PC-COMPA-01” which resides in Company_A-West (as of now “West”) to “PC-COMPA-02” which resides in Company_A-North (as of now “North”).
The Provider core has to be free of BGP and has to be MPLS enabled. The core has to make use of a dynamic routing protocol.

I started with the dynamic routing configuration of the “Provider Core” which exists of the following routers : R1, R3, R2 and R4. Below is the configuration of R1 (R2, R3 and R4 are almost the same):

R1_config

After configuring the other routers, the routing table of R1 looks like the picture beneath:

ip route

The above steps are needed, because on the PE routers (R6 and R9) BGP will be configured. BGP makes use of the core network, so the routing needs to be in order.
Routers R6 and R9 will also make use of the eigrp protocol. So make sure it is possible to ping from R6=6.6.6.6 to R8=8.8.8.8.
In the picture below the configuration of the eigrp configuration of router R6:

Config R6

If this works, the BGP configuration can be made. As we all know BGP makes use of TCP, because of that it is important there is L3 connection from R6 to R8 and everthing in between.
Below the BGP configuration on R6 and R8.

BGP

To confirm that BGP functions as intended, use the “show ip bgp neighbors” command. Below the output of the command on R6.

Sh ip bgp neig

 

Before creating the VRF’s MPLS can be configured. Just give the “mpls ip” (Yes it’s really as simple as that!) command on the interfaces which have to take part in MPLS.
To confirm MPLS is active use the “show mpls forwarding-table” command. Below is the ouput of R1.

sh mpls forwa

Now it’s time to create the VRF’s, VRF stands for “Virtual Routing and Forewarding”. It’s like a virtual routing table which makes it possible to have the same ip subnets on one router. Which, in turn, makes it possible to have different customers with the same ip subnets on one router (or infrastructure for that matter).
To make communication possible between West and North, two VRF’s are created. One on R6 named “Customer_A-West” and one on R8 named “Customer_A-North”. Add the interfaces facing the CE router to the correct VRF.
Below the configuration needed.

VRF

 

Once the VRF’s are created, some changes have to be made on the BGP configuration, to let BGP know there is a VRF. Below the config of R6. The configuration for R8 is the same, only use the R8 ip addresses etc.

bgp vrf

 

As can be seen in the above picture, a static route has to be configured to make communications possible between routers R6 and R9 and also between R8 and R10. This static route will be configured in the VRF routing table, not in the global routing table! To test connectivity use the “ping VRF <vrf name>” command. With this command the ping originates from within the VRF and not from the global routing table!

Once the above configurations are made, R9 and R10 have to be configured. It’s a pretty straightforward configuration. Below the configuration of R9.

R9

Configure the clients with the correct ip addresses and test the connection between the workstations with the ping command:

pingR9-R10 ping R10 - R9

That’s basically all there is to make a MPLS VPN work!

Check for more info about MPLS VPN’s http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-bgp-mpls-vpn.html

 

Redistribution and Route-Maps (part 2)

In part two of this post I will explain how to make use of route-maps to influence the redistribution process of routing protocols.

First take a look again at the network topology.
Network Layout

As can be seen the redistribution point is between R4 and R5. The actual redistribtion configuration is done on R5.
With the configuration made in part 1 of this post, all routes are known to all routers in the topology. For whatever reason, sometimes you don’t want that all routes are vissible. This is where a route-map comes in handy.
With the use of route-maps I can influence a lot of things, like traffic flow and in this case the redistribution of routes.

Let’s assume the network administrator wants to exclude the ip-address of router R7 (7.7.7.7) from the routing table in the OSPF cloud. To make this happen the next configuration has to be made.

First of all make a standard ACL, in which you permit the 7.7.7.7 traffic
ACL

Then configure the route-map. Give it a name that makes sense to you (document this to make sure future colleagues understand it to!).
route_map

The “deny 10” does what it say’s, deny everything what comes after this line. The “match ip address 1” matches the traffic that hits access-list 1. The “route-map Redis permit 15” is not explicitly necessary, but to make things clear I added it nevertheless.

Now we have to tell the routing protocol to look at the “Redis” route-map. Otherwise the traffic will just flow as before
OSPF_redis
As you can see in the screenshot above, you just make an addition to the redistribution command.

Now take a look at the routing table of let’s say, router R1
Route_table_RM
As you can see there is no entry to the 7.7.7.7 route anymore
To be totally sure, do a ping test to 7.7.7.7
R1_ping_aft_RM

Route maps can be used for a lot of things and influence alsmost everthing. Check the Cisco documentation for more options!

Redistribution and Route-Maps (part 1)

This post will be about redistribution and the use of route-maps to influence the redistribution process.

When companies merge, the network has to merge too. Often the networks don’t use the same routing protocols. Sometimes it’s possible to migrate a netwerk from let’s say OSPF to EIGRP, but when the company’s don’t use Cisco only, it’s is hard to migrate.

To tackle this problem it’s is possible to redistribute the OSPF routes into EIGRP and also the other way around. This means that all the routes from OSPF are known in the EIGRP cloud, and al the EIGRP routes are known in the OSPF cloud. Sometimes it is not necessary for the EIGRP cloud to know al the OSPF routes. That’s when route-maps come in. With a route-map it is possible to make sure certain routes will never get to the routing table.

In the next section a configuration example.

First have a look a the network layout:

Network Layout

Al routers have two intfaces to connect to their neighbours and one loopback interface to identify the router.
Below an example of router R3:

Interfaces R3

After that configure OSPF:

EIGRP_redistribute R3

Make sure you configure these steps on all the OSPF routers.
To make sure the configuration is correct, check if the “show ip ospf neighbours” command shows two neighbours
OSPF_neighbours R3

 

After configuring the correct interfaces, configure EIGRP:

EIGRP R6

The initial configuration is done. Now the redistribution part can be configured. To make redistribution possible there has to be a redistribution point, in other words, there has to be a router which has an interface (or interfaces) in the OSPF aswell as the EIGRP cloud. In this example R5 is the redistribution point.

Below an example of the redistribution between OSPF and EIGRP on R5:

OSPF_redistribute EIGRP_redistribute R3

As shown in the examples the redistribution command has some options. The default values are enough to make the redistribution work.

To make sure the redistribution works, use the command show ip route on for example router R4.

Routes R4 after redistribution

As can be seen in the above example the EIGRP routes are learned as E2 routes. To make sure the connectivity is correct, use the ping command. As can be seen in the next example, the ping command is succesfull from router R1 to router R7.

ping

 

In part 2 I will describe the route-map configuration.