IPv6 bsr

Hi

------(f0/0.67)R6(f0/0.146)----------ipv4 cloud-----------(s0/0/1)R5(f0/0)----------

IPv6 is configured on R6's f0/0.67, lo0 and tunn56

IPv6 is also configured on R5's f0/0 , lo0 and tunn56

tunn56 is connected IPv6 network over ipv4 cloud.

EIGRPv6 is running on all ipv6 enabled interfaces and all interface are reachable.

R5 is configured as ipv6 bsr on its f0/0 interface and its information is propogated to R6 as well. 

Up to this point there is no issue at all.

Now as soon as R6 is configured as bsr rp candidate on its f0/0.67 interface there are two tunnel created tunnel1 and tunnel2.

Why these tunnel are not stable and are getting up and down ? How these tunnel elect its source ipv6 address ?

 

 

Rack1R6#

% Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfaces

% Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfaces

*Mar 20 16:03:02.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

*Mar 20 16:03:02.631: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

 

Therefore sometimes these tunnel show up in this output and sometimes not.

 

Rack1R6#sh ipv6 pim tunnel 

Tunnel0* 

  Type  : PIM Encap

  RP    : Embedded RP Tunnel

  Source: 2001:155:1:67::6

Tunnel1* 

  Type  : PIM Encap

  RP    : 2001:155:1:67::6*

  Source: 2001:155:1:56::6

Tunnel2* 

  Type  : PIM Decap

  RP    : 2001:155:1:67::6*

  Source:  - 

 

 

 

Comments

  • The Tunnels here are used for source registration. IPv6 breaks from the traditional rule of registration, by using automatic temporary tunnels. I beleive the tunnels are supposed to be deleted after registration, but IOS code keeps the tunnels in the config. 

     

    This was helpful for me, maybe you've already seen it: 

     

    http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/ps6594/product_data_sheet0900aecd80320fb8.pdf

  • The Tunnels here are used for source registration. IPv6 breaks from the traditional rule of registration, by using automatic temporary tunnels. I beleive the tunnels are supposed to be deleted after registration, but IOS code keeps the tunnels in the config. 

    Thats true but the problem is why these tunnels are flapping. There is no source existed in the topology yet.

  • Further more why there are two tunnels with the same RP ipv6 address. There is just one RP in this topology.

  • Isn't this a source here - " Source: 2001:155:1:56::6"  ? 

     

    The tunnels are unidirectional. 

  • Isn't this a source here - " Source: 2001:155:1:56::6"  ? 

    The tunnels are unidirectional. 

    This is tunnel end point address on this router which is an RP.

  • Hi Deepak

    after doing this simple lab I got stuck with ipv6 bsr configs....

     

    and the dreaded router logs of 

    %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

    % Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfaces

    % Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfash ver

     

    can you recall what the issue was on your topology....

    R5 is the cRP and R4 the BSR with the ipv6 eigrp enabled tunnel between them....

     

    I just seem to not get this one right :-(

     

    I also got the intermittend issues of R5 loosing the dynamic tunnels and then it re-appears again...thus R4 kinows about the RP for some time and then loses the RP info?

     

     

     

     

  • % Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfaces

    % Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfash ver

    It usually appears when we remove any type of logical interfaces like virtual-template or sub interfaces and it doesn't get removed until we reboot the router. Here in this case, we can't modify the tunnel interface which was created by PIM registration process in IPv6 multicast. Is this the same tunnel interface as you mentioned or this log has been generated against any other interfaces modification. By the way , I don't see any issue like this during IPv6 BSR configuration on "c2800nm-adventerprisek9-mz.124-25b.bin" IOS version. Please post the config and IOS version, could be bug with software version as well.

     

Sign In or Register to comment.