Ivan,
1. Not sure if I fully understood the question but for QinQ in general one
link should be configured as trunk and the other end as the tunnel port.
Routers configured with subinterfaces emulate the trunk end (packets are
tagged across that link). Now when you configure it, you should assign a
tunnel port to a VLAN ID that is *dedicated* to tunneling plus each customer
requires a separate service-provider VLAN ID (metro tag).
3. I think that depending on IOS version it will not let you assign the
DLCI already mapped via the main interface. It will be a good idea to
configure main interface with frame-relay encapsulation and no IP address.
Then remove all subinterfaces configured, save the config and reload the
router. After a reload you should be able to configure a p2p subinterface,
assign it an IP address and move DLCI from the main interface to this p2p
subinterface using "frame-relay interface-dlci" command.
Regards,
-- Piotr Kaluzny CCIE #25665 (Security), CCSP, CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com On Tue, Feb 16, 2010 at 7:21 PM, Ivan Hrvatska <ivanzghr_at_gmail.com> wrote: > Hi, > > since I'm going through the prep for CCIE R&S I'm writing down some > questions to ask you guys: > > 1. QINQ - In scenario where you have R1 router connected on SW1 and R2 > router connected in SW2, and connection of switches goes like this > R1--SW1---SW3---SW4---SW2---R2. Task is to configure dot1q tunnel > (QinQ). Routers R1 and R2 have subinterfaces, one in VLAN 12 and the > other in VLAN 34. Routers are connected to appropriate switches to > access port in VLAN 12. After configuring that access port as dot1q > tunnel I have communication between R1 and R2 through both VLAN 12 and > VLAN 34. My question is, how come that service provider's VLAN 12 > (access port on SW1 and SW2) doesn't get in the way for customer VLAN > 12 (R1 and R2 are customer routers)? > > 2. FALLBACK BRIDGING - I have simple configuration for fallback > bridging of IPX traffic. As I understood, NO BRIDGE 1 ACQUIRE should > not forward packets to dynamically learned MAC addresses. On my 3560 > that doesn't work. My traffic is still forwarded. Are there some > tricks or is just the bug? > > 3. FRAME RELAY MAPPING - simple scenario where I have R1 as hub and > R2, R3 as spokes. Task is to configure p2p links R1-R2 and R1-R3. As I > understood, inverse ARP will be activated when you put IP adress on > MAIN interface. As long as you are using subinterfaces there is no > need to put NO FRAME INVARP. So, I configured R1 with p2p subint and > IP add. I started configuring R2: configured ENC FRAM under main int, > made p2p subint and when I wanted to put FRAME INTERF-DLCI on my R2's > p2p subint msg says that my DLCI is already mapped to main interface? > Why? > > 4.PPP MULTILINK - you have 2 connections between two routers, FR > connections and you wanna configure multilink authentication. My > learning materials say that you have to configure ppp auth under > virtual template. I configured under multilink int and it works. > Question is: is the right way under virtual-temp or ppp auth can be > configured under multilink int? > > 5. RIPv2 over FR - simple scenario, one hub and two spokes. Hub has > multipoint subint and spokes have ip addresses under main interface. > All three routers have one loopback which is advertised via RIPv2. I > didn't put BROADCAST keyword in the mapping line just to see what will > happened. My spokes exchange routing updates, so one spoke knows about > other's loopback and vice verse. > Hub router doesn't get any update. What is the reason for that behavior? > > OK. I got number 5 question. My spokes learn about each other via > dynamic mapping which has BROADCAST feature on. :) > > That's it for now. Thanks. > > Regards > > > Blogs and organic groups at http://www.ccie.net > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Wed Feb 17 2010 - 10:03:17 ART
This archive was generated by hypermail 2.2.0 : Mon Mar 01 2010 - 06:28:36 ART