I wanted to test 6PE and 6VPE interoperability with the three major vendors. As always I’m stuck with IOS only in the Cisco world for now, but what can I do. This test will run over a Junos MPLS core. All my MPLS labs thus far has been using RSVP, so let’s change this to LDP for now just to mix things up a bit.

6PE allows you to run IPv6 transport over a IPv4 MPLS core. MPLS does not have native label support for IPv6 addresses, at least yet. This means if you need to transport IPv6 traffic over your MPLS core, you need to tunnel it over IPv4. 6PE is one of those ways. 6VPE is essentially MPLS layer 3 VPN for IPv6 over an IPv4 as opposed to 6PE which is simple IPv6 over an IPv4 MPLS core.

multi vendor l3vpn IPv6 over IPv4 MPLS Core Interop   IOS, Junos, Netiron   Part 1 of 2   6PE

6PE

There is no need to worry about CPE kit for now. I’ll simply have an IPv6 loopback address on R3, R4, and R8. These PE routers will peer over MP-BGP over the IPv4-only core.

R3 – Junos

interfaces {
    ae1 {
        unit 13 {
            vlan-id 13;
            family inet {
                address 10.0.4.13/30;
            }
            family inet6;
            family mpls;
        }
    lo0 {
        unit 3 {
            family inet {
                address 3.3.3.3/32;
            }
            family inet6 {
                address 2001:db8:3333::3333/128;
            }
        }
    }
}
protocols {

    mpls {
        ipv6-tunneling;
        interface ae1.13;
    }
    bgp {
        group 6PE {
            family inet6 {
                labeled-unicast {
                    explicit-null;
                }
            }
            export LOOPBACK;
            peer-as 100;
            neighbor 4.4.4.4;
            neighbor 8.8.8.8;
        }
    }
    ldp {
        interface ae1.13;
    }
}
policy-options {
    policy-statement LOOPBACK {
        from {
            protocol direct;
            route-filter 2001:db8:3333::3333/128 exact;
        }
        then accept;
    }
}
routing-options {
    autonomous-system 100;
}

Junos requires you to active the family inet6 address family on the core-facing interface, even if no address is applied. LDP is configured. BGP has been configured with family inet6 address family only. You also need to send labelled unicast as well as explicit-null. Junos will not commit if you leave this out.

I’ve then redistributed my IPv6 loopback address into BGP.

R4 – IOS

interface Loopback6
 no ip address
 ipv6 address 2001:DB8:4444::4444/128
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet1/0.24
 encapsulation dot1Q 24
 ip address 10.0.4.9 255.255.255.252
 ip ospf network point-to-point
 mpls ip
!
router bgp 100
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 8.8.8.8 remote-as 100
 neighbor 8.8.8.8 update-source Loopback0
 !
 address-family ipv6
  no synchronization
  network 2001:DB8:4444::4444/128
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-label
  neighbor 8.8.8.8 activate
  neighbor 8.8.8.8 send-label
 exit-address-family

IOS is a bit easier. Create my loopback, IPv6 unicast BGP sessions with send-label configured, and advertise IPv6 loopback.

R8 – Netiron

interface loopback 1
 ip ospf area 0
 ip address 8.8.8.8/32
 ipv6 address 2001:db8:8888::8888/128
!
router bgp
 local-as 100
 next-hop-mpls
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source 8.8.8.8
 neighbor 4.4.4.4 remote-as 100
 neighbor 4.4.4.4 update-source 8.8.8.8

 address-family ipv6 unicast
 network 2001:db8:8888::8888/128
 neighbor 3.3.3.3 activate
 neighbor 3.3.3.3 send-label
 neighbor 4.4.4.4 activate
 neighbor 4.4.4.4 send-label
 exit-address-family
!
router mpls

 mpls-interface ve2
  ldp-enable

Very similar to IOS here.

Verification

First let’s see if each of our boxes has the IPv6 routes to the others loopbacks:

USER3:R3> show route 2001:db8:4444::4444/128

inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:db8:4444::4444/128
                   *[BGP/170] 00:19:31, MED 0, localpref 100, from 4.4.4.4
                      AS path: I
                    > to 10.0.4.14 via ae1.13, Push 16, Push 300016(top)

USER3:R3> show route 2001:db8:8888::8888/128

inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:db8:8888::8888/128
                   *[BGP/170] 21:40:12, MED 0, localpref 100, from 8.8.8.8
                      AS path: I
                    > to 10.0.4.14 via ae1.13, Push 794624, Push 300048(top)
7200_SRD_R4#show ipv6 route 2001:DB8:3333::3333/128
Routing entry for 2001:DB8:3333::3333/128
  Known via "bgp 100", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
    3.3.3.3%default indirectly connected
      MPLS Required
      Last updated 00:20:47 ago

7200_SRD_R4#show ipv6 route 2001:DB8:8888::8888/128
Routing entry for 2001:DB8:8888::8888/128
  Known via "bgp 100", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
    8.8.8.8%default indirectly connected
      MPLS Required
      Last updated 00:21:00 ago
SSH@XMR_R8#show ipv6 route 2001:db8:3333::3333/128
Type Codes - B:BGP C:Connected I:ISIS L:Local O:OSPF R:RIP S:Static
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
STATIC Codes - d:DHCPv6
Type IPv6 Prefix           Next Hop Router    Interface     Dis/Metric     Uptime src-vrf
Bi   2001:db8:3333::3333/128
                           ::                 LDP (5)       200/0          8m3s   -
label information: 2(OUT)
SSH@XMR_R8#show ipv6 route 2001:db8:4444::4444/128
Type Codes - B:BGP C:Connected I:ISIS L:Local O:OSPF R:RIP S:Static
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
STATIC Codes - d:DHCPv6
Type IPv6 Prefix           Next Hop Router    Interface     Dis/Metric     Uptime src-vrf
Bi   2001:db8:4444::4444/128
                           ::                 LDP (3)       200/0          7m25s  -
label information: 16(OUT)

Control plane looks fine. Routes are installed with next-hops associated with labels. Let’s see if data actually flows:

USER3:R3> ping 2001:db8:4444::4444 source 2001:db8:3333::3333 rapid count 5
PING6(56=40+8+8 bytes) 2001:db8:3333::3333 --> 2001:db8:4444::4444
!!!!!
--- 2001:db8:4444::4444 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 1.262/1.399/1.789/0.196 ms
7200_SRD_R4#ping 2001:DB8:8888::8888 source lo6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:8888::8888, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:4444::4444
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
SSH@XMR_R8#ping ipv6 2001:db8:3333::3333 source 2001:db8:8888::8888 count 5
Sending 5, 16-byte ICMPv6 Echo to 2001:db8:3333::3333
timeout 5000 msec, Hop Limit 64
Type Control-c to abort
Reply from 2001:db8:3333::3333: bytes=16 time=1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Success rate is 100 percent (5/5), round-trip min/avg/max=0/0/1 ms.

All looks good to me.

You can find part 2 here: hhttp://mellowd.co.uk/ccie/?p=3546

Tagged with:  

Basic IPv6 Multicast

On January 22, 2013, in CCIE, by Darren

Quite a lot of engineers don’t know too much about either IPv6 or multicast. And hence when they’re together a lot of people will automatically think it’s difficult. But I think it’s actually easier than IPv4 multicast. At least for now.

With v4, we had to deal with sparse, dense, and sparse-dense mode. We also had to deal with auto-rp and BSR if we wanted the RP to be found automatically.

With v6, multicast is always sparse-mode. We also only have BSR as a dynamic RP protocol. So there already we have fewer things to worry about.

Let’s use the following topology in this discussion:
Screen Shot 2013 01 22 at 10.06.30 Basic IPv6 Multicast

PIM

With v4 on IOS, you need to enable ipv4 multicast-routing and then enable PIM on your interfaces. With v6 you only need to enable ipv6 multicast-routing. This automatically enabled PIM on all current and future v6 interfaces:

R2(config)#ipv6 multicast-routing
R2#sh ipv6 pim neighbor 
Neighbor Address           Interface          Uptime    Expires DR pri Bidir

FE80::C000:DFF:FE60:0      FastEthernet0/0    00:00:14  00:01:30 1      B
FE80::C003:DFF:FE60:0      FastEthernet0/1    00:00:09  00:01:37 1 (DR) B

You can however disable PIM on an interface if you want to, but it has to be explicitly disabled:

R2(config)#int fa0/1
R2(config-if)#no ipv6 pim
R2(config-if)#end
R2#

R2#sh ipv6 pim neighbor 
Neighbor Address           Interface          Uptime    Expires DR pri Bidir

FE80::C000:DFF:FE60:0      FastEthernet0/0    00:02:48  00:01:25 1      B

For now I’m going to re-enable it again.

BSR

With v4 there was a concept of candidate BSR and candidate RP. With v6 you have the same but it goes a step further. For now let’s make R1 and R3 the candidate RPs and R2 the candidate BSR:

R1(config)#ipv6 pim bsr candidate rp 3000:1111::1
R3(config)#ipv6 pim bsr candidate rp 3000:3333::3
R2(config)#ipv6 pim bsr candidate bsr 3000:2222::2

If you take a look on R2, you can see that it’s currently going through an election to determine the BSR. After a while it will elect itself as the BSR as there is no other candidate BSR.

 
Going through election:

R2#show ipv6 pim bsr election 
PIMv2 BSR information

BSR Election Information
  Scope Range List: ff00::/8
     BSR Address: ::
     Uptime: 00:00:00, BSR Priority: 0, Hash mask length: 0
     RPF: ::,
     BS Timer: 00:00:43
  This system is candidate BSR
      Candidate BSR address: 3000:2222::2, priority: 0, hash mask length: 126

Elected:

R2#show ipv6 pim bsr election 
PIMv2 BSR information

BSR Election Information
  Scope Range List: ff00::/8
  This system is the Bootstrap Router (BSR)
     BSR Address: 3000:2222::2
     Uptime: 00:00:45, BSR Priority: 0, Hash mask length: 126
     RPF: FE80::C001:DFF:FE60:0,Loopback0
     BS Timer: 00:00:15
  This system is candidate BSR
      Candidate BSR address: 3000:2222::2, priority: 0, hash mask length: 126

So now R2 should be determining who the RP is from the two candidate RPs. Let’s see the final decision:

R2#show ipv6 pim range-list 
Static SSM Exp: never Learnt from : ::
  FF33::/32 Up: 00:14:17
  FF34::/32 Up: 00:14:17
  FF35::/32 Up: 00:14:17
  FF36::/32 Up: 00:14:17
  FF37::/32 Up: 00:14:17
  FF38::/32 Up: 00:14:17
  FF39::/32 Up: 00:14:17
  FF3A::/32 Up: 00:14:17
  FF3B::/32 Up: 00:14:17
  FF3C::/32 Up: 00:14:17
  FF3D::/32 Up: 00:14:17
  FF3E::/32 Up: 00:14:17
  FF3F::/32 Up: 00:14:17
BSR SM RP: 3000:1111::1 Exp: 00:02:27 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:02:02
BSR SM RP: 3000:3333::3 Exp: 00:02:27 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:02:02

As this is BSR, these RPs are then advertised through PIM itself. This means R4 should have the same information. Let’s see if this is the case:

R4#show ipv6 pim range-list 
Static SSM Exp: never Learnt from : ::
  FF33::/32 Up: 00:15:03
  FF34::/32 Up: 00:15:03
  FF35::/32 Up: 00:15:03
  FF36::/32 Up: 00:15:03
  FF37::/32 Up: 00:15:03
  FF38::/32 Up: 00:15:03
  FF39::/32 Up: 00:15:03
  FF3A::/32 Up: 00:15:03
  FF3B::/32 Up: 00:15:03
  FF3C::/32 Up: 00:15:03
  FF3D::/32 Up: 00:15:03
  FF3E::/32 Up: 00:15:03
  FF3F::/32 Up: 00:15:03
BSR SM RP: 3000:1111::1 Exp: 00:01:30 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:02:59
BSR SM RP: 3000:3333::3 Exp: 00:01:30 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:02:59

You can of course play with priorities and group-lists just like in v4. For now both RPs simply say they can be candidate RPs for the entire FF00::/8

So, both candidate RPs have advertised their candidacy to the BSR who has chosen who is the RP and then advertised that out. What if we wanted to do this all from the BSR itself? i.e. let the BSR tell everyone who the RP is without waiting for any candidate RP messages. Let’s remove the candidacy config form both R1 and R3:

R1(config)#no ipv6 pim bsr candidate rp 3000:1111::1
R3(config)#no ipv6 pim bsr candidate rp 3000:3333::3

just to be sure, let’s take a look at R2 quick. We can see no RP for any group:

R2#show ipv6 pim range-list 
Static SSM Exp: never Learnt from : ::
  FF33::/32 Up: 00:19:31
  FF34::/32 Up: 00:19:31
  FF35::/32 Up: 00:19:31
  FF36::/32 Up: 00:19:31
  FF37::/32 Up: 00:19:31
  FF38::/32 Up: 00:19:31
  FF39::/32 Up: 00:19:31
  FF3A::/32 Up: 00:19:31
  FF3B::/32 Up: 00:19:31
  FF3C::/32 Up: 00:19:31
  FF3D::/32 Up: 00:19:31
  FF3E::/32 Up: 00:19:31
  FF3F::/32 Up: 00:19:31

On the BSR I now tell it to advertise R1 as the RP:

R2(config)#ipv6 pim bsr announced rp 3000:1111::1

All routers, including R1, will receive this message. So therefore R1 will consider itself the RP. Do we see that?

R1#show ipv6 pim range-list 
Static SSM Exp: never Learnt from : ::
  FF33::/32 Up: 00:21:43
  FF34::/32 Up: 00:21:43
  FF35::/32 Up: 00:21:43
  FF36::/32 Up: 00:21:43
  FF37::/32 Up: 00:21:43
  FF38::/32 Up: 00:21:43
  FF39::/32 Up: 00:21:43
  FF3A::/32 Up: 00:21:43
  FF3B::/32 Up: 00:21:43
  FF3C::/32 Up: 00:21:43
  FF3D::/32 Up: 00:21:43
  FF3E::/32 Up: 00:21:43
  FF3F::/32 Up: 00:21:43
BSR SM RP: 3000:1111::1 Exp: 00:02:12 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:01:17

We sure do.

As noted you can still use group lists. Let’s divide the range a bit and ensure R3 is the RP for the smaller range:

R2(config)#ipv6 access-list FFA0_RANGE
R2(config-ipv6-acl)#permit ipv6 any ffa0::/16
R2(config-ipv6-acl)#exit
R2(config)#ipv6 pim bsr announced rp 3000:3333::3 group-list FFA0_RANGE

Let’s take a look from R4′s perspective again:

R4#show ipv6 pim range-list 
Static SSM Exp: never Learnt from : ::
  FF33::/32 Up: 00:24:45
  FF34::/32 Up: 00:24:45
  FF35::/32 Up: 00:24:45
  FF36::/32 Up: 00:24:45
  FF37::/32 Up: 00:24:45
  FF38::/32 Up: 00:24:45
  FF39::/32 Up: 00:24:45
  FF3A::/32 Up: 00:24:45
  FF3B::/32 Up: 00:24:45
  FF3C::/32 Up: 00:24:45
  FF3D::/32 Up: 00:24:45
  FF3E::/32 Up: 00:24:45
  FF3F::/32 Up: 00:24:45
BSR SM RP: 3000:1111::1 Exp: 00:02:06 Learnt from : 3000:2222::2
  FF00::/8 Up: 00:04:33
BSR SM RP: 3000:3333::3 Exp: 00:02:06 Learnt from : 3000:2222::2
  FFA0::/16 Up: 00:01:23

Sure enough we see R3 as the RP for FFA0::/16

So there we have two different RPs configured, even though neither R1 nor R3 are even configured to advertise themselves as candidate RPs. The BSR simply tells everyone who is the RP for which groups.

Embedded RP

Embedded RP, as it’s name suggests, allows you to insert the RP address into the group address directly. There are a number of caveats as you can’t hide a 128bit address into a 128 bit address. The format of the embedded RP group is as follows:
FF7[scope]:0[RP Interface ID][Prefix Length in HEX]:[64 bit RP Prefix]:[32 bit group ID]

Scope is worked out as follows:
1 = node local
2 = link local
5 = site local
8 = orginisation local
E = global

RP Interface ID is the final digit in the RP’s IPv6 address. For this example I’ll be using R1′s loopback address and so this value will be 1.

The prefix length is then converted to HEX. As R1′s loopback has a /128 mask, this converted to HEX equals 80

The 64bit RP prefix is the actual network portion of R1′s loopback address. This will be 3000:1111:0000:0000, shortened to 3000:1111::

the final part is the 32bit group ID. Essentially this is the actual group as you can have multiple groups mapped to the same RP. For this example I’ll simply use 1

So in order to create a site local embedded RP address mapped to R1, my initial group address will be: FF75:0180:3000:1111::1

If I configure R4 to join this group, you can take a look at the mroute table and the RP address will be there without us having to actually configure it anywhere:

interface FastEthernet0/0
 ipv6 mld join-group FF75:180:3000:1111::1
R4#show ipv6 mroute | beg \(
(*, FF75:180:3000:1111::1), 00:05:22/never, RP 3000:1111::1, flags: SCLJ
  Incoming interface: FastEthernet0/0
  RPF nbr: FE80::C003:DFF:FE60:1

The trickiest part of Embedded RP is remembering how the address breaks down. In real life you could just stick this on a post-it note and stick it on your monitor :)

