IPv6 6PE and a default route?

Unanswered Question
Feb 23rd, 2010

hello

I cam e across a situation in a test lab, that i don't quite understand

i have two test 6PE edge routers advertising IPv6 prefixes across an IPv4 MPLS core. when advertising 'known' routes across the core this is fine, and there is reachability between the IPv6 islands.

However, as a test, i originated a default from one of the 6PE devices to the other, but the other 6PE device will not install this default as it says the next-hop is inaccessible, even though the next-hop is the same as the ones for the valid routes. any ideas?

see below for the comparison of the two prefixes

*Mar  1 00:21:16.295: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, localpref 100, metric 0
*Mar  1 00:21:16.303: BGP(1): 1.1.1.1 rcvd ::/0


*Mar  1 00:21:16.335: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, localpref 100, metric 0, path 2
*Mar  1 00:21:16.339: BGP(1): 1.1.1.1 rcvd 2002::/16


*Mar  1 00:21:16.351: BGP(1): no valid path for ::/0
*Mar  1 00:21:16.355: BGP(1): nettable_walker ::/0 no best path


*Mar  1 00:21:16.363: BGP(1): Revise route installing 2002::/16 -> ::FFFF:1.1.1.1 (::) to main IPv6 table

PE2#sh ip bgp ipv6 uni ::/0
BGP routing table entry for ::/0, version 2
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    ::FFFF:1.1.1.1 (inaccessible) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal


PE2#sh ip bgp ipv6 uni 2002::/16
BGP routing table entry for 2002::/16, version 4
Paths: (1 available, best #1, table Global-IPv6-Table)
  Advertised to update-groups:
     1
  2
    ::FFFF:1.1.1.1 (metric 3) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      mpls labels in/out nolabel/20

thank you

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (2 ratings)
dean holroyd Tue, 02/23/2010 - 12:25

i do see a difference in a packet capture in that the default has no label in the NLRI, whereas the 'good' routes do have 6PE labels.

how can i inject a default with labels into 6PE? is it possible?

dean holroyd Tue, 02/23/2010 - 12:45

i think i may have answered my own question

initially, i was sending a default to the 6PE peer using a neighbor default-originate statement, however, this would seem not to do

if i remove this, and inject a default into bgp on the PE1 device, i see it on PE2 with valid 6PE labels attached

PE2#sh ip bgp ipv6 uni ::/0
BGP routing table entry for ::/0, version 21
Paths: (1 available, best #1, table Global-IPv6-Table)
  Advertised to update-groups:
     1
  Local
    ::FFFF:1.1.1.1 (metric 3) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      mpls labels in/out nolabel/26

stevendodd Wed, 01/11/2012 - 08:21

Dean,

If you want to use the 'default-originate' command you also need a route map that forces the MPLS label to be applied.

route-map V6_DEFAULT permit 10

set mpls-label

router bgp 1

address-family ipv6

  neighbor X activate

  neighbor X default-originate route-map V6_DEFAULT

exit-address-family

HTH,

Steve

dean holroyd Thu, 01/12/2012 - 01:31

Thanks for the reply Steve

This is an old post from last year, and we fixed the issue a long time ago. What you are saying should work (so you would think), but at the time we came to the conclusion that it doesn't

R1#

route-map set-label permit 10

set mpls-label

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 2.2.2.2 remote-as 1

neighbor 2.2.2.2 update-source Loopback0

address-family ipv6

  network ::/0

  neighbor 2.2.2.2 activate

  neighbor 2.2.2.2 default-originate route-map set-label

  neighbor 2.2.2.2 route-map set-label out

  neighbor 2.2.2.2 send-label

exit-address-family

R2#

*Jan 12 09:23:06.403: BGP(1): no valid path for ::/0

R2#

*Jan 12 09:24:06.439: BGP(1): no valid path for ::/0

R2#sh bgp ipv6 un ::/0

BGP routing table entry for ::/0, version 0

Paths: (1 available, no best path)

  Not advertised to any peer

  Local

    ::FFFF:1.1.1.1 (inaccessible) from 1.1.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, internal

you can however assign a label to the default by getting it in to the RIB before the neighbor statement e.g. via a network statement

R1(config)#ipv6 route ::/0 null0      

R1(config)#router bgp 1

R1(config-router)#address-f ipv6

R1(config-router-af)#network ::/0

R1(config-router-af)#no nei 2.2.2.2 default-originate

R2#

*Jan 12 09:26:55.767: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, localpref 100, metric 0

*Jan 12 09:26:55.767: BGP(1): 1.1.1.1 rcvd ::/0, label 21

*Jan 12 09:26:55.767: BGP: TX IPv6 Unicast Net global ::/0 Changed.

*Jan 12 09:26:55.775: BGP(1): Revise route installing ::/0 -> ::FFFF:1.1.1.1 (::) to main IPv6 table

R2#sh bgp ipv6 un ::/0

BGP routing table entry for ::/0, version 4

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  Local

    ::FFFF:1.1.1.1 (metric 11) from 1.1.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      mpls labels in/out nolabel/21

Thanks

Dean

dean holroyd Thu, 01/12/2012 - 01:37

Hello Peter

From experience. If you are not using route-maps at all, then the label assignment occurs automatically and is advertised to peers. If you do use route-maps, then they strip off the label as the prefix goes out to the peer, and you need to force it back on with a set-mpls label command

Thanks

Dean

Peter Paluch Thu, 01/12/2012 - 01:41

Hi Dean,

Thanks a lot! Hmmm... I have not experienced that so far - but I haven't been playing very much with labeled routes and route-maps together. Does this happen only in 6PE, or can this be observed also in common BGP + send-label scenarios?

I still wonder if this is documented anywhere.

Best regards,

Peter

dean holroyd Thu, 01/12/2012 - 01:45

Haven't experienced it with IPv4 L3 VPN Peter. Not tried a 6VPE yet

Thanks

Dean

Peter Paluch Thu, 01/12/2012 - 01:57

Hello Dean,

Thank you very much. So let me sum this up to see if I got it correctly: the issue can be replicated only with 6PE and not with plain BGP+send-label or IPv4 MPLS VPNs (VPNv4). To replicate the issue in 6PE, simply use a route-map in an outbound direction to filter some IPv6 prefixes and observe that all labels are being dropped unless the route-map contains the set mpls-label command. Is this correct?

Thank you once again!

Best regards,

Peter

dean holroyd Thu, 01/12/2012 - 02:01

Correct.

From other threads I have seen, it may affect plain  IPv4 + label as well (i.e. not in a VPN). Not tried it though.

Thanks

Dean

Peter Paluch Thu, 01/12/2012 - 01:34

Steven and Dean,

This intrigues me a bit. Why do you believe we have to specifically use a route-map to force a label assignment?

Best regards,

Peter

stevendodd Thu, 01/12/2012 - 06:51

Perhaps it is code dependent.

In SRE4 the default-originate + route-map works fine without having to declare a network under the ipv6 AF or redistribute a static.

stevendodd Thu, 01/12/2012 - 07:41

R1#sh run | s bgp

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 2.2.2.2 remote-as 1

neighbor 2.2.2.2 update-source Loopback0

!

address-family ipv4

  no synchronization

  no auto-summary

exit-address-family

!

address-family ipv6

  no synchronization

  network 2001:DB8::1/128

  neighbor 2.2.2.2 activate

  neighbor 2.2.2.2 default-originate route-map V6_DEFAULT

  neighbor 2.2.2.2 send-label

exit-address-family

R2#sh run | s bgp

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 1.1.1.1 remote-as 1

neighbor 1.1.1.1 update-source Loopback0

!

address-family ipv4

  no synchronization

  no auto-summary

exit-address-family

!

address-family ipv6

  no synchronization

  network 2001:DB8::2/128

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 send-label

exit-address-family

R2#sh bgp ipv6 uni label

   Network          Next Hop      In label/Out label

   ::/0             ::FFFF:1.1.1.1  nolabel/18

   2001:DB8::1/128 ::FFFF:1.1.1.1  nolabel/17

   2001:DB8::2/128 ::              17/nolabel

dean holroyd Thu, 01/12/2012 - 07:44

nice one.

as you say, it must be a code thing. I tested on SRD last year, and a 12.4 image yesterday

thanks for looking into it

chintan-shah Thu, 01/12/2012 - 07:48

Even Cisco 12K – 12.0(32)SY12 doesn’t need set mpls label.

Whereas SXI for 6500 still needs so yes it may be code thing….

Regards,

Chintan

Actions

Login or Register to take actions

This Discussion

Posted February 23, 2010 at 12:18 PM
Stats:
Replies:14 Avg. Rating:
Views:1996 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard