Qstyk

Members
  • Content count

    12
  • Joined

  • Last visited

  • Days Won

    1

Qstyk last won the day on March 7 2013

Qstyk had the most liked content!

Community Reputation

-10 Poor

About Qstyk

  • Rank
    Newbie
  • Birthday July 2

Profile Information

  • Gender
    Male
  1. When working my way through a practice lab, I encountered the following scenario in a hub-and-spoke environment. R5 (hub): point-to-multipoint subinterface R4 (spoke): point-to-point subinterface R6 (spoke): physical interface My natural inclination is to force the physical interface (R6) to a point-to-point interface, the multipoint (R4) to point-to-multipoint, and have R5 be a point-to-point interface. Everything seemed to configure properly, until I entered in the neighbor statements. At that point, I received the message: From Cisco's error message decoder, this means that: The configured neighbor was found on a point-to-multipoint broadcast network. Either the cost or database-filter option needs to be configured. Recommended Action: Check the configuration options for the neighbor command and correct the options or the network type for the neighbor's interface. My first thought was that this was due to changing the type on the physical interface, but I received this message when applying the neighbor message to both spokes. My next thought was that this could be because the broadcast flag on my map statements was on the link-local address and not the physical, but this did not appear to matter, after switching. My question is two-fold: What caused the error message? The fact that the altered physical interface was a part of the network at all? My method of handling this topology was to use "ipv6 ospf network non-broadcast" on each interface. Is this the best method and if not, what should I have done differently? Thanks in advance, -Jon
  2. Literally, from a bare config, the commands were: queue-list 1 default 0 queue-list 1 protocol ip 1 list 7 I'm doing this in GNS3, but I've tried it with a 1700, 2600, 2691, 3600, 3700, and 7200. It appears that anything that's not in the default queue gets dumped into queue two.
  3. Out of the many things Cisco does well, I'd have to say their NAT syntax is a festering pile of dung, sorely in need of an overhaul. That having been said, I'm perfectly open to the possibility that I may have a flaw in my understanding of the configuration of it. Please consider the following: The routers are connected as such: (R1)---fast-e---(R2)---serial---(R3). In the tests, we attempt to ping R3's loopback (172.17.255.7) from R1. The R2 NAT configuration is as follows: ip nat pool NAT_POOL 10.10.10.10 10.10.10.19 netmask 255.255.255.0 access-list 199 permit icmp any host 172.17.255.7 ip nat inside source list 199 pool NAT_POOL int fa 0/0 ip nat inside int ser 0/0 ip nat outside This is met with total failure. The source of the ping (R1's fa0/0 inteface of 172.17.1.5) remains unchanged. I've tried changing the ip nat inside/outside statements to ip nat enable to no avail. I'd appreciate the insight and explanation from someone with a better understanding of this than I apparently have. Apparently, the same holds true of my understanding of static NAT. When attempting to NAT the source based on a static entry, the following command yielded no success: ip nat source static 172.17.1.5 20.20.20.20
  4. I'm afraid not - same result, though I had to change "tcp" to "ip." To my knowledge, these are completely software-based queues, so there shouldn't be any sort of limitation. r4#show queueing custom Current custom queue configuration: List Queue Args 1 2 protocol ip list 7 1 2 protocol ip list 6
  5. Am I missing something here? The following config: queue-list 1 default 0 queue-list 1 protocol ip 1 list 7 Yields the following output: R1(config)#do show queueing custom Current custom queue configuration: List Queue Args 1 0 default 1 2 protocol ip list 7 Despite having specified queue 1 to be associated with access-list seven, we see that it is associated with queue 2. Why is that?
  6. Just out of curiousity, why are you looking to do that? Typically, VPNV4 routes are exchanged in an MPLS environment. I don't think there's a lot to it. I'm not in a position to lab this up at the moment, so what follows is literally of the top of my head, but I believe the basics would go like this: router bgp <ASN> neighbor <w.x.y.z> remote-as <far-end ASN> address-family vpnv4 neighbor <w.x.y.z> activate neighbor <w.x.y.z> send-community both You may need to do some ebgp-multihop to get the relationship to come up. Typically, VPNV4 routes are exchanged via loopback addresses and via iBGP sessions. If this helps, please respond back with some details regarding what you're trying to accomplish and what you had to do to make it work. I suspect there are others that are curious, as well. Good luck! -Jon
  7. Congratulations! Keep record of your passing score and date, as you'll need to reference them to schedule your lab. I signed up for the Cisco 360 program through CCBootCamp. I'm taking the CIERS1&2 classes and their advanced mock lab bootcamp. It comes with all of the materials you'll need, as far as workbooks and reading goes, though I'm augmenting with some other CBT's and reading on the side. So far, my studying is taking twice as long as I had expected it to, but I shall persist.
  8. Got a 921/1000. Materials: CCBootCamp R&S written bootcamp book, the bootcamp itself, and a LOT (4 months) of study and practice. I went through the book and configured almost every technology mentioned in it. GNS3 was profanely helpful. Am doing the Cisco 360 program through CCBootCamp, so am now working my way through their lab curriculum.
  9. Found the issue! PIM wasn't configured on R6 s0/0. Thank you for your help. The process you were taking me through was very educational. New tricks I learned as a result of this thread: sh ip rpf <w.x.y.z> show ip mroute count
  10. Reconfigured as such. R6 fa1/0 now has the "ip igmp static-group 224.1.2.3" command and R2 fa1/0 has the "ip igmp join-group 224.1.2.3" command. When I look on R6, I see that it has a *,G entry with the appropriate outbound interface of fa1/0, but no inbound interface: (*, 224.1.2.3), 04:02:04/00:02:38, RP 10.10.255.4, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet1/0, Forward/Sparse-Dense, 00:05:19/00:02:38 PIM debugging on R6 yields: Nov 29 04:38:42.852: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.1.2.3 Nov 29 04:38:43.452: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40 Nov 29 04:39:42.649: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.1.2.3 Likewise, on R4 (the RP) I see no outbound interface for the S,G stream. (*, 224.1.2.3), 06:33:06/stopped, RP 10.10.255.4, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (10.10.1.1, 224.1.2.3), 05:05:13/00:02:22, flags: P Incoming interface: Serial0/0, RPF nbr 10.10.3.3 Outgoing interface list: Null It's almost like R6 isn't sending the join message to the RP, much less trying to join the SPT. Please note the "pruned" (P) flag in the R4 mroute entry.
  11. I gave that a try and it did give me more debugging information, rather than just having it get stuffed into the cache, but the issue persists. I've got 10 years of routing/switching experience and none of it involved mcast, hence my issues. I've attached my router configs - is there something that jumps out at you? configs.zip
  12. This should NOT be this difficult, but I'm having issues configuring a static RP. Imagine (picture attached) a router with four routers, R3, R4, R5, and R6, all connected sequentially via serial cables, with R6 connected back to R3. IP connectivity is flawless, OSPF is running throughout. Connected to R5 is R1, firing off UDP SLA probes to 224.1.2.3 on port 777. Connected to R6 is R2, my receiver. It's R6 interface is statically joined via an "ip igmp join-group" command on it's interface on R6. R3-R6 are running sparse-dense mode and everything works fine. Running debug on R2 (the receiver,) I see the packets just fine. As soon as I add a static RP command in on R3-R6, pointing at R4's loopback, R2 no longer sees traffic. What gives?