Both Juniper and Cisco has introduce features to assist the setup & speed of deploying BGP neighbors. With cisco it's called "Bgp listen" and in Juniper is called "Promiscuous peering".
1st here the network layout;
BGPR1 is going to be enable for BGP listen and a subnet range of 10.10.0/24 established.
BGPR1 cfg;
!
!
ip routing
!
router bgp 65001
bgp router-id 1.0.0.1
bgp listen range 10.10.0.0/24 peer-group ibgp
bgp listen limit 10
neighbor ibgp peer-group
neighbor ibgp remote-as 65001
neighbor ibgp default-originate
!
!
and now on the BGPR3/4 device we deploy the standard cfg;
config t
!
ip routing
!
router bgp 65001
neighbor 10.10.0.1 remote-as 65001
!
!
end
And now when these devices attempts to established a BGP peering relationship, BGPR1 router will dynamically build the neighbor-ship. Very simple to rollout and deploy.
To confirm bgp listen is setup and for what range;
BGPR1#show ip bgp sum
BGP peergroup ibgp listen range group members:
10.10.0.0/24
and our two routers will have the following when BGP is established;
show ip bgp sum
BGP router identifier 1.0.0.3, local AS number 65001
BGP table version is 7, main routing table version 7
1 network entries using 117 bytes of memory
1 path entries using 48 bytes of memory
2/1 BGP path/bestpath attribute entries using 232 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 397 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.0.1 4 65001 7 6 7 0 0 00:02:12 1
and BGPR1 will show the following in it's bgp summary table;
show ip bgp sum
BGP router identifier 1.0.0.1, local AS number 65001
BGP table version is 2, main routing table version 2
1 network entries using 136 bytes of memory
1 path entries using 56 bytes of memory
1/0 BGP path/bestpath attribute entries using 128 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 320 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.10.0.3 4 65001 7 9 2 0 0 00:03:55 0
*10.10.0.4 4 65001 7 9 2 0 0 00:04:15 0
* Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1
BGP peergroup ibgp listen range group members:
10.10.0.0/24
Total dynamically created neighbors: 2/(10 max), Subnet ranges: 1
and syslog;
*Feb 11 08:27:10.787: %BGP-5-ADJCHANGE: neighbor *10.10.0.3 Up
*Feb 11 08:47:10.883: %BGP-5-ADJCHANGE: neighbor *10.10.0.4 Up
Now why one would deploy bgp listen for bgp configurations?
- to rapidly deploy bgp peers within a AS
- to reduce human error such as with remote-as number or other peer-group items
- to ease the renumbering and moves of existing BGP peers as in a migration or merge
Now I have never seen this feature used outside of the enterprise community, and one should at least enable some type of security by specifying the range and with using a md5-tcp password for the segments that have BGP peers.
Ken Felix
Freelance Network /Security Engineer
kfelix at hyperfeed com
No comments:
Post a Comment