Re: Couple of CCIE lab questions for experts

From: Piotr Kaluzny <piotrk_at_ipexpert.com>
Date: Wed, 17 Feb 2010 12:43:57 +0100

Ivan,

1. This VLAN, as I mentioned before, should be dedicated to customer. This
means that ISP should not use that VLAN for any other purpose. Oh, and by
the way - "sw access vlan 12" on the ISP tunnel port describes the metro
tag, because mode is set to "tunnel".

3. In some IOS versions (e.g. mine) you don't have to shut the interface
down before you move the DLCI.

If the interface has no IP address configured INARP requests/responses
should not be sent/received.

Regards,
 --
Piotr Kaluzny
CCIE #25665 (Security), CCSP, CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com <http://www.ipexpert.com/>

On Wed, Feb 17, 2010 at 12:08 PM, Ivan Hrvatska <ivanzghr_at_gmail.com> wrote:

> 3. I can do configuration with main int in shut down state. After I
> configure subinterfaces with frame interface-dlci command I unshut
> main int and everything is fine. There is no IP add configured under
> main int. JUst fr enc.
> So, conclusion is that when you put enc frame (without IP add) on main
> interface mapping of DLCI occurs after that? Because I don't put IP
> add under main int, just enc frame.
>
>
> 1. Question was if you have provider's switch which has one access
> port for customer who want QinQ, and that port is dot1q tunnel and it
> is access VLAN 12 (provider's VLAN). Customer also has VLAN 12 which
> is going to be tunneled. Doesn't provider's VLAN 12 interference with
> customer's VLAN 12 which has to be tunneled?
>
> On Wed, Feb 17, 2010 at 10:03 AM, Piotr Kaluzny <piotrk_at_ipexpert.com>
> wrote:
> > 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>

-- 
Piotr Kaluzny
CCIE #25665 (Security), CCSP, CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
Blogs and organic groups at http://www.ccie.net
Received on Wed Feb 17 2010 - 12:43:57 ART

This archive was generated by hypermail 2.2.0 : Mon Mar 01 2010 - 06:28:36 ART