Asa pixfwsm multicast tips and common problems
Upcoming SlideShare
Loading in...5
×
 

Asa pixfwsm multicast tips and common problems

on

  • 917 views

Asa pixfwsm multicast tips and common problems

Asa pixfwsm multicast tips and common problems

Statistics

Views

Total Views
917
Views on SlideShare
917
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Asa pixfwsm multicast tips and common problems Asa pixfwsm multicast tips and common problems Document Transcript

  • ASA-PIX/FWSM: Multicast Tips and Common Problems The purpose of this document is to provide assistance to everyone in configuring and troubleshooting multicast through the firewall. This document is meant to be interpreted with the aid of the official documentation from the configuration guide located here: ASA:http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/rou te_multicast.html FWSM:http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/gui de/ip_f.html#wp1041648 PIX:http://www.cisco.com/en/US/docs/security/pix/pix63/configuration/guide/bafw cfg.html#wp1170913 The Cisco TAC has created another ASA Multicast Troubleshooting and Common Problems guide and posted it to Cisco.com: http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080b efd2a.shtml Support: ASA supports igmp forwarding, sparse mode, and bidirectional mode. There is no sparse-dense-mode support. ASA forwards auto-rp packets (unless configured to not to). ASA itself requires static auto-rpconfig. Configuring multicast: Pls. follow this link: http://www.cisco.com/en/US/products/ps6120/products_configuration_example091 86a00807631d2.shtml Shared tree and Source specific tree: I read once that Multicast is like dating service. Sender starts the stream and the DR on the local LAN registers the sender with the dating service (RP). Reciever sends IGMP report and the DR on that local LAN segment sends a PIM join towards the RPshared tree. Once the dating service connects the two - sender and receiver, then they can talk via the shortest path and do not have to go through the dating service shared tree anymore. Where to add these commands: igmp join-group: This command when applied under the interface, sends a join for the group address. Think of this as a permanent receiver for the group. This comes in handy when the receivers off of the interface do not send igmp reports in a regular interval. This command makes the firewall to accept and forward the multicast packets. Configuring the firewall to join a multicast group causes upstream routers to
  • maintain multicast routing table information for that group and keep the paths for that group active. Where to add this command: This command needs to be configured under the interface config mode facing the receivers. hostname(config-if)# igmp join-group group-address igmp static-group: The firewall does not accept the multicast packets but rather forwards them to the specified interface. To configure the security appliance to forward the multicast traffic without being a member of the multicast group, use the igmp static-group command. When this command is added, the ASA sends out an IGMP report out the interface sourcing with its IP address on the interface. Where to add this command: This command needs to be applied under the interface configfacing the receivers. hostname(config-if)# igmp static-group group-address igmp forward interface: Where to add this command: This command when applied under the interface config facing the receivers. This command will forward all the igmp reports received on the interface towards the interface where the server is located. This command cannot be configured along with PIM. hostname(config-if)# igmp forward interface outside Terminology: What is a first hop router: A first hop router is the router that is connected to the source which is responsible for registering the source with the RP. If there are two routers connected to the same segment as the source then the one that is the DR (designated router) for that LAN segment will take care of the registering process. Now, if one of the two is the firewall and you want the firewall to take care of the registration process because the RP is on the other side of the firewall then, the firewall should be DR for that LAN segment. What is a last hop router? A last hop router is the one that is connected to the receiver. Again if there are two or more routers in the LAN connected to the receiver, the router which is the DR is the one that is resonsible to connect the receiver to the shared tree. If one of the devices is the firewall then, if we want the firewall to process the igmp reports then it has to be the DR with a higher priority.
  • OIL: OIL stands for Outgoing Interface List. OIL is always taken from the (*,G) and copied as the OIL for the (S,G). In coming interface and outgoing interface for (*, G): Incoming interface for the (*, G) is always towards the RP. Outgoing interface is towards the receiver. In coming interface and outgoing interface for (S, G): Incoming interface for (S,G) is always towards the source. Outgoing interface is towards the receiver. DR - How to increase the pim priority: The following example sets the DR (Designated Router) priority for the interface to 5: hostname(config-if)# pimdr-priority 5 PIM Chart: (*,G) (S,G) When it is created By receipt of IGMP Membership report from directly-connected Receiver (host) Dynamically created when an (S,G) entry must be created. By receipt of (S,G) PIM join By receipt of Multicast packet OIL info Interface that received IGMP membership report Interface that received PIM (*,G) Join Manually configured If none of the above, "NULL" Interface that received a PIM (S,G) join Cop of (*,G) OIL except when matching (S,G) IIF Otherwise "NULL" RPF info IP address of next-hop neighbor towards RP according to unicast routing table. If on the RP itself then "NULL" IP address of next-hop neighbor towards the Multicast Source If directly connected to Multicast Source then 0.0.0.0 IIF Info Interface that leads to RP according to unicast routing table If on the RP itself then "NULL" Interface that leads to Multicast Source according to unicast routing table. when (S,G) entry expires When notified by the IGMP After 210 sec. if no multicast packets or PIM When entry this is
  • deleted? process that all members for a group are gone. By receipt of PIM (*,G) Prune message from downstream neighbor. register messages received from SPT. When (*,G) entry deleted. How to interpret the "shmroutex.x.x.x" Sample 1: Topology: Receiver--RP---(INT_SCI/8)ASA(INT_MANDAT/0)--(10.2.112.9)source Group address: 239.252.1.10 ASA#shmroute 239.252.1.10 Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires (10.2.112.9, 239.252.1.10), 00:10:48/00:03:11, flags: SFT Incoming interface: INT-MANDAT RPF nbr: 10.2.112.9, Registering Outgoing interface list: INT-SCI, Forward, 00:10:48/00:03:29 Tunnel0, Forward, 00:10:48/never There is no *, G which indicates that the receiver hasn't requested the feed yet. Only the source has started and the source lives behind the interface named INT-MANDAT. "F" - is the Register Flag. Meaning the firewall hasn't seen a register stop message from the RP yet. The "Tunnel0" interface is a transient state and goes away once the register stop is received. RP lives behind the INT-SCI interface. Sample 2: RPF neighbor all zeros means that the ASA is the first hop router connected local to the sender. When you see the "T" flat you can jump in joy. This mean the shortest path tree has formed and multicast traffic is being received by the receiver. Topology: receiver--(inside)ASA(outside)--sender ASA#shmroute 230.0.0.10
  • (*, 230.0.0.10), 00:08:20/never, RP 0.0.0.0, flags: SCL (Connected Local LAN) Incoming interface: Null -----> receiver is directly connected RPF nbr: 0.0.0.0 Immediate Outgoing interface list: ------> receiver is off of the inside interface inside, Forward, 00:08:20/never (10.135.152.47, 230.0.0.10), 00:08:16/00:03:13, flags: SJT (shortest Path Tree - T) Incoming interface: outside ------> source is on the outside interface. RPF nbr: 0.0.0.0 Inherited Outgoing interface list: inside, Forward, 00:08:20/never ------> receiver is off the inside interface. Sample 3: Topology: sender(172.25.1.11)--RP(172.20.50.254)--vlan50--nonpci(0)ASA(0)WLAN--vlan30--Re ceiver(172.20.30.133) same security level - 0 Group add 225.4.5.7 ASA#shmroute 225.4.5.7 (*, 225.4.5.7), 01:08:42/never, RP 172.20.50.254, flags: SCLJ Incoming interface: nonpci ------> (routing table shows intnonpci towards the RP) RPF nbr: 172.20.50.254 Immediate Outgoing interface list: ------> (receiver is off the interface WLAN) WLAN, Forward, 01:08:42/never (172.25.1.11, 225.4.5.7), 00:04:59/00:03:00, flags: SJT Incoming interface: nonpci ------>(routing table shows intnonpci for the source) RPF nbr: 172.20.50.254 Inherited Outgoing interface list: WLAN, Forward, 01:08:42/never------> (receiver is off the interface WLAN) How to interpret the "shmfibx.x.x.x" Sample 1: Topology: (10.204.125.81)R1-------(10.204.125.85/OUT)***ASA***(IN/172.25.250.11)-R2(172.2 5.250.1)--receiver. I -------------| | Sender-10.29.95.133 RP-10.29.95.252
  • Group address: 233.49.81.127 Source or source is on the lower security interface and the receiver is on the higher security interface. It is very important to see the "F" flag so indicate that the ASA is forwarding multicast traffic. ASA5520-01# shmfib Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag, AR - Activity Required, K - Keepalive Forwarding Counts: Pkt Count/Pkts per second/AvgPkt Size/Kbits per second Other counts: Total/RPF failed/Other drops Interface Flags: A - Accept, F - Forward, NS - Negate Signalling IC - Internal Copy, NP - Not platform switched SP - Signal Present Interface Counts: FS Pkt Count/PS Pkt Count (*,233.49.81.127) Flags: C K Forwarding: 0/0/0/0, Other: 846486/2/846484 OUT Flags: A NS ----> We are accepting packets on the outside interface inside Flags: F NS ---> We are forwarding packets to the inside interface. Pkts: 0/0 (10.29.95.133,233.49.81.127) Flags: K Forwarding: 1/0/36/0, Other: 0/0/0 OUT Flags: A inside Flags: F NS Pkts: 0/1 Sample 2: Topology: receiver--(inside)ASA(XETRA)--router--N/W-RP-Source source: 193.29.93.62 Group address: 224.0.46.0 ASA5520-01# sh conn UDP XETRA 193.29.93.62:25100 inside 224.0.46.0:55199, idle 0:00:00, bytes 2649468, flags ASA5520-01# shmfib 224.0.46.0 193.29.93.62 Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag, AR - Activity Required, K - Keepalive
  • Forwarding Counts: Pkt Count/Pkts per second/AvgPkt Size/Kbits per second Other counts: Total/RPF failed/Other drops Interface Flags: A - Accept, F - Forward, NS - Negate Signalling IC - Internal Copy, NP - Not platform switched SP - Signal Present Interface Counts: FS Pkt Count/PS Pkt Count (193.29.93.62,224.0.46.0) Flags: K Forwarding: 18629/10/1295/105, Other: 4716/0/4716 XETRA Flags: A F ---> XETRA interface is where the source is and we Accept packets from. Pkts: 0/0 inside Flags: F NS ---> inside interface is where the receiver is where we Forward the packets to. Pkts: 1598/2 Common Problems: Syslog 106010: Topology: receiver---(inside)FWSM(outside)---sender (10.11.21.10) group add: 239.226.16.3 %FWSM-3-106010: Deny inbound udpsrc OUTSIDE:10.11.21.10/1450 DMZ-EMP90:239.226.16.3/30120 dst With nat-control enabled on the FWSM the above issue can be corrected with the following: nat (inside) 0 access-list 101 access-list 101 permit ip host 239.226.16.3 host 10.11.21.10 Think of the above as the source when sends out multicast packets the destination is the multicast address 239.226.16.3 and is destined towards the inside. Even though no traffic will be sourced from a multicast address, we just need to provide translation for the reverse flow from high security to low security. If this case were an ASA we would see the following in asp drop captures 1. ASA was dropping all the multicast packet for the reason below: union-asa# sh cap capasp | i 239.0.1.2 38: 12:07:56.782689 10.80.8.38> 239.0.1.2: icmp: echo request Drop-reason: (no-mcast-intrf) 2. nat 0 with acl was configured on this ASA and it didn't allow exemption for our
  • group 239.0.1.2. Once I added that flow reached the other ASA2 and we saw *,g as well as s,g mfib limit (5000) reached: "shmfib<group-address>" may not show any output. This may due to the fact that the mfib entries max limit may have been reached. This ENH request CSCtj22365 is filed so, that when resolved, the FWSM will send a syslog message indicating that the max mfib entry limit has been reached. fwsm# shmfib sum IPv4 MFIB summary: 5000 total entries [4974 (S,G), 23 (*,G), 3 (*,G/m)] 190440 total MFIB interfaces Failed to locate egress interface: Oct 23 2010 21:40:44: %ASA-6-110002: Failed to locate egress interface for UDP from outside:10.135.152.47/1034 to 230.0.0.10/7060 Look for contradicting lines in the config. In this case where does the sender live on the inside or outside? static (inside,outside) 10.135.152.47 10.135.152.47 net 255.255.255.255 mroute 10.135.152.47 net 255.255.255.255 outside In the above case we had to remove the static and "toggle" multicast-routing on the ASA. HSRP: Let us say that the RP is a loop back address configured on a pair of routers running HSRP. We need to make sure the mroute configured on the firewall points to one of the physical IP addresses and not the HSRP address. When we issue "shpimint<name>" , the firewall only forms neighbor relationship with the physical IP addresses and not the HSRP address. Also, we cannot configure mroute to both the physical IP addresses. There is no redundancy when it comes to multicast. Pls. read this link for further explanation: http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aa b.shtml TTL (Time to Live Value) too low or set to 1: When a router forwards a multicast packet from one interface to another, it decrements the Time To Live (TTL) value in the IP header by one. The firewall does not decrement the TTL value in the IP header but, still it will drop the packet if the TTL is set to 1. It sends the packet only if the resulting TTL value is not zero and is greater than the multicast TTL threshold value of the outgoing interface when
  • configured. If a multicast application on the source allows the setting of a TTL value and results in not matching the mentioned criteria, the packets are dropped by the router. The multicast source needs to set the TTL value as there are number of hops between the source and the receiver. Multicast TTL threshold: http://www.cisco.com/en/US/customer/tech/tk828/technologies_tech_note09186a 0080094b55.shtml#ttlsetting Multicast TTL value too low or set to 1: http://www.cisco.com/en/US/customer/tech/tk828/technologies_tech_note09186a 0080094b55.shtml#ttlthreshold Multlicast over VPN tunnel: ASA/PIX will not pass multicast traffic over IPsec VPN tunnels. Only unicast traffic over VPN tunnel is supported. The alternative option is to use GRE between two end points on either side of the tunnel and send multicast over GRE and encrypt that traffic and send it over the tunnel. FP no mcast output intrf R1(receiver)--(inside)ASA(outside)---R3(rp/sender) Group 239.1.1.1 "capturecapasptyps asp-drop all" may show the following: ASA1# sh cap capasp | i 239.1.1.1 18: 14:52:02.979731 10.7.123.3.64281 > 239.1.1.1.5000: udp 16 Drop-reason: (no-mcast-intrf) FP no mcast output intrf Here is the command reference link to shasp-drop: Name: no-mcast-intrf FP no mcast output intrf: All output interfaces have been removed from the multicast entry. - OR The multicast packet could not be forwarded. Recommendation: Verify that there are no longer any receivers for this group. - OR Verify that a flow exists for this packet. Syslogs: None
  • In this case R1 being the receiver was also the DR for that segment so, the ASA did not do anything with theIGMP reports that it received. In this case making the ASA as the DR resolved the issue. Debug pim group x.x.x.x shows Assert processing message wins Topology: Group address 239.1.1.247 vlan13 - INSIDE vlan300 - OUTSIDE FWSM (10.20.213.1)----vlan 13----FWSM---vlan300--RTR----RP---Sender (172.16.41.205) | Receivers (10.20.213.204)----| | ASA(10.20.13.2)----| IGMP reports from the receivers arrive on the FWSM but, the FWSM doesn't send PIM join up to the RP. The egress multicast packets do not show the joins due to CSCsf31515 Debug pim group 239.1.1.247 showed the following: IPv4 PIM: (172.16.41.205,239.1.1.227)RPT J/P adding Prune on OUTSIDE IPv4 PIM: (172.16.41.253,239.1.1.227)RPT J/P adding Prune on OUTSIDE IGMP: Received v2 Report on INSIDE from 10.20.213.201 for 239.1.1.227 IGMP: Updating EXCLUDE group timer for 239.1.1.227 IPv4 PIM: (172.16.41.205,239.1.1.227) Received [15/110] Assert from 10.20.13.2 on INSIDE IPv4 PIM: (172.16.41.205,239.1.1.227) Assert processing message wins IPv4 PIM: (172.16.41.205,239.1.1.227) INSIDE Update assert timer (winner 10.20.13.2) FWSM (backup site) ASA (production site) FWSM and ASA though configured to be on the same vlan, were not supposed to see each other. The problem is that the FWSM saw the presence of the ASA but the ASA didn't see the presence of the FWSM. FWSM was DR on VLAN 13 and the ASA was DR (since it did not see the FWSM) as well. Both tried to process multicast packets and ended in a race condition and the Assert messages and winner indicated that. Troubleshooting commands: On the Firewall: shpim neighbor shigmp interface
  • shigmp traffic shmroutex.x.x.x shmfibx.x.x.x debugpim group x.x.x.x debugigmp group x.x.x.x On the Router: shippim interface shipmroutex.x.x.x shipigmp group debugippim ---Doc Reference from https://supportforums.cisco.com/docs/DOC-12943 More Cisco and Networking Tips you can visit: http://blog.router-switch.com/category/networking-2/