IPv6. Multicasting.
Anyone still here to read this? There is? I didn’t scare all of you off?
:)
While labbing last night I managed to configure myself a perfectly non-working IPv6 multicast configuration that appeared to have nothing wrong. In fact, under certain circumstances it did work, but the one specific test I wanted to do to prove reachability just simply wasn’t working. I eventually managed to sort it out, though it took a bit of brute forcing PIM parameters to get it to work, and to then sort out why it worked.
Showing posts with label IPv6. Show all posts
Showing posts with label IPv6. Show all posts
Tuesday, February 5, 2013
Thursday, December 22, 2011
Simple IPv6 Multicast Configuration
IPv6 Multicasting is something that's been confusing me a bit lately. I think I finally have the basics figured out... And I'm going to put there here so that you can read all about it. Because you want to read all about it. Don't you?
I thought so.
I thought so.
Thursday, February 24, 2011
IPv6 Will Make You Think Differently: We Don't Need No Stinking FHRP
I got into a discussion about the availability of HSRP for IPv6 being in higher end Cisco platforms but not the lower ones. I didn't think too much of the question when first saw it, but in reading up on IPv6 last night I came across some of the details in Neighbour Discovery that I thought might be a good replacement. Deep within RFC 2461 lies section 6.3.6:
6.3.6. Default Router Selection
The algorithm for selecting a router depends in part on whether or
not a router is known to be reachable. The exact details of how a
node keeps track of a neighbor's reachability state are covered in
Section 7.3. The algorithm for selecting a default router is invoked
during next-hop determination when no Destination Cache entry exists
for an off-link destination or when communication through an existing
router appears to be failing. Under normal conditions, a router
would be selected the first time traffic is sent to a destination,
with subsequent traffic for that destination using the same router as
indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages.
The policy for selecting routers from the Default Router List is as
follows:
1) Routers that are reachable or probably reachable (i.e., in any
state other than INCOMPLETE) SHOULD be preferred over routers
whose reachability is unknown or suspect (i.e., in the
INCOMPLETE state, or for which no Neighbor Cache entry exists).
An implementation may choose to always return the same router or
cycle through the router list in a round-robin fashion as long
as it always returns a reachable or a probably reachable router
when one is available.
2) When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been
selected.
Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability
as a side effect.
3) If the Default Router List is empty, assume that all
destinations are on-link as specified in Section 5.2.
Let's take a look at how we can use this to our advantage.
The algorithm for selecting a router depends in part on whether or
not a router is known to be reachable. The exact details of how a
node keeps track of a neighbor's reachability state are covered in
Section 7.3. The algorithm for selecting a default router is invoked
during next-hop determination when no Destination Cache entry exists
for an off-link destination or when communication through an existing
router appears to be failing. Under normal conditions, a router
would be selected the first time traffic is sent to a destination,
with subsequent traffic for that destination using the same router as
indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages.
The policy for selecting routers from the Default Router List is as
follows:
1) Routers that are reachable or probably reachable (i.e., in any
state other than INCOMPLETE) SHOULD be preferred over routers
whose reachability is unknown or suspect (i.e., in the
INCOMPLETE state, or for which no Neighbor Cache entry exists).
An implementation may choose to always return the same router or
cycle through the router list in a round-robin fashion as long
as it always returns a reachable or a probably reachable router
when one is available.
2) When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been
selected.
Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability
as a side effect.
3) If the Default Router List is empty, assume that all
destinations are on-link as specified in Section 5.2.
Let's take a look at how we can use this to our advantage.
Monday, October 18, 2010
PeerIX Version 6: BGP and IPv6
I got involved in a project called PeerIX this week. It's a group of guys that have all connected various routing devices together over GRE and/or IPsec tunnels to form a BGP network for learning purposes. I got involved when a a thread on Networking-Forum about this group started thinking that this might be interesting to do the same concept with IPv6. As I was one of the people that was interested here I am posting about it.
Subscribe to:
Posts (Atom)