HSRP on unnumbered interface with MGO

[evan.r.moore]

Should the following configuration work?

!
interface Bundle-Ether20.2238
 description test customer
 service-policy input input-classify
 ipv4 point-to-point
 ipv4 unnumbered Loopback0
 encapsulation dot1ad 2238 dot1q 2238
!
interface Bundle-Ether20.2810
 description HSRP tracker
 ipv4 address 64.17.122.169 255.255.255.248
 encapsulation dot1ad 2301 dot1q 2301
!
router hsrp
 interface Bundle-Ether20.2238
  address-family ipv4
   hsrp 2238 slave
    follow master
    address 64.17.122.65
   !
  !
 !
 interface Bundle-Ether20.2810
  address-family ipv4
   hsrp 2 version 2
    name master
    preempt
    priority 120
    address 64.17.122.171
   !
  !
 !
!
router static
 address-family ipv4 unicast
  64.17.122.64/30 Bundle-Ether20.2238 tag 10
 !
!

While I admit it's not the cleanest arrangement, I don't see any reason it would not work.  However, on XR 5.1.2 (w/ sp1), it appears broken:

RP/0/RSP0/CPU0:node0#show hsrp brief
IPv4 Groups:
                        P indicates configured to preempt.
                        |
Interface      Grp  Pri P State   Active addr     Standby addr   Group addr    
BE20.2238      2238 sla   Init    unknown         unknown        64.17.122.65  
BE20.2810         2 120 P Active  local           64.17.122.170  64.17.122.171 

[xthuijs]

hi evan,

yeah this won't work. well you can make it work, but the solution is horrific. you need to add static arp entries for all those destinations off the unnumbered.

currently the cef adj is not resolved, because theoretically the destination can exist on any interface that leverages that unnumbered. In IOS, arp would blast out a request on all interfaces trying to get a destination, which was not fancy either. in XR we limited that behavior whereby we expect a static arp entry tied to the interface so we know or effectively can send targeted requests.

along with HSRP, yeah makes the situation a bit more nasty.

the other crux is, you specify the interface to be point to point, otherwise you cant do unnumbered, and then there is effectively a point to multipoint scenario.

best to fix the addr and not unnumber it.

if you need to aggregate multiple interfaces together in an L3 env like this, then consider the BD with a BVI and pull in all AC's into that BD.

then the BD will manage the mac situation, and BVI provides you that routing endpoint.

xander

[evan.r.moore]

I'd hoped the static route at an interface would be enough of a hint for ARP.

I assume BD means bridge domain, which means all those AC has visibility to each other.  That's not desirable.

The real driver, however, is moving existing links built on /30 subnets into an arrangement where HSRP is providing redundancy for the L3 gateway service without having to renumber.  Do you have any ideas on for that?

ERM

[xthuijs]

the static route tied to an interface will resolve the recursion, that is correct, but I dont think that HSRP is going to like that still. that is the nasty dependency here.

if you want to entertain the BD approach, you could put the AC's in a split horizon group so they can't speak with each other, but only with the gateway. something like the "promiscuous" vs "private" port thing that c6k used to have at the time with pvlans.

I dont have the full picture as to what the problem is you're trying to resolve, but I think there may be some options.

xander
 

[evan.r.moore]

Here's the situation:

Node A connects a number of customers with DS1 circuits, using /30 subnets across various IP allocations.

The customers are migrating to metro Ethernet connections.  When this happens, the customer is on a unique VLAN (or QinQ VLAN pair), which contains the customer's router, and our nodes B and C.

I'm hoping there's a solution that allows us to run HSRP between B and C, without the customer having to renumber his router.  I know I can do this with VRRP, but I don't see that as well supported on the ASR9ks.

Does that make it more clear?

[xthuijs]

evan yes thanks scenario is a bit more clear.

few options you have; both hsrp and vrrp can be used here, but for both options the subnet needs to be larger then a /30. this so we can put 2 adds on the phy access interface and use one for the virtual ip address. so there will be some renumbering in play here on the cpe side.

Another option is I see you're using bundle. You could use MCLAG, putting bundle members on each node, share the address between both sides, no renumbering necessary and MCLAG will handle which member (set) is active on what node.

depending on whether you can renumber the CPE, HSRP/VRRP is a more simpler option then MCLAG I guess, and MCLAG requires the introduction of another protocol (ICCP, to comm state between the POA's/point of attachment, the bundle masters).

the unnumbered you're doing here requires a lot of funkiness and routes etc and hsrp/vrrp is not going to like that.

regards

xander