Tagged with:  

Ok, it took a bit longer than I wanted it to but here we go.

 

You can now reach www.mellowd.co.uk/ccie via both IPv4 and IPv6 natively. Hooray.

 

 

And it only makes sense to get an address with ccie in it? Sure!

Name:    mellowd.co.uk
Addresses:  2001:a08:da2::cc1e
            89.248.22.45

A couple of things to note. I had to enable listening on ipv6 of my web server software as well as sort my ip6tables out. ICMP is a lot more important in IPv6 than it is in IPv4 so watch that.


button ipv6 big mellowd.co.uk finally reachable via IPv6

Tagged with:  

CCIE R&S Multicasting notes

On December 31, 2011, in CCIE, notes, by Darren

Sparse mode:

  • When user joins, connected router will have *,G entry, as it knows the group joined by the user, but not the source of that feed yet. This is the SHARED tree.
  • The RP WILL have an S,G entry. Once the router connects it will stay on the *,G shared tree at first, then switch over to the S,G source tree.
  • While on the shared tree, the RPF check will be towards the RP, NOT the source! This will change to the source once the router connects to the source tree
  • ip pim spt threshold controls when the router will switch from the *,G to the S,G tree. A value of infinity means it’ll NEVER switch to the S,G tree

Dense mode:

  • In dense mode you’ll always see S,G entries as the source has been flooded through the network. i.e. all PIM routers will already have the feed, and hence will know the source

Sparse-Dense mode:

  • Sparse-dense mode is mainly like sparse mode, but any group that cannot be registered with the RP becomes dense mode
  • This is good for Auto-RP, but it also means that mis-configurations on the RP could cause lots of groups to be dense mode instead of sparse mode

Rendezvous point:

All modes:

  • You need to run PIM on the interface that you are advertising as the RP. i.e if you’re running it on a loopback interface, run PIM on that loopback!
  • Auto assignments OVERRIDE static assignments! You can use ip pim rp-address (rp_address) (acl) override to override this default behaviour

Static RP:

  • Easiest to configure, pretty much like a static route
  • ip pim rp-address (rp_address) (acl)
  • (acl) determines what groups the router will be the RP for
  • The RP router ALSO needs to have the above configured. i.e the RP does not automatically know it is the RP, you need to tell the router that it is!

Auto-RP (Cisco proprietary):

  • Auto-RP is made up of 1 or more routers announcing themselves as candidate RPs using the command: ip pim send-rp-announce (acl) as well as a mapping agent using the command: ip pim send-rp-discovery
  • Only the mapping agent listens to the RP announcements
  • The MA then determines which RP to use for which groups and advertises that to all other PIM routers
  • The auto-rp process uses the 224.0.1.39 and 224.0.1.40 groups
  • In sparse-dense mode the 2 groups above are automatically in dense mode
  • If running sparse mode only, you need to configure ip pim auto-rp listener on transit PIM interfaces which will ensure that ONLY 224.0.1.39 and 224.0.1.40 are in dense mode
  • If the MA receives 2 announcements from candidate RPs for the same groups, the MA will choose the one with the highest IP address
  • The RP and MA can be the same device if needs be
  • Auto-RP IS supported by a number of Non Cisco devices. Confirm with proctor is question is not clear
  • When specifying an ACL with a RP announcement, the deny statements will create negative entries for groups. However a deny any at the end of the ACL will effectively make ALL groups negative, and hence dense mode, regardless of what’s configured. As an example:

ip pim send-rp-announce Loopback0 scope 15 group-list 12 interval 1
access-list 12 deny 224.110.110.110
access-list 12 permit 224.0.0.0 15.255.255.255
access-list 12 deny any

If you check the mapping agent you see this:

Group(s) (-)224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Once the deny statement at the end of the ACL is removed, you see this:

Group(s) 224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Bootstrap router – BSR (Open standard)

  • BSR uses the group 224.0.0.13, but it does NOT need to be in dense mode, unlike auto-rp
  • 224.0.0.13 is the link-local ALL PIM ROUTERS address as well
  • The Bootstrap router is the Mapping Agent in auto-rp, configured using: ip pim bsr-candidate (int) (hash) (pri)
  • The RP uses the same name as in auto-rp, configured using: ip pim rp-candidate (int) (ttl) (pri) (acl)
  • The hash field will allow you to load balance groups over your RPs – A hash value of 31 ensures all even groups are with on RP and odds are with another, if you have 2 RPs
  • You can see which group is mapped to which RP with show ip pim rp-hash (group)
  • BSR has priority fields so you can choose which router does what without having to rely on the high IP taking over
  • If priority is the same, then highest IP will be chosen like auto-rp
  • ip pim bsr-border will allow you to run PIM on an edge interface, but not to share bsr messages

Multicast on Frame-Relay:

  • By default, multicast traffic is process switched over frame-relay. Multicast frames also have the pak-priority set so have the highest priority
  • If you have a hub router connected to 2 spokes over the same interface, you’ll have problem with RPF checks as you are going in and out the same interface. You can also have problem where a spoke says it no longer wants to receive a feed, this would make the hun stop sending to ALL spokes.
  • ip pim nbma-mode fixes both of the above issues. When configuring nbma mode on sparse-dense and dense mode interfaces you’ll get a warning, but it’ll still work.

Multicast Boundry:

  • int# ip multicast-boundry will stop multicast packets getting through an interface.
  • Any address ALLOWED through the acl is ALLOWED through the interface
  • The boundry is bidirectional by default. If you specify the IN option it will prevent multicast control traffic coming into the interface. If you specify the OUT option it will prevent the interface from being added to the OIL

Stub Multicast:

  • Prevent routers from fully participating in PIM. Consider the diagram:

multicast filter CCIE R&S Multicasting notes

  • R2 has users on the Fa0/0 interface that want to join the multicast feed. However you do not want R2 to fully run PIM. In order to do so, you need to have R1 configured to prevent R2 from becoming a PIM neighbour. You need then to configure R2 to forward IGMP join messages to R1. Note that dense mode is configured on R2 as it needs to flood multicast traffic over to fa0/0 when it gets an igmp join.

