Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 04:47:22 PM Phil Mayers wrote:

> I knew there was something else I meant to ask: since I
> know you've had an interest in it, do you have any idea
> how MVPNv6 will pan out absent LDP/RSVP to signal the
> LSPs? Can SR do this job?

At this time (on Junos anyway, which I have more experience 
with re: NG-MVPN), you can transport IPv6 Multicast traffic 
in an NG-MVPN. I should expect Cisco and ALU have an 
implementation as well.

It is based on 6VPE, really, since the "VPN" portion of NG-
MVPN is really just a Unicast l3vpn instantiation.

Of course, it is my hope that native MPLSv6 will also add  
support for p2mpv6 and mp2mpv6 scenarios over SR, which will 
enable true/native NG-MVPNv6 (dual-stack, of course, shared 
within a single NG-MVPN VRF, of course). 

Given that LDPv6 and RSVPv6 have poor vendor interest at the 
moment, you can be reasonably confident mLDPv6 or p2mp RSVP-
TEv6 will never see the light of day either. So yes, SR is 
probably where we want to be pushing for this from vendors 
as well.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 03:50:46 PM Tarko Tikan wrote:

> What about QOS? MPLS EXP is a great way to carry QOS
> markings without overriding TOS/DSCP/TC sent, seen and
> used by customers.

So we support only DSCP and EXP. We don't generally perform 
QoS on IPP.

For IP traffic, we trust DSCP values that come from Managed 
Service customers, i.e., we can vouch for the customer's QoS 
configuration on their end.

We "can" trust DSCP values from customers that "know what 
they're doing", but deciding this is not always scientific. 
At any rate, customer- and core-facing ports are reasonably 
over-engineered such that if trusted customers were naughty 
enough to place unimportant traffic in important queues over 
an unscientifically trusted port, they'd only be hurting 
themselves and not other customers.

For non-IP traffic (Ethernet, really), we don't care what TC 
IP markings customer packets come with. We only mark with 
EXP for core handling. So whatever TC values they send 
across are preserved (this wasn't always the case when "mls 
qos" was enabled on older Cisco switches, for example).

For untrusted customer ports, we apply our own DSCP values. 
We also apply explicit EXP values to avoid the automated 
copying of the first 3 bits of the DSCP value to the EXP 
field (most annoying, but understandable).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 03:50:46 PM Tarko Tikan wrote:

> What about QOS? MPLS EXP is a great way to carry QOS
> markings without overriding TOS/DSCP/TC sent, seen and
> used by customers.

So we support only DSCP and EXP. We don't generally perform 
QoS on IPP.

For IP traffic, we trust DSCP values that come from Managed 
Service customers, i.e., we can vouch for the customer's QoS 
configuration on their end.

We "can" trust DSCP values from customers that "know what 
they're doing", but deciding this is not always scientific. 
At any rate, customer- and core-facing ports are reasonably 
over-engineered such that if trusted customers were naughty 
enough to place unimportant traffic in important queues over 
an unscientifically trusted port, they'd only be hurting 
themselves and not other customers.

For non-IP traffic (Ethernet, really), we don't care what TC 
IP markings customer packets come with. We only mark with 
EXP for core handling. So whatever TC values they send 
across are preserved (this wasn't always the case when "mls 
qos" was enabled on older Cisco switches, for example).

For untrusted customer ports, we apply our own DSCP values. 
We also apply explicit EXP values to avoid the automated 
copying of the first 3 bits of the DSCP value to the EXP 
field (most annoying, but understandable).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Phil Mayers]

On 02/01/14 10:49, Mark Tinka wrote:


I think the future of an IPv6 control plane for MPLS is in
SR. To be honest, I wouldn't bother developing LDPv6 or
RSVPv6 with SR on the horizon, if I were a vendor in-tune
with the times.


I knew there was something else I meant to ask: since I know you've had 
an interest in it, do you have any idea how MVPNv6 will pan out absent 
LDP/RSVP to signal the LSPs? Can SR do this job?

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Tarko Tikan]

hey,


I'll keep everything native, and will continue to carry
BGPv6 in my core until I can safely remove it a la BGPv4
with an IPv6-signaled MPLS.


What about QOS? MPLS EXP is a great way to carry QOS markings without 
overriding TOS/DSCP/TC sent, seen and used by customers.


--
tarko
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Tim Durack]

You could run vpnv4 (4VPE) and vpnv6 (6VPE), and use: mpls label mode
all-vrfs protocol all-afs per-vrf

Works for us. You will take a pps hit due to the aggregate triggered IP
lookup.

I too dream of and IPv6 control-plane. If that be SR, bring it on...

Tim:>


On Thu, Jan 2, 2014 at 3:29 AM, Steve Glendinning wrote:

> Hi all,
>
> I've enabled 6PE on some of our rsp720-3cxl's (running SRE8) that carry
> full global routes, and it appears to have allocated a separate MPLS label
> for each IPv6 prefix in BGP (approx 16,000 of them).  Consequently this is
> chewing up significantly more FIB space, as each (global) IPv6 prefix now
> uses 1 144-bit slot and 1 72-bit slot (so 3 of the 1M entries available).
>
> Is this right?  It seems very wasteful, given that in the IPv4 world I only
> have labels for my IGP routes and everything else is happy being sent
> towards their favourite default route with just a "loopback" label on it.
>
> Some of the Cisco documentation mentions an "aggregate" IPv6 label, which
> would make more sense.  Is this available on 7600/6500?
>
> Thanks,
> --
> Steve
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Tim:>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 02:19:55 PM Phil Mayers wrote:
 
