Update Cisco ASA 5506-X with Firepower

A customer bought a Cisco 5506-X with Firepower. It was delivered with Firepower version 5.4.1 (221). The upgrade process of a Cisco ASA is normally pretty straightforward. So I thought maybe a Firepower (FP) module is as easy to upgrade as an ASA box. I thought wrong.
Within ASDM it is possible to manage and upgrade the FP module. The first thing to stick out is the fact that ASDM on numerous occasions couldn’t contact the FP module. So after serveral tries I was able to manage the module from ASDM.
According to the Cisco manual it is possible to download the updates from within the ASDM. But after several tries and a lot of error messages I gave up on ASDM. So then there is only one solution. Go back to the good old CLI!

First of all I had to get the image file to the ASA box.This time I used a http server, the code looks like beneath:

Firewall# copy <interface> http flash:
Address or name of remote host []? <ip address>
Source filename []? asasfr-5500x-boot-6.0.0-1005.img
Destination filename [asasfr-5500x-boot-6.0.0-1005.img]? 

Now the FP module has to be rebooted with a new image, this can be done from the ASA cli:

Firewall(config)# sw-module module sfr recover configure image disk0:/asasf$
Firewall(config)# sw module sfr recover boot
Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.

Recover module sfr? [confirm]
Recover issued for module sfr. 

To monitor what’s going on, you have to enable debugging:

Firewall(config)# debug module-boot
debug module-boot  enabled at level 1

This step will take a while. I waited for about 20 minutes. After that you have to configure the FP module again. So login to the module and run the setup:

Firewall(config)# session sfr console 
Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco FirePOWER Services Boot Image 6.0.0

asasfr login: admin
Password: Admin123


Cisco FirePOWER Services Boot 6.0.0 (1005)
Type ? for list of commands
asasfr-boot>setup


Welcome to Cisco FirePOWER Services Setup 
 [hit Ctrl-C to abort]
Default values are inside []

Enter a hostname [asasfr]: <Name>
Do you want to configure IPv4 address on management interface?(y/n) [Y]: Y
Do you want to enable DHCP for IPv4 address assignment on management interface?(y/n) [N]: N
Enter an IPv4 address [192.168.8.8]: <IP address>
Enter the netmask [255.255.255.0]: <Netmask>
Enter the gateway [192.168.8.1]: <Default Gateway>
Do you want to configure static IPv6 address on management interface?(y/n) [N]: N
Stateless autoconfiguration will be enabled for IPv6 addresses.
Enter the primary DNS server IP address: <DNS server>
Do you want to configure Secondary DNS Server? (y/n) [n]: N
Do you want to configure Local Domain Name? (y/n) [n]: Y
Enter the local domain name: <domain name>
Do you want to configure Search domains? (y/n) [n]: Y
Enter the comma separated list for search domains: <Domain name>
Do you want to enable the NTP service? [Y]: Y
Enter the NTP servers separated by commas: <NTP pool>
Do you want to enable the NTP symmetric key authentication? [N]: N
Please review the final configuration:


Hostname:Firewall
Management Interface Configuration

IPv4 Configuration:static
IP Address:<IP address>
Netmask:<Netmask>
Gateway:<Default Gateway>

IPv6 Configuration:Stateless autoconfiguration

DNS Configuration:
Domain:<Domain>
Search:<Domain>
DNS Server:<DNS server>
NTP configuration: <NTP pool>
CAUTION:
You have selected IPv6 stateless autoconfiguration, which assigns a global address
based on network prefix and a device identifier. Although this address is unlikely
to change, if it does change, the system will stop functioning correctly.
We suggest you use static addressing instead.

Apply the changes?(y,n) [Y]: Y
Configuration saved successfully!
Applying...
Restarting network services...
Restarting NTP service...
Done.
Press ENTER to continue...{Enter}


After the previous step it’s time to get the new FP version on the FP module:

asasfr-boot>system install http://<ip address>/asasfr-sys-6.0.0-1005.pkg
   