R1:
access-list 1 deny 192.168.1.2
!
int s0/0
ip pim sparse-mode
ip pim neighbor-filter 1

R2:
int s0/0
ip pim dense-mode
!
int fa0/0
ip pim dense-mode
ip igmp helper-address 192.168.1.1

Multicast/Broadcast conversion:

  • You can convert multicast to broadcast, and from broadcast to multicast. You can also do this multiple times backwards and forwards if you need to. Consider the following example:

multicast2 CCIE R&S Multicasting notes

  • We have a server with the IP of 172.16.1.25 that is sending out a udp broadcast to port 5000. For whatever reason we need that same frame to be broadcasted onto the 10.50.50.0/24 network.
  • To convert from broadcast to multicast you configure like so:

R1:
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
ip forward-protocol udp 5000
!
int fa0/1
ip multicast helper-map broadcast 224.10.10.10 100

  • Then back from multicast to broadcast like so:

R3:
ip forward-protocol udp 5000
!
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
int fa0/0
ip multicast helper-map 224.10.10.10 10.50.50.255 100
!
int fa0/1
ip directed-broadcast

MSDP:

  • MSDP is used for inter-domain multicasting as well as to allow RPs in a single AS to share source information if running anycast RP. All you need to configure on the RPs is:

ip msdp peer (peer_unique_address) connect-source (local_unique_interface)