> Sure; SR looks like a more natural fit for MPLS than LDP
> ever was in hindsight. That said, it looks better for
> IS-IS users than OSPF, due to needing OSPF & OSPFv3 or
> OSPFv3 dual-AF which is not well supported.

OSPFv3 is much more scalable than OSPFv2.

IMHO, OSPFv3 should have been designed to support IPv4 
without needing an IPv6 link layer, simply because it scales 
as well as IS-IS in terms of feature set expansions. But 
that's just me.

That said, when OSPFv3 becomes more mainstream (because IPv6 
will be more prevalent than it is today), I'm not sure 
whether it will be more useful for all vendors to support 
the IPv4 address family for OSPFv3, given that some may see 
IPv4 as a protocol on its way out (although I would support 
vendors looking to collapse both address families into 
OSPFv3, like IS-IS does).

Or, this may make the case for some who want to migrate to 
IS-IS for this particular reason. Then again, if OSPFv3 is 
upgraded as I mention above, then there really only might be 
just one major difference between both IGP's - the fact that 
one has an Area 0 restriction and the other doesn't (for 
those that feel the differences between them still matter). 

> Obviously people will have to move their vpnv6 BGP AFs to
> their IPv6 BGP RR sessions, which is a bit of a drag,
> but that's what peer templates are for (on sensible
> OSes).

My otherwise uninformed guess is that folk who have deployed 
6PE or 6VPE today will be less inclined to migrate to native 
MPLSv6 unless they are running into some resource issue 
brought on by 6PE or 6VPE, and it's cheaper to turn on 
MPLSv6 than to buy more resources.

I'll keep everything native, and will continue to carry 
BGPv6 in my core until I can safely remove it a la BGPv4 
with an IPv6-signaled MPLS.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Phil Mayers]

On 02/01/14 10:49, Mark Tinka wrote:


I think the future of an IPv6 control plane for MPLS is in
SR. To be honest, I wouldn't bother developing LDPv6 or
RSVPv6 with SR on the horizon, if I were a vendor in-tune
with the times.


Sure; SR looks like a more natural fit for MPLS than LDP ever was in 
hindsight. That said, it looks better for IS-IS users than OSPF, due to 
needing OSPF & OSPFv3 or OSPFv3 dual-AF which is not well supported.


Obviously people will have to move their vpnv6 BGP AFs to their IPv6 BGP 
RR sessions, which is a bit of a drag, but that's what peer templates 
are for (on sensible OSes).



It is for such reasons that I don't like today's breed of
MPLS-biased forwarding engines (like Cisco's LSP for the
CRS, and some of Juniper's PTX line cards), because they all
assume everything is encapsulated in MPLS, including IPv6


That's an excellent point.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 12:08:12 PM Phil Mayers wrote:

> 6vPE is IMO a slightly different beast, because the v4/v6
> variants are much closer. The use of v4 loopbacks in
> 6vPE next hops is a bit odd to be sure, but it's not a
> fundamentally different traffic forwarding paradigm as
> with 6PE.

Agree, but still not clean enough for me :-).

> That said, I agree that LDPv6 and friends would be good
> to have; one assumes big providers would be keen to run
> 4vPE and have v4-free cores to save on address space
> without using 10/8 for p2p links.

I think LDPv6 and RSVPv6 are dead, to be honest. No interest 
from vendors (probably because of little interest coming 
from operators - especially those flush with cash).

I think the future of an IPv6 control plane for MPLS is in 
SR. To be honest, I wouldn't bother developing LDPv6 or 
RSVPv6 with SR on the horizon, if I were a vendor in-tune 
with the times.

Vendors always complain about lack of use cases for MPLSv6, 
but I know one (in addition to an IPv6-free BGP core) - 
congruency between IPv4 and IPv6 for MPLS (or SR) Traffic 
Engineering. It's terrible that you can't point native IPv6 
traffic into an MPLS-TE LSP built over IPv4. So you end up 
with your IPv4 traffic taking the "best" path, while your 
IPv6 traffic is left to fend for itself. Not cool. Not cool 
at all.

It is for such reasons that I don't like today's breed of 
MPLS-biased forwarding engines (like Cisco's LSP for the 
CRS, and some of Juniper's PTX line cards), because they all 
assume everything is encapsulated in MPLS, including IPv6 
(6PE), and that's just not true when you're running (and 
sticking to) native IPv6. Those label-only forwarding 
engines have very little FIB space to keep them cheap and 
dumb, so what happens when you need to carry a full (and 
growing) IPv6 BGP table on such a card because you're a 
native IPv6 zealot, like myself?

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Phil Mayers]

On 02/01/14 10:01, Mark Tinka wrote:

On Thursday, January 02, 2014 11:51:50 AM Phil Mayers wrote:


Sure, but that's labelled v4. 6PE is not just a straight
translation of the same concepts because the labels are
advertised in BGP to permit a v6-free, MPLS-only core.


Probably why I'm not keen to support l3vpnv6 until we can
natively signal MPLS control planes for/over IPv6.


