Haben Sie heute Morgen, als Sie sich fertig gemacht haben, um zur Arbeit zu gehen, einen Moment innegehalten und nachgedacht, wie stark Ihr Leben bisher von Krieg beeinflusst wurde Aller Wahrscheinlichkeit nach nicht. Die USA waren seit über 50 Jahren nicht mehr in einen Weltkrieg verwickelt. Dennoch haben unzählige Dinge des täglichen Gebrauchs ihren Ursprung in Erfindungen, die ursprünglich für kriegerische Einsätze vorgesehen waren - von Haarbürsten bis hin zur Mikrowelle. Auf der einen Seite bringt Krieg schreckliche Massaker, Krankheiten und Leiden. Auf der anderen Seite hat er einige der größten Erfindungen ermöglicht, die die Welt je gesehen hat. Forschungs- und Entwicklungsarbeit für Rüstungszwecke hat nicht nur das Kommunikations- und Transportwesen, sondern auch die Medizin revolutioniert. Sie hat Erfindungen hervorgebracht, die der Menschheit zugute kommen und sich für den alltäglichen Gebrauch eignen. In Kriegszeiten ziehen alle an einem Strang und arbeiten auf ein gemeinsames Ziel hin, wissenschaftliche Ziele stehen über Konkurrenzdenken, und finanzielle Mittel und Personal stehen in Hülle und Fülle zur Verfügung. Einige Erfindungen werden aus der Not geboren, wie beispielweise Margerine aufgrund der Nahrungsmittelknappheit an der Heimatfront. Einige stammen direkt von zerstörenden Waffensystemen ab (Atomkraft), andere wiederum von Verteidigungstechnik (Mikrowelle). Die Ironie des Krieges ist, dass die gleiche Wissenschaft, die zum Töten Abertausender von Menschen erfunden wurde, heute eingesetzt wird, um Leben zu retten. Vom Handy bis zum Haarspray - der Bezug zum Krieg ist in unserem täglichen Leben allgegenwärtig. ‘Erfunden im Krieg’ verfolgt einen Tag im Leben einer ganz normalen Frau und untersucht, inwieweit ihr Leben von Kriegserfindungen beeinflusst wird.
The easiest way to display BGP routes originating in the local autonomous system is to use the regular expression ^$ (empty AS-path) in the show ip bgp regexp command, for example:
PE-A#show ip bgp regexp ^$
BGP table version is 10, local
router ID is 10.0.1.1
Status codes: s suppressed, d damped, h history,
* valid, > best, i - internal,
r RIB-failure, S
Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop Metric LocPrf Weight Path
*> 10.0.1.1/32
0.0.0.0 0 32768 i
r>i10.0.1.2/32
10.0.1.2 0 100 0 i
If you want to apply a show filter to the printout of this command, you have to use the quote-regexp variant; otherwise the rest of the line is interpreted as regular expression. To skip the header explaining the BGP status code (we know them by heart by now, don’t we?), use …
PE-A#show ip bgp
quote-regexp "^$" begin Network
Network Next Hop Metric LocPrf Weight Path
*>
10.0.1.1/32 0.0.0.0 0 32768
i
r>i10.0.1.2/32 10.0.1.2 0 100 0
i
… and end with the eye candy – define this command as an alias: alias exec localbgp show ip bgp quote-regexp "^$" begin Network.
If you use multiprotocol BGP (MP-BGP) in your network to support MPLS VPN, IPv6 or IP Multicast over BGP, it's best if you go all the way and configure an explicit ipv4 address family; the resulting BGP configuration is significantly easier to read and understand as the session-specific parameters are clearly separated from the routing-specific parameters and the IPv4 settings are nicely grouped in an explicit section.
To change the format of the BGP configuration, configure the IPv4 address family with the address-family ipv4 unicast router configuration command (the neighbor statements and other configuration settings pertinent to IPv4 configuration are automatically moved into the new address family) or manually activate a BGP neighbor for IPv4 route exchange with the neighbor activate router configuration command.To illustrate the differences between the traditional BGP configuration and the per-address-family configuration, consider a simple MPLS VPN+Internet setup. First the traditional approach:
router bgp 65000
template peer-policy Internal
send-community both
exit-peer-policy
!
template peer-session
Internal
remote-as 65000
update-source Loopback0
exit-peer-session
!
no synchronization
bgp
log-neighbor-changes
network 10.0.1.1 mask 255.255.255.255
neighbor 10.0.1.5 inherit peer-session Internal
neighbor 10.0.1.5
description PE-C(RR)
neighbor 10.0.1.5 inherit peer-policy
Internal
no auto-summary
!
address-family vpnv4
neighbor
10.0.1.5 activate
neighbor 10.0.1.5 send-community extended
exit-address-family
... and the changed configuration after the address-family ipv4 command has been entered:
router bgp
65000
template peer-policy Internal
send-community both
exit-peer-policy
!
template peer-policy InternalV6
send-label
inherit peer-policy Internal 1
exit-peer-policy
!
template peer-session Internal
remote-as 65000
update-source Loopback0
exit-peer-session
!
bgp
log-neighbor-changes
neighbor 10.0.1.5 inherit peer-session
Internal
neighbor 10.0.1.5 description PE-C(RR)
!
address-family ipv4
no synchronization
network 10.0.1.1 mask
255.255.255.255
neighbor 10.0.1.5 activate
neighbor 10.0.1.5
inherit peer-policy Internal
no auto-summary
exit-address-family
!
address-family vpnv4
neighbor 10.0.1.5
activate
neighbor 10.0.1.5 send-community extended
exit-address-family
I was browsing the Google AJAX Search API blog recently when I discovered they were using an interesting widget at the bottom of the page, it turned out to be PartnerBar. PartnerBar was created as an example for the Google AJAX Feed API. I have been very busy with family stuff recently so I managed to completely miss this when news of it first broke in December (Ajax Feed Partner Bar and The PartnerBar - Contextual Cross Linking). In my defence this is easy to miss, it is called "PartnerBar", which means nothing to anybody on this side of the pond and the launch article talks about "contextual cross linking" (meaningless technobabble!). Essentially, PartnerBar is a feed aggregating magic javascript widget thingy, if it had been launched as such I would have spotted it sooner.
AnywayI have been playing with it recently and have made some minor tweaks to improve it for my own usage, I'm very happy with the results. I can't decide whether to install the resulting widget permanently on my blog because I think people would find it annoying if I were to place it somewhere prominent.
My tweaks and modifications
Feed titles and links.
In the instance of PartnerBar on their blog, Google store an array of their blogs in a JavaScript file: http://www.google.com/uds/solutions/partnerbar/google-blogs.js.
Incidentally, notice how it supports tags so that you can use the same array for multiple widgets with distinct content.
My first modification was to tweak the code so that I did not have to supply the feed name and link, this information is stored in the feed (why store it twice?). To achieve this I overrode the loadPartner method - I think the trick with overriding methods in JavaScript is to make sure the method you override is a small one!
My array of blogs looks like this: blogs.js
Alternating row colours
Secondly, I wanted the feed entries to display in alternating colours. Again, I found a small JavaScript method in PartnerBar (resetClassOnPartnerDom) and overrode it (AFAIK there is no "super" keyword in JavaScript, which is a shame). In order to do this I made use of a getElementsByClassName method that I found on the web.
Final result
You should be able to see the widget in action at the top of this blog entry. However, you can link out to see the final result in standalone glory here.
Hereis my final JavaScript which my customised widget uses: partnerBar.js.
Design
Although I suffer with CSS, I am not a graphic designer and so I tend to
stealgather inspiration from elsewhere. I based my widget on the Infected table theme from the CSS table gallery.
Erfolgsgeschichte Mobiltelefon
IEEE 802.1X for Wired Networks and Internet Protocol Security with Microsoft Windows (Microsoft Whitepaper)
This white paper examines and compared 802.1X for wired networks and IPsec.
Download:
8021X_IPsec.doc, 2/6/2008, version 1.1
Overview:
Microsoft Windows Server 2003 and Windows XP support both the IEEE 802.1X standard for wired networks and the Internet Protocol security (IPsec) Internet standard. The IEEE 802.1X standard for wired networks provides authentication and authorization protection at the network edge where a host attaches to the network. IPsec provides peer authentication and cryptographic protection of IP traffic from end-to-end. This white paper describes the security and capabilities of 802.1X for wired networks and IPsec based on industry standards and their support in Windows Server 2003 and Windows XP, and provides comparison information when evaluating deployment of these security technologies.
related resources @ Microsoft
IPsec Web site
Network Access Protection Web site
Extensible Authentication Protocol Web site
Deployment of IEEE 802.1X for Wired Networks Using Microsoft Windows
see also:
Step-by-Step Guide: Demonstrate NAP IPsec Enforcement in a Test Lab
Stateful Failover for IPSec (Cisco Systems)
Stateful failover for IP Security (IPSec) enables a router to continue processing and forwarding IPSec packets after a planned or unplanned outage occurs. Customers employ a backup (secondary) router that automatically takes over the tasks of the active (primary) router if the active router loses connectivity for any reason. This process is transparent to the user and does not require adjustment or reconfiguration of any remote peer.
Stateful failover for IPSec is designed to work in conjunction with stateful switchover (SSO) and Hot Standby Routing Protocol (HSRP). HSRP provides network redundancy for IP networks, ensuring that user traffic immediately and transparently recovers from failures in network edge devices or access circuits. That is, HSRP monitors both the inside and outside interfaces so that if either interface goes down, the whole router is deemed to be down and ownership of Internet Key Exchange (IKE) and IPSec security associations (SAs) is passed to the standby router (which transitions to the HSRP active state). SSO allows the active and standby routers to share IKE and IPSec state information so that each router has enough information to become the active router at any time. To configure stateful failover for IPSec, a network administrator should enable HSRP, assign a virtual IP address, and enable the SSO protocol.
Downloads:
Stateful Failover for IPSec (pdf)
Certifies expert-level knowledge of networking across various LAN and WAN interfaces, and a variety of routers and switches.
Certifies expertise with specific security protocols and components, as well as IP and IP routing.
Filtered Index Design Guidelines (SQL Server 2008, MSDN)
A filtered index is an optimized nonclustered index, especially suited to cover queries that select from a well-defined subset of data. It uses a filter predicate to index a portion of rows in the table. A well-designed filtered index can improve query performance, reduce index maintenance costs, and reduce index storage costs compared with full-table indexes.
Filtered indexes can provide the following advantages over full-table indexes:
Worm Mitigation Technical Details - Cisco Systems
Sinkholes
A sinkhole is a multifaceted security tool-essentially, a portion of the network that is designed to accept and analyze attack traffic. Sinkholes were originally used by ISPs to engulf attack traffic, in many cases drawing attacks away from a customer or other target. In more recent times, sinkholes have been used in enterprise environments to monitor attacks, detect scanning activity from infected machines, and generally monitor for other malicious activity.
This document illustrates how a sinkhole can be used in diverting attack traffic, monitoring for worm propagation, and monitoring other potentially malicious traffic.
Traditional Sinkhole - Diverting Attack Traffic
In the first sinkhole application, a publicly accessible Web server is the target of either a DoS or DDoS attack. Figure 1 illustrates how server WWW1 is unavailable due to the attack. Additionally, the extremely high traffic volume has saturated links and routers, making server WWW2 unavailable as well.
The Attack
The Diversion
Monitoring for Worm Propagation
Backscatter Traffic
First Sinkhole Design Option
Second Sinkhole Design Option
Routing Techniques
Again using an attack scenario as an example, there are many cases where it will not be desirable or feasible to shift the attack stream to a sinkhole. In these cases, it might be preferable to simply drop the stream as close to ingress as possible.
As such, a technique called remote-triggered black hole routing (also known as remote-triggered black hole filtering) can be used. Although the technique was originally developed for dealing with attacks in ISP environments, it can also be used effectively in an enterprise network for preventing worm spread. Additionally, this technique can be used for "black holing" any internal hosts participating in outbound DoS attacks, in the event that a host (such as a roaming laptop) has been compromised in this way.
This technique performs multiple functions:
To explain the technique, we will initially illustrate how it is used to mitigate an Internet-based DoS or DDoS attack. We will then explain how it can be adapted in an enterprise network.
Black Hole Routing
Remote-Triggered Black Hole Routing
Configuration for Announcing Prefixes to Send to Black Hole
router bgp 999
...
redistribute static route-map STATIC-TO-BGP
...
!
route-map STATIC-TO-BGP permit 10
match tag 66
set ip next-hop 192.0.2.1
set local-preference 50
set community no-export 999:000
set origin igp
!
Route-map STATIC-TO-BGP permit 20
!
...
ip route 171.xxx.xxx.1 255.255.255.255 Null0 Tag 66
!
Mapping of a Prefix to Null0
Internal Routing Operation of Remote-Triggered Black Hole Routing (Filtering)
Dropping on Source Address
One of the criteria for remote-triggered black hole routing to be effective as a security tool is the ability to drop traffic based on both destination address and source addresses. For example, if a host is infected with a worm, it will be identified by its source address. To prevent the spread of the worm, it is necessary to have the capability to drop any traffic originating from that source address.
A second scenario requiring a mitigation technique is one in which spoofed source addresses are used. With recent worms, such as SQL Slammer and Blaster, the host’s real IP address is used to propagate the worm. This is not to say that other worms might not use spoofed addresses. As such, the scenario needs to be accommodated. There is no reason that any host should ever send out a packet with an address other than what was assigned to it. Any packets being sent out with illegitimate source addresses should be dropped at the first router hop.
The feature that enables both of these requirements is Unicast Reverse Path Forwarding (Unicast RPF). Information about Unicast RPF is available at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fothersf/scfrpf.htm
Unicast RPF in the traditional strict mode. If a packet is received on an interface, a route to that packet’s source address must be available back through the same interface on which the packet was received. If this route does not exist, the packet fails the RPF check and is dropped. It is recommended that this technique be deployed on all user-facing interfaces. This technique is an effective way to drop any spoofed packets from hosts on the local network at the first router hop.
Unicast RPF in Strict Mode
!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast reverse-path
...
speed 100
full-duplex
!
!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast source reachable-via any
...
speed 100
full-duplex
!
Selective Remote Traffic Dropping
Brian,
Ihave a question regarding the R&S Lab exam. Can I telnet to the back bone routers
totest routing?For our rack rentals we allow access to the backbone routers but in the real CCIE lab you will not have access to them. You will have to understand how to verify your solutions without access to the backbone routers.
ShareThis
Hi Brian,Howdo I switch between devices when using a Cisco access server?
Thereare two ways to connect to devices attached to an access server, you can terminate your exec session on the access server itself (one terminal window for all sessions), or you can terminate your exec session on the device connected to the access server (one terminal window for each session). In the CCIE Lab Exam you will have the option to do either, so pick whichever method works best for you and stick with it during your preparation.
Whenyou terminate your exec session on the access server you then “reverse telnet” to the individual devices connected to the access server. Normally to do this you first login to the access server and then issue the “show hosts” command to see the host mappings. Next, reverse telnet to them by typing the hostname and pressing enter. To get back to the access server issue the escape sequence CTRL-SHIFT-6-X. To do so hold ctrl and shift, hit 6, release all keys, then hit X. From the access server you can then open new connections or resume connections that you already have open.
Whenyou terminate your exec session on the device connected to the access server, i.e. by telnetting to the access server at port 2001, you cannot issue the escape sequence to reconnect to the access server. In this situation you would open multiple terminal windows if you wanted to connect to multiple devices.
Formore information watch this class-on-demand video on using an access server.
ShareThis
Access-list address and wildcard pair calculations are based
aroundthe AND and XOR logic gates.AND: The output is high only when both inputs A and B are high.
A AND B
______________|A | B | out |
| 0 | 0 | 0 ||0 | 1 | 0 |
| 1 | 0 | 0 ||1 | 1 | 1 |
--------------XOR: The output is high when either of inputs A or B is high, but not if
bothA and B are high.AXOR B
______________|A | B | out |
| 0 | 0 | 0 ||0 | 1 | 1 |
| 1 | 0 | 1 ||1 | 1 | 0 |
--------------To find the most specific address and wildcard pair that will
match two addresses, A and B, we use the gates AND and XOR. The address
wewill check in the access-list is A AND B. The wildcard used to check
in this list will be A XOR B.access-list 1 permit [address_to_check] [wildcard_used_to_check]Takethe following example:
We have two IP addresses, 10.20.30.40, and 40.30.20.10. How do we
createan access-list that is the most specific match for these two
addresses? First, write both addresses out in binary:10.20.30.40 = 00001010.00010100.00011110.00101000
40.30.20.10 = 00101000.00011110.00010100.00001010To find the address_to_check, take the logical AND of these addresses.
00001010.00010100.00011110.00101000
&& 00101000.00011110.00010100.00001010-------------------------------------- 00001000.00010100.00010100.00001000Thisis our address_to_check: 8.20.20.8
To find the matching wildcard_used_to_check, we take the logical XOR of
theseaddresses.00001010.00010100.00011110.00101000
XOR 00101000.00011110.00010100.00001010--------------------------------------- 00100010.00001010.00001010.00100010Thisis our wildcard_used_to_check: 34.10.10.34
Therefore, the most specific match for both 10.20.30.40 and 40.30.20.10
wouldbe:access-list 1 permit 8.20.20.8 34.10.10.34Here’sone more:
A = 1.2.3.4
B= 5.6.7.81.2.3.4= 00000001.00000010.00000011.00000100
5.6.7.8 = 00000101.00000110.00000111.00001000A && B = 00000001.00000010.00000011.00000000
A XOR B = 00000100.00000100.00000100.00001100Therefore the access-list would read:
access-list 1 permit 1.2.3.0 4.4.4.12ShareThis
Prefix-lists are used to match on prefix and prefix-length pairs. Normal prefix-list syntax is as follows:
ip prefix-list LIST permit w.x.y.z/lenWherew.x.y.z is your exact prefix
And where len is your exact prefix-length“ipprefix-list LIST permit 1.2.3.0/24″ would be an exact match for the prefix 1.2.3.0 with a subnet mask of 255.255.255.0. This does not match 1.2.0.0/24, nor does it match 1.2.3.4/32, nor anything in between.
Whenyou add the keywords “GE” and “LE” to the prefix-list, the “len” value changes its meaning. When using GE and LE, the len value specifies how many bits of the prefix you are checking, starting with the most significant bit.
ip prefix-list LIST permit 1.2.3.0/24 le 32Thismeans:
Check the first 24 bits of the prefix 1.2.3.0
Thesubnet mask must be less than or equal to 32This equates to the access-list syntax:
access-list1 permit 1.2.3.0 0.0.0.255ip prefix-list LIST permit 0.0.0.0/0 le 32Thismeans:
Check the first 0 bits of the prefix 0.0.0.0
Thesubnet mask must be less than or equal to 32
This equates to anythingipprefix-list LIST permit 0.0.0.0/0This means:
Theexact prefix 0.0.0.0, with the exact prefix-length 0.
This is matching a default route.ipprefix-list LIST permit 10.0.0.0/8 ge 21 le 29This means:
Checkthe first 8 bits of the prefix 10.0.0.0
The subnet mask must be greater than or equal to 21, and less than or
equalto 29.ip prefix-list CLASS_A permit 0.0.0.0/1 ge 8 le 8Thismatches all class A addresses with classful masks. It means:
Check the first bit of the prefix, it must be a 0.
Thesubnet mask must be greater than or equal to 8, and less than or equal to 8. ( It is exactly 8 )Whenusing the GE and LE values, you must satisfy the condition:
Len < GE <= LE
Therefore“ip prefix-list LIST permit 1.2.3.0/24 ge 8″ is not a valid list.
What you can not do with the prefix-list is match on arbitrary bits like you can in an access-list. Prefix-lists cannot be used to check if a number is even or odd, nor check if a number is divisible by 15, etc… Bit checking in a prefix-list is sequential, starting with the most significant (leftmost) bit.
ShareThis
Unlike PAP, CHAP does not actually send a password over the line. Instead, a hash value made up of the password and magic number is sent. Unless the hash matches from both authenticating parties, authentication is not successful.
By default, the router sends it’s hostname for authentication when using chap. The router on the other side does a lookup in its local database, radius server, or tacacs server, and finds the password that is paired with that username. If there is no matching username in the database, the password specified with the interface level command ‘ppp chap password’ is used as the default password.
Suppose you have a central office that has many remote clients dialing into it. If you don’t want to create an entry in the user database for each remote client, you can just specify a default password with ‘ppp chap password’. As long as the remote clients have an entry for the central site in their user database, authentication will be successful.ShareThis
Hi Brian,Ihave a router with two interfaces running both RIP and EIGRP as follows:
Interface IP-Address OK? Method Status Prot
Serial0 172.16.5.5 YES manual up upSerial1172.16.1.5 YES manual up up
router rip network 172.16.0.0
!
router eigrp 2001 network 172.16.0.0S0 should be RIP only, and S1 should be EIGRP only. RIP should not listen to broadcasts on S1
andEIGRP should not listen to multicasts on S0. How do I do that?SinceEIGRP uses periodic hellos to establish adjacency, passive-interface is sufficient in this case. Since passive-interface in EIGRP suppresses the generation of hellos out an interface, adjacency cannot be established, and therefore there can be no exchange of routes.
Aneven easier method of choosing which specific interfaces are running EIGRP is to use a wildcard mask when you use the network statement. The ‘network’ statement in IGP does not actually mean what networks you are advertising, it means what interfaces you are running the protocol on. If you only want to run EIGRP on your Serial 1 interface with an address of 172.16.1.5, use the following syntax:
router eigrp 2001
network 172.16.1.5 0.0.0.0This means that only the interface 172.16.1.5 is running EIGRP. The opposite of this most specific syntax would be:
router eigrp 2001
network 0.0.0.0 255.255.255.255This means that all interfaces are running EIGRP.
With RIP, the case is different than EIGRP. Since RIP does not use periodic hellos like EIGRP, OSPF, or IS-IS, passive-interface simply means that you will not send any routing updates out an interface. This does not mean that you will not receive routing updates in that interface. To prevent learning routes in an interface using RIP, you could use a distribute-list that denies everything (which would also work for EIGRP), or use an access-list that denies RIP altogether. Take the following examples:
access-list 1 deny any
!
router rip network 172.16.0.0
distribute-list 1 in serial 1or
access-list 100 deny udp any eq rip any eq rip
access-list 100 permit ip any any!interface serial 1
ip access-group 100 inBoth would accomplish the same goal.
HiBrian,
I am using dialer profiles for ISDN and I want protocol broadcasts such as RIP to be sent out accross the ISDN link. I tried to find the command that allows me to configure broadcast but the dialer interfaces do not accept the dialer map command. How do I accomplish this?
When using dialer profiles, dialer interfaces are point-to-point, therefore there is no need for protocol mappings. IP broadcasts should not have any trouble being sent across the interface as long as you have an IP address configured on the interface. Dialer maps are only used on dialer interfaces when using rotary groups. Dialer profiles are for when you have a single physical interface, but multiple destinations to dial. Rotary groups are for when you have multiple physical interfaces, but one destination to dial.
ShareThis
OSPF point-to-multipoint non-broadcast was designed to allow for the assignment of the cost on a per neighbor basis as opposed to using the interface’s cost. This
isuseful on a multipoint Frame Relay interface where there are two neighbors advertising the same route but the CIRs for the DLCIs to reach each neighbor is different or these two neighbors that are advertising the same route have different port speeds to the Frame Relay network. Remember that the cost is based on your “incoming” interface’s bandwidth and not the bandwidth of the neighbor’s interface that connects to you.Asan example say we have two remote routers over Frame Relay and the remote routers are both connected to and advertising the same Ethernet segment. Our router is connected to these two routers via Frame Relay. One of the remote routers has a T1 Frame Relay connection and the other has a 64k Frame Relay connection. Since our cost to the Ethernet segment advertised by these two routers will be calculated based on the cost of the Ethernet segment plus the cost of our incoming interface, both routes appear to be equal cost. Obviously this is not what we would want. We would want to prefer the route from the router with the T1 connection over the 64k connection.
Hereis an example with two remote routers advertising the same network (loopback interfaces):
Rack2R4#showip ospf interface s0/0 | include Cost
Process ID 1, Router ID 150.1.4.4, Network Type POINT_TO_MULTIPOINT,
Cost: 64Rack1R4#sho run int s0/0
interface Serial0/0 ip address 154.1.0.4 255.255.255.0
encapsulation frame-relay ip ospf network point-to-multipoint
frame-relay map ip 154.1.0.3 403 broadcast frame-relay map ip 154.1.0.5 405 broadcast
no frame-relay inverse-arpendRack2R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24 Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 154.1.0.3 on Serial0/0, 00:00:30 ago Routing Descriptor Blocks:
* 154.1.0.3, from 150.1.3.3, 00:00:30 ago, via Serial0/0 Route metric is 65, traffic share count is 1
154.1.0.5, from 150.1.5.5, 00:00:30 ago, via Serial0/0 Route metric is 65, traffic share count is 1As you can see both 154.1.0.3 (router-ID 150.1.3.3) and 154.1.0.5 (router-ID 150.1.5.5) are advertising the 150.1.0.0/24 network with an OSPF cost of 1 (total cost minus our interface’s cost, 65-64=1). If both of these routers have the same port speed to the Frame Relay network then this is what we would want to see, two equal cost paths. But if they have different port speeds, then we would want to prefer the route from the router with the higher port speed, theoretically. The problem is that OSPF does not take into account the cost of the remote router’s interface to us. We only take into account the cost of the loopback and our interface’s cost to reach the remote neighbor.
Toprefer the route from the router with the higher port speed, we are going to use OSPF point-to-multipoint non-broadcast to specify the cost on a per neighbor basis. In this example we are going to add a cost of 25 to the routes from 154.1.0.5 and 50 to the routes from 154.1.0.3.
Rack1R4#shorun | be router ospf
router ospf 1 network 154.1.0.0 0.0.255.255 area 0
neighbor 154.1.0.5 cost 25 neighbor 154.1.0.3 cost 50
Rack1R4#sho run int s0/0interfaceSerial0/0
ip address 154.1.0.4 255.255.255.0 encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast frame-relay map ip 154.1.0.3 403 broadcast
frame-relay map ip 154.1.0.5 405 broadcast no frame-relay inverse-arp
endRack1R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24 Known via "ospf 1", distance 110, metric 26, type intra area
Last update from 154.1.0.5 on Serial0/0, 00:06:13 ago Routing Descriptor Blocks:
* 154.1.0.5, from 150.1.5.5, 00:06:13 ago, via Serial0/0 Route metric is 26, traffic share count is 1
^^^^^^^^^^^^^^^^^^^Nowwe can see that we prefer the route from 154.1.0.5 (router-ID 150.1.5.5).
ShareThis
Hi Brian,Ienjoy the new blog feature. Lots of valuable information condensed in a small space. Could you explain in a nutshell how to troubleshoot multicast RPF failures? I understand the concept, just figuring out what shows and/or debugs to use always seems to take me 30 minutes rather than 5 minutes.
Firstlet’s talk briefly about what the RPF check, or Reverse Path Forwarding check, is for multicast. PIM is known as Protocol Independent Multicast routing because it does not exchange its own information about the network topology. Instead it relies on the accuracy of an underlying unicast routing protocol like OSPF or EIGRP to maintain a loop free topology. When a multicast packet is received by a router running PIM the device first looks at what the source IP is of the packet. Next the router does a unicast lookup on the source, as in the “show ip route w.x.y.z”, where “w.x.y.z” is the source. Next the outgoing interface in the unicast routing table is compared with the interface in which the multicast packet was received on. If the incoming interface of the packet and the outgoing interface for the route are the same, it is assumed that the packet is not looping, and the packet is candidate for forwarding. If the incoming interface and the outgoing interface are *not* the same, a loop-free path can not be guaranteed, and the RPF check fails. All packets for which the RPF check fails are dropped.
Nowas for troubleshooting the RPF check goes there are a couple of useful show and debug commands that are available to you on the IOS. Suppose the following topology:
Wewill be running EIGRP on all interfaces, and PIM dense mode on R2, R3, R4, and SW1. Note that PIM will not be enabled on R1. R4 is a multicast source that is attempting to send a feed to the client, SW1. On SW1 we will be generating an IGMP join message to R3 by issuing the “ip igmp join” command on SW1’s interface Fa0/3. On R4 we will be generating multicast traffic with an extended ping. First let’s look at the topology with a successful transmission:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.SW1(config)#intfa0/3
SW1(config-if)#ip igmp join 224.1.1.1SW1(config-if)#endSW1#R4#pingProtocol [ip]:
Target IP address: 224.1.1.1Repeatcount [1]: 5
Datagram size [100]:Timeoutin seconds [2]:
Extended commands [n]: yInterface[All]: Ethernet0/0
Time to live [255]:Sourceaddress: 150.1.124.4
Type of service [0]:SetDF bit in IP header? [no]:
Validate reply data? [no]:Datapattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:Sweeprange of sizes [n]:
Type escape sequence to abort.Sending5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.124.4Reply to request 0 from 150.1.37.7, 32 ms
Reply to request 1 from 150.1.37.7, 28 msReplyto request 2 from 150.1.37.7, 28 ms
Reply to request 3 from 150.1.37.7, 28 msReplyto request 4 from 150.1.37.7, 28 msNow let’s trace the traffic flow starting at the destination and working our way back up the reverse path.
SW1#show ip mroute 224.1.1.1
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data groupOutgoinginterface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/ExpiresInterfacestate: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:03:05/stopped, RP 0.0.0.0, flags: DCLIncominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:FastEthernet0/3,Forward/Dense, 00:03:05/00:00:00
(150.1.124.4, 224.1.1.1), 00:02:26/00:02:02, flags: PLTXIncominginterface: FastEthernet0/3, RPF nbr 150.1.37.3
Outgoing interface list: NullSW1’sRPF neighbor for (150.1.124.4,224.1.1.1) is 150.1.37.3, which means that SW1 received the packet from R3.
R3#show ip mroute 224.1.1.1
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:03:12/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
Serial1/3, Forward/Dense, 00:03:12/00:00:00Serial1/2,Forward/Dense, 00:03:12/00:00:00
Ethernet0/0, Forward/Dense, 00:03:12/00:00:00(150.1.124.4, 224.1.1.1), 00:02:33/00:01:46, flags: T
Incoming interface: Serial1/3, RPF nbr 150.1.23.2Outgoinginterface list:
Ethernet0/0, Forward/Dense, 00:02:34/00:00:00Serial1/2,Prune/Dense, 00:02:34/00:00:28R3’s RPF neighbor is 150.1.23.2, which means the packet came from R2.
R2#show ip mroute 224.1.1.1
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:02:44/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
FastEthernet0/0, Forward/Dense, 00:02:44/00:00:00Serial0/1,Forward/Dense, 00:02:44/00:00:00
(150.1.124.4, 224.1.1.1), 00:02:44/00:01:35, flags: TIncominginterface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:Serial0/1,Forward/Dense, 00:02:45/00:00:00R2 has no RPF neighbor, meaning the source is directly connected. Now let’s compare the unicast routing table from the client back to the source.
SW1#show ip route 150.1.124.4
Routing entry for 150.1.124.0/24Knownvia "eigrp 1", distance 90, metric 20540160, type internal
Redistributing via eigrp 1Lastupdate from 150.1.37.3 on FastEthernet0/3, 00:11:23 ago
Routing Descriptor Blocks:*150.1.37.3, from 150.1.37.3, 00:11:23 ago, via FastEthernet0/3
Route metric is 20540160, traffic share count is 1Totaldelay is 21100 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytesLoading1/255, Hops 2
R3#show ip route 150.1.124.4Routingentry for 150.1.124.0/24
Known via "eigrp 1", distance 90, metric 20514560, type internalRedistributingvia eigrp 1
Last update from 150.1.13.1 on Serial1/2, 00:11:47 agoRoutingDescriptor Blocks:
* 150.1.23.2, from 150.1.23.2, 00:11:47 ago, via Serial1/3Routemetric is 20514560, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 128 KbitReliability255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1150.1.13.1,from 150.1.13.1, 00:11:47 ago, via Serial1/2
Route metric is 20514560, traffic share count is 1Totaldelay is 20100 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytesLoading1/255, Hops 1
R2#show ip route 150.1.124.4Routingentry for 150.1.124.0/24
Known via "connected", distance 0, metric 0 (connected, via
interface)Redistributingvia eigrp 1
Routing Descriptor Blocks:*directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1Basedon this output we can see that SW1 sees the source reachable via R3, which was the neighbor the multicast packet came from. R3 sees the source reachable via R1 and R2 due to equal cost load-balancing, with R2 as the neighbor that the multicast packet came from. Finally R2 sees the source as directly connected, which is where the multicast packet came from. This means that the RPF check is successful as traffic is transiting the network, hence we had a successful transmission.
Nowlet’s modify the routing table on R3 so that the route to R4 points to R1. Since the multicast packet on R3 comes from R2 and the unicast route will going back towards R1 there will be an RPF failure, and the packet transmission will not be successful. Again note that R1 is not routing multicast in this topology.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.R3(config)#iproute 150.1.124.4 255.255.255.255 serial1/2
R3(config)#endR3#R4#pingProtocol [ip]:
Target IP address: 224.1.1.1Repeatcount [1]: 5
Datagram size [100]:Timeoutin seconds [2]:
Extended commands [n]: yInterface[All]: Ethernet0/0
Time to live [255]:Sourceaddress: 150.1.124.4
Type of service [0]:SetDF bit in IP header? [no]:
Validate reply data? [no]:Datapattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:Sweeprange of sizes [n]:
Type escape sequence to abort.Sending5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.124.4.....R4#We can now see that on R4 we do not receive a response back from the final destination… so where do we start troubleshooting? First we want to look at the first hop away from the source, which in this case is R2. On R2 we want to look in the multicast routing table to see if the incoming interface list and the outgoing interface list is correctly populated. Ideally we will see the incoming interface as FastEthernet0/0, which is directly connected to the source, and the outgoing interface as Serial0/1, which is the interface downstream facing towards R3.
R2#show ip mroute 224.1.1.1
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data groupOutgoinginterface flags: H - Hardware switched
Timers: Uptime/ExpiresInterfacestate: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:07:27/stopped, RP 0.0.0.0, flags: DIncominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:Serial0/1,Forward/Dense, 00:07:27/00:00:00
FastEthernet0/0, Forward/Dense, 00:07:27/00:00:00(150.1.124.4, 224.1.1.1), 00:07:27/00:01:51, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0Outgoinginterface list:
Serial0/1, Forward/Dense, 00:04:46/00:00:00Thisis the correct output we should see on R2. Two more verifications we can do are with the “show ip mroute count” command and the “debug ip mpacket” command. “show ip mroute count” will show all currently active multicast feeds, and whether packets are getting dropped:
R2#show ip mroute count
IP Multicast Statistics3routes using 1864 bytes of memory
2 groups, 0.50 average sources per groupForwardingCounts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 4, Packets received:
4
Source: 150.1.124.4/32, Forwarding: 4/1/100/0, Other: 4/0/0Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets
received: 0“debugip mpacket” will show the packet trace in real time, similar to the “debug ip packet” command for unicast packets. One caveat of using this verification is that only process switched traffic can be debugged. This means that we need to disable fast or CEF switching of multicast traffic by issuing the “no ip mroute-cache” command on the interfaces running PIM. Once this debug is enabled we’ll generate traffic from R4 again and we should see the packets correctly routed through R2.
R4#ping 224.1.1.1 repeat 100
Type escape sequence to abort.Sending100, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
…
R2(config)#int f0/0R2(config-if)#noip mroute-cache
R2(config-if)#int s0/1R2(config-if)#noip mroute-cache
R2(config-if)#endR2#debugip mpacket
IP multicast packets debugging is onR2#IP(0): s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=231,
prot=1, len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=232, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=233, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=234, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=235, prot=1,
len=100(100), mforwardR2#undebugallNow that we see that R2 is correctly routing the packets let’s look at all three of these verifications on R3.
R3#show ip mroute 224.1.1.1
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:00:01/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
Serial1/3, Forward/Dense, 00:00:01/00:00:00Ethernet0/0,Forward/Dense, 00:00:01/00:00:00
(150.1.124.4, 224.1.1.1), 00:00:01/00:02:58, flags:Incominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:Ethernet0/0,Forward/Dense, 00:00:02/00:00:00
Serial1/3, Forward/Dense, 00:00:02/00:00:00FromR3’s show ip mroute output we can see that the incoming interface is listed as Null. This is an indication that for some reason R3 is not correctly routing the packets, and is instead dropping them as they are received. For more information let’s look at the “show ip mroute count” output.
R3#show ip mroute count
IP Multicast Statistics3routes using 2174 bytes of memory
2 groups, 0.50 average sources per groupForwardingCounts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits
per secondOthercounts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received:
15Source:150.1.124.4/32, Forwarding: 0/0/0/0, Other: 15/15/0
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets
received: 0Fromthis output we can see that packets for (150.1.124.4,224.1.1.1) are getting dropped, and specifically the reason they are getting dropped is because of RPF failure. This is seen from the “Other: 15/15/0” output, where the second field is RPF failed drops. For more detail let’s look at the packet trace.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.R3(config)#inte0/0
R3(config-if)#no ip mroute-cacheR3(config-if)#ints1/3
R3(config-if)#no ip mroute-cacheR3(