ip msdp originator-id (unique_address_interface)

Bidirectional PIM:

  • You need to configure ip pim bidir-enable on ALL PIM interfaces. Most RP commands will then have the bidir switch added to the end of commands.

IPv6 Multicast:

  • Sparse mode only
  • Enabled using Ipv6 multicast-routing
  • When enabled, Pim will run automatically on all ipv6 interfaces. Need to run no ipv6 pim on the interface to remove
  • Multicast listener discovery (MLD), part of ICMPv6, replaces igmp
  • Mldv1 is equivalent to IGMPv2. Same timers and so on
  • Mldv2 equivalent to IGMP3 for ssm
  • BSR and Static RP only. No auto-rp. You can also use embedded RP which encodes the RP address in the group address
  • sh ipv6 Pim range-list will show you the rp mapping
  • ipv6 mld join-group will join a group on an interface
  • IPv6 mroute is created using ipv6 route (address/prefix) (next_hop) multicast, NOT ipv6 mroute
  • Pretty much everything else is the same as ipv4

Miscellaneous:

  • PIM assert will take the Administrative Distance into account first, and then metric if that AD matches. So in order to force a router to be the PIM assert router, you may need to adjust the AD
  • ip pim accept-rp (acl) will ensure the RP only accepts *,G joins for groups defined in the ACL. In theory you only need to put this on the RP, but it’s more efficient to put it on all routers so they drop the requests before it even gets to the RP
  • int#ip igmp (acl) is used to allow only joins to certain groups through an interface. This interface is pointing towards the receivers as the control packet is igmp
  • int#ip igmp limit is used to limit the amount of igmp states on an interface. Can also configure this globally
  • When configuring source specific multicast, you are required to configure ip pim ssm default or ip pim ssm (acl) on all PIM routers to ensure they do not create *,G entries. SSM does not actually need an RP as they do not connect to shared trees, only source trees.
  • On an ethernet segment a DR will be chosen between the PIM neighbours. By default, the priority is 1. If the priority is the same, the highest IP wins. This can be changed with the int#ip pim dr-priority command. Note that not all switches support this command!
  • If your IGP is load-balancing certain paths, you can load-balanse multicast as well with the ip multicast multipath command. This is essential so that your rpf checks don’t fail.
Tagged with:  

I went a bit fast when I posted this write-up: http://mellowd.co.uk/ccie/?p=1369

I think it’s better to have a longer discussion about how authentication OSPFv3 SHOULD be set up to begin with, then show how it doesn’t work without a security license.

Let’s begin with regular IPv4. I’ve got 2 1841′s running and this is the config. This config is IDENTICAL whether you’re using a base license or security license, as the authentication is handled by OSPF’s internal authentication.
Router1

interface FastEthernet0/0
 ip address 10.0.0.1 255.0.0.0
 duplex auto
 speed auto
!
router ospf 1
 router-id 10.0.0.1
 log-adjacency-changes
 network 10.0.0.1 0.0.0.0 area 0

Router2

interface FastEthernet0/0
 ip address 10.0.0.2 255.0.0.0
 duplex auto
 speed auto
!
router ospf 1
 router-id 10.0.0.2
 log-adjacency-changes
 network 10.0.0.2 0.0.0.0 area 0

They see each other?

1841test2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.1          1   FULL/BDR        00:00:38    10.0.0.1        FastEthernet0/0

Let’s authenticate. Again, you can do this on a base license.

interface FastEthernet0/0
 ip address 10.0.0.2 255.0.0.0
 ip ospf message-digest-key 1 md5 ipv4test
!
router ospf 1
 router-id 10.0.0.2
 area 0 authentication message-digest
 network 10.0.0.2 0.0.0.0 area 0
1841test2# sh ip ospf 1
 ! - removed
       Area has message digest authentication

Let’s now move to IPv6 and OSPFv3. This is a regular set up without authentication:

ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/1
 no ip address
 ipv6 address 2001:DB8::/64 eui-64
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes

router2

ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/1
 no ip address
 ipv6 address 2001:DB8::/64 eui-64
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
1841test1#sh ipv6 ospf neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/BDR        00:00:39    4               FastEthernet0/1

Let’s now add authentication. In order to do so we use the interface specific “ipv6 ospf authentication ipsec” command

interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:DB8::/64 eui-64
 ipv6 ospf 1 area 0
 ipv6 ospf authentication ipsec spi 512 sha1 5C4070ED005A378F1529065802B4B5BF44032A0F

We immediately see the following error as the other side has no authentication set up:

#:%IPSECV6-4-RECVD_PKT_NOT_IPSECV6: Rec'd packet not an IPSEC packet.
        (ip) dest_addr= FF02::5, src_addr= FE80::6616:8DFF:FECB:C32B, prot= 89

Let’s fix it quick:

interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:DB8::/64 eui-64
 ipv6 ospf 1 area 0
 ipv6 ospf authentication ipsec spi 512 sha1 5C4070ED005A378F1529065802B4B5BF44032A0F

Comes straight up again:

#:%OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1 from LOADING to FULL, Loading Done

This is all great, until you realise that you can NOT set ipsec authentication without an expensive security license!
This is a router with a security license:

1841test1(config-if)#ipv6 ospf ?
  <1-65535>            Process ID
  authentication       Enable authentication
  cost                 Interface cost
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  neighbor             OSPF neighbor
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state
                       advertisements
  transmit-delay       Link state transmit delay

This is a 1941 with a base license:

1941test(config-if)#ipv6 ospf ?
  <1-65535>            Process ID
  cost                 Route cost of this interface
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state
                       advertisements
Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved