[j-nsp] BGP peering from a VIP address

[Harry Reynolds]

Well, I agree its not best practice, and while it made it through
tech-edits, and seemed to work fine, the example I provided in the E-BGP
chapter of the JNCIP prep book, did result in a bit of controversy.
While I recall no killer reason why this should not be
allowed/supported, the general concensous was to use BFD/IGP for this
type of redundancy and that VIP/VRRP was for dumb host.

Note that I have not tested this in some time, and recall that the VRRP
backup will log messages relating to its inability to use the VIP for
its BGP session (as its owned by the current master).


HTHs, and regards

Harry



[excerpt from EBGP chapter in JNCIP prep guide]

The highlighted entry provides the information being sought. The output
confirms that P1's address is 10.0.5.254, and that it has been
configured to peer with 10.0.5.200, which is the VRRP virtual IP (VIP)
address shared by r1 and r2. The requirement that both r1 and r2 should
peer to a router with a single neighbor statement, and that the failure
of either router r1 or r2 should not disrupt this peering session,
suddenly becomes feasible when illuminated by this newfound information.

To test the hypothesis that P1 is supposed to (or even can) peer with
the VIP address shared by r1 and r2, you make the highlighted changes to
r1's configuration:
[edit protocols bgp group p1]
lab at r1# show 
type external;
traceoptions {
    file p1;
    flag open detail;
}
local-address 10.0.5.200;
peer-as 65050;
neighbor 10.0.5.254;

A few minutes after the changes are committed the session is still down
so something else must be amiss. Analyzing the p1 trace file uncovers
another clue:
Jun 18 22:28:54 task_addr_local: task BGP_65050.10.0.5.254 address
10.0.5.200: Can't assign requested address
Jun 18 22:28:54 bgp_select_myaddr: peer 10.0.5.254 (External AS 65050)
local address 10.0.5.200 unavailable, connection failed

Seem like r1 is having trouble sourcing packets from its VIP address.
Displaying the VRRP status confirms that it is the current master,
however:
[edit protocols bgp group p1]
lab at r1# run show vrrp summary 
Interface   Unit  Group  Type  Address          Int state    VR state
fe-0/0/0     0     1     lcl   10.0.5.1         up           master
                         vip   10.0.5.200

Any ideas? 
Another invaluable clue is obtained by r2's indication that pings to the
VIP address fail:
[edit]
lab at r2# run ping 10.0.5.200 count 1 
PING 10.0.5.200 (10.0.5.200): 56 data bytes
^C
--- 10.0.5.200 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

Examining r2's ARP cache confirm that r1 has responded to ARP request
for the VIP address:
[edit]
lab at r2# run show arp | match 10.0.5.200 
00:00:5e:00:01:01 10.0.5.200      10.0.5.200               fe-0/0/0.0

At this point you should recall that, according to the VRRP standard,
with the exception of ARP replies, a router can only respond to traffic
addressed to the VIP when it is the VRRP group's master, and when the
VIP is actually assigned to one of its interfaces. You should also
recall that JUNOS software provides a knob that allows a router to
respond to traffic sent to the VIP address, even though this address is
not assigned to any of its interfaces. This sounds like an option worth
exploring, so the following change is committed:
[edit interfaces fe-0/0/0 unit 0 family inet address 10.0.5.1/24]
lab at r1# set vrrp-group 1 accept-data

A minute or so later the BGP session status on router r1 is again
displayed:
[edit]
lab at r1# run show bgp summary    
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paqths  Act Paths Suppressed    History Damp State
Pending
inet.0                38         26          0          0          0
0
Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn
State|#Active/Received/Damped...
10.0.3.3        65000         46         40       0       2       17:12
3/8/0                0/0/0
10.0.3.4        65000         48         39       0       2       17:12
13/20/0              0/0/0
10.0.5.254      65050         19         26       0       0        6:03
10/10/0              0/0/0


> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of 
> Stefan Fouant
> Sent: Friday, March 28, 2008 9:22 AM
> To: juniper-nsp
> Subject: [j-nsp] BGP peering from a VIP address
> 
> Hi folks,
> 
> There is some internal debate here in my office today as to 
> whether or not Juniper can support a BGP implementation in 
> conjunction with VRRP, as in, BGP is sourced from a VRRP VIP address.
> 
> Now before everyone attempts to tear me a new one...  I 
> should state that I'm pretty sure this shouldn't be done and 
> to do so would pretty much break the protocol in every way 
> imaginable... however, I am being told that Cisco has some 
> knobs to accomplish this and I just want to be certain if 
> Juniper can do something along these lines...
> 
> Thoughts?
> 
> Stefan Fouant
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>