6vPE is IMO a slightly different beast, because the v4/v6 variants are 
much closer. The use of v4 loopbacks in 6vPE next hops is a bit odd to 
be sure, but it's not a fundamentally different traffic forwarding 
paradigm as with 6PE.


That said, I agree that LDPv6 and friends would be good to have; one 
assumes big providers would be keen to run 4vPE and have v4-free cores 
to save on address space without using 10/8 for p2p links.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 11:51:50 AM Phil Mayers wrote:

> Sure, but that's labelled v4. 6PE is not just a straight
> translation of the same concepts because the labels are
> advertised in BGP to permit a v6-free, MPLS-only core.

Probably why I'm not keen to support l3vpnv6 until we can 
natively signal MPLS control planes for/over IPv6.

But that's another story.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE FIB usage on 6500/7600

[Phil Mayers]

On 02/01/14 08:29, Steve Glendinning wrote:


Is this right?  It seems very wasteful, given that in the IPv4 world I only
have labels for my IGP routes and everything else is happy being sent
towards their favourite default route with just a "loopback" label on it.


Sure, but that's labelled v4. 6PE is not just a straight translation of 
the same concepts because the labels are advertised in BGP to permit a 
v6-free, MPLS-only core.



Some of the Cisco documentation mentions an "aggregate" IPv6 label, which
would make more sense.  Is this available on 7600/6500?


I believe so, though I can't remember the command off the top of my 
head. However, be aware that aggregate labels require recirculation, so 
halve your max PPS IIRC? Bit hazy on that last bit.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6PE FIB usage on 6500/7600

[Steve Glendinning]

Hi all,

I've enabled 6PE on some of our rsp720-3cxl's (running SRE8) that carry
full global routes, and it appears to have allocated a separate MPLS label
for each IPv6 prefix in BGP (approx 16,000 of them).  Consequently this is
chewing up significantly more FIB space, as each (global) IPv6 prefix now
uses 1 144-bit slot and 1 72-bit slot (so 3 of the 1M entries available).

Is this right?  It seems very wasteful, given that in the IPv4 world I only
have labels for my IGP routes and everything else is happy being sent
towards their favourite default route with just a "loopback" label on it.

Some of the Cisco documentation mentions an "aggregate" IPv6 label, which
would make more sense.  Is this available on 7600/6500?

Thanks,
-- 
Steve
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE our only option?

[Blake Dunlap]

I too would like to see LDPv6 very much, for the same reasons, as I have
had the same issues and was forced to redo my true dual stack in to 6PE due
to conversion to MPLS.

-Blake

On Thu, Mar 29, 2012 at 19:25, Lobo  wrote:

> Apologies if this is a little long but looking for some friendly advice
> from you experts on rolling out IPv6 on our network.
>
> Our network follows a traditional model where it's
> edgedistributioncore--**---gwy for our internet customers.  The
> entire distribution, core and gwy routers have had MPLS enabled on them for
> a couple of years in order to offer EoMPLS like services.  The edge routers
> have not had MPLS enabled on them as there was no real need since they only
> provide internet access.  The IGP is OSPF and BGP is running on the
> distribution & gwy routers towards our route-reflectors.  The core is BGP
> less now so they are functioning as true P routers.
>
> We have managed to dual stack (v4 & v6) all of our distribution, core and
> gwy routers' interfaces as we believed that dual stack is always the
> preferred option.  We followed the same principles as our v4 implementation
> (loopbacks & PTPs only in the IGP and static/connected routes at the edge
> distributed via iBGP).  Upon installing a new edge router that would
> participate in IPv6 we discovered that the core could not route the packets
> to other IPv6 destinations because it only knows about LBs & PTPs.  Even if
> it made it to the gwy because of a default route (::/0), there were times
> when another gwy router had a better route and then we would have packets
> bouncing back and forth between a gwy and core router until the TTL expired.
>
> Now we're at the point of wondering if 6PE is our only option in order to
> forward the packets or if we go back to the old way of doing things by
> re-enabling BGP on the core (for ipv6 only) and having a partial set of
> ipv6 routes?  Personally I've been configuring 6PE in our lab for the
> entire week and it's really racking my head.  There are times when I have
> things working and then I make the smallest change in a route-map and
> suddenly things no longer work.  Do I configure the 6PE stuff on the edge
> router or can it start at the distribution router?  Traceroutes look really
> odd with the core not showing and I'm wondering if I'm introducing more
> problems for our NOC to troubleshoot (and learn) vs going with some other,
> simpler option.
>
> Right now I'm really wishing that LDPv6 was implemented.  :)
>
> Appreciate any comments, feedback or suggestions.  Please let me know I
> can provide any further information.
>
> Thanks!
>
> Jose
>
> __**_
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6PE our only option?

[Lobo]

Apologies if this is a little long but looking for some friendly advice 
from you experts on rolling out IPv6 on our network.


Our network follows a traditional model where it's 
edgedistributioncore-gwy for our internet customers.  The 
entire distribution, core and gwy routers have had MPLS enabled on them 
for a couple of years in order to offer EoMPLS like services.  The edge 
routers have not had MPLS enabled on them as there was no real need 
since they only provide internet access.  The IGP is OSPF and BGP is 
running on the distribution & gwy routers towards our route-reflectors.  
The core is BGP less now so they are functioning as true P routers.


We have managed to dual stack (v4 & v6) all of our distribution, core 
and gwy routers' interfaces as we believed that dual stack is always the 
preferred option.  We followed the same principles as our v4 
implementation (loopbacks & PTPs only in the IGP and static/connected 
routes at the edge distributed via iBGP).  Upon installing a new edge 
router that would participate in IPv6 we discovered that the core could 
not route the packets to other IPv6 destinations because it only knows 
about LBs & PTPs.  Even if it made it to the gwy because of a default 
route (::/0), there were times when another gwy router had a better 
route and then we would have packets bouncing back and forth between a 
gwy and core router until the TTL expired.


Now we're at the point of wondering if 6PE is our only option in order 
to forward the packets or if we go back to the old way of doing things 
by re-enabling BGP on the core (for ipv6 only) and having a partial set 
of ipv6 routes?  Personally I've been configuring 6PE in our lab for the 
entire week and it's really racking my head.  There are times when I 
have things working and then I make the smallest change in a route-map 
and suddenly things no longer work.  Do I configure the 6PE stuff on the 
edge router or can it start at the distribution router?  Traceroutes 
look really odd with the core not showing and I'm wondering if I'm 
introducing more problems for our NOC to troubleshoot (and learn) vs 
going with some other, simpler option.


Right now I'm really wishing that LDPv6 was implemented.  :)

Appreciate any comments, feedback or suggestions.  Please let me know I 
can provide any further information.


Thanks!

Jose

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE

[Vitkovsky, Adam]

> If your MPLS dies, your v6 dies.

With a proper design if MPLS dies -customers should not even notice :) (MPLS-TE 
and FRR)

adam

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mathieu Paonessa
Sent: Wednesday, August 03, 2011 11:02 AM
To: mti...@globaltransit.net
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6PE

Hi!

On 8/3/11 3:28 AM, Mark Tinka wrote:
> On Wednesday, August 03, 2011 03:55:43 AM waseem thaer 
> wrote:

>> I'm interested in the 6PE solution to offer IPv6 for
>> customers, for those of you who have checked this
>> solution in production network please share your
>> experiences and what are the hardware and software
>> configurations you have??
> 
> It is a valid approach in operationalizing v6 in your 
> network, and has been used quite extensively. But I'd say 
> that if you had the choice, don't run it.

We've been running 6PE since late 2007 and are very happy about it.
Here's why I don't agree with you:


> 6PE depends on MPLS, which depends on IPv4. If your v4 dies, 
> your MPLS dies, your v6 dies.

There's two different v4 world here:
- We run IPv4 + IGP + MPLS with only the P/PE loopback and interco
subnet. This keeps a very compact internal routing table and allows all
our core infrasctructure not to be visible from outside.

- "Internet" IPv4 is running inside a VRF like any other MPLS IP/VPN.
Any routing issue on that IPv4 Internet world would not affect our IPv6
infrastructure.


> If your MPLS dies, your v6 dies.

For many network these days, if your MPLS dies, your network dies.


> Plus, 6PE is yet another tunneling technology through which 
> to run your v6 network.

Sure but what's the issue there? If you're running MPLS you're tunneling
in v4 ou v6 anyway.


> We have 2 large MPLS networks, but have resisted 6PE which 
> always seems easier (and makes the MPLS zealots happy 
> because it's yet another thing MPLS can wrap itself around).

Damn, I must be one of those zealots :)


> Native/dual-stack is always best. If you can do it, prefer 
> that. It's cleaner and less dependent on many other things.

Depending on what your network looks like, not always.
For example if you run OSPF, you'll have to run two IGP so that makes
twice the work when deploying new devices. Not saying that I've seen
many people modifying their ospf cost in v4 and forgetting to do it in
v6 when changing their routing topology.


> But if 6PE is your only option (I don't see how since 
> anything decent enough to run 6PE these days can run native 
> v6), then by all means, go ahead :-).

One of the reasons we went for 6PE back in 2007 is that we still had
some Engine 2 GSR cards on the network and those are not able to do IPv6
in hardware. There was no way on earth that we would run software IPv6
on our core and had no budget to renew the core at that time.

