[c-nsp] 7600: eompls on Vlan ?
David Freedman
david.freedman at uk.clara.net
Tue Feb 14 13:28:48 EST 2006
Ian Cox wrote:
> At 05:18 PM 2/14/2006 +0000, David Freedman wrote:
<snip>
>
>
> You guess incorrectly. The Supervisor L2 switches the packet to the
> OSM/FlexWAN/SIP module that has joined the specific vlan, and the
> OSM/FlexWAN/SIP receives the L2 packet and adds the MPLS labels. Similar
> process happens when bridge packets on ATM interfaces arrive and are
> switched out onto ethernet interfaces.
Yes, I believe that this is what I described, but in reverse.
Either way, the OSM does the MPLS and the Sup does the Layer 2.
>
>> What is the point? is it so hard to do both on the Sup in a two stage
>> (allbeit slow) process?
>
>
> It is impossible to with the current Sup720 Forwarding ASICs.
So, what you are saying is that this functionality is not in the
silicon? why not? this appears to be a design oversight.
>
>> Are there any plans to add software to support this? and if so when?
>
>
> No.
Thanks, if thats the case, you should at the very least offer an option
for doing this in software with reduced performance as a result, if not,
I don't see a use for this architecture moving forward with our current
EOMPLS plans.
Kind Regards,
David Freedman
>
>
> Ian
>
>> Thanks,
>>
>> Dave.
>>
>>
>>
>> Kristofer Sigurdsson wrote:
>> > David,
>> >
>> > The Sup2 can't do MPLS on the Sup - it has to use the line cards, ie.
>> > OSM/FlexWAN etc.
>> >
>> > The Sup720 (vanila) is the same. The Sup720-3B and -3BXL can do MPLS,
>> > but they have this restriction.
>> >
>> > -Kristo
>> >
>> > 2006/2/14, David Freedman <david.freedman at uk.clara.net>:
>> >> I'm right in thinking that this restriction only applies to Sup2
>> >> architecture and not Sup720, surely the 720 should be able to do SVI
>> >> EOMPLS without the need for the PE->P link to be on a WAN module?
>> >>
>> >> Dave.
>> >>
>> >> Bill Wade (wwade) wrote:
>> >> > SVI based EoMPLS --
>> >> >
>> >> > interface Vlan501
>> >> > xconnect 192.1.1.1 501 encapsulation mpls
>> >> >
>> >> > requires an OSM+, FlexWAN, enhanced FlexWAN or SIP-600 as MPLS core
>> >> > facing interface.
>> >> >
>> >> > Bill
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: cisco-nsp-bounces at puck.nether.net
>> >> >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> >> >> Alexandre Snarskii
>> >> >> Sent: Tuesday, February 14, 2006 9:43 AM
>> >> >> To: Cisco-NSP Mailing List
>> >> >> Subject: [c-nsp] 7600: eompls on Vlan ?
>> >> >>
>> >> >>
>> >> >> Hi!
>> >> >>
>> >> >> As my tests show me, EoMPLS VC configured on interface Vlan
>> >> >> does not come up (and debug shows "Imposition setup
>> >> >> incomplete because unable to find a tunnel label" error), but
>> >> >> the same xconnect config applied to subinterface works well,
>> >> >> vc comes up and passes traffic.
>> >> >>
>> >> >> IOS version: 12.2(18)SXD7, also tested with 12.2(18)SXF2, ip
>> >> >> services.
>> >> >> Testbed network topology: c2950 <-> Gi4/4 Sup720 Gi4/12 <->
>> >> >> GE3/1 Sup2/OSM
>> >> >>
>> >> >> Is this a bug or some kind of feature ? If a bug: is there an
>> >> >> IOS version unaffected by this bug, or when it planned to be
>> >> >> fixed ? If a feature - are there any hints to get eompls
>> >> >> working together with switching without hardware upgrade ?
>> >> >> (box should stay as simple as chassis+sup+ WS-X6516-GBIC combo).
>> >> >>
>> >> >> Full log of "failed" connection:
>> >> >>
>> >> >> Feb 13 13:45:54.451 MSK: AToM SMGR [RE.MO.TE.IP, 900]:
>> >> >> Adjacency creation succeeded for Vlan900.
>> >> >> Feb 13 13:45:54.515 MSK: DISP XDR cktidx: 196 Feb 13
>> >> >> 13:45:54.515 MSK: AToM SMGR [RE.MO.TE.IP, 900]: Processing
>> >> >> imposition update, vc_handle 50D68200, update_action 1,
>> >> >> remote_vc_label 731 Feb 13 13:45:54.515 MSK: CWAN_ATOM:
>> >> >> AtomSmgr Set parentRew, vcID: 900 Feb 13 13:45:54.515 MSK:
>> >> >> CWAN_ATOM: GetParentRew failed, vcId: 900, rewCnt: 0 Feb 13
>> >> >> 13:45:54.515 MSK: CWAN_ATOM: lb-mode: default, vcId: 900,
>> >> >> rew: n/a Feb 13 13:45:54.515 MSK: CWAN_ATOM: find parentRew
>> >> >> for vcId: 900 failed Feb 13 13:45:54.515 MSK: AToM SMGR
>> >> >> [RE.MO.TE.IP, 900]: no parent rewrite: LFIB entry not present
>> >> >> or unresolved Feb 13 13:45:54.515 MSK: AToM SMGR
>> >> >> [RE.MO.TE.IP, 900]: Imposition setup incomplete because
>> >> >> unable to find a tunnel label Feb 13 13:45:54.515 MSK: AToM
>> >> >> SMGR: Processing TFIB event for RE.MO.TE.IP Feb 13
>> >> >> 13:45:54.515 MSK: CWAN_ATOM: AtomSmgr Set parentRew, vcID:
>> >> >> 900 Feb 13 13:45:54.515 MSK: CWAN_ATOM: GetParentRew failed,
>> >> >> vcId: 900, rewCnt: 0 Feb 13 13:45:54.515 MSK: CWAN_ATOM:
>> >> >> lb-mode: default, vcId: 900, rew: n/a Feb 13 13:45:54.515
>> >> >> MSK: CWAN_ATOM: find parentRew for vcId: 900 failed Feb 13
>> >> >> 13:45:54.515 MSK: AToM SMGR [RE.MO.TE.IP, 900]: no parent
>> >> >> rewrite: LFIB entry not present or unresolved Feb 13
>> >> >> 13:45:54.515 MSK: AToM SMGR [RE.MO.TE.IP, 900]: Imposition
>> >> >> setup incomplete because unable to find a tunnel label
>> >> >>
>> >> >> The same log, using subinterface with the same vlan configured:
>> >> >>
>> >> >> Feb 13 14:25:48.745 MSK: AToM SMGR [RE.MO.TE.IP, 900]:
>> >> >> Processing disposition update, vc_handle 50D68200,
>> >> >> update_action 1, local_vc_label 489 Feb 13 14:25:48.745 MSK:
>> >> >> AToM SMGR [RE.MO.TE.IP, 900]: Adjacency creation succeeded
>> >> >> for GigabitEthernet4/4.900.
>> >> >> Feb 13 14:25:48.805 MSK: AToM SMGR [RE.MO.TE.IP, 900]:
>> >> >> Processing imposition update, vc_handle 50D68200,
>> >> >> update_action 1, remote_vc_label 731 Feb 13 14:25:48.805 MSK:
>> >> >> CWAN_ATOM_IMP: XDR HW l2ckt: 900, ACtype: 4, local_vc_label:
>> >> >> 489 Feb 13 14:25:48.805 MSK: AToM SMGR [RE.MO.TE.IP, 900]:
>> >> >> Imposition Programmed, Output Interface: Gi4/12, flags 0x0011
>> >> >> Feb 13 14:25:48.805 MSK: AToM SMGR: Processing TFIB event for
>> >> >> RE.MO.TE.IP Feb 13 14:25:48.805 MSK: CWAN_ATOM_IMP: XDR HW
>> >> >> l2ckt: 900, ACtype: 4, local_vc_label: 489 Feb 13
>> >> >> 14:25:48.805 MSK: AToM SMGR [RE.MO.TE.IP, 900]: Imposition
>> >> >> Programmed, Output Interface: Gi4/12, flags 0x0011
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >> >
>> >>
>> >> _______________________________________________
>> >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >>
>> >
>> > _______________________________________________
>> > cisco-nsp mailing list cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list