Archives for posts with tag: show

It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….

http://www.netcontractor.pl/blog/?p=371

RH

Advertisements

This lab is set up for the bootstrap protocol, for this to work we specify the candidate BSR router (C-BSR) and the candidate RP (C-RP). I have set the same router to provide both functions.
The command “ip pim bsr-candidate [interface] [0-32] [0-255]” sets the router as candidate BSR, the 0-32 is the hash mask value, and the 0-255 is the priority. The hash value can be used to distribute group addresses evenly among multiple C-RP. The next command needed is “ip pim rp-candidate [interface]” this allows the router to send candidate rp advertisements to the BSR.

BSR Topology

The C-BSR will send bootstrap messages to all PIMv2 on address 224.0.0.13, once the C-RP’s receive this they unicast their C-RP messages to the BSR. The BSR doesn’t select the RP it just lists them and the PIMv2 routers choose the RP. See the picture below from a packet capture the BSR sends the bootstrap message to all PIMv2 routers with the group and C-RP’s. This is how the Bootstrap Protocol differs from Auto-RP.

BSR Message

BSR Message

I’ve used an access-list in my example to show that we can distribute certain groups among multiple RP’s. For example I’ve only allowed this C-RP to become RP for the groups 232.1.1.1 and 232.4.4.4.

Attached are the config’s for each router (Router-Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Now let’s confirm configurations with some well-known commands

Run “debug ip pim bsr” from R3 this will show us the C-RP announcing to the BSR that it has 2 prefix’s and its IP address. Next the BSR sends out the message to set the RP for each of the RP’s prefix’s, it also sends the originating address.

*Mar 1 01:40 PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.10.10.3 priority 0, holdtime 150
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0): Send Candidate RP Advertisement to 10.10.10.3
*Mar 1 01:40 PIM-BSR(0): RP 10.10.10.3, 2 Group Prefixes, Priority 0, Holdtime 150
!
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): Bootstrap message for 10.10.10.3 originated

From R2 use the command “show ip pim rp mapping” this will show us the group address and the RP responsible for that group, also listed is via bootstrap. You may wonder what the (?) is for? All this means is that the router cannot resolve a DNS name for the IP.

Group(s) 232.1.1.1/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13
Group(s) 232.4.4.4/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13

From R3 run the command “show ip pim bsr”, this will show all the information regarding our bootstrap setup, including the BSR, C-RP, uptime and any ACL’s associated.

PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 10.10.10.3 (?)
Uptime:     01:46:19, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:45
Candidate RP: 10.10.10.3(FastEthernet0/0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:22
Group acl: 20

Generate some traffic from the source R1 to the groups listed then you can use the “show ip mroute” command from a PIM enable router and see the source tree entry.

(*, 232.4.4.4), 00:00:15/stopped, RP 10.10.10.3, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 15.15.15.3
Outgoing interface list: Null

(56.56.56.1, 232.4.4.4), 00:00:15/00:03:21, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 56.56.56.1
Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:00:15/00:03:16

RH

I will follow-up my notes with some labs over the coming weeks.

Enabled on the router with “ip multicast-routing
reserved range 224.0.0.0/4 for IPv4, FF00::/8 for IPv6

If multiple PIM routers on the same LAN only one can forward the join and prune messages to the RP, so there is an election on the Designated Router (DR) uses the highest IP.

PIM Dense-Mode – uses a push method to all routers and if no hosts need the stream the router prunes off, this repeats every 3 minutes so not ideal for a large deployments.

Bi Directional PIM – uses shared trees (*, G) , this is useful for large scale deployment saves the RP building multiple source tree entries. The emphasis on location of the RP is critical in this mode, to ensure loop free path there is a designated forwarder (DF) role, this is worked out by the lowest cost unicast path to the RP.

PIM Sparse-Mode – uses on demand mechanism, clients will send a join message. Requires a Rendezvous Point (RP) Initially the multicast source will send traffic and the RP will build the source tree (S,G), once a client requests the stream the RP builds the shared tree (*,G) and source receives the traffic, if there is a better unicast path to the source the router (RP)will build the source tree (show ip mroute) and begin using that path.

PIM Sparse Mode Message Process.

Uses 7 messages , Hello, Bootstrap, Candidate RP-advertisement, Join/Prune, Assert, Register, Register-Stop, Neighbour discovery uses hello messages on PIMv2 224.0.0.13

Source sends traffic to destination multicast address, first router will see this and send a PIM register to the RP, RP acknowledges with register-stop, the RP now has the (S,G) entry in mroute table

Receivers send an IGMP join to the LAN the Designated Router (DR) will send the PIM join message to the RP, each router adds the OIL (outgoing interface list)back towards the receiver for (*, G)

Once the receiver knows about the RP and the source knows about the receiver, they will look to then build the source tree (S,G) entry.

RPF- Reverse path forwarding.

Loop prevention method for multicast, checks the multicast source address against the unicast routing table to see if it should be coming from there if not it will drop the packets.

Rendezvous Point

Statically assign this on each router with command “ip pim rp-address x.x.x.x”, this must be done on each router participating in multicast.

Auto-RP – we use commands to assign the mapping-agent and the candidate RP, we could have redundant RP’s or limit each RP to a certain Multicast address with filtering using ACL’s
we use “ip pim send-rp-announce [interface] scope [0-255]” , the scope is the number of hops we allow this to travel or TTL. Once configured it will begin to send RP-Announce message to the 224.0.1.39 every 60 seconds

Next the mapping agent listens for RP-Announce messages from the C-RP’s and selects the RP’s. It then advertises the RP’s t the rest of the PIM domain RP-Discovery messages to 224.0.1.40 every 60 seconds. “ip pim send-rp-discovery [interface] scope [0-255] interval [seconds]”

We can change the intervals at which RP announce and discovery messages are sent out by using the interval command at the end of the command. Shown above.

Cisco use the “ip pim auto rp listener” command to overcome the sparse mode problem with routers adding the RP. Use this on non RP routers. This is known as the chicken and the egg scenario. You need multicast to run multicast.
This enables the sparse-mode interface to dense flood only the rp-annoucne and rp-discovery messages on 224.0.0.39 224.0.0.40 , enabling the RP to be elected on a sparse-mode network.

PIM BSR – Boot Strap Protocol – open standard compared to auto-rp , uses the all PIM routers address of 224.0.0.13 and TTL of 1. So we select the BSR using the command “ip pim bsr-candidate [interface]” next we can set the candidate rp using “ip pim rp-candidate [interface]”

When router is configured as candidate BSR it sets timer to 130secs then listens for other BSR candidate messages, it advertises its priority 0-255 and IP address, highest priority wins, and then begins sending out BSR messages every 60 secs. When a PIM router receives a BSR message it floods out all interfaces except the one it received it on, this ensures the rest of the multicast routers know who is the BSR.

Once the BSR is know the C-RP begins sending candidate-RP-advertisement messages to the BSR (unicast) they contain the priority 0-255, RP IP address and the Multicast group address for which the RP is an originator for.

Hash function is useful for large multicast deployments where lots of sources are used, when we use the hash feature the RP’s can be load-balanced, the BSR advertises advertise a hash mask in its messages and the receiving routers run the algorithm that can assign a consecutive number of group addresses to one C-RP then it will assign the next group to the next C-RP, much like a standard subnet mask would work. This is specified in the “ip pim bsr-candidate” command.

RPF with Tunnel – This is implemented when need to load-balance traffic over to equal-cost path’s but with the RPF this prevents load balancing over physical links. So for example we would build a tunnel between the two routers that pass traffic through the two links, using per-destination or per packet balancing. (no ip route-cache) on the interfaces. This used along with the ip mroute command should see it work

Source Specific Multicast – Defined in RFC 4607, enables you to identify a set of multicast sources not only by group address but the sources as well, the SSM group is called a channel this is identified using the (S,G) the reserved group address’s for SSM 232.0.0.0/8 and the IPv6 range FF3x::/32.
SSM channel is defined by a source and a group address so multiple sources can be assigned to the same group for examples. (10.100.5.24 , 232.5.5.5) then (10.100.15.60 , 232.5.5.5) this is a unique channel for each multicast group. Hosts will only receive traffic from the requested sources. Can help to protect against DOS attacks.

No RP is needed in this mode as Source Trees are built directly towards the source, because the source is already known. This uses the unicast routing table for forwarding decisions, The multicast source must be manually inputted in advance.

Enabled with “ip pim ssm default” also relies on IGMPv3 so “ip igmp version 3” this command is used at interface level

IGMP – Internet Group Management Protocol

IGMP is the protocol that functions between the hosts, it allows the router to know that a host is interested in the receiving the multicast stream for specific group.

Routers acts as a querier checking to see if host are still interested in a stream, on a LAN segment when more than one router exists.

IGMP is enabled when PIM is enabled has a TTL of 1 and are restricted to the LAN

IGMP 1 – RFC 1112, sends IGMP queries to 224.0.0.1 (all-hosts multicast address) has no election as the IGMP querier, only one host per multicast address replies to the query all other suppress, no mechanism to leave the group. could take up to 3 minutes after the client has stopped listening before the traffic flow will stop.

IGMP 2- RFC 2236, querier election mechanism based on IP address ensures one router per segment sends IGMP.leave group message host send message to leave group when no longer requires the traffic. Leave latency reduced when compared to V1, when a host wants to leave the multicast stream is sends the leave message to 224.0.0.2 (all routers multicast)

IGMP 3 – This version added support for SSM (source specific multicast) which allows for the client to not only specify the group they want to subscribe to but also the source of that traffic (useful if there are many sources in the same group).

 

Well Known Multicast Address

————————————————————-

224.0.0.1 All host group which contains all devices on the same network

224.0.0.2 All multicast routers group which contains all routers on the same network PIMv1

224.0.0.5 All OSPF

224.0.0.6 All OSPF DR

224.0.0.10 EIGRP

224.0.0.13 PIM v2 all PIM routers multicast address.

224.0.0.22 IGMP Version 3

224.0.1.39 Cisco Auto-RP-Announce address

224.0.1.40 Cisco Auto-RP-Discovery address

MSDP – Multicast Source Discovery Protocol

Purpose is to discover multicast sources in other PIM domains, what happens is your own RP’s exchange information with RP’s in other domains. Just like BGP each peer must be explicitly configured. When a PIM DR registers a source with the RP, the RP sends out a SA (Source Active) message to all its MSDP peers.

SA message contains.
Address of the source
group address to which the source is sending
Originating IP

Uses TCP port 639 for peering connections

Every MSDP peer that receives a Source Active message floods those downstream to its own peers from the originator. If the RP receives more than one copy of a SA, the RP will consult the BGP next hop database to determine the next hop towards the SA originator. If AS is non-transit or stub the consult of BGP next hop database still applies to override this we use the command “ip msdp default-peer” so RPF checks are not necessary. One path – no possible loops.

MSDP Mesh Groups are used effectively when multiple RP’s are present in a single domain sources always register to certain RP’s but members must find any source. Every RP has a peering to all other RP’s in the domain. Mesh groups are configured with the command “ip msdp mesh-group [WORD] [IP address]”

SA-Filter

Inbound – here is an example of an inbound SA from msdp 10.255.255.3, only allows SA messages for group 239.8.8.8 from the source 74.74.74.5.
access-list 101 permit ip host 74.74.74.5 host 239.8.8.8
ip msdp sa-filter in 10.255.255.3 list 101

Outbound – here is an example of an outbound SA filter which only sends SA messages to peer 10.255.255.1 from specific group 232.4.4.4 from source 74.74.74.5
access-list 102 permit ip host 74.74.74.5 host 232.4.4.4
ip msdp sa-filter out 10.255.255.1 list 102

Locally originated sources can be filtered with the command same idea as above.
ip msdp redistribute list xxx

ANYCAST – RP

A simple explanation of anycast is packets can be sent to a single IP and any number of devices can respond. When PIM-SM is brought into the mix what this means is we can map a single group to multiple RP’s all with the same “virtual IP” we cannot achieve this without MSDP.

 

RH

This command might save you from a whole world of trouble!

For example you’ve got a scheduled change coming up on your WAN router that’s a little risky, you might just cut yourself off from the router half way through the change…….. what do you do to mitigate this risk?

Well if you don’t have OOB (out-of-band) access to the router you would use the following command

#reload in 20

What this does is reload the router in 20 minutes reverting back to the last saved config. So if you’ve been cut off just wait the time you’ve specified and the router will reload with the old config.

To confirm how much time you have before a reload use the command

#show reload

Once you’ve completed your changes and they are successful just issue the command

#reload cancel

Also used to schedule a reload is the command

#reload at 09:45

This reloads your router and the time you specify but obviously relies your NTP settings to be correct so check this first.

Plan ahead!!

RH

“When I’m asked by Cisco TAC to send them a #show tech-support it gives me too much information to copy to a text file?” “how can I output that information to a text file without using copy and paste?”

There is a few ways you can do this, but are not limited to just below.

1. Redirect the file to tftp, ftp, http, flash etc.

#sh tech-support | redirect tftp://192.168.1.1/tech-support.txt

2. Set your terminal session to record ( I use putty, in my example this will output everything you do to a text file)

Capture1

Once you have set your telnet program to log you should use the command “terminal length 0″ what this does is save you having to hit the space bar to display the full config, by default the terminal length is 24 lines. On a cisco ASA the command is “terminal pager 0”

As you can see this is pretty simple stuff, but if you don’t know then you might pull a few hairs out trying to copy and paste!!!

.
Watch out for yourself!

RH