I've done a presentation during the last FrNOG meeting about our 6PE
experience. The talk is in french but the slides are in english
(http://dai.ly/kRr5WE) if that could help.

Cheers,

--
Mathieu Paonessa

___
cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE

[Mathieu Paonessa]

Hi!

On 8/3/11 3:28 AM, Mark Tinka wrote:
> On Wednesday, August 03, 2011 03:55:43 AM waseem thaer 
> wrote:

>> I'm interested in the 6PE solution to offer IPv6 for
>> customers, for those of you who have checked this
>> solution in production network please share your
>> experiences and what are the hardware and software
>> configurations you have??
> 
> It is a valid approach in operationalizing v6 in your 
> network, and has been used quite extensively. But I'd say 
> that if you had the choice, don't run it.

We've been running 6PE since late 2007 and are very happy about it.
Here's why I don't agree with you:


> 6PE depends on MPLS, which depends on IPv4. If your v4 dies, 
> your MPLS dies, your v6 dies.

There's two different v4 world here:
- We run IPv4 + IGP + MPLS with only the P/PE loopback and interco
subnet. This keeps a very compact internal routing table and allows all
our core infrasctructure not to be visible from outside.

- "Internet" IPv4 is running inside a VRF like any other MPLS IP/VPN.
Any routing issue on that IPv4 Internet world would not affect our IPv6
infrastructure.


> If your MPLS dies, your v6 dies.

For many network these days, if your MPLS dies, your network dies.


> Plus, 6PE is yet another tunneling technology through which 
> to run your v6 network.

Sure but what's the issue there? If you're running MPLS you're tunneling
in v4 ou v6 anyway.


> We have 2 large MPLS networks, but have resisted 6PE which 
> always seems easier (and makes the MPLS zealots happy 
> because it's yet another thing MPLS can wrap itself around).

Damn, I must be one of those zealots :)


> Native/dual-stack is always best. If you can do it, prefer 
> that. It's cleaner and less dependent on many other things.

Depending on what your network looks like, not always.
For example if you run OSPF, you'll have to run two IGP so that makes
twice the work when deploying new devices. Not saying that I've seen
many people modifying their ospf cost in v4 and forgetting to do it in
v6 when changing their routing topology.


> But if 6PE is your only option (I don't see how since 
> anything decent enough to run 6PE these days can run native 
> v6), then by all means, go ahead :-).

One of the reasons we went for 6PE back in 2007 is that we still had
some Engine 2 GSR cards on the network and those are not able to do IPv6
in hardware. There was no way on earth that we would run software IPv6
on our core and had no budget to renew the core at that time.

I've done a presentation during the last FrNOG meeting about our 6PE
experience. The talk is in french but the slides are in english
(http://dai.ly/kRr5WE) if that could help.

Cheers,

--
Mathieu Paonessa

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE

[Mark Tinka]

On Wednesday, August 03, 2011 05:01:53 PM Mathieu Paonessa 
wrote:

> There's two different v4 world here:
>   - We run IPv4 + IGP + MPLS with only the P/PE 
loopback
> and interco subnet. This keeps a very compact internal
> routing table and allows all our core infrasctructure
> not to be visible from outside.

Right, but MPLS forwarding requires IPv4 to be working. 
Something that can affect your IPv4 forwarding (it could be 
configuration, it could be code, it could be hardware) has a 
high chance of affecting your MPLS forwarding.

Now not only have you lost both v4 and MPLS, you've also 
lost v6 if you're doing 6PE (yes, it is possible that 
something which affects your v4 may not affect your v6, and 
vice versa).

I've seen many networks get themselves out of trouble when 
they muck up their v4 ACL's, but can still log back into the 
router/switch via v6. Of course, not a valid reason to 
deploy v6, but a good side benefit nonetheless.

>   - "Internet" IPv4 is running inside a VRF like any 
other
> MPLS IP/VPN. Any routing issue on that IPv4 Internet
> world would not affect our IPv6 infrastructure.

Of course, but I wasn't talking about your v4 Internet - I 
was just saying that MPLS needs v4 to work, and 6PE needs 
MPLS. So in a long chain, 6PE needs v4, and would, thus, be 
sensitive to v4 events that have the potential to cause MPLS 
events.

> For many network these days, if your MPLS dies, your
> network dies.

Yes, but for others, it's not the case if your v6 is native.

Native v6 isn't affected by MPLS failure. 6PE is affected by 
MPLS failure, whatever the failure is caused by.

> Sure but what's the issue there?

Troubleshooting is more difficult, traceroutes look strange, 
complexity is increased especially at the edge, e.t.c.

Of course, it's not the end of the world, but if native is 
an option that is feasible, it certainly is much simpler to 
deploy and manage. Whether an operator chooses to go native 
or 6PE is really up to them.

> If you're running MPLS
> you're tunneling in v4 ou v6 anyway.

Ummh - not necessarily. Yes, v4 is wrapped inside MPLS for 
forwarding in the core when you turn MPLS on. But you also 
have native v4 running in the core which can forward v4 
packets without having them wrapped in MPLS (normally 
packets following the IGP, barring special cases of MPLS-
TE).

6PE is different - there's no v6 running in the core. It's 
just one big hole through which v6 packets enter, and 
hopefully, come out at the other end :-).

What I don't mind is native MPLS signaling for v6. That way, 
you still have native v6 configured in the core. But that's 
another IETF story :-).

> Damn, I must be one of those zealots :)

MPLS does have its benefits, and we use it to deliver 
several applications in our network, including IPTv services 
to a decent number of homes. So we do like it.

But it is possible to believe in MPLS too much that it tends 
to become a panacea. This is not just an operator problem, 
some vendors too. It's no secret that a huge amount of 
revenue for vendors comes from MPLS-related sales, which is 
why young IP engineers today want to learn about MPLS before 
they know what an IP address is :-). But let me not digress.

> Depending on what your network looks like, not always.
> For example if you run OSPF, you'll have to run two IGP
> so that makes twice the work when deploying new devices.
> Not saying that I've seen many people modifying their
> ospf cost in v4 and forgetting to do it in v6 when
> changing their routing topology.

There's a solution for that - go IS-IS :-).

But seriously, is native/dual-stack hard to do? Certainly! 
Ensuring that your v4 and v6 policies always match is a 
challenge to the level of human diligence (or laziness). You 
know what they say about good engineers :-).