Verifying.    .. 
Downloading.    ..   
Extracting.    ..  
Package Detail
Description:Cisco ASA-SFR 6.0.0-1005 System Install
Requires reboot:Yes 

Do you want to continue with upgrade? [y]: Y
Warning: Please do not interrupt the process or turn off the system.
Doing so might leave system in unusable state.


This really takes al long time. So don’t forget if you are performing this upgrade in a production environment to get an updateslot of at least three hours!
In my case it took 100 minutes before the FP module was in the UP state again.

Now you have to accept the new EULA en go trough the initial setup again.


Firewall# session sfr 
Opening command session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco ASA5506 v6.0.0 (build 1005)

firepower login: admin
Password: Admin123
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0

Copyright 2004-2015, Cisco and/or its affiliates. All rights reserved. 
Cisco is a registered trademark of Cisco Systems, Inc. 
All other trademarks are property of their respective owners.

Cisco Fire Linux OS v6.0.0 (build 258)
Cisco ASA5506 v6.0.0 (build 1005)

Last login: Wed Nov  2 16:08:16 UTC 2016 on cron
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0
You must accept the EULA to continue.
Press  to display the EULA: {Enter}
END USER LICENSE AGREEMENT

IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY.  IT IS VERY
IMPORTANT THAT YOU CHECK THAT YOU ARE PURCHASING CISCO SOFTWARE OR EQUIPMENT
FROM AN APPROVED SOURCE AND THAT YOU, OR THE ENTITY YOU REPRESENT
(COLLECTIVELY, THE "CUSTOMER") HAVE BEEN REGISTERED AS THE END USER FOR THE

--Output Removed for the Sake of Brevity - Press Space Bar (A LOT!)--

Please enter 'YES' or press  to AGREE to the EULA:  YES

System initialization in progress.  Please stand by.  
You must change the password for 'admin' to continue.
Enter new password: Password123
Confirm new password: Password123
You must configure the network to continue.
You must configure at least one of IPv4 or IPv6.
Do you want to configure IPv4? (y/n) [y]: Y
Do you want to configure IPv6? (y/n) [n]: N
Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]: {Enter}
Enter an IPv4 address for the management interface [192.168.45.45]: 
Enter an IPv4 netmask for the management interface [255.255.255.0]: 
Enter the IPv4 default gateway for the management interface []: 
Enter a fully qualified hostname for this system [firepower]: 
Enter a comma-separated list of DNS servers or 'none' []: 
Enter a comma-separated list of search domains or 'none' [example.net]: 
If your networking information has changed, you will need to reconnect.

For HTTP Proxy configuration, run 'configure network http-proxy'

Creating default Identity Policy.
Creating default SSL Policy.

Update policy deployment information
    - add device configuration
    - add network discovery
    - add system policy
    - add access control policy
    - applying access control policy

You can register the sensor to a Firepower Management Center and use the 
Firepower Management Center to manage it. Note that registering the sensor 
to a Firepower Management Center disables on-sensor Firepower Services 
management capabilities.

When registering the sensor to a Firepower Management Center, a unique 
alphanumeric registration key is always required.  In most cases, to register
a sensor to a Firepower Management Center, you must provide the hostname or 
the IP address along with the registration key.
'configure manager add [hostname | ip address ] [registration key ]'

However, if the sensor and the Firepower Management Center are separated by a
NAT device, you must enter a unique NAT ID, along with the unique registration
key.
'configure manager add DONTRESOLVE [registration key ] [ NAT ID ]'

Later, using the web interface on the Firepower Management Center, you must 
use the same registration key and, if necessary, the same NAT ID when you add 
this sensor to the Firepower Management Center.
> exit
Remote card closed command session. Press any key to continue.
 Command session with module sfr terminated.

Now login to your ASA via ASDM and you will see that your box is upgraded.

Advertisements

Connect to OSPF area 0 over GRE tunnel

We all know that all OSPF areas have to be connected to area 0. But sometimes you encounter
a situation where it is not possible to connect an area to area 0. This can happen because of
poor network design or because two or more networks merge together. There are several options
to deal with this problem. In the CCNP curriculum you learn that a virtual-link is the way
to go on this problem. But there is an other option which is not as popular, but in my opinion
is even more elegant. I’m talking about a GRE tunnel solution.

Let’s take the topology as shown in the picture below.

OSPF_GRE_TOPOLOGY

Router R2 is connected to R1 in area 0. R2 and R3 are connected in area 1 and R3 is connected
to R4 in area 2. Which means that R3 has no connection to area 0.

Below the configurations of routers R1 to R4 before the configuration of the GRE tunnel.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.100.100.254 255.255.255.0
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.100.100.0 0.0.0.255 area 0
!
R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 1
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.3 area 1
!
R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.3.1 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 1
network 10.0.1.0 0.0.0.3 area 1
network 10.0.3.0 0.0.0.3 area 2
!
R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.3.2 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.200.200.254 255.255.255.0
!
!
router ospf 10
router-id 4.4.4.4
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 2
network 10.0.3.0 0.0.0.3 area 2
network 10.200.200.0 0.0.0.255 area 2
!

To make this topology work there needs to be a connection from R3 to area 0. To make this happen
make the following configurations to router R2 and R3.

R2
!
interface Tunnel0
ip address 172.18.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 3.3.3.3
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!
R3
!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!

If you do a “show ip ospf neighbors” on R2 you can see there is a full neighborship between router
R2 and R3 in area 0.

show ip ospf neighbors R2-R3
And with the “show ip route” command you see the network from “area 2” is now in the table.

show ip route R2-R3
Now ping from PC1 to PC2 and this will succeed.

ping PC2-PC2

More interesting is a traceroute from PC1 to PC2, this will show the traffic is actually going
trough the GRE Tunnel!

traceroute PC1-PC2

Web Cache Communication Protocol (WCCP)

A customer implemented a transparant Cisco WSA (Ironport) for the redirection of the http and https traffic. WCCP had to be configured on their Cisco 3750 switch with IOS releas 12.2(55)SE9.
First some background info on WCCP:

The Cisco IOS WCCP feature allows utilization of Cisco Cache Engines (or other caches running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.
WCCP enables Cisco IOS routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a cache engine. The word “transparent” is this case means that the end user does not know that a requested file (such as a web page) came from the cache engine instead of from the originally specified server.
When a cache engine receives a request, it attempts to service it from its own local cache. If the requested information is not present, the cache engine issues its own request to the originally targeted server to get the required information. When the cache engine retrieves the requested information, it forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.
WCCP enables a series of cache engines, called a cache engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their cache engines to handle heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cache member to work in parallel, resulting in linear scalability. Clustering cache engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 cache engines to scale to your desired capacity.

I took the above text from the Cisco website, so if you want to read more on the theory behind WCCP check out: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf018.html

To configure WCCP on a Cisco 3750 there are some constraints:

  • Make sure SDM prefer is on an routing image
  • Forwarding can only be L2 (in the WSA this is default GRE or L2, configure it hard on L2 only)
  • Assignement method can only be MASK (in the WSA this is default HASH or MASK, configure it hard on MASK only)
  • Make sure clients and WSA are on different vlan’s
  • Forwarding redirect list can only understand PERMIT statements
  • When usig a dynamic WCCP identifier configure in the WSA the ports that have to be redirected, in this example it has to be 80(http) and 443(https)

Configuration will look like below:
First configure the routed vlan’s
!
vlan 100
name WSA
!
vlan 200
name Clients
!
int vlan 100
ip address 10.10.10.254 255.255.255.0
no shut
!
int vlan 200
ip address 172.18.10.254 255.255.255.0
no shut
!

Then configure the access-lists to “catch” the client traffic that has to be redirected:
!
ip access-list extended 100
permit tcp 172.18.10.0 0.0.0.255 any eq www
permit tcp 172.18.10.0 0.0.0.255 any eq 443
!
I used a numbered ACL, so I can debug it. A named list can’t be debugged! Make the ACL as specific as possible!

Then create an ACL for the redirect-list. This ACL consists of the WSA addresses.
!
access-list 10 permit 10.10.10.1
access-list 10 permit 10.10.10.2
!

The actual WCCP configuration consist out of two command.
A global command:
!
ip wccp 100 redirect-list 10
!

And a command on the client vlan interface:
!
int vlan 200
ip wccp 100 redirect in
!

There isn’t more to it. To check if WCCP is functioning use the “show ip wccp 100 [detail|view]” command.
To check a little deeper, use the “debug ip wccp packets” command. If you see the “WCCP2_HERE_I_AM” and “WCCP2_I_SEE_YOU” packets than the WCCP mechanism is functioning.
Even if WCCP functions it’s possible traffic does not get redirected. This can be due to a dozen of problems. First step is to check if the client traffic is redirect at all. This can be done by using the “debug ip packet detail 100” command. If no traffic hits the ACL, traffic won’t be redirected to the WSA.

Protect your network against HSRP attacks!

As in my earlier post, I’m writing a series of postings to help protect your network against attacks. A good hacker will always find a way to hurt your network. But with the recommendations described in this series of postings it will be more difficult for the hacker to find a way in.

In this post I will describe the hacking of HSRP operations and off course I will describe a solution to this problem.

As always I use GNS3. Below the topology and the configuration of multilayer switch R2.
topology

R2
!
interface FastEthernet0/0
switchport mode trunk
!
interface FastEthernet0/5
switchport access vlan 13
no cdp enable
!
interface Vlan10
ip address 10.0.0.253 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.253 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.253 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.253 255.255.255.0
standby 13 ip 192.168.80.254
!

HSRP
The cisco.com website explains HSRP as follows:

“HSRP is Cisco’s standard method of providing high network availability by providing first-hop redundancy for IP hosts on an IEEE 802 LAN configured with a default gateway IP address. HSRP routes IP traffic without relying on the availability of any single router. It enables a set of router interfaces to work together to present the appearance of a single virtual router or default gateway to the hosts on a LAN. When HSRP is configured on a network or segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among a group of configured routers. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not exist; it represents the common target for routers that are configured to provide backup to each other. One of the routers is selected to be the active router and another to be the standby router, which assumes control of the group MAC address and IP address should the designated active router fail.”

So in short, HSRP provides a virtual default gateway. And that’s the problem, when someone or something finds a way to hack into the HSRP operations it is possible to change the default gateway and reroute networktraffic or blackhole the networktraffic. This turns out to be very simple with Kali. Below a simple explanation how to change the behaviour of HSRP operations.

Start Kali, start yersinia, click the HSRP tab, choose to become active router, give in an ip address and that’s al there is:
hsrp_att

hsrp ip

 

When you have enable terminal monitor on your switch, you’ll see a state change
state change
Now check the HSRP settings with “show standby vlan 13” and you’ll see that the gateway has changed to 10.10.10.10
sh stand vlan 13

When you look closer to the config you’ll notice something else:
config change
For Yersinia to be able to take over the HSRP operations, it alters the config by entering a static entry to the mac address table!

Again this al there is to! To prevent this, make sure u use authetication on your HSRP interfaces as described in the following example:

First create a key-chain
key chain

 

Then configure the authentication on the vlan interface. If your are in a production network. First configure the standby unit, then the active unit. Otherwise the actions are disruptive!

 

stand auth

Now try the HSRP attack again and you’ll see it will not work this time!
stand vlan 13 auth

 

And to make it even more clear, when terminal monitor is enabled you’ll get the message depicted in the picture below
bad auth

 

 

 

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!

 

 

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

 

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