tag:blogger.com,1999:blog-61934178009216178972024-02-19T07:57:33.498-08:00CCIE TO BE<b>learning to fly</b>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.comBlogger196125tag:blogger.com,1999:blog-6193417800921617897.post-87164109220399717562009-03-03T05:57:00.000-08:002009-03-03T05:59:34.350-08:00TO BEOn my way back home from San Jose. I want to thank those that follow this blog and especially IPexpert for all the help. Will right more soon :)<br /><br />-CCIE# 23707deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com21tag:blogger.com,1999:blog-6193417800921617897.post-91399562900576488002009-02-25T18:08:00.000-08:002009-02-25T18:18:07.008-08:00PIM NBMA, DR and RPF issuesBelow is the topology. RIP is running everywhere, PIM-SM on all interfaces and everyone has R4 at 192.168.100.4 as the static RP.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjNsx67TrH8TmkhjvOa7Ab3La0TluFJxYkscmezfhh_Pax7gMSmf9E3KxebOhC4psYdyS9VoO3qzYGHOP3wx1IFZxI1xPBcL_zxE_UjqPT6CPpjuGEiWb8rweKCZZ7mThbYBGlU1mebJw/s1600-h/pim+nbma.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 331px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjNsx67TrH8TmkhjvOa7Ab3La0TluFJxYkscmezfhh_Pax7gMSmf9E3KxebOhC4psYdyS9VoO3qzYGHOP3wx1IFZxI1xPBcL_zxE_UjqPT6CPpjuGEiWb8rweKCZZ7mThbYBGlU1mebJw/s400/pim+nbma.jpg" alt="" id="BLOGGER_PHOTO_ID_5306922806637050722" border="0" /></a><br />R1 has the following config on its LAN interface:<br /><pre><span style="color: rgb(102, 204, 204);">interface Ethernet0/0</span><br /><span style="color: rgb(102, 204, 204);"> ip address 192.168.0.1 255.255.255.0</span><br /><span style="color: rgb(102, 204, 204);"> ip pim sparse-mode</span><br /><span style="color: rgb(102, 204, 204);"> ip igmp join-group 239.0.0.1</span><br /></pre>Let's ping from R6:<br /><pre><span style="color: rgb(102, 204, 204);">R6#ping 239.0.0.1 re 5 </span><br /><br /><span style="color: rgb(102, 204, 204);">Type escape sequence to abort.</span><br /><span style="color: rgb(102, 204, 204);">Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><span style="color: rgb(102, 204, 204);">.....</span><br /><span style="color: rgb(102, 204, 204);">R6#</span><br /></pre>Hmmm....what gives? Let's look at R4:<br /><pre><span style="color: rgb(102, 204, 204);">R4#sho ip pim neighbor</span><br /><span style="color: rgb(102, 204, 204);">PIM Neighbor Table</span><br /><span style="color: rgb(102, 204, 204);">Neighbor Interface Uptime/Expires Ver DR</span><br /><span style="color: rgb(102, 204, 204);">Address Prio/Mode</span><br /><span style="color: rgb(102, 204, 204);">192.168.34.3 Ethernet0/0 03:29:50/00:01:39 v2 1 / S</span><br /><span style="color: rgb(102, 204, 204);">192.168.100.2 Serial0/0 02:25:22/00:01:38 v2 1 / S</span><br /><span style="color: rgb(102, 204, 204);">192.168.100.5 Serial0/0 02:25:22/00:01:39 v2 1 / DR S</span><br /><span style="color: rgb(102, 204, 204);">192.168.100.1 Serial0/0 02:25:22/00:01:38 v2 1 / S</span><br /><br /><span style="color: rgb(102, 204, 204);">R4#sho ip mroute 239.0.0.1 | be \(</span><br /><span style="color: rgb(102, 204, 204);">(*, 239.0.0.1), 00:24:31/00:02:33, RP 192.168.100.4, flags: S</span><br /><span style="color: rgb(102, 204, 204);"> Incoming interface: Null, RPF nbr 0.0.0.0</span><br /><span style="color: rgb(102, 204, 204);"> Outgoing interface list:</span><br /><span style="color: rgb(102, 204, 204);"> Serial0/0, 192.168.100.2, Forward/Sparse, 00:24:31/00:02:33</span><br /><br /><span style="color: rgb(102, 204, 204);">(192.168.56.6, 239.0.0.1), 00:02:03/00:02:45, flags: T</span><br /><span style="color: rgb(102, 204, 204);"> Incoming interface: Serial0/0, RPF nbr 192.168.100.5</span><br /><span style="color: rgb(102, 204, 204);"> Outgoing interface list:</span><br /><span style="color: rgb(102, 204, 204);"> Serial0/0, 192.168.100.2, Forward/Sparse, 00:02:03/00:00:57</span><br /><br /><span style="color: rgb(102, 204, 204);">R4#</span><br /></pre>Well, it looks R2 is showing up in the OIL, but why isn't R1? It is a PIM neighbor afterall. The reason is because R2 has won the DR election and has the right to forward traffic. So it is the neighbor that sends PIM joins to R4. R1 receives the traffic, but it comes in on its LAN interface and thus fails the RPF check.<br /><br /><span style="color: rgb(102, 204, 204);font-size:85%;" ><span style="font-family:courier new;">R1#debug ip mpacket </span><br /><span style="font-family:courier new;">IP multicast packets debugging is on</span><br /><span style="font-family:courier new;">03:40:21: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=197, ttl=251, prot=1, len=114(100), not RPF interface</span><br /><span style="font-family:courier new;">03:40:23: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=198, ttl=251, prot=1, len=114(100), not RPF interface</span></span><br /><br />It is important to remember we have at least two ways to resolve this:<br /><br /><span style="font-weight: bold; color: rgb(51, 255, 51);">1) Make R1 the DR</span><br /><br /><span style="font-size:85%;"><span style="color: rgb(102, 204, 204);font-family:courier new;" >R1(config)#int e0/0</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >R1(config-if)#ip pim dr-priority 3000</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" ></span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >R6#ping 239.0.0.1 re 1 </span><br /><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >Type escape sequence to abort.</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >Reply to request 0 from 192.168.100.1, 60 ms</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >R6#</span><br /><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >R1(config-if)#^Z</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >03:41:47: IP(0): s=192.168.56.6 (Serial0/0) d=239.0.0.1 (Ethernet0/0) id=207, ttl=252, prot=1, len=100(100), mforward</span></span><br /><br /><span style="font-weight: bold; color: rgb(51, 255, 51);">2) Static mroute to R2 for 192.168.56.6</span><br /><br /><span style="color: rgb(102, 204, 204);font-size:85%;" ><span style="font-family:courier new;">R1(config)#int e0/0 </span><br /><span style="font-family:courier new;">R1(config-if)#no ip pim dr-priority 3000</span><br /><span style="font-family:courier new;">R1(config-if)#exit</span><br /><span style="font-family:courier new;">R1(config)#ip mroute 192.168.56.0 255.255.255.0 192.168.0.2</span><br /><br /><span style="font-family:courier new;">Make sure to clear mroutes otherwise previous state may mislead you :)</span><br /><br /><span style="font-family:courier new;">R4#clear ip mroute *</span><br /><br /><span style="font-family:courier new;">R6#ping 239.0.0.1 re 1 </span><br /><br /><span style="font-family:courier new;">Type escape sequence to abort.</span><br /><span style="font-family:courier new;">Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="font-family:courier new;">Reply to request 0 from 192.168.100.1, 56 ms</span><br /><span style="font-family:courier new;">R6#</span></span><br /><br />This is one of those labs where I had no idea where I was going and I ended up with a nice troubleshooting scenario. If multicast is one your weaknesses than I highly recommend digging in and making something happen. Debug ip mpacket works best with "no ip mroute-cache" on your interfaces. In this scenario, I started troubleshooting on R5, then worked my way around to resolve the issue :)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com6tag:blogger.com,1999:blog-6193417800921617897.post-79841624864396410452009-02-23T20:26:00.000-08:002009-02-23T20:55:48.243-08:00PIM Forwarder and the Assert MechanismI know, it's a cool name for a band, huh? Ladies and gentlemen...PIM Forwarder and the Assert Mechanism! Anyways, I always get confused about PIM DR and PIM Forwarder so this is to clear up my confusion. Here we take a look at PIM Forwarder and how to verify the assert process is working.<br /><br /><span style="font-weight: bold;">Here is the topology:</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEih8LNdKUAxU5O6f_3qo_Mqw2Qamz8ihy3MXnrQL5Ql8xVeh7Wiy29JPDNa7FsWOhD_PR9TScnfPBBQGqRREbrnZGqs4DptjJrTmpkTLdZjoYimBo_-wH2ipC0gc2AIM4-L1-C3TvxC2yw/s1600-h/pim+forwarder+lab.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 331px; height: 400px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEih8LNdKUAxU5O6f_3qo_Mqw2Qamz8ihy3MXnrQL5Ql8xVeh7Wiy29JPDNa7FsWOhD_PR9TScnfPBBQGqRREbrnZGqs4DptjJrTmpkTLdZjoYimBo_-wH2ipC0gc2AIM4-L1-C3TvxC2yw/s400/pim+forwarder+lab.jpg" alt="" id="BLOGGER_PHOTO_ID_5306219087929444962" border="0" /></a><br /><span style="font-weight: bold;">Here is what I have enabled:</span><br />-RIP on all interfaces<br />-ip multicast-routing on all routers<br />-ip pim sparse-dense on all interfaces<br />-ip igmp join-group 239.0.0.1 on R5 ethernet<br /><br /><span style="font-weight: bold;">For debugging:</span><br />-no ip mroute-cache<br />-debug ip mpacket<br />-ping<br /><br /><span style="font-weight: bold; color: rgb(51, 255, 51);">Scenario 1: R2 is the PIM Forwarder based on highest IP</span><br /><br />From R4 we ping twice:<br /><pre><span style="color: rgb(102, 204, 204);">R4#ping 239.0.0.1 re 2</span><br /><br /><span style="color: rgb(102, 204, 204);">Type escape sequence to abort.</span><br /><span style="color: rgb(102, 204, 204);">Sending 2, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="color: rgb(102, 204, 204);">Reply to request 0 from 192.168.0.5, 20 ms</span><br /><span style="color: rgb(102, 204, 204);">Reply to request 0 from 192.168.0.5, 20 ms</span><br /><span style="color: rgb(102, 204, 204);">Reply to request 1 from 192.168.0.5, 8 ms</span><br /></pre>On R1 and R2 we see the following:<br /><br /><span style="color: rgb(102, 204, 204);font-size:85%;" ><span style="font-family:courier new;">R1#</span><br /><span style="font-family:courier new;">*Mar 2 02:05:36.795: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >*Mar 2 02:05:36.799: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface</span><br /><span style="font-family:courier new;">*Mar 2 02:05:38.787: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=71, ttl=252, prot=1, len=114(100), not RPF interface</span><br /><br /><span style="font-family:courier new;">R2# </span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >*Mar 1 02:25:00.567: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward</span><br /><span style="font-family:courier new;">*Mar 1 02:25:00.571: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface</span><br /><span style="color: rgb(102, 204, 204);font-family:courier new;" >*Mar 1 02:25:02.559: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=71, ttl=253, prot=1, len=100(100), mforward</span></span><br /><br />Notice that each router sent the first packet onto the LAN and R5 responded to both. We can tell because R4 got two replies. What also happened is that R1 and R2 each saw that very same packet on their LAN interfaces. Immediately the PIM Assert process took over. Because both routers have the same AD (90) and metric (2) to the source, R2 won the right to forward based on highest IP.<br /><br />Next we see that the second packet only gets forwarded by R2. Here we see that R2 has the A (Assert Winner) flag in its mroute entry. R1 has pruned that same interface.<br /><pre><span style="color: rgb(102, 204, 204);">R2#sho ip mroute 239.0.0.1 192.168.34.4 | be \(</span><br /><span style="color: rgb(102, 204, 204);">(192.168.34.4, 239.0.0.1), 00:00:39/00:02:26, flags: T</span><br /><span style="color: rgb(102, 204, 204);"> Incoming interface: Serial0/1, RPF nbr 192.168.23.3</span><br /><span style="color: rgb(102, 204, 204);"> Outgoing interface list:</span><br /><span style="color: rgb(102, 204, 204);"> Ethernet0/0, Forward/Sparse-Dense, 00:00:39/00:00:00, <span style="color: rgb(255, 0, 0);">A</span></span><br /><br /><span style="color: rgb(102, 204, 204);">R1#sho ip mroute 239.0.0.1 192.168.34.4 | be \(</span><br /><span style="color: rgb(102, 204, 204);">(192.168.34.4, 239.0.0.1), 00:01:27/00:01:34, flags: PT</span><br /><span style="color: rgb(102, 204, 204);"> Incoming interface: Serial0/1, RPF nbr 192.168.13.3</span><br /><span style="color: rgb(102, 204, 204);"> Outgoing interface list:</span><br /><span style="color: rgb(102, 204, 204);"> Ethernet0/0, Prune/Sparse-Dense, 00:01:27/00:01:32</span><br /><br /></pre><span style="font-weight: bold; color: rgb(51, 255, 51);">Scenario 2: R1 is the PIM Forwarder based on lowest AD</span><br /><br />Now we change R1's AD for RIP below the default of 120:<br /><pre><span style="color: rgb(102, 204, 204);">R1(config)#router rip</span><br /><span style="color: rgb(102, 204, 204);">R1(config-router)#distance 89</span><br /></pre>We see the same behavior from R4's perspective but now R1 has won the Assert process and is forwarding group 239.0.0.1 onto the LAN:<br /><pre><span style="color: rgb(102, 204, 204);">R4#ping 239.0.0.1 re 2</span><br /><br /><span style="color: rgb(102, 204, 204);">Type escape sequence to abort.</span><br /><span style="color: rgb(102, 204, 204);">Sending 2, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="color: rgb(102, 204, 204);">Reply to request 0 from 192.168.0.5, 12 ms</span><br /><span style="color: rgb(102, 204, 204);">Reply to request 0 from 192.168.0.5, 12 ms</span><br /><span style="color: rgb(102, 204, 204);">Reply to request 1 from 192.168.0.5, 8 ms</span><br /><span style="color: rgb(102, 204, 204);">R4#</span><br /><br /><span style="color: rgb(102, 204, 204);">R1#sho ip mroute 239.0.0.1 192.168.34.4 | be \(</span><br /><span style="color: rgb(102, 204, 204);">(192.168.34.4, 239.0.0.1), 00:00:07/00:02:54, flags: T</span><br /><span style="color: rgb(102, 204, 204);"> Incoming interface: Serial0/1, RPF nbr 192.168.13.3</span><br /><span style="color: rgb(102, 204, 204);"> Outgoing interface list:</span><br /><span style="color: rgb(102, 204, 204);"> Ethernet0/0, Forward/Sparse-Dense, 00:00:07/00:00:00, <span style="color: rgb(255, 0, 0);">A</span></span><br /><br /><span style="color: rgb(102, 204, 204);">R1#</span><br /></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com6tag:blogger.com,1999:blog-6193417800921617897.post-63236745595920476992009-02-23T15:12:00.000-08:002009-02-23T15:55:24.851-08:00How Route-Reflector clusters prevent loopsThis is the topology I used to get familiar with the concept:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCD1knGi9khIYNwz88lMip8HQOHxaWdoA3wVXleheMsYp7m_OMPEFTEiAsWOS8AERSS4c_PpI98AXezM0wTGj9kdWWXRaR_VM8F-G-GM7Dw9bMrqhWHZLpr-USIuXkWSiIw9-raZe13Pw/s1600-h/route-reflector.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 235px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCD1knGi9khIYNwz88lMip8HQOHxaWdoA3wVXleheMsYp7m_OMPEFTEiAsWOS8AERSS4c_PpI98AXezM0wTGj9kdWWXRaR_VM8F-G-GM7Dw9bMrqhWHZLpr-USIuXkWSiIw9-raZe13Pw/s400/route-reflector.jpg" alt="" id="BLOGGER_PHOTO_ID_5306135679830041410" border="0" /></a><br />The idea is fairly easy to understand. You never want to learn routes from someone who learned them from you (directly or indirectly). I made the peers one by one to step through the process.<br /><br />Here is the route on R1:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R1#sho ip bgp 200.0.0.0</span><br /><span style="font-family:courier new;">BGP routing table entry for 200.0.0.0/8, version 12</span><br /><span style="font-family:courier new;">Paths: (1 available, best #1, table Default-IP-Routing-Table)</span><br /><span style="font-family:courier new;"> Advertised to update-groups:</span><br /><span style="font-family:courier new;"> 3 </span><br /><span style="font-family:courier new;"> 100, (Received from a RR-client)</span><br /><span style="font-family:courier new;"> 6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)</span><br /><span style="font-family:courier new;"> Origin IGP, metric 0, localpref 100, valid, internal, best</span><br /><span style="font-family:courier new;">R1#</span></span><br /><br />Now on R2, we see the first case of the origintaor-id as set by R1. And we also see the beginning of the cluster-list:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2#sho ip bgp 200.0.0.0</span><br /><span style="font-family:courier new;">BGP routing table entry for 200.0.0.0/8, version 9</span><br /><span style="font-family:courier new;">Paths: (1 available, best #1, table Default-IP-Routing-Table)</span><br /><span style="font-family:courier new;"> Advertised to update-groups:</span><br /><span style="font-family:courier new;"> 2 </span><br /><span style="font-family:courier new;"> 100</span><br /><span style="font-family:courier new;"> 6.6.6.6 (metric 3) from 1.1.1.1 (1.1.1.1)</span><br /><span style="font-family:courier new;"> Origin IGP, metric 0, localpref 100, valid, internal, best</span><br /><span style="font-family:courier new;"> Originator: 6.6.6.6, Cluster list: 1.1.1.1</span><br /><span style="font-family:courier new;">R2#</span></span><br /><br />R2 appends itself to the cluster-list before advertising to R5:<br /><br /><span style="font-size:85%;"><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5#sho ip bgp 200.0.0.0</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >BGP routing table entry for 200.0.0.0/8, version 12</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >Paths: (1 available, best #1, table Default-IP-Routing-Table)</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > Advertised to update-groups:</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > 2 </span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > 100</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > 6.6.6.6 (metric 2) from 2.2.2.2 (2.2.2.2)</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > Origin IGP, metric 0, localpref 100, valid, internal, best</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > Originator: 6.6.6.6, Cluster list: 2.2.2.2, 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5#</span></span><br /><br />Eventually, these are the messages we get on R6 and R2, respectively.<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R6#<br /></span> <span style="font-family:courier new;">*Mar 1 00:44:55.807: BGP(0): 5.5.5.5 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: ORIGINATOR is us;<br />*Mar 1 00:44:55.811: BGP(0): 5.5.5.5 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: ORIGINATOR is us;</span><span style="font-family:courier new;"></span></span><br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2#<br /></span> <span style="font-family:courier new;">*Mar 1 00:53:39.075: BGP(0): 3.3.3.3 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;</span> <span style="font-family:courier new;"><br />*Mar 1 00:53:39.083: BGP(0): 3.3.3.3 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;</span></span>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-62368840471565180542009-02-23T12:12:00.000-08:002009-02-23T12:14:54.555-08:00My new favorite IOS messageI don't know what my previous one was, but this is the new one:<br /><pre><br />R1(config-if)#traffic-shape rate 64000 ? <br /> <0-100000000> bits per interval, sustained<br /> <cr><br />R1(config-if)#traffic-shape rate 64000 640<br /><span style="font-weight: bold; color: rgb(255, 0, 0);">less than 1000 bits in an interval doesn't make sense</span><br />R1(config-if)#<br /></cr></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com4tag:blogger.com,1999:blog-6193417800921617897.post-27869341667829243712009-02-14T23:34:00.000-08:002009-02-14T23:39:27.424-08:00Watch the RIP metric when summarizing redistributed routesI was reading through the GS archives and saw this interesting issue about the metrics of summarized routes after being redistributed into RIP.<br /><br /><span style="font-weight: bold;"><span style="color: rgb(51, 255, 51);">Scenario:</span></span><br /><br />R1---RIP---R2---OSPF---R5---5.5.5.5/32<br /><br />R2 is redistributing OSPF to RIP as follows:<br /><pre><span style="color: rgb(102, 204, 204);">R2#sho run | sec router rip</span><br /><span style="color: rgb(102, 204, 204);">router rip</span><br /><span style="color: rgb(102, 204, 204);"> version 2</span><br /><span style="color: rgb(102, 204, 204);"> redistribute ospf 1 metric 2</span><br /><span style="color: rgb(102, 204, 204);"> network 192.168.0.0</span><br /><span style="color: rgb(102, 204, 204);"> no auto-summary</span><br /></pre>R1 has the following route:<br /><pre><span style="color: rgb(102, 204, 204);">R1#sho ip route | sec 5.0.0.0</span><br /><span style="color: rgb(102, 204, 204);"> 5.0.0.0/32 is subnetted, 1 subnets</span><br /><span style="color: rgb(102, 204, 204);">R 5.5.5.5 [120/<span style="color: rgb(255, 0, 0);">2</span>] via 192.168.0.2, 00:00:11, FastEthernet0/0</span><br /></pre><span style="font-weight: bold; color: rgb(51, 255, 51);">1) Manual Summary</span><br /><pre><span style="color: rgb(102, 204, 204);">R2(config)#int f0/0</span><br /><span style="color: rgb(102, 204, 204);">R2(config-if)#ip summary-address rip 5.0.0.0 255.0.0.0 </span><br /><br /><span style="color: rgb(102, 204, 204);">R1#sho ip route | sec 5.0.0.0</span><br /><span style="color: rgb(102, 204, 204);">R 5.0.0.0/8 [120/<span style="color: rgb(255, 0, 0);">3</span>] via 192.168.0.2, 00:00:01, FastEthernet0/0</span><br /></pre>The metric increased by 1.<br /><br /><span style="font-weight: bold; color: rgb(51, 255, 51);">2) Auto-summary</span><br /><pre><span style="color: rgb(102, 204, 204);">R2(config-if)#router rip</span><br /><span style="color: rgb(102, 204, 204);">R2(config-router)#auto-summary </span><br /><br /><span style="color: rgb(102, 204, 204);">R1#sho ip route | sec 5.0.0.0</span><br /><span style="color: rgb(102, 204, 204);">R 5.0.0.0/8 [120/<span style="color: rgb(255, 0, 0);">2</span>] via 192.168.0.2, 00:00:05, FastEthernet0/0</span><br /></pre>The metric is the same as when redistributed.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com6tag:blogger.com,1999:blog-6193417800921617897.post-78822746365477264032009-02-14T13:50:00.000-08:002009-02-14T14:26:20.366-08:00CCIE Assessor Lab ReviewI don't know how much I can say about this so I will keep it brief. I purchased both assessor labs, one for today and one for tomorrow. I just completed the first one in about 2 hours. That left a good chunk of time to verify and run the assessment. I only missed two tasks and they were very simple mistakes.<br /><br />My one worry was that it would take awhile to get used to the topology and the web interface. I spent about 30 minutes last night reading the user guide and it was smooth transition getting used to the GUI and the controls. This should not worry you.<br /><br />I redrew a diagram and kept a task/point tracker. I read the lab before I started and first glanced seemed to be pretty easy. There are some things that will leave you scratching your head and that is good. The best part: There were no errors or typos in any tasks or drawings! :)<br /><br />The telnet sessions are Java based and you have to open one in each window and then arrange them on your screen. I opened R1 first, the moved on so they were arranged in my taskbar in order. I don't expect many difference for tomorrow's session, so hopefully I do good.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-87074131989872726252009-02-13T10:42:00.000-08:002009-02-13T16:21:38.280-08:00OSPF filtering issue when virtual-links are presentHere is the topology I will start off with:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC1VKSynNXlAPMVu4nWwiWvgUsygpoUCY-0X5zzTxyH2NB44UNGsGoLbdjRvFpO8AsNlnklot9cMrIsAHtLoIhJPAALlOJZ6Z7ljaVnqHc0xew7ugyyMCVgBvjE313B93GuFxFDheMGx8/s1600-h/ospf+filter1.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 397px; height: 259px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC1VKSynNXlAPMVu4nWwiWvgUsygpoUCY-0X5zzTxyH2NB44UNGsGoLbdjRvFpO8AsNlnklot9cMrIsAHtLoIhJPAALlOJZ6Z7ljaVnqHc0xew7ugyyMCVgBvjE313B93GuFxFDheMGx8/s400/ospf+filter1.jpg" alt="" id="BLOGGER_PHOTO_ID_5302354496683671362" border="0" /></a><br />R4 has two <span style="font-weight: bold;">INTER</span>-area routes to 1.1.1.1:<br /><pre><span style="color: rgb(51, 204, 255);">R4#sho ip route 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 1.1.1.1/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 4, type inter area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.45.5 on Serial1/0, 00:00:11 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> 192.168.45.5, from 5.5.5.5, 00:00:11 ago, via Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.34.3, from 2.2.2.2, 00:00:11 ago, via Serial1/1</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /></pre>If we want to filter the path from R2 through 192.168.34.3 we could do it this way:<br /><pre><span style="color: rgb(51, 204, 255);">R4(config)#access-list 1 permit 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);">R4(config)#access-list 2 permit 2.2.2.2</span><br /><span style="color: rgb(51, 204, 255);">R4(config)#route-map OSPF deny 10</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#match ip address 1</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#match ip route-source 2</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#route-map OSPF permit 20</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#router ospf 1</span><br /><span style="color: rgb(51, 204, 255);">R4(config-router)#distribute-list route-map OSPF in</span><br /><span style="color: rgb(51, 204, 255);">R4(config-router)#^Z</span><br /><span style="color: rgb(51, 204, 255);"> </span><br /><span style="color: rgb(51, 204, 255);">R4#sho ip route 1.1.1.1 </span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 1.1.1.1/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 4, type inter area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.45.5 on Serial1/0, 00:00:12 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.45.5, from 5.5.5.5, 00:00:12 ago, via Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /></pre>But let's say we have a task that asks us to create a new area attached to R4 as follows:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-U-0_APy8H0_UIs-2fQoXcW03VM4Ni_g2QjMEbHadhHjE8J2LdGBN87KEoWGbUA_y0VseqQD_zWYd8ivDqN58cV3EBeXdunGEVY5CpR_7-bzZhGDNpunowtH6fGEYpxBEO12JE3mS9a0/s1600-h/ospf+filter2.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 397px; height: 259px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-U-0_APy8H0_UIs-2fQoXcW03VM4Ni_g2QjMEbHadhHjE8J2LdGBN87KEoWGbUA_y0VseqQD_zWYd8ivDqN58cV3EBeXdunGEVY5CpR_7-bzZhGDNpunowtH6fGEYpxBEO12JE3mS9a0/s400/ospf+filter2.jpg" alt="" id="BLOGGER_PHOTO_ID_5302354664220090946" border="0" /></a><br />Now we need two virtual-links and look at was happened to our route 1.1.1.1.<br /><pre><span style="color: rgb(51, 204, 255);">R4(config)#router ospf 1 </span><br /><span style="color: rgb(51, 204, 255);">R4(config-router)#area 1 virtual-link 5.5.5.5 </span><br /><span style="color: rgb(51, 204, 255);">R4(config-router)#area 1 virtual-link 2.2.2.2</span><br /><br /><span style="color: rgb(51, 204, 255);">*Mar 3 01:31:13.935: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on<br />OSPF_VL2 from LOADING to FULL, Loading Done</span><br /><span style="color: rgb(51, 204, 255);">*Mar 3 01:31:16.979: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on<br />OSPF_VL3 from LOADING to FULL, Loading Done</span><br /><br /><span style="color: rgb(51, 204, 255);">R4#sho ip route 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 1.1.1.1/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 4, type intra area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.34.3 on Serial1/1, 00:00:00 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.45.5, from 1.1.1.1, 00:00:00 ago, via Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /><span style="color: rgb(51, 204, 255);"> 192.168.34.3, from 1.1.1.1, 00:00:00 ago, via Serial1/1</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /></pre>What gives? Well now we are learning 1.1.1.1 as an <span style="font-weight: bold;">INTRA</span>-area route so the router-ID advertising the LSA has changed. We are now learning the route from type-1 LSAs originated by R1 directly in Area 0. If we filter based on router-id we will lose both paths so now we need to filter based on next-hop:<br /><pre><span style="color: rgb(51, 204, 255);">R4(config)#access-list 3 permit 192.168.34.3</span><br /><span style="color: rgb(51, 204, 255);">R4(config)#no route-map OSPF</span><br /><span style="color: rgb(51, 204, 255);">R4(config)#route-map OSPF deny 10</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#match ip add 1</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#match ip next-hop 3</span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#route-map OSPF pe 20 </span><br /><span style="color: rgb(51, 204, 255);">R4(config-route-map)#^Z</span><br /><br /><span style="color: rgb(51, 204, 255);">R4#sho ip route 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 1.1.1.1/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 4, type intra area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.45.5 on Serial1/0, 00:00:02 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.45.5, from 1.1.1.1, 00:00:02 ago, via Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 4, traffic share count is 1</span><br /></pre>All of this change could of course been prevented had we read ahead :-)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com4tag:blogger.com,1999:blog-6193417800921617897.post-76265431856633229902009-02-12T15:43:00.000-08:002009-02-12T15:45:55.836-08:00OSPF on unnumbered linksI was reviewing the OSPF chapter in the CCIE exam guide today and something irked me. It said that OSPF neighbors will become adjacent if one or both of the neighbors are using unnumbered interfaces between them. I swear this was not case as I had experienced before so I labbed it up.<br /><pre><span style="color: rgb(51, 204, 255);">R3#sho ip ospf ne</span><br /><br /><span style="color: rgb(51, 204, 255);">Neighbor ID Pri State Dead Time Address Interface</span><br /><span style="color: rgb(51, 204, 255);">2.2.2.2 0 FULL/ - 00:00:37 192.168.23.2 Serial1/1</span><br /><span style="color: rgb(51, 204, 255);">4.4.4.4 0 FULL/ - 00:00:39 192.168.34.4 Serial1/0</span><br /><span style="color: rgb(51, 204, 255);">R3#</span><br /><br /><span style="color: rgb(51, 204, 255);">R3(config)#int s1/0</span><br /><span style="color: rgb(51, 204, 255);">R3(config-if)#ip unnumbered lo 0</span><br /><span style="color: rgb(51, 204, 255);">R3(config-if)#</span><br /><span style="color: rgb(51, 204, 255);">*Mar 2 06:31:01.600: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Serial1/0<br />from FULL to DOWN, Neighbor Down: Interface down or detached</span><br /></pre>The adjcency will not come back up. Let's configure R4:<br /><pre><span style="color: rgb(51, 204, 255);">R4(config)#int s1/1</span><br /><span style="color: rgb(51, 204, 255);">R4(config-if)#ip unnumbered lo 0</span><br /><span style="color: rgb(51, 204, 255);">R4(config-if)#</span><br /><span style="color: rgb(51, 204, 255);">*Mar 2 06:33:14.288: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/1<br />from LOADING to FULL, Loading Done</span><br /></pre>There we go! If one side is unnumbered, the other side needs to be also. I am running 12.4(7) so maybe this was not the case awhile ago, but right now it seems so. There are a few other mistakes in this chapter, especially in the beginning quiz - <span style="font-weight: bold; color: rgb(51, 255, 51);">SO QUESTION (LAB) EVERYTHING!</span>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-91050686710476145812009-02-12T10:41:00.000-08:002009-02-12T10:48:02.876-08:00SNMP - sending traps to specific hostsThis was an issue I ran into awhile ago. I was trying to send BGP traps to one host, and PIM traps to another. As you can see below, BGP traps were getting sent to both hosts when I used version 1.<br /><br />When I had version 2c specified, traps were only sent to the host configured for BGP. I do not know if this is difference in the protocol, but it is something you may want to be aware of if you need to send traps to different hosts.<br /><br /><span style="color: rgb(51, 255, 51); font-weight: bold;">Version 1, traps get sent to both hosts:</span><br /><pre><span style="color: rgb(51, 204, 255);">R1#sho run | inc </span><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><div style="color: rgb(51, 204, 255);" class="Ih2E3d"><span class="nfakPe">snmp</span>-server enable traps bgp<br /></div><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><span style="color: rgb(51, 204, 255);">-server enable traps pim</span><br /><div style="color: rgb(51, 204, 255);" class="Ih2E3d"><span class="nfakPe">snmp</span>-server host 2.2.2.2 public bgp<br /></div><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><span style="color: rgb(51, 204, 255);">-server host 3.3.3.3 public pim</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#clear ip bgp *</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /><span style="color: rgb(51, 204, 255);">00:11:49: %BGP-5-ADJCHANGE: neighbor 172.12.14.4 Down User reset</span><br /><span style="color: rgb(51, 204, 255);">00:11:49: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: Queuing packet to 2.2.2.2</span><br /><span style="color: rgb(51, 204, 255);"> 00:11:49: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: V1 Trap, ent bgp, addr 172.12.12.1, gentrap 6, spectrap 2 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.14.172.12.14.4 = 00 00 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.2.172.12.14.4 = 1</span><br /><span style="color: rgb(51, 204, 255);">00:11:49: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: Queuing packet to 3.3.3.3</span><br /><span style="color: rgb(51, 204, 255);">00:11:49: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: V1 Trap, ent bgp, addr 172.12.13.1, gentrap 6, spectrap 2 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.14.172.12.14.4 = 00 00 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.2.172.12.14.4 = 1</span><br /><span style="color: rgb(255, 0, 0);">00:11:49: </span><span style="color: rgb(255, 0, 0);" class="nfakPe">SNMP</span><span style="color: rgb(255, 0, 0);">: Packet sent via UDP to 2.2.2.2</span><br /><span style="color: rgb(255, 0, 0);">00:11:49: </span><span style="color: rgb(255, 0, 0);" class="nfakPe">SNMP</span><span style="color: rgb(255, 0, 0);">: Packet sent via UDP to 3.3.3.3</span><br /><span style="color: rgb(51, 204, 255);"></span></pre><span style="color: rgb(51, 255, 51); font-weight: bold;">Version 2c, traps get sent to one as desired:</span><br /><span style="color: rgb(51, 204, 255);"><pre><span style="color: rgb(51, 204, 255);">R1#sho run | inc </span><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><div style="color: rgb(51, 204, 255);" class="Ih2E3d"><span class="nfakPe">snmp</span>-server enable traps bgp<br /></div><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><span style="color: rgb(51, 204, 255);">-server enable traps pim</span><br /><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><span style="color: rgb(51, 204, 255);">-server host 2.2.2.2 version 2c public bgp</span><br /><span style="color: rgb(51, 204, 255);" class="nfakPe">snmp</span><span style="color: rgb(51, 204, 255);">-server host 3.3.3.3 version 2c public pim</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#clear ip bgp *</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /><span style="color: rgb(51, 204, 255);">00:13:09: %BGP-5-ADJCHANGE: neighbor 172.12.14.4 Down User reset</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /><span style="color: rgb(51, 204, 255);">00:13:09: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: Queuing packet to 2.2.2.2</span><br /><span style="color: rgb(51, 204, 255);">00:13:09: </span><span style="color: rgb(51, 204, 255);" class="nfakPe">SNMP</span><span style="color: rgb(51, 204, 255);">: V2 Trap, reqid 21, errstat 0, erridx 0 </span><br /><span style="color: rgb(51, 204, 255);"> sysUpTime.0 = 78967 </span><br /><span style="color: rgb(51, 204, 255);"> snmpTrapOID.0 = bgpTraps.2 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.14.172.12.14.4 = 00 00 </span><br /><span style="color: rgb(51, 204, 255);"> bgpPeerEntry.2.172.12.14.4 = 1</span><br /><span style="color: rgb(255, 0, 0);">00:13:09: </span><span style="color: rgb(255, 0, 0);" class="nfakPe">SNMP</span><span style="color: rgb(255, 0, 0);">: Packet sent via UDP to 2.2.2.2</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /></pre></span>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com0tag:blogger.com,1999:blog-6193417800921617897.post-42587652873001614902009-02-11T15:14:00.000-08:002009-02-11T15:30:53.446-08:00Messin' around with multicast boundaryI got a multicast lab in dynamips going so I thought I would just play around with some lesser known commands and learn how they actually work.<br /><br />Here is the topology:<br /><br /><span style="color: rgb(51, 204, 0);">R5---R6---R1---R2---R3---R4</span><br /><br />R1 = MA and RP for 232/8, 233/8, 234/8<br /><pre><br /><span style="color: rgb(51, 204, 255);">R4#show ip pim rp mapping </span><br /><span style="color: rgb(51, 204, 255);">PIM Group-to-RP Mappings</span><br /><br /><span style="color: rgb(51, 204, 255);">Group(s) 232.0.0.0/8</span><br /><span style="color: rgb(51, 204, 255);"> RP 1.1.1.1 (?), v2v1</span><br /><span style="color: rgb(51, 204, 255);"> Info source: 1.1.1.1 (?), elected via Auto-RP</span><br /><span style="color: rgb(51, 204, 255);"> Uptime: 00:10:08, expires: 00:02:48</span><br /><span style="color: rgb(51, 204, 255);">Group(s) 233.0.0.0/8</span><br /><span style="color: rgb(51, 204, 255);"> RP 1.1.1.1 (?), v2v1</span><br /><span style="color: rgb(51, 204, 255);"> Info source: 1.1.1.1 (?), elected via Auto-RP</span><br /><span style="color: rgb(51, 204, 255);"> Uptime: 00:10:08, expires: 00:02:47</span><br /><span style="color: rgb(51, 204, 255);">Group(s) 234.0.0.0/8</span><br /><span style="color: rgb(51, 204, 255);"> RP 1.1.1.1 (?), v2v1</span><br /><span style="color: rgb(51, 204, 255);"> Info source: 1.1.1.1 (?), elected via Auto-RP</span><br /><span style="color: rgb(51, 204, 255);"> Uptime: 00:10:08, expires: 00:02:46</span><br /></pre><br />R4 has the following on Loopback 0:<br /><pre><br /><span style="color: rgb(51, 204, 255);">interface Loopback0</span><br /><span style="color: rgb(51, 204, 255);"> ip address 4.4.4.4 255.255.255.255</span><br /><span style="color: rgb(51, 204, 255);"> ip pim sparse-mode</span><br /><span style="color: rgb(51, 204, 255);"> ip igmp join-group 233.0.0.1</span><br /><span style="color: rgb(51, 204, 255);"> ip igmp join-group 234.0.0.1</span><br /></pre><br />R3 has set up a multicast boundary as follows:<br /><pre><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 232.0.0.0 0.255.255.255</span><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 233.0.0.0 0.255.255.255</span><br /><span style="color: rgb(51, 204, 255);"> </span><br /><span style="color: rgb(51, 204, 255);">interface Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> ip address 192.168.34.3 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);"> ip pim sparse-mode</span><br /><span style="color: rgb(51, 204, 255);"> ip multicast boundary 1</span><br /></pre><br />Now R3 only allows PIM joins that are in 232/8 or 233/8.<br /><pre><br /><span style="color: rgb(51, 204, 255);">R3#sho ip mroute 234.0.0.1</span><br /><span style="color: rgb(51, 204, 255);">Group 234.0.0.1 not found</span><br /><span style="color: rgb(51, 204, 255);">R3#</span><br /></pre><br />Let's ping 233.0.0.1:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R6#ping 233.0.0.1 re 100</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 100, 100-byte ICMP Echos to 233.0.0.1, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">......................................................................</span><br /><span style="color: rgb(51, 204, 255);">..........</span><br /></pre><br />Whoa now, what gives? Well...remember we only allowed 2 groups...what does Auto-RP use to propagate messages? Group 224.0.1.40! So even if you start passing traffic to 233.0.0.1 after you enable the boundary, eventually R3 will lose state for the Auto-RP discovery group and R4 will lose the RP information. All multicast traffic will then fail the RPF check.<br /><br />So here is our modified ACL on R3:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R3#sho run | inc access</span><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 224.0.1.40</span><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 233.0.0.0 0.255.255.255</span><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 232.0.0.0 0.255.255.255</span><br /></pre><br />224.0.1.39 is what the MA's listen to so we don't need to worry about that for this example. Now we can ping:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R6#ping 233.0.0.1 re 2 </span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 2, 100-byte ICMP Echos to 233.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="color: rgb(51, 204, 255);">Reply to request 0 from 192.168.34.4, 212 ms</span><br /><span style="color: rgb(51, 204, 255);">Reply to request 0 from 192.168.34.4, 216 ms</span><br /><span style="color: rgb(51, 204, 255);">Reply to request 1 from 192.168.34.4, 184 ms</span><br /><span style="color: rgb(51, 204, 255);">Reply to request 1 from 192.168.34.4, 184 ms</span><br /></pre><br />Now this seems a little inefficient, right? Why should R4 even know about the RP if R3 is going to prevent mroute state from being created for 234.0.0.1 on that interface. If we could prevent R4 from learning that RP information, that would be great. Well on R3 we can modify the boundary as follows:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R3(config)#int s1/0 </span><br /><span style="color: rgb(51, 204, 255);">R3(config-if)#ip multicast boundary 1 filter-autorp</span><br /></pre><br />Now R3 only sends RP information for the groups permitted in the ACL:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R4#show ip pim rp mapping </span><br /><span style="color: rgb(51, 204, 255);">PIM Group-to-RP Mappings</span><br /><br /><span style="color: rgb(51, 204, 255);">Group(s) 232.0.0.0/8</span><br /><span style="color: rgb(51, 204, 255);"> RP 1.1.1.1 (?), v2v1</span><br /><span style="color: rgb(51, 204, 255);"> Info source: 1.1.1.1 (?), elected via Auto-RP</span><br /><span style="color: rgb(51, 204, 255);"> Uptime: 00:00:03, expires: 00:02:55</span><br /><span style="color: rgb(51, 204, 255);">Group(s) 233.0.0.0/8</span><br /><span style="color: rgb(51, 204, 255);"> RP 1.1.1.1 (?), v2v1</span><br /><span style="color: rgb(51, 204, 255);"> Info source: 1.1.1.1 (?), elected via Auto-RP</span><br /><span style="color: rgb(51, 204, 255);"> Uptime: 00:00:03, expires: 00:02:53</span><br /><span style="color: rgb(51, 204, 255);">R4#</span><br /></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-24392387423865579812009-02-11T09:28:00.000-08:002009-02-11T09:32:21.858-08:00Multicast TTL-ThresholdMaybe I am misunderstanding some things, but documents and books always say that the TTL of a packet must be higher than the threshold to be forwarded. From the 12.4 command reference:<br /><br /><a href="http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1011911">ip multicast ttl-threshold</a><br /><br /><span style="font-weight: bold;">Usage Guidelines</span><br /><br />"Only multicast packets with a TTL value greater than the threshold are forwarded out the interface."<br /><br />Oh yeah?! I guess it depends on when you look at the TTL. Consider the network:<br /><br />R1----R2----R3----R4<br /><br />PIM-DM is enabled everywhere.<br />R4 has joined 239.0.0.1<br />R1 is sending pings which have 255 TTL when sent from R1.<br />R2 receives the PING, decrements the TTL to 254 before sending to R3.<br /><br />So if we set TTL threshold to 254 on R2's interface to R3, it should block it right? No:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2(config)#int s1/0</span><br /><span style="color: rgb(51, 204, 255);">R2(config-if)#ip multicast ttl-threshold 254</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#ping 239.0.0.1 </span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><br /><span style="color: rgb(51, 204, 255);">Reply to request 0 from 192.168.34.4, 164 ms</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /></pre><br />The router will still pass packets that have a TTL equal to the threshold if it was the router that decremented the TTL to reach that value. Here we see 255 will fail:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2(config)#int s1/0</span><br /><span style="color: rgb(51, 204, 255);">R2(config-if)#ip multicast ttl-threshold 255</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#ping 239.0.0.1</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">.</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com4tag:blogger.com,1999:blog-6193417800921617897.post-85172748375879225132009-02-08T10:32:00.000-08:002009-02-08T11:05:53.212-08:00IE Mock Lab 4 ReviewIf you plan on taking this lab, don't read this post as it may contain some spoilers. I took this lab yesterday and did okay, though I could have done a lot better. I got a 73, but I finished in about 4 hours. After verifying the whole the lab for the next 2 hours, I didn't really make any major changes. In fact, the only error I noticed was that I had an OSPF key configured wrong. Turns out, there was more...<br /><br />"Do not configure anything on SW3 for this task." This refers to every thing in this task!<br /><br />In a hub spoke topology, we were only allowed one map statement on one of the spokes. This means we need that map statement for L3/L2 resolution to the other spoke, then rely on INARP for spoke-to-hub resolution. On the hub, I mapped by local IP for self-ping (which was not required) which in effect turns of INARP for that IP. The bottom line is INARP has to be enabled on one end. My mappings did show up dynamically, but the grader said this wouldn't work after a reboot. I am going to lab this up again and verify.<br /><br />I missed 3 tasks (out of 13) in the IGP section. One was impossible (IMO) but by looking at the SG it appears the task itself was worded incorrectly, had to do with summarizing in OSPF on R3 and R5. The SG has them summarizing <span style="font-weight: bold;">SW2 </span>and <span style="font-weight: bold;">R5 </span>which are in the same area so it would have worked. The task said to summarize <span style="font-weight: bold;">R3 </span>and <span style="font-weight: bold;">R5</span>, which are not in the same area. Another IGP task required a tunnel with a new adressing. I think this violates the rule (clearly stated at the beginning) that we are not allowed to add any addresses. Lastly, I failed to redistribute a BB link into an IGP.<br /><br />My traffic filter in the security task was fine except I didn't allow IGMP, which then caused me to miss one multicast task. Two Birds, One stone. Meh.<br /><br />The other two tasks I missed involved TFTP: Limiting access to a router's config via SNMP, and TFTP boot. These were definitely doable, I was just unfamiliar with a couple commands and configured "half-solutions" which are just as good as "no-solutions" :-)<br /><br />This lab was rated a 9 (from what I here the real thing is about a 7 or so) and recommended by IE to take within the final month of preparation. The grade report wasn't too detailed but then again, there was not a whole lot to explain. The tasks I did miss, were very simple mistakes. There is also a report that says how well you did in relation to other people who took this lab. For example, I got an 11% in NAT which means 89% people also got this right. Each task has a breakdown like this.<br /><br />I try not to put too much stock in that though. I just want to learn from my mistakes and work on time management. I know a couple people who failed miserably on mocks and then passed the lab. And I am sure there are people who did great on mocks, then failed the real thing. I would rather be part of that first group :-)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com0tag:blogger.com,1999:blog-6193417800921617897.post-16335506961866944712009-02-04T11:06:00.000-08:002009-02-04T11:22:29.018-08:00Overlapping/Duplicate AS-External-LSA IDsI was reading <a href="http://www.amazon.com/OSPF-Anatomy-Internet-Routing-Protocol/dp/0201634724"><span style="font-style: italic;">OSPF: Anatomy of an Internet Routing Protocol</span></a> by John T. Moy today and I came across an issue with AS-external LSA Link-State IDs. The LSA uses the network address as the identifier. If one router was to generate multiple Type 5 LSA's with the same network number but different masks, only 1 would be advertised because the LSA ID would be the same.<br /><br />The book was published in 1998 and at the time there was no way of dealing with this. After doing this lab, I realized there was a way and it had since been documented in Appendix E of RFC 2328:<br /><br /><a href="http://tools.ietf.org/html/rfc2328#appendix-E">RFC 2328 Appendix E</a><br /><br />Here I create 3 static routes, that all end up with the same network number and would normally have the same LSA ID:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1(config)#ip route 192.9.0.0 255.255.0.0 Null0 </span><br /><span style="color: rgb(51, 204, 255);">R1(config)#ip route 192.9.0.0 255.255.254.0 Null0</span><br /><span style="color: rgb(51, 204, 255);">R1(config)#ip route 192.9.0.0 255.255.255.0 Null0</span><br /><span style="color: rgb(51, 204, 255);">R1(config)#router ospf 1</span><br /><span style="color: rgb(51, 204, 255);">R1(config-router)#redistribute static subnets </span><br /></pre><br />Let's see what the LSA IDs are:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1#sho ip osp database | inc 192.9</span><br /><span style="color: rgb(51, 204, 255);">192.9.0.0 1.1.1.1 246 0x80000001 0x00933F 0</span><br /><span style="color: rgb(255, 0, 0);">192.9.0.255 1.1.1.1 149 0x80000001 0x00933F 0</span><br /><span style="color: rgb(255, 0, 0);">192.9.1.255 1.1.1.1 234 0x80000001 0x00834F 0</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#sho ip ospf database external 192.9.0.0</span><br /><br /><span style="color: rgb(51, 204, 255);"> OSPF Router with ID (1.1.1.1) (Process ID 1)</span><br /><br /><span style="color: rgb(51, 204, 255);"> Type-5 AS External Link States</span><br /><br /><span style="color: rgb(51, 204, 255);"> LS age: 14</span><br /><span style="color: rgb(51, 204, 255);"> Options: (No TOS-capability, DC)</span><br /><span style="color: rgb(51, 204, 255);"> LS Type: AS External Link</span><br /><span style="color: rgb(51, 204, 255);"> Link State ID: 192.9.0.0 (External Network Number )</span><br /><span style="color: rgb(51, 204, 255);"> Advertising Router: 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);"> LS Seq Number: 80000003</span><br /><span style="color: rgb(51, 204, 255);"> Checksum: 0x8F41</span><br /><span style="color: rgb(51, 204, 255);"> Length: 36</span><br /><span style="color: rgb(51, 204, 255);"> <span style="color: rgb(255, 0, 0);"> Network Mask: /16</span></span><br /><span style="color: rgb(51, 204, 255);"> Metric Type: 2 (Larger than any link state path)</span><br /><span style="color: rgb(51, 204, 255);"> TOS: 0 </span><br /><span style="color: rgb(51, 204, 255);"> Metric: 20 </span><br /><span style="color: rgb(51, 204, 255);"> Forward Address: 0.0.0.0</span><br /><span style="color: rgb(51, 204, 255);"> External Route Tag: 0</span><br /></pre><br />The router gives the last 2 networks the broadcast address of that respective network as the Link State ID. The /16 network got the network address as the ID. I wonder if order of operations has anything to do with it<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1(config)#no ip route 192.9.0.0 255.255.0.0 Null0</span><br /><span style="color: rgb(51, 204, 255);">R1(config)#no ip route 192.9.0.0 255.255.254.0 Null0</span><br /><span style="color: rgb(51, 204, 255);">R1(config)#no ip route 192.9.0.0 255.255.255.0 Null0</span><br /><span style="color: rgb(51, 204, 255);">R1(config)#ip route 192.9.0.0 255.255.255.0 Null0 </span><br /></pre><br />Ok, so now the /24 is the only in there and it is using 192.9.0.0 as its ID:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1#sho ip osp database external 192.9.0.0</span><br /><br /><span style="color: rgb(51, 204, 255);"> OSPF Router with ID (1.1.1.1) (Process ID 1)</span><br /><br /><span style="color: rgb(51, 204, 255);"> Type-5 AS External Link States</span><br /><br /><span style="color: rgb(51, 204, 255);"> LS age: 36</span><br /><span style="color: rgb(51, 204, 255);"> Options: (No TOS-capability, DC)</span><br /><span style="color: rgb(51, 204, 255);"> LS Type: AS External Link</span><br /><span style="color: rgb(51, 204, 255);"> Link State ID: 192.9.0.0 (External Network Number )</span><br /><span style="color: rgb(51, 204, 255);"> Advertising Router: 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);"> LS Seq Number: 80000001</span><br /><span style="color: rgb(51, 204, 255);"> Checksum: 0x933F</span><br /><span style="color: rgb(51, 204, 255);"> Length: 36</span><br /><span style="color: rgb(51, 204, 255);"> <span style="color: rgb(255, 0, 0);">Network Mask: /24</span></span><br /><span style="color: rgb(51, 204, 255);"> Metric Type: 2 (Larger than any link state path)</span><br /><span style="color: rgb(51, 204, 255);"> TOS: 0 </span><br /><span style="color: rgb(51, 204, 255);"> Metric: 20 </span><br /><span style="color: rgb(51, 204, 255);"> Forward Address: 0.0.0.0</span><br /><span style="color: rgb(51, 204, 255);"> External Route Tag: 0</span><br /></pre><br />What happens if we add a /16 now?<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1(config)#ip route 192.9.0.0 255.255.0.0 Null0</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#sho ip osp database external 192.9.0.0</span><br /><br /><span style="color: rgb(51, 204, 255);"> OSPF Router with ID (1.1.1.1) (Process ID 1)</span><br /><br /><span style="color: rgb(51, 204, 255);"> Type-5 AS External Link States</span><br /><br /><span style="color: rgb(51, 204, 255);"> LS age: 12</span><br /><span style="color: rgb(51, 204, 255);"> Options: (No TOS-capability, DC)</span><br /><span style="color: rgb(51, 204, 255);"> LS Type: AS External Link</span><br /><span style="color: rgb(51, 204, 255);"> Link State ID: 192.9.0.0 (External Network Number )</span><br /><span style="color: rgb(51, 204, 255);"> Advertising Router: 1.1.1.1</span><br /><span style="color: rgb(51, 204, 255);"> LS Seq Number: 80000002</span><br /><span style="color: rgb(51, 204, 255);"> Checksum: 0x9140</span><br /><span style="color: rgb(51, 204, 255);"> Length: 36</span><br /><span style="color: rgb(51, 204, 255);"> <span style="color: rgb(255, 0, 0);">Network Mask: /16</span></span><br /><span style="color: rgb(51, 204, 255);"> Metric Type: 2 (Larger than any link state path)</span><br /><span style="color: rgb(51, 204, 255);"> TOS: 0 </span><br /><span style="color: rgb(51, 204, 255);"> Metric: 20 </span><br /><span style="color: rgb(51, 204, 255);"> Forward Address: 0.0.0.0</span><br /><span style="color: rgb(51, 204, 255);"> External Route Tag: 0</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /></pre><br />The /16 stold the ID from the /24!<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1#sho ip osp database | inc 192.9 </span><br /><span style="color: rgb(51, 204, 255);">192.9.0.0 1.1.1.1 45 0x80000002 0x009140 0</span><br /><span style="color: rgb(51, 204, 255);">192.9.0.255 1.1.1.1 45 0x80000001 0x00933F 0</span><br /></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com0tag:blogger.com,1999:blog-6193417800921617897.post-57706766706712199592009-02-03T10:16:00.001-08:002009-02-03T10:35:33.875-08:00How OSPF transmit capability can prevent virtual-link routing loopsI ran into the command "capability transit" some time ago but never really understood how it worked. The explanation in the RFC and the DocCD may seem pretty vague unless you understand what issues cause it to be necessary or desirable. It is on by default so you probably will never have any issues with it, but I find it an interesting feature to look into. And by doing so, you tend to learn more about how OSPF works.<br /><br />In this lab, I turn it off so we can see what issues arise. We will focus on R2's path to R4's loopback of 4.4.4.4. Each router's interface IP address ends ends with the router number so we can tell easily where traffic is flowing. Here is the topology:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-CflxkszbJpUyHMdIGI8Yw_rkjvLKCH0oG0CnjdJV2PtWnKm1RJlEx6iyRk2ya1mJy8ssceEkn4rTHO19MXP-bEtmOe4IhRcZIBSiV-K8aoynhWteaVftKwpnNFC3Auxg7HWKaJNbHcM/s1600-h/ospf+transit+lab.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 183px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-CflxkszbJpUyHMdIGI8Yw_rkjvLKCH0oG0CnjdJV2PtWnKm1RJlEx6iyRk2ya1mJy8ssceEkn4rTHO19MXP-bEtmOe4IhRcZIBSiV-K8aoynhWteaVftKwpnNFC3Auxg7HWKaJNbHcM/s400/ospf+transit+lab.jpg" alt="" id="BLOGGER_PHOTO_ID_5298636933849881570" border="0" /></a><br />I disabled capability transit on all routers, but I found that in this lab R2 is where the action is, so that might be only place we need to do it:<br /><pre><br /><span style="color: rgb(51, 204, 255);">router ospf 1</span><br /><span style="color: rgb(51, 204, 255);"> no capability transit</span><br /></pre><br />Now we begin...<br /><br />R1 has a virtual link to R3 in order to connect area 234 to area 0. This works fine. R3 has become an ABR and R2 will use R3 to get to R4's loopback:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho ip route 4.4.4.4<br />Routing entry for 4.4.4.4/32<br />Known via "ospf 1", distance 110, metric 66, type inter area<br />Last update from 192.168.23.3 on Serial1/0, 00:00:07 ago<br />Routing Descriptor Blocks:<br />* 192.168.23.3, from 3.3.3.3, 00:00:07 ago, via Serial1/0<br /> Route metric is 66, traffic share count is 1</span><br /></pre><br /><br />Now let's say R2 needs to add a network to area 2 as follows<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2(config)#int lo 0</span><br /><span style="color: rgb(51, 204, 255);">R2(config-if)#ip address 2.2.2.2 255.255.255.255</span><br /><span style="color: rgb(51, 204, 255);">R2(config-if)#ip ospf 1 area 2</span><br /></pre><br />Since R2 does not have an interface in area 0 we can build a virtual-link to R1:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2(config)#router ospf 1 </span><br /><span style="color: rgb(51, 204, 255);">R2(config-router)#area 123 virtual-link 1.1.1.1 </span><br /><br /><span style="color: rgb(51, 204, 255);">R1(config)#router ospf 1 </span><br /><span style="color: rgb(51, 204, 255);">R1(config-router)#area 123 virtual-link 2.2.2.2</span><br /><span style="color: rgb(51, 204, 255);">*Mar 1 00:59:19.191: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on<br />OSPF_VL3 from LOADING to FULL, Loading Done</span><br /></pre><br />Perfect, right?<br /><br />Let's take a look at that route towards R4 again:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho ip route 4.4.4.4</span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 4.4.4.4/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 194, type inter area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.12.1 on Serial1/1, 00:00:04 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.12.1, from 3.3.3.3, 00:00:04 ago, via Serial1/1</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 194, traffic share count is 1</span><br /></pre><br />Oh-no...Let's trace:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#trace 4.4.4.4 </span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Tracing the route to 4.4.4.4</span><br /><br /><span style="color: rgb(51, 204, 255);"> 1 192.168.12.1 72 msec 24 msec 8 msec</span><br /><span style="color: rgb(51, 204, 255);"> 2 192.168.12.2 56 msec 20 msec 84 msec</span><br /><span style="color: rgb(51, 204, 255);"> 3 * * *</span><br /><span style="color: rgb(51, 204, 255);"> 4 * * *</span><br /></pre><br />We have a loop all-right.To fix it, on R2:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2(config)#router ospf 1</span><br /><span style="color: rgb(51, 204, 255);">R2(config-router)#capability transit</span><br /><br /><span style="color: rgb(51, 204, 255);">R2#clear ip ospf process</span><br /><span style="color: rgb(51, 204, 255);">Reset ALL OSPF processes? [no]: yes</span><br /><span style="color: rgb(51, 204, 255);">R2#</span><br /></pre><br />Few moments later:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho ip route 4.4.4.4</span><br /><span style="color: rgb(51, 204, 255);">Routing entry for 4.4.4.4/32</span><br /><span style="color: rgb(51, 204, 255);"> Known via "ospf 1", distance 110, metric 66, type inter area</span><br /><span style="color: rgb(51, 204, 255);"> Last update from 192.168.23.3 on Serial1/0, 00:00:18 ago</span><br /><span style="color: rgb(51, 204, 255);"> Routing Descriptor Blocks:</span><br /><span style="color: rgb(51, 204, 255);"> * 192.168.23.3, from 3.3.3.3, 00:00:18 ago, via Serial1/0</span><br /><span style="color: rgb(51, 204, 255);"> Route metric is 66, traffic share count is 1</span><br /></pre><br />From cisco.com<br /><br />"The OSPF Area Transit Capability feature provides an OSPF Area Border Router (ABR) with the ability to discover shorter paths through the transit area for forwarding traffic that would normally need to travel through the virtual-link path."<br /><br /><a href="http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfatc.html">OSPF Area Transit Capability</a><br /><br />So in this case, we have allowed R2 to use it direct path to R3 instead of it's own path through the backbone area. We have basically made area 123 a transit area that can carry traffic to destinations not in it's own area. We are flowing from Area 0 (R2 is an ABR now) to Area 123 to Area 234!<br /><br />Since this command is enabled by default on recent IOS versions, I am not sure you would ever run into this issue in the lab. However, it is still an interesting feature and it is always good to know what's really going on under the hood :-)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com7tag:blogger.com,1999:blog-6193417800921617897.post-7888111114953067762009-02-02T11:59:00.000-08:002009-02-02T12:26:08.690-08:003560 QoS: Per-port per-vlan policingI know the name is scary, but I do dig Catalyst QoS. This is the second of back-to-back posts on the subject. This is one is a little more complex than classification and decided on a Visio for it:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikZggAbnH1b_vx5kEawINdGdbaDfCHUxaBNGClpdEaLR0R76y9cXkFHSgAMo0WedP0wcxZkwZLYPALKgNeQ_tw5oDfH8pXYR-kv4VbP3zc_fxabUmygHUPOc7GaXH74WavWW6FCXY8xQQ/s1600-h/3560+lab.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 191px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikZggAbnH1b_vx5kEawINdGdbaDfCHUxaBNGClpdEaLR0R76y9cXkFHSgAMo0WedP0wcxZkwZLYPALKgNeQ_tw5oDfH8pXYR-kv4VbP3zc_fxabUmygHUPOc7GaXH74WavWW6FCXY8xQQ/s400/3560+lab.jpg" alt="" id="BLOGGER_PHOTO_ID_5298292875755941170" border="0" /></a><br />Per-van policing in the 3560s is different from the 3550s because there is no "match VLAN" clause available. Instead you create hierarchical policies and attach them to the SVI.<br /><br />Here is the scenario:<br /><br />VLAN100 will be policed to 64k (192.168.100.0/24)<br />VLAN200 Will be policed to 128k (192.168.200.0/24)<br /><br />Because of bursts, I was not able to get these exact rates, but you will see how these policies are applied and the effect they have on traffic flow. Plus you can always play with the burst sizes on your own :)<br /><br />Here is the tracker I created on R2:<br /><pre><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 192.168.100.1</span><br /><span style="color: rgb(51, 204, 255);">access-list 1 permit 192.168.100.3</span><br /><span style="color: rgb(51, 204, 255);">access-list 2 permit 192.168.200.5</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">class-map match-any VLAN100</span><br /><span style="color: rgb(51, 204, 255);"> match access-group 1</span><br /><span style="color: rgb(51, 204, 255);">class-map match-any VLAN200</span><br /><span style="color: rgb(51, 204, 255);"> match access-group 2</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">policy-map TRACKER</span><br /><span style="color: rgb(51, 204, 255);"> class VLAN100</span><br /><span style="color: rgb(51, 204, 255);"> class VLAN200</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Ethernet0/0</span><br /><span style="color: rgb(51, 204, 255);"> no ip address</span><br /><span style="color: rgb(51, 204, 255);"> load-interval 30</span><br /><span style="color: rgb(51, 204, 255);"> full-duplex</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Ethernet0/0.100</span><br /><span style="color: rgb(51, 204, 255);"> encapsulation dot1Q 100</span><br /><span style="color: rgb(51, 204, 255);"> ip address 192.168.100.2 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input TRACKER</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Ethernet0/0.200</span><br /><span style="color: rgb(51, 204, 255);"> encapsulation dot1Q 200</span><br /><span style="color: rgb(51, 204, 255);"> ip address 192.168.200.2 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input TRACKER</span><br /></pre><br />All configuration is being done on SW2. There really is not an order of operations to follow, but basically you just need to make sure class-maps and policy-maps are created before you apply them. The logical flow is what you want to get used to. Otherwise you will be jumping into and out of classes and policies, reconfiguring them like I did :)<br /><br />At our child (aka "second") level we have a class-map that matches the interface and we have our policer. The interface matching here is whats is referred into in the first clause of "per-port per-vlan" policing.<br /><pre><br /><span style="color: rgb(51, 204, 255);">class-map match-all TRUNK</span><br /><span style="color: rgb(51, 204, 255);"> match input-interface FastEthernet0/13</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">policy-map VLAN100-POLICER</span><br /><span style="color: rgb(51, 204, 255);"> class TRUNK</span><br /><span style="color: rgb(51, 204, 255);"> police 64000 12000 exceed-action drop</span><br /><span style="color: rgb(51, 204, 255);">policy-map VLAN200-POLICER</span><br /><span style="color: rgb(51, 204, 255);"> class TRUNK</span><br /><span style="color: rgb(51, 204, 255);"> police 128000 24000 exceed-action drop</span><br /></pre><br />As far as I know, this "bottom" or "second" level class-map can only match input-interface. And this second level policy must be a policer.<br /><br />Now, at the parent level we create a new class to match IP traffic and then apply our child polices below that. This top-level class must match an ACL (match protocol ip gave me errors when applying the policy).<br /><pre><br /><span style="color: rgb(51, 204, 255);">access-list 100 permit ip any any</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">class-map match-all IP</span><br /><span style="color: rgb(51, 204, 255);"> match access-group 100</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">policy-map VLAN100-PARENT</span><br /><span style="color: rgb(51, 204, 255);"> class IP</span><br /><span style="color: rgb(51, 204, 255);"> set ip precedence 1</span><br /><span style="color: rgb(51, 204, 255);"> service-policy VLAN100-POLICER</span><br /><span style="color: rgb(51, 204, 255);">policy-map VLAN200-PARENT</span><br /><span style="color: rgb(51, 204, 255);"> class IP</span><br /><span style="color: rgb(51, 204, 255);"> set ip precedence 2</span><br /><span style="color: rgb(51, 204, 255);"> service-policy VLAN200-POLICER</span><br /></pre><br />Notice that I have the "set ip precedence" clause in our parent policies. These first level policies are required to have an action. You will get an error message stating this if you try to apply it to the SVI without an action:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">SW2(config)#int vlan 100 </span><br /><span style="font-family:courier new;">SW2(config-if)#service-policy input VLAN100-PARENT</span><br /><span style="font-family:courier new;">%QoS: No action is configured in the policymap VLAN100-PARENT classmap IP, or it is being modified.</span></span><br /><br />So make sure you have set or trust clause in there. Now we can apply them to the SVIs:<br /><pre><br /><span style="color: rgb(51, 204, 255);">mls qos<br />!<br />interface FastEthernet0/13</span><br /><span style="color: rgb(51, 204, 255);"> mls qos vlan-based</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Vlan100</span><br /><span style="color: rgb(51, 204, 255);"> no ip address</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input VLAN100-PARENT</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Vlan200</span><br /><span style="color: rgb(51, 204, 255);"> no ip address</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input VLAN200-PARENT</span><br /></pre><br />From R1, R3 and R5 I will send a bunch of pings to R2:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R1#ping 192.168.100.2 re 1000000</span><br /><span style="color: rgb(51, 204, 255);">R3#ping 192.168.100.2 re 1000000</span><br /><span style="color: rgb(51, 204, 255);">R5#ping 192.168.200.2 re 1000000</span><br /></pre><br />Let's look at R2 after a few minutes.<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho policy-map interface e0/0.100 | section VLAN100</span><br /><span style="color: rgb(51, 204, 255);"> Class-map: VLAN100 (match-any)</span><br /><span style="color: rgb(51, 204, 255);"> 107819 packets, 12722642 bytes</span><br /><span style="color: rgb(51, 204, 255);"> 30 second offered rate 50000 bps</span><br /><span style="color: rgb(51, 204, 255);"> Match: access-group 1</span><br /><span style="color: rgb(51, 204, 255);"> 107819 packets, 12722642 bytes</span><br /><span style="color: rgb(51, 204, 255);"> 30 second rate 50000 bps</span><br /><br /><span style="color: rgb(51, 204, 255);">R2#sho policy-map interface e0/0.200 | section VLAN200</span><br /><span style="color: rgb(51, 204, 255);"> Class-map: VLAN200 (match-any)</span><br /><span style="color: rgb(51, 204, 255);"> 156873 packets, 18511014 bytes</span><br /><span style="color: rgb(51, 204, 255);"> 30 second offered rate 107000 bps</span><br /><span style="color: rgb(51, 204, 255);"> Match: access-group 2</span><br /><span style="color: rgb(51, 204, 255);"> 156873 packets, 18511014 bytes</span><br /><span style="color: rgb(51, 204, 255);"> 30 second rate 107000 bps</span><br /></pre><br />We don't see the limits of 64k and 128k being reached, but the drops on the senders indicate that policing is working. And we can also tell VLAN 200 is getting roughly twice the bandwidth that VLAN 100 is getting. We could get closer to the limit by adjusting the burst sizes appropriately.<br /><br /><span style="color: rgb(51, 255, 51);">Key things to remember:</span><br /><ul><li>Child classes use match input-interface</li><li>Child policies use police</li><li>Parent classes match ACL (I think you can also match dscp, maybe others)<br /></li><li>Parent policies must have an action (e.g. set or trust)</li><li>Apply parent policies to SVI</li></ul>I strongly recommend getting your hands dirty with these configurations if you want to master them. I read a lot about switch qos, but it wasn't until I started playing around with scenarios like this that I got a better understanding of how to do it and what is required. If we truly understand what each QoS method does, then we should have no trouble deciphering what we are asked to do on the lab :)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com5tag:blogger.com,1999:blog-6193417800921617897.post-17315333646592905732009-02-02T09:08:00.001-08:002009-02-02T09:13:06.259-08:003560 QoS: VLAN-Based ClassificationThis is a topic I learned about while reading blogs over at IE. Here is the original:<br /><br /><a href="http://blog.internetworkexpert.com/2008/09/11/comparing-traffic-policing-features-in-the-3550-and-3560-switches/">Comparing Traffic Policing Features in the 3550 and 3560 switches </a><br /><br />I have the following topology:<br /><br />R1----|<br />R3---SW1---SW2---R2<br />R5----|<br /><br />R1,R3 are in vlan 100, 192.168.100.0/24<br />R5 is in vlan 200, 192.168.200.0/24<br /><br />R2 is on a trunked port with the following configuration:<br /><pre><br /><span style="color: rgb(51, 204, 255);">interface Ethernet0/0.100</span><br /><span style="color: rgb(51, 204, 255);"> encapsulation dot1Q 100</span><br /><span style="color: rgb(51, 204, 255);"> ip address 192.168.100.2 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);"> ip accounting precedence input</span><br /><span style="color: rgb(51, 204, 255);"> no snmp trap link-status</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Ethernet0/0.200</span><br /><span style="color: rgb(51, 204, 255);"> encapsulation dot1Q 200</span><br /><span style="color: rgb(51, 204, 255);"> ip address 192.168.200.2 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);"> ip accounting precedence input</span><br /><span style="color: rgb(51, 204, 255);"> no snmp trap link-status</span><br /></pre><br />On SW2 we will enable vlan-based qos and then mark traffic based on ACLs. First we make the ACLs:<br /><pre><br /><span style="color: rgb(51, 204, 255);">ip access-list extended ICMP</span><br /><span style="color: rgb(51, 204, 255);"> permit icmp any any</span><br /><span style="color: rgb(51, 204, 255);">ip access-list extended TCP</span><br /><span style="color: rgb(51, 204, 255);"> permit tcp any any</span><br /></pre><br />Next we make our class-maps and policy-maps:<br /><pre><br /><span style="color: rgb(51, 204, 255);">class-map match-all ICMP</span><br /><span style="color: rgb(51, 204, 255);"> match access-group name ICMP</span><br /><span style="color: rgb(51, 204, 255);">class-map match-all TCP</span><br /><span style="color: rgb(51, 204, 255);"> match access-group name TCP</span><br /><br /><span style="color: rgb(51, 204, 255);">policy-map VLAN</span><br /><span style="color: rgb(51, 204, 255);"> class TCP</span><br /><span style="color: rgb(51, 204, 255);"> set ip precedence 5</span><br /><span style="color: rgb(51, 204, 255);"> class ICMP</span><br /><span style="color: rgb(51, 204, 255);"> set ip precedence 3</span><br /></pre><br />Next enable mls qos, vlan-based qos and apply the policy to an SVI. Note that the SVI does not need an IP address:<br /><pre><br /><span style="color: rgb(51, 204, 255);">mls qos</span><br /><br /><span style="color: rgb(51, 204, 255);">int f0/13</span><br /><span style="color: rgb(51, 204, 255);"> interface FastEthernet0/13</span><br /><span style="color: rgb(51, 204, 255);"> switchport trunk encapsulation dot1q</span><br /><span style="color: rgb(51, 204, 255);"> switchport trunk native vlan 50</span><br /><span style="color: rgb(51, 204, 255);"> switchport mode trunk</span><br /><span style="color: rgb(51, 204, 255);"> mls qos vlan-based</span><br /><br /><span style="color: rgb(51, 204, 255);">int vlan 100</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input VLAN</span><br /><span style="color: rgb(51, 204, 255);">int vlan 200</span><br /><span style="color: rgb(51, 204, 255);"> service-policy input VLAN</span><br /></pre><br />Now run some tests. Here I Ping and Telnet from R5, telnet from R1 and then ping from R3:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R5#ping 192.168.200.2 rep 100</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 100, 100-byte ICMP Echos to 192.168.200.2, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!</span><br /><span style="color: rgb(51, 204, 255);">!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!</span><br /><span style="color: rgb(51, 204, 255);">Success rate is 100 percent (100/100), round-trip min/avg/max = 1/3/4 ms</span><br /><span style="color: rgb(51, 204, 255);">R5#</span><br /><br /><span style="color: rgb(51, 204, 255);">R5#telnet 192.168.200.2</span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.200.2 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R2>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.200.2 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R5#</span><br /><br /><span style="color: rgb(51, 204, 255);">R1#telnet 192.168.100.2 </span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.100.2 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R2>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.100.2 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R1#</span><br /><br /><span style="color: rgb(51, 204, 255);">R3#ping 192.168.100.2 re 50</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 50, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!</span><br /><span style="color: rgb(51, 204, 255);">Success rate is 100 percent (50/50), round-trip min/avg/max = 1/3/4 ms</span><br /><span style="color: rgb(51, 204, 255);">R3#</span><br /></pre><br />Verify on R2:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho int precedence </span><br /><span style="color: rgb(51, 204, 255);">Ethernet0/0.100 </span><br /><span style="color: rgb(51, 204, 255);"> Input</span><br /><span style="color: rgb(51, 204, 255);"> Precedence 3: 50 packets, 5900 bytes</span><br /><span style="color: rgb(51, 204, 255);"> Precedence 5: 46 packets, 2953 bytes</span><br /><span style="color: rgb(51, 204, 255);">Ethernet0/0.200 </span><br /><span style="color: rgb(51, 204, 255);"> Input</span><br /><span style="color: rgb(51, 204, 255);"> Precedence 3: 100 packets, 11800 bytes</span><br /><span style="color: rgb(51, 204, 255);"> Precedence 5: 15 packets, 969 bytes</span><br /><span style="color: rgb(51, 204, 255);">R2#</span><br /></pre>deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com0tag:blogger.com,1999:blog-6193417800921617897.post-61927211531166091752009-02-01T19:41:00.000-08:002009-02-01T19:46:43.696-08:00TCP Load Balancing, Destination NATThe "ip nat inside destination" command can be used to split up the load from what looks like one global destination, to several inside hosts. This behaves very much like server load balancing, at least without all the health checks.<br /><br />Below is the topology. I have static default routes from R1, R2, and R3 pointing to R4. R7 has a static route to each serial link.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFFQU_2jZeh_lR5RI82rog0wM6gUD_KJc2TeCYlEUqBkHSMcU46mkOgkBPA0DjTgI4Dklir0h8iAY2TNOqCi3xkeUeb15Vz25npC45l0dL1f_7p_hYptlEHDK-Q0YWzh496pT-MpZvWfQ/s1600-h/destination+NAT+Scenario.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 271px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFFQU_2jZeh_lR5RI82rog0wM6gUD_KJc2TeCYlEUqBkHSMcU46mkOgkBPA0DjTgI4Dklir0h8iAY2TNOqCi3xkeUeb15Vz25npC45l0dL1f_7p_hYptlEHDK-Q0YWzh496pT-MpZvWfQ/s400/destination+NAT+Scenario.jpg" alt="" id="BLOGGER_PHOTO_ID_5298040780397967890" border="0" /></a><br />Here is R4's config:<br /><pre><br /><span style="color: rgb(51, 204, 255);">interface FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);">ip address 192.168.0.4 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);">ip nat inside</span><br /><span style="color: rgb(51, 204, 255);">ip virtual-reassembly</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Serial1/0</span><br /><span style="color: rgb(51, 204, 255);">ip address 192.168.45.4 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);">ip verify unicast reverse-path</span><br /><span style="color: rgb(51, 204, 255);">ip nat outside</span><br /><span style="color: rgb(51, 204, 255);">ip virtual-reassembly</span><br /><span style="color: rgb(51, 204, 255);">serial restart-delay 0</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface Serial1/1</span><br /><span style="color: rgb(51, 204, 255);">ip address 192.168.46.4 255.255.255.0</span><br /><span style="color: rgb(51, 204, 255);">ip verify unicast reverse-path</span><br /><span style="color: rgb(51, 204, 255);">ip nat outside</span><br /><span style="color: rgb(51, 204, 255);">ip virtual-reassembly</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">ip route 0.0.0.0 0.0.0.0 192.168.45.5</span><br /><span style="color: rgb(51, 204, 255);">ip route 0.0.0.0 0.0.0.0 192.168.46.6</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">ip nat pool POOL 192.168.0.1 192.168.0.3 prefix-length 24 type rotary</span><br /><span style="color: rgb(51, 204, 255);">ip nat inside destination list 10 pool POOL</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">access-list 10 permit 192.168.45.10</span><br /><span style="color: rgb(51, 204, 255);">access-list 10 permit 192.168.46.10</span><br /></pre><br />From R7 we will verify:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R7#telnet 192.168.45.10 </span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.45.10 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R1></span><br /><span style="color: rgb(51, 204, 255);">R1>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.45.10 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R7#telnet 192.168.45.10</span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.45.10 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R2>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.45.10 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R7#telnet 192.168.45.10</span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.45.10 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R3>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.45.10 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R7#telnet 192.168.46.10</span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.46.10 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R1>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.46.10 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R7#telnet 192.168.46.10</span><br /><span style="color: rgb(51, 204, 255);">Trying 192.168.46.10 ... Open</span><br /><br /><span style="color: rgb(51, 204, 255);">R2>exit</span><br /><br /><span style="color: rgb(51, 204, 255);">[Connection to 192.168.46.10 closed by foreign host]</span><br /><span style="color: rgb(51, 204, 255);">R7#</span><br /></pre><br />R4's NAT table:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R4#sho ip nat translations</span><br /><span style="color: rgb(51, 204, 255);">Pro Inside global Inside local Outside local Outside global</span><br /><span style="color: rgb(51, 204, 255);">tcp 192.168.45.10:23 192.168.0.1:23 200.0.0.7:51519 200.0.0.7:51519</span><br /><span style="color: rgb(51, 204, 255);">tcp 192.168.46.10:23 192.168.0.1:23 200.0.0.7:64139 200.0.0.7:64139</span><br /><span style="color: rgb(51, 204, 255);">tcp 192.168.46.10:23 192.168.0.2:23 200.0.0.7:11691 200.0.0.7:11691</span><br /><span style="color: rgb(51, 204, 255);">tcp 192.168.45.10:23 192.168.0.2:23 200.0.0.7:62913 200.0.0.7:62913</span><br /><span style="color: rgb(51, 204, 255);">tcp 192.168.45.10:23 192.168.0.3:23 200.0.0.7:17295 200.0.0.7:17295</span><br /></pre><br />I used two links just to show the flexibility of this configuration. I was playing around with route-map NAT failover/LB and then decided to work on this scenario.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com8tag:blogger.com,1999:blog-6193417800921617897.post-68269062359496027182009-02-01T11:24:00.001-08:002009-02-01T12:08:45.464-08:00NTP - How long is too long?This is how long I waited for NTP to sync today:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2(config)#ntp server 136.10.4.4</span></span><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2(config)#^Z</span><br /><span style="font-family:courier new;">Feb 1 19:26:53.915: %SYS-5-CONFIG_I: Configured from console by console</span><br /><br /><span style="font-family:courier new;">Feb 1 19:37:11.852: NTP Core(NOTICE): Clock is synchronized.</span></span><br /><br />More than 10 minutes. It should be noted that the clocks were only seconds apart to begin with. Code on these routers is 12.4(22)T. I don't know if I have ever waited so long but it's unbelievably ridiculous.<br /><br />Then I enable authentication:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R4(config)#ntp authentication-key 1 md5 ipexpert</span><br /><br /><span style="font-family:courier new;">R2(config)#ntp authentication-key 1 md5 ipexpert</span><br /><span style="font-family:courier new;">R2(config)#ntp trusted-key 1</span><br /><span style="font-family:courier new;">R2(config)#ntp authenticate</span><br /><span style="font-family:courier new;">R2(config)#ntp server 136.10.4.4 key 1 </span><br /><br /><span style="font-family:courier new;">Feb 1 19:45:02.628: NTP Core(INFO): key (1) added.</span><br /><span style="font-family:courier new;">Feb 1 19:45:02.752: NTP Core(INFO): key (1) marked as trusted.</span><br /><span style="font-family:courier new;">Feb 1 19:45:03.276: NTP Core(INFO): system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 10 events, event_peer/strat_chg' (0xC0A4)</span><br /><span style="font-family:courier new;">Feb 1 19:45:03.276: NTP Core(NOTICE): Clock synchronization lost.</span></span><br /><br />Peers never come up, I get this every so often (debug ntp all):<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">.Feb 1 19:45:47.852: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 19:45:47.852: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 19:45:47.852: NTP Core(DEBUG): ntp_receive: message received</span><br /><span style="font-family:courier new;">.Feb 1 19:45:47.852: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.</span><br /><span style="font-family:courier new;">.Feb 1 19:45:47.852: NTP Core(NOTICE): ntp_receive: dropping message: crypto-NAK.</span><br /><br /><span style="font-family:courier new;">.Feb 1 19:50:52.852: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 19:50:52.852: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 19:50:52.852: NTP Core(DEBUG): ntp_receive: message received</span><br /><span style="font-family:courier new;">.Feb 1 19:50:52.852: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.</span><br /><span style="font-family:courier new;">.Feb 1 19:50:52.852: NTP Core(NOTICE): ntp_receive: dropping message: crypto-NAK.</span></span><br /><br />Here we are still<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:85%;" >.Feb 1 19:58:19.851: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).<br />.Feb 1 19:58:19.851: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).<br />.Feb 1 19:58:19.851: NTP Core(DEBUG): ntp_receive: message received<br />.Feb 1 19:58:19.851: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.<br />.Feb 1 19:58:19.851: NTP Core(NOTICE): ntp_receive: dropping message: crypto-NAK</span>.<br /><br />So, for kicks on the master I do this:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R4(config)#ntp authenticate</span><br /><span style="font-family:courier new;">R4(config)#ntp trusted-key 1</span></span><br /><br />I now get a new message on R2:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:85%;" >.Feb 1 20:01:20.851: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).<br />.Feb 1 20:01:20.851: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).<br />.Feb 1 20:01:20.851: NTP Core(DEBUG): ntp_receive: message received<br />.Feb 1 20:01:20.851: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.<br />.Feb 1 20:01:20.851: NTP Core(DEBUG): receive: packet given to process_packet</span><br /><br />This looks promising:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2#</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP Core(DEBUG): ntp_receive: message received</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP Core(DEBUG): receive: packet given to process_packet</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.</span><br /><span style="font-family:courier new;">.Feb 1 20:03:30.851: NTP Core(INFO): peer 136.10.4.4 event 'event_reach' (0x84) status 'unreach, conf, auth, 1 event, event_reach' (0xE014)</span></span><br /><br />TA-DA!<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">.Feb 1 20:06:43.851: NTP Core(NOTICE): Clock is synchronized.</span></span><br /><br />I have never had to enable trusted-key on the master before. Watch this:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R4(config)#no ntp trusted-key 1</span></span><br /><br />Back on R2:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R2#</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP message sent to 136.10.4.4, from interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP message received from 136.10.4.4 on interface 'Loopback0' (136.10.2.2).</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP Core(DEBUG): ntp_receive: message received</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP Core(DEBUG): ntp_receive: peer is 0x674B9DF8, next action is 1.</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP Core(INFO): system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xC0F4)</span><br /><span style="font-family:courier new;">Feb 1 20:07:47.851: NTP Core(NOTICE): Clock synchronization lost.</span><br /><span style="font-family:courier new;">.Feb 1 20:07:47.851: NTP Core(NOTICE): ntp_receive: dropping message: crypto-NAK.</span></span><br /><br />Maybe something has changed in this T train but looks like we need "ntp trusted-key" on the Master now. I am not an NTP guru by any means but if you look at some of my other ntp blogs, you will see I didn't need this command. Note that I only needed "trusted-key" on the Master, not "ntp authenticate" even though I showed it above. Removing it did not cause sync loss. Something to keep in mind if you find yourself singing the NTP blues.<br /><br />Oh, and while you are waiting for the sync - go configure something else in the meantime!deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-53041584076624980692009-01-31T17:48:00.000-08:002009-01-31T18:34:01.576-08:00IPexpert Volume 3 Mock Lab 1 - Take 2I did this lab again today mainly to see how much I improved since the first time. If your curious, here was my original post:<br /><br /><a href="http://ccietobe.blogspot.com/2008/07/review-ipexpert-volume-3-mock-lab-1.html">IPexpert Volume 3 Mock Lab 1 - Take 1</a><br /><br />That was just over 5 months ago, and I more than doubled my score and finished in about half the time. I got a 91 this time, missing 3 tasks. The first one was a grading script error. The second one was a bonehead mistake because the task said to prevent odd routes and I blocked odd (BGP task).<br /><br />The last one was tricky and I skipped it because I did not know how to complete it without messing up another task. It was 2 points vs 3 points and I took the 3-pointer. I will explain what the issue was and how to resolve it.<br /><br />The first task had you allow telnet only on port 3005 of R9. Then you create a privilege 15 user named cisco with a password cisco. The next task says that the user cisco should only be allowed to do show commands and not configure anything. Menus are not allowed.<br /><br />Well....since user cisco is a level 15 user he can do anything he wants. And he HAS to be a level 15 user according to the first task. The solution was to configure AAA which basically ignores privilege levels that are assigned to username commands. Now, when user cisco logs in, he is actually in level 1 and he cannot get to configuration mode (without an enable password). Do you think this violates the previous task?<br /><br />Anyways, it felt good to know that I have retained a lot of info. I'm going to do another mock lab tomorrow morning from IPexpert (<span style="font-style: italic;">Before </span>the Super Bowl of course!). Then next week I have an IE mock lab and another proctor lab session scheduled. The week after that, it will be Cisco Assessor Labs on the 14th and 15th (if my schedule gets accepted).<br /><br />That leaves one more weekend of nothing which I plan on just reviewing and tying up loose ends. Probably play around on the home lab most of the time. Then the next weekend I will be in San Jose :-)deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com1tag:blogger.com,1999:blog-6193417800921617897.post-8562615779190863922009-01-31T10:33:00.000-08:002009-12-04T08:24:11.693-08:00RSPAN between 3550 and 3560 - Multiple SourcesTopology is as follows:<br /><br />R5----SW1----SW2----SW4----R4/R6<br /><br />R4 and R6 are on VLAN 300, 192.168.250.0/24 subnet<br />R5 is on VLAN 100, connected to port f0/5 of SW1<br />Inter-switch links are dot1q trunks<br />I will set up RSPAN between the switches and use debug ip packet with an ACL to verify.<br /><br />3550 is the source:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">SW4(config)#vlan 999</span><br /><span style="font-family:courier new;">SW4(config-vlan)#remote-span</span><br /><span style="font-family:courier new;">SW4(config)#monitor session 1 source vlan 300 rx</span><br /><span style="font-family:courier new;">SW4(config)#monitor session 1 destination remote vlan 999 reflector-port f0/12</span></span><br /><br />3560 is connected to the monitor:<br /><span style="font-size:85%;"><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >SW1(config)#monitor session 1 source remote vlan 999</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >SW1(config)#monitor session 1 destination interface f0/12 </span></span><br /><br />On R5 We can verify like this:<br /><br /><span style="font-size:85%;"><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5(config)#access-list 1 permit 192.168.250.4 0.0.0.0<br />R5(config)#access-list 1 permit 192.168.250.6 0.0.0.0<br />R5(config)#no service timestamps debug<br />R5#debug ip packet 1 detail<br />IP packet debugging is on (detailed) for access list 1<br />IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89<br />IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89<br />IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89<br />IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89</span></span><br /><br />Here we can see EIGRP packets from VLAN 300, which verifies our monitoring is working. The only place I specified "remote-span" under a VLAN was the source 3550. However, I have read that that this required on all switches that carry the remote-span VLAN.<br /><br />Let's add a source on SW2, where R2 is plugged into f0/2. We will put it on a different VLAN just to prove it is working:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">SW2(config)#int f0/2</span><br /><span style="font-family:courier new;">SW2(config-if)#sw a v 150</span></span><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">SW2(config)#vlan 999</span><br /><span style="font-family:courier new;">SW2(config-vlan)#remote-span </span></span><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">SW2(config)#monitor session 1 source interface f0/2</span><br /><span style="font-family:courier new;">SW2(config)#monitor session 1 destination remot vlan 999</span><br /></span><br />If we jump to R5, we won't see any packets from R2...hmm...oh yeah, the ACL!<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R5(config)#access-list 1 permit 192.168.0.2 0.0.0.0</span></span><br /><br />There we go:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">IP: <span style="color: rgb(255, 0, 0);">s=192.168.0.2</span> (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0</span><br /><span style="font-family:courier new;"> UDP src=1985, dst=1985</span><br /><span style="font-family:courier new;">IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.5, len 88, rcvd 0, proto=89</span><br /><span style="font-family:courier new;">IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89</span><br /><span style="font-family:courier new;">IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0</span><br /><span style="font-family:courier new;"> UDP src=1985, dst=1985</span><br /><span style="font-family:courier new;">IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89</span></span><br /><br />Looks like we got HSRP packets from R2 and OSPF packets from R4 and R6.<br /><br /><span style="color: rgb(51, 255, 51); font-weight: bold;">Key things to remember:</span><br /><br />-Reflector port needed on 3550<br />-<span style="font-weight: bold;">remote-span</span> command used under the RSPAN VLAN. In this example, I only did it on the source, but I would verify that you need it on all devices with this VLAN.<br />-To allow destination port to connect back to the network use "ingress" keyword on session destination commanddeadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com3tag:blogger.com,1999:blog-6193417800921617897.post-87735236673279838182009-01-30T10:17:00.000-08:002009-01-30T10:30:50.222-08:00EIGRP Bounded updatesI was reading about EIGRP in Routing TCP/IP Volume 1 by Jeff Doyle and focusing on the comparisons between it and distance vector and link-state protocols. One characteristic of EIGRP that sets it part from other protocols is that updates are "bounded" meaning that they are only sent to the "affected" neighbors. I was trying to find a way to see this behavior in action so I created this summarization scenario.<br /><br />R4 is in the middle of the star with R3,R5 and R7 at the edges:<br /><br />R4-R5 = 192.168.45.0/24<br />R4-R7 = 192.168.47.0/24<br />R4-R3 = 192.168.34.0/24<br /><br />R4 is advertising a summary of 192.168.44.0/22 to R3.<br />If a new link was brought up in the /22 range, R4 will not send an update to R3.<br /><br />Here it is in action:<br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R3#debug eigrp packets update </span><br /><span style="font-family:courier new;">R4#debug eigrp packets update </span><br /><span style="font-family:courier new;">R5#debug eigrp packets update </span></span><br /><br /><span style="color: rgb(51, 204, 255);font-size:85%;" ><span style="font-family:courier new;">R3#sho ip route eigrp </span><br /><span style="font-family:courier new;">D 192.168.44.0/22 [90/2681856] via 192.168.34.4, 00:02:54, Serial1/1</span></span><br /><br />R7 is off of R4 serial 1/1, R3 is off of R4 serial 1/0:<br /><br /><span style="font-size:85%;"><span style="color: rgb(51, 204, 255);font-family:courier new;" >R4#sho ip eigrp ne </span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >IP-EIGRP neighbors for process 1</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >H Address Interface Hold Uptime SRTT RTO Q Seq</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" > (sec) (ms) Cnt Num</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >1 192.168.47.7 Se1/1 10 00:11:55 75 450 0 8</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >2 192.168.34.3 Se1/0 13 00:30:39 106 636 0 8</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >0 192.168.45.5 Se1/2 12 00:32:16 106 636 0 8</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >R4#</span></span><br /><br />Let's add a new loopback on R5 in the range of the summary:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:85%;" >R5(config)#int lo 1<br />R5(config-if)#ip address 192.168.46.5 255.255.255.0<br />R5(config-if)#router eigrp 1<br />R5(config-router)#network 192.168.46.5 0.0.0.0<br /><br />*Mar 1 20:02:59.075: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 8-8<br />*Mar 1 20:02:59.079: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.45.4 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 8-8<br />*Mar 1 20:02:59.087: EIGRP: Sending UPDATE on Serial1/0 nbr 192.168.45.4<br />*Mar 1 20:02:59.095: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 8-8<br />*Mar 1 20:02:59.235: EIGRP: Received UPDATE on Serial1/0 nbr 192.168.45.4<br />*Mar 1 20:02:59.235: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0</span><br /><br />R5 sends an update to R4. R4 only sends it to R7:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:85%;" >*Mar 1 20:02:59.515: EIGRP: Received UPDATE on Serial1/2 nbr 192.168.45.5<br />*Mar 1 20:02:59.519: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0<br />*Mar 1 20:02:59.563: EIGRP: Enqueueing UPDATE on Serial1/1 iidbQ un/rely 0/1 serno 11-11<br />*Mar 1 20:02:59.567: EIGRP: Enqueueing UPDATE on Serial1/1 nbr 192.168.47.7 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11<br />*Mar 1 20:02:59.575: EIGRP: Sending UPDATE on Serial1/1 nbr 192.168.47.7<br />*Mar 1 20:02:59.579: AS 1, Flags 0x0, Seq 24/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11<br />*Mar 1 20:02:59.583: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 11-11<br />*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.34.3 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11<br />*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/2 iidbQ un/rely 0/1 serno 11-11<br />*Mar 1 20:02:59.591: EIGRP: Enqueueing UPDATE on Serial1/2 nbr 192.168.45.5 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11<br />*Mar 1 20:02:59.591: EIGRP: Sending UPDATE on Serial1/2 nbr 192.168.45.5<br />*Mar 1 20:02:59.591: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11</span><br /><br />And of course on R3 we see nothing. What's really interesting is we see R4 "Enqueuing" the update but never actually sending it as it does to R5 and R7.<br /><br />I am still not sure of one thing though. Is this a fundamental characteristic of EIGRP itself or the fact that we are summarizing? I cannot think of another scenario where this "bounded" update scenario would take place without summarization. If you can, please drop a comment.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com2tag:blogger.com,1999:blog-6193417800921617897.post-42626784871316876412009-01-27T13:39:00.000-08:002009-01-27T13:59:05.250-08:00OSPFv3 Neighbors do not need to be on same subnetCheck it out:<br /><br /><span style="color: rgb(51, 255, 51);">R2 F0/0 <-----> F0/0 R3</span><br /><br />Here is R2's config:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho run int f0/0</span><br /><span style="color: rgb(51, 204, 255);">Building configuration...</span><br /><br /><span style="color: rgb(51, 204, 255);">Current configuration : 153 bytes</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);"> no ip address</span><br /><span style="color: rgb(51, 204, 255);"> duplex auto</span><br /><span style="color: rgb(51, 204, 255);"> speed auto</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 address 2001:2::2/64</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 address FE80::2 link-local</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 ospf 1 area 0</span><br /><span style="color: rgb(51, 204, 255);">end</span><br /></pre><br />Here is R3's config:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R3#sho run int f0/0</span><br /><span style="color: rgb(51, 204, 255);">Building configuration...</span><br /><br /><span style="color: rgb(51, 204, 255);">Current configuration : 153 bytes</span><br /><span style="color: rgb(51, 204, 255);">!</span><br /><span style="color: rgb(51, 204, 255);">interface FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);"> no ip address</span><br /><span style="color: rgb(51, 204, 255);"> duplex auto</span><br /><span style="color: rgb(51, 204, 255);"> speed auto</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 address 2001:3::3/64</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 address FE80::3 link-local</span><br /><span style="color: rgb(51, 204, 255);"> ipv6 ospf 1 area 0</span><br /><span style="color: rgb(51, 204, 255);">end</span><br /></pre><br />R2's show commands:<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#sho ipv6 ospf ne </span><br /><br /><span style="color: rgb(51, 204, 255);">Neighbor ID Pri State Dead Time Interface ID Interface</span><br /><span style="color: rgb(51, 204, 255);">3.3.3.3 1 FULL/DR 00:00:35 4 FastEthernet0/0</span><br /><br /><span style="color: rgb(51, 204, 255);">R2#sho ipv6 route </span><br /><span style="color: rgb(51, 204, 255);">IPv6 Routing Table - 5 entries</span><br /><span style="color: rgb(51, 204, 255);">Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP</span><br /><span style="color: rgb(51, 204, 255);"> U - Per-user Static route</span><br /><span style="color: rgb(51, 204, 255);"> I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary</span><br /><span style="color: rgb(51, 204, 255);"> O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2</span><br /><span style="color: rgb(51, 204, 255);"> ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2</span><br /><span style="color: rgb(51, 204, 255);">C 2001:2::/64 [0/0]</span><br /><span style="color: rgb(51, 204, 255);"> via ::, FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);">L 2001:2::2/128 [0/0]</span><br /><span style="color: rgb(51, 204, 255);"> via ::, FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);">O 2001:3::/64 [110/10]</span><br /><span style="color: rgb(51, 204, 255);"> via ::, FastEthernet0/0</span><br /><span style="color: rgb(51, 204, 255);">L FE80::/10 [0/0]</span><br /><span style="color: rgb(51, 204, 255);"> via ::, Null0</span><br /><span style="color: rgb(51, 204, 255);">L FF00::/8 [0/0]</span><br /><span style="color: rgb(51, 204, 255);"> via ::, Null0</span><br /></pre><br />R2 can now ping 2001:3::3<br /><pre><br /><span style="color: rgb(51, 204, 255);">R2#ping 2001:3::3</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">!!!!!</span><br /><span style="color: rgb(51, 204, 255);">Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/56 ms</span><br /><span style="color: rgb(51, 204, 255);">R2#</span><br /></pre><br />This is possible because neighbors are known by their router-ids and link-local addresses are used as next hops, not the actual interface addresses.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com0tag:blogger.com,1999:blog-6193417800921617897.post-28762639280833337052009-01-26T20:11:00.000-08:002009-01-26T20:28:14.550-08:00Dynamic ARP Inspection with NON-DHCP hostsThe Dynamic ARP Inspection concept is well understood, but sometimes the commands and requirements can be hard to remember. This scenario shows how DAI works with DHCP snooping to block ARP requests from untrusted ports and how NON-DHCP clients can still be apart of the network.<br /><br />R1,R3 and R5 are all on VLAN100, connected to switch SW1:<br /><br />R1 = Static host<br />R3 = DHCP Server<br />R5 = DHCP client<br /><br />SW1 has ARP Inspection and DHCP snooping enabled already, with trust enabled on the port connected to R3.<br /><br /><pre><span style="color: rgb(51, 204, 255);">SW1#sho run | inc snoop|arp</span><br /><span style="color: rgb(51, 204, 255);">ip dhcp snooping vlan 100</span><br /><span style="color: rgb(51, 204, 255);">ip dhcp snooping</span><br /><span style="color: rgb(51, 204, 255);">ip arp inspection vlan 100</span><br /><span style="color: rgb(51, 204, 255);"> ip dhcp snooping trust</span><br /><br /></pre>R5 gets an IP address from R3 and now we have the following entry on SW1:<br /><br /><pre><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1#sho ip dhcp snooping binding </span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >MacAddress IpAddress Lease(sec) Type VLAN Interface</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >------------------ ----------- ---------- ------------- ---- ---------------</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >00:00:00:00:00:05 192.168.0.5 86381 dhcp-snooping 100 FastEthernet0/5</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Total number of bindings: 1</span><br /></pre><br />R5 tries to ping R1 but can't:<br /><pre><br /><span style="color: rgb(51, 204, 255);font-size:100%;" >R5#ping 192.168.0.1</span><span style="font-size:100%;"><br /><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Type escape sequence to abort.</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:</span><span style="font-size:100%;"><br /><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Jan 7 09:36:20.361: IP: tableid=0, s=192.168.0.5 (local), d=192.168.0.1<br /> (Ethernet0/0), routed via RIB</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Jan 7 09:36:20.361: IP: s=192.168.0.5 (local), d=192.168.0.1 (Ethernet0/0),<br /> len 100, sending</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Jan 7 09:36:20.361: ICMP type=8, code=0</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Jan 7 09:36:20.361: IP ARP: creating incomplete entry for IP address:<br /> 192.168.0.1 interface Ethernet0/0</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Jan 7 09:36:20.361: IP ARP: sent req src 192.168.0.5 0000.0000.0005,</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > dst 192.168.0.1 0000.0000.0000 Ethernet0/0</span><br /></pre><br />On SW1 we see this:<br /><pre><br /><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1#debug arp </span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >07:43:49: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/1, vlan 100.<br />([0000.0000.0001/192.168.0.1/0000.0000.0005/192.168.0.5/07:43:49 UTC Mon Mar 1 1993])</span><span style="font-size:85%;"><br /></span></pre><br />SW1 is not allowing the ARP reply from R1 because the port is untrusted in the arp inspection configuration and R1's address is not in the DHCP snooping database. We can see the request make it on R1:<br /><pre><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >R1#</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Mar 2 00:31:09.685: IP ARP: rcvd req src 192.168.0.5 0000.0000.0005,<br /> dst 192.168.0.1 Ethernet0/0</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >*Mar 2 00:31:09.685: IP ARP: sent rep src 192.168.0.1 0000.0000.0001,</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > dst 192.168.0.5 0000.0000.0005 Ethernet0/0</span><br /></pre><br />But R5 never gets the reply. For NON-DHCP hosts we can create an ARP ACL and apply it to the DAI configuration:<br /><pre><br /><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config)#arp access-list ARP-TEST </span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config-arp-nacl)#permit ip host 192.168.0.1 ?</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > mac Sender MAC address</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac ?</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > H.H.H Sender MAC address</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > any Any MAC address</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" > host Single Sender host</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac host 0000.0000.0001</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config-arp-nacl)#exit</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1(config)#ip arp inspection filter ARP-TEST vlan 100 </span><br /></pre><br />Now let's ping:<br /><pre><br /><span style="color: rgb(51, 204, 255);font-size:100%;" >R5#ping 192.168.0.1</span><span style="font-size:100%;"><br /><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Type escape sequence to abort.</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >.!!!!</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >Success rate is 80 percent (4/5), round-trip min/avg/max = 8/9/12 ms</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >R5#</span><br /></pre><br />There is another option for the DAI filter and that is "static".<br /><pre><br /><span style="color: rgb(51, 204, 255);">SW1(config)#ip arp inspection filter ARP-TEST vlan 100 ?</span><br /><span style="color: rgb(51, 204, 255);"> static Apply the ACL statically</span><br /><span style="color: rgb(51, 204, 255);"> <cr></cr></span><br /></pre><br />If we applied this argument to the command, DAI would only check the ARP ACL and not fallback to the DHCP snooping database. That would prevent R5 ARPs from being allowed:<br /><pre><br /><span style="color: rgb(51, 204, 255);">SW1(config)#ip arp inspection filter ARP-TEST vlan 100 static </span><br /><br /><span style="color: rgb(51, 204, 255);">R5#ping 192.168.0.1</span><br /><br /><span style="color: rgb(51, 204, 255);">Type escape sequence to abort.</span><br /><span style="color: rgb(51, 204, 255);">Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:</span><br /><span style="color: rgb(51, 204, 255);">.....</span><br /><span style="color: rgb(51, 204, 255);">Success rate is 0 percent (0/5)</span><br /><span style="color: rgb(51, 204, 255);">R5#</span><br /></pre><br />Check debugs on SW1:<br /><pre><br /><span style="color: rgb(51, 204, 255);font-size:100%;" >SW1#</span><span style="font-size:100%;"><br /></span><span style="color: rgb(51, 204, 255);font-size:100%;" >07:52:53: %SW_DAI-4-ACL_DENY: 1 Invalid ARPs (Req) on Fa0/5, vlan 100.<br />([0000.0000.0005/192.168.0.5/0000.0000.0000/192.168.0.1/07:52:53 UTC Mon Mar 1 1993])</span><br /></pre><br />Requests are being denied inbound on f0/5 now.deadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com6tag:blogger.com,1999:blog-6193417800921617897.post-91903613081316876752009-01-26T15:16:00.000-08:002009-01-26T15:46:27.233-08:00RSH/RCP - quick and easyThis is one of those topics that probably won't be in the exam, but it can't hurt to learn it if its easy enough.<br /><br />On R3, I have:<br /><br /><span style="color: rgb(51, 204, 255);font-size:100%;" ><span style="font-family:courier new;">R3#sho run | inc rcmd</span><br /><span style="font-family:courier new;">ip rcmd remote-username R3</span><br /><span style="font-family:courier new;">ip rcmd source-interface Loopback0</span></span><br /><br />On R5, I have:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:100%;" >R5#sho run | inc rcmd<br />ip rcmd rsh-enable<br />ip rcmd remote-host cisco 172.16.0.3 R3 enable<br />ip rcmd source-interface Loopback0</span><br /><br />On R3:<br /><pre><span style="color: rgb(51, 204, 255);">R3#rsh 172.16.0.5 /user cisco sho run int lo0<br /><br />Building configuration...<br /><br />Current configuration : 63 bytes<br />!<br />interface Loopback0<br />ip address 172.16.0.5 255.255.255.255<br />end<br /><br />R3#</span><br /></pre>Now Let's do some RCP file copying:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5(config)#ip rcmd rcp-enable </span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5(config)#^Z</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >R5#copy run r5test.txt</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >Destination filename [r5test.txt]? </span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >Erase flash: before copying? [confirm]n</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >Verifying checksum... OK (0xFD5B)</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >2714 bytes copied in 4.856 secs (559 bytes/sec)</span><br /><span style="color: rgb(51, 204, 255);font-family:courier new;" >Rack1R5#</span><br /><br />Copy from R3:<br /><br /><span style="color: rgb(51, 204, 255);font-family:courier new;font-size:100%;" >R3#copy rcp://cisco@172.16.0.5/R5test.txt flash:<br />Destination filename [R5test.txt]?<br />Accessing rcp://cisco@172.16.0.5/R5test.txt...<br />Erase flash: before copying? [confirm]n!<br />Verifying checksum... OK (0xFD5B)<br />2714 bytes copied in 0.644 secs (4214 bytes/sec)<br />R3#</span><br /><span style="color: rgb(51, 255, 51);"><br />Key things to remember:</span><br /><br />-Server side has two names in that rcmd command<br />-First one must match /user on client<br />-Second one must match client hostname or client "remote-username" commanddeadhead blueshttp://www.blogger.com/profile/10566569168999502387noreply@blogger.com1