But the long-term gain in suffering the pain now, in my 
opinion, is all worth it. For us, the simplicity of 
native/dual-stack is a huge pay off for all the time and 
hassle it took to equalize v4 and v6 configurations.

I can understand that for some networks, the effort may 
simply be too much to bear, so 6PE and other tunneling 
technologies are likely the only option, even though they 
may not be simple to manage in the long-term.

It's a trade-off.

> One of the reasons we went for 6PE back in 2007 is that
> we still had some Engine 2 GSR cards on the network and
> those are not able to do IPv6 in hardware. There was no
> way on earth that we would run software IPv6 on our core
> and had no budget to renew the core at that time.

Like I said, constraints such as yours are obviously very 
valid, as you have no other option but to tunnel v6 into v4 
somehow.

However, some networks don't have this restriction, and the 
extra effort involved in going dual-stack turns them away 
from, well, going native/dual-stack. We're human.

Some other folks have gone 6PE because they want to ensure 
v6 forwarding rates are equal to those of v4/MPLS (as the 
router as

Re: [c-nsp] 6PE

[Mikael Abrahamsson]

On Tue, 2 Aug 2011, waseem thaer wrote:

I'm interested in the 6PE solution to offer IPv6 for customers, for 
those of you who have checked this solution in production network please 
share your experiences and what are the hardware and software 
configurations you have??


I know quite a lot of people who run 6PE, it should be mature code since 
the feature has been around since at least 2008 on quite a lot of 
platforms.


 
seems to be a good presentation to describe what it is. I'd imagine 7600 
and any software platform (7200) will do this just fine. If you instead 
say what platform you have, people might be able to share experiences with 
that perticular platform.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE

[Mark Tinka]

On Wednesday, August 03, 2011 03:55:43 AM waseem thaer 
wrote:

> Hello,
> 
> I'm interested in the 6PE solution to offer IPv6 for
> customers, for those of you who have checked this
> solution in production network please share your
> experiences and what are the hardware and software
> configurations you have??

It is a valid approach in operationalizing v6 in your 
network, and has been used quite extensively. But I'd say 
that if you had the choice, don't run it.

6PE depends on MPLS, which depends on IPv4. If your v4 dies, 
your MPLS dies, your v6 dies. 

If your MPLS dies, your v6 dies.

Plus, 6PE is yet another tunneling technology through which 
to run your v6 network.

We have 2 large MPLS networks, but have resisted 6PE which 
always seems easier (and makes the MPLS zealots happy 
because it's yet another thing MPLS can wrap itself around).

Native/dual-stack is always best. If you can do it, prefer 
that. It's cleaner and less dependent on many other things.

But if 6PE is your only option (I don't see how since 
anything decent enough to run 6PE these days can run native 
v6), then by all means, go ahead :-).

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6PE

[waseem thaer]

Hello,

I'm interested in the 6PE solution to offer IPv6 for customers, for those of 
you who have checked this solution in production network please share your 
experiences and what are the hardware and software configurations you have??

Kind regards,
Waseem
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6PE question

[Vikas Sharma]

Hi,

I need another advice on IPv6. Setup looks like - rtr1 -- P
 rtr3 and it's 6PE setup. 7206 is SRE3 image and 12k is 4.0.1
image.

rtr.LAB-7206G2#show ipv6 route 2001:920:0:f002:10:54:0:3
Routing entry for 2001:920:0:F002:10:54:0:3/128
  Known via "bgp 8220", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
10.54.0.3%default indirectly connected  <<< any
idea abt this? it should be shown as ; also what is % sign ?
  MPLS label: 16048
  Last updated 17:58:59 ago

10.54.0.3 is loopback ip of rtr1.

But when I see on rtr3.lab for rtr1.lab loopback, I see following

RP/0/9/CPU0:rtr3.LAB-12410#sh route ipv6 2001:920:0:F002:10:54:0:9
Mon Apr 25 22:47:31.344 UTC

Routing entry for 2001:920:0:f002:10:54:0:9/128
  Known via "bgp 8220", distance 200, metric 0, type internal
  Installed Apr 21 04:47:10.868 for 4d18h
  Routing Descriptor Blocks
:::10.54.0.9, from :::10.54.0.6
<< this is correct
  Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table
Id: 0xe000
  Route metric is 0
  No advertising protos.


Regards,
Vikas
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6pe Cisco-Juniper Re: RFC 4798 IPv6 over IPv4 MPLS Backbone Configuration

[Jared Mauch]

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_sheet09186a008052edd3.html

http://www.juniper.net/techpubs/software/junos/junos82/feature-guide-82/download/fg-ipv6-over-mpls.pdf

On Oct 19, 2010, at 6:25 PM, texas ex wrote:

> Hi All,
> 
> I was wondering if someone could point me to Cisco documentation on how to 
> configure a Cisco box to exchange IPv6 reachability information based on RFC 
> 4798 in BGP (especially when the BGP neighbor is a non-Cisco device such as  
> Juniper). 
> 
> 
> Thanks.
> 
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Christian MacNevin]

Hi

I just revisited this,and yeah the only 6PE doc I've seen (here: 
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_sheet09186a008052edd3.html
 ) seems to be totally out of date.

Note that this is using 12.2(33)SRD4 on a 7200 platform (Dynamips actually).

The basic syntax there relies on the default IPv6 table passing labels like so:

Router bgp 100
Nei 1.2.3.4 remote-as 100
Address-family ipv6
Nei 1.2.3.4 activate
Nei 1.2.3.4 send-label
!

Which for me, when redistributing connected routes, dropped them for some 
reason.

The following, however, apparently works just fine:

Router bgp 100
Nei 1.2.3.4 remote-as 100
Address-family vpnv6
Nei 1.2.3.4 activate
!

Is there any newer source of documentation anyone knows of that works with the 
newer bgp/vrf syntax and more recent IOS?

Cheers
Christian







-Original Message-
From: Tim Durack [mailto:tdur...@gmail.com] 
Sent: Thursday, July 01, 2010 12:31 PM
To: Christian MacNevin
Cc: Chris Nicholls; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6PE: was: mpls over native ipv6?

On Thu, Jul 1, 2010 at 1:48 PM, Christian MacNevin
 wrote:
> Oh really? So there's still no native ipv6 MPLS?
>
> OK, well thanks to finding out about the new CLI and this doc, which seems to 
> be making out that everything should work just fine: 
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ipv4_ipv6.html
>
> I now at least have routes propagating across the core via BGP, and they have 
> valid-looking BGP labels. But I can't ping between the damn things. This my 
> missing LDP? And why does that doc look like it should all work just fine?
>

I ran into this about a year ago. Cisco docs say things like:

"Restrictions for Implementing IPv6 VPN over MPLS
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core
is not supported."

I found VPNv6 has to be enabled on IPv4 peers, not IPv6. There is no
IPv6 signalled label path, due to their being no implemented LDPv6.

-- 
Tim:>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[David Freedman]

Christian MacNevin wrote:
> Standard schmandard. What's needed is a business case. 
> 
> I've got a fiver. Who wants it? TDPv2 anyone?
> 

http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03

http://tools.ietf.org/html/draft-manral-mpls-rsvpte-ipv6-00

Dave.


> 
> 
> 
> -Original Message-
> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] 
> Sent: Thursday, July 01, 2010 1:47 PM
> To: Christian MacNevin
> Cc: Tim Durack; Chris Nicholls; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] 6PE: was: mpls over native ipv6?
> 
> On Thu, 1 Jul 2010, Christian MacNevin wrote:
> 
>> Anyone from cisco care to comment on the LDPv6 road map?
> 
> Last I checked (couple of months ago) there wasn't even a standard for it, 
> I expressed my opinion in the IETF WG IPv6 control plane for MPLS needs 
> feature parity with IPv4, and LDPv6 is definitely one of the things needed 
> first.
> 


-- 


David Freedman
Group Network Engineering
Claranet Group

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Christian MacNevin]

Standard schmandard. What's needed is a business case. 

I've got a fiver. Who wants it? TDPv2 anyone?




-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] 
Sent: Thursday, July 01, 2010 1:47 PM
To: Christian MacNevin
Cc: Tim Durack; Chris Nicholls; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6PE: was: mpls over native ipv6?

On Thu, 1 Jul 2010, Christian MacNevin wrote:

> Anyone from cisco care to comment on the LDPv6 road map?

Last I checked (couple of months ago) there wasn't even a standard for it, 
I expressed my opinion in the IETF WG IPv6 control plane for MPLS needs 
feature parity with IPv4, and LDPv6 is definitely one of the things needed 
first.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Mikael Abrahamsson]

On Thu, 1 Jul 2010, Christian MacNevin wrote:


Anyone from cisco care to comment on the LDPv6 road map?


Last I checked (couple of months ago) there wasn't even a standard for it, 
I expressed my opinion in the IETF WG IPv6 control plane for MPLS needs 
feature parity with IPv4, and LDPv6 is definitely one of the things needed 
first.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Christian MacNevin]

Anyone from cisco care to comment on the LDPv6 road map?


-Original Message-
From: Tim Durack [mailto:tdur...@gmail.com] 
Sent: Thursday, July 01, 2010 12:31 PM
To: Christian MacNevin
Cc: Chris Nicholls; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6PE: was: mpls over native ipv6?

On Thu, Jul 1, 2010 at 1:48 PM, Christian MacNevin
 wrote:
> Oh really? So there's still no native ipv6 MPLS?
>
> OK, well thanks to finding out about the new CLI and this doc, which seems to 
> be making out that everything should work just fine: 
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ipv4_ipv6.html
>
> I now at least have routes propagating across the core via BGP, and they have 
> valid-looking BGP labels. But I can't ping between the damn things. This my 
> missing LDP? And why does that doc look like it should all work just fine?
>

I ran into this about a year ago. Cisco docs say things like:

"Restrictions for Implementing IPv6 VPN over MPLS
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core
is not supported."

I found VPNv6 has to be enabled on IPv4 peers, not IPv6. There is no
IPv6 signalled label path, due to their being no implemented LDPv6.

-- 
Tim:>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Tim Durack]

On Thu, Jul 1, 2010 at 1:48 PM, Christian MacNevin
 wrote:
> Oh really? So there's still no native ipv6 MPLS?
>
> OK, well thanks to finding out about the new CLI and this doc, which seems to 
> be making out that everything should work just fine: 
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ipv4_ipv6.html
>
> I now at least have routes propagating across the core via BGP, and they have 
> valid-looking BGP labels. But I can't ping between the damn things. This my 
> missing LDP? And why does that doc look like it should all work just fine?
>

I ran into this about a year ago. Cisco docs say things like:

"Restrictions for Implementing IPv6 VPN over MPLS
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core
is not supported."

I found VPNv6 has to be enabled on IPv4 peers, not IPv6. There is no
IPv6 signalled label path, due to their being no implemented LDPv6.

-- 
Tim:>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Christian MacNevin]

Oh really? So there's still no native ipv6 MPLS?

OK, well thanks to finding out about the new CLI and this doc, which seems to 
be making out that everything should work just fine: 
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ipv4_ipv6.html

I now at least have routes propagating across the core via BGP, and they have 
valid-looking BGP labels. But I can't ping between the damn things. This my 
missing LDP? And why does that doc look like it should all work just fine?





-Original Message-
From: Chris Nicholls [mailto:ch...@timico.net] 
Sent: Wednesday, June 30, 2010 3:54 AM
To: Christian MacNevin
Subject: Re: [c-nsp] 6PE: was: mpls over native ipv6?

I have it running, 6PE is pretty simple

I extended our current peer groups for ibgp into the address-family
ipv6, and added the "send-label" attribute. then peer over a v4
transport within the v6 address family.

There is no native LDP for IPv6 so no true native MPLS(yet)

address-family ipv6
  neighbor ibgp-rr send-label
  neighbor xxx.xxx.19.204 activate
  neighbor xxx.xxx.19.206 activate
  neighbor xxx.xxx.252.251 activate

You can use "show mpls forwarding-table", "sho ipv6 cef" to check the
usual stuff.

Regards

On Tuesday, 29 June 2010 at K:50:28 -0700, Christian MacNevin wrote:
> Ok,so anybody got any experience with 6PE? I'm having trouble finding an 
> image that supports the feature, particularly the command:
> 'mpls ipv6..' anything.
> 
> Anybody?
> 
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christian MacNevin
> Sent: Tuesday, June 29, 2010 2:18 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] mpls over native ipv6?
> 
> Hey there,
> 
> I'm prodding around at a couple of different IOSes and googling, and it seems 
> as though 6PE is well documented, but
> while I can see white papers about MPLS over native ipv6, I'm not exactly 
> sure how well supported it really is.
> 
> Anyone got the info on this? Supported trains for the 7200 perhaps?
> 
> Thanks!
> Christian
> ___
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
---end quoted text---

-- 
Chris Nicholls
Timico Network Operations
ch...@timico.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Mateusz Blaszczyk]

On 30 June 2010 02:57, Harold Ritter  wrote:
> Hi Christian,
>
> Most recent IOS versions should support 6PE. The command "mpls ipv6 
> source-interface" has been removed from most recent IOS versions as well. 
> This command only applied to locally originated traffic and the source 
> address selection is now as per RFC3484.
>

And what IPv6 address should it be used by 6PE router when originating
ICMPv6 packets in response to traceroutes coming from behind the MPLS
network?
On 7600 with SRB7[1] and SRD[2] it takes an IPv6 address that is
configured on the first physical interface (ie. not SVI) visible in
the configuration...
Not like with MPLS/VPNs where the source address is taken from the
egress interface towards VPN.

Bug?

Best Regards,

-mat

[1] Cisco IOS Software, c7600rsp72043_rp Software
(c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB7, RELEASE
SOFTWARE (fc1)
[2] Cisco IOS Software, c7600rsp72043_rp Software
(c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRD, RELEASE
SOFTWARE (fc2)
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6PE: was: mpls over native ipv6?

[Harold Ritter]

Hi Christian,

Most recent IOS versions should support 6PE. The command "mpls ipv6 
source-interface" has been removed from most recent IOS versions as well. This 
command only applied to locally originated traffic and the source address 
selection is now as per RFC3484.

Regards
 
Le 2010-06-29 à 18:50, Christian MacNevin a écrit :

> Ok,so anybody got any experience with 6PE? I'm having trouble finding an 
> image that supports the feature, particularly the command:
> 'mpls ipv6..' anything.
> 
> Anybody?
> 
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christian MacNevin
> Sent: Tuesday, June 29, 2010 2:18 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] mpls over native ipv6?
> 
> Hey there,
> 
> I'm prodding around at a couple of different IOSes and googling, and it seems 
> as though 6PE is well documented, but
> while I can see white papers about MPLS over native ipv6, I'm not exactly 
> sure how well supported it really is.
> 
> Anyone got the info on this? Supported trains for the 7200 perhaps?
> 
> Thanks!
> Christian
> ___
> cisco-nsp mailing list  cisco-nsp@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6PE: was: mpls over native ipv6?

[Christian MacNevin]

Ok,so anybody got any experience with 6PE? I'm having trouble finding an image 
that supports the feature, particularly the command:
'mpls ipv6..' anything.

Anybody?


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christian MacNevin
Sent: Tuesday, June 29, 2010 2:18 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] mpls over native ipv6?

Hey there,

I'm prodding around at a couple of different IOSes and googling, and it seems 
as though 6PE is well documented, but
while I can see white papers about MPLS over native ipv6, I'm not exactly sure 
how well supported it really is.

Anyone got the info on this? Supported trains for the 7200 perhaps?

Thanks!
Christian
___
cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/