Re: BGP Route-maps

From: Sam Munzani (sam@xxxxxxxxxxx)
Date: Tue Nov 07 2000 - 18:24:18 GMT-3


   
O.K. Here is comes from 12.1.4 IOS experiment.
R1 knows about bunch of subnets by IBGP from it's neighbor.
Using Route-map on R1 we match 192.168.11.0 segment and set local preference
for that subnet to 200.

router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 132.5.5.5 remote-as 1
 neighbor 132.5.5.5 update-source Loopback9
 neighbor 132.5.5.5 route-map inbound in
 neighbor 132.5.6.6 remote-as 1
 neighbor 132.5.6.6 update-source Loopback9
 neighbor 132.5.6.6 route-map inbound in
!
ip classless
no ip http server
!
access-list 88 permit 192.168.11.0 0.0.0.255
route-map inbound permit 10
 match ip address 88
 set local-preference 200
!
route-map inbound permit 20

Following is BGP table.

BGP table version is 6, local router ID is 132.5.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.1/32 150.100.1.1 0 100 0 7 i
*>i192.168.2.0 150.100.1.1 0 100 0 7 i
*>i192.168.3.0 150.100.1.1 0 100 0 7 i
*>i192.168.4.0 150.100.1.1 0 100 0 7 i
*>i192.168.11.0 132.5.6.6 0 200 0 i

It still works. Looks like this is IOS version issue. What IOS are you
working with?

Sam

> Another experiment that might make this more clear is instead of trying to
> permit or deny routes, send an IBGP peer to routes using BGP and on the
> peer, try to change the local preference of just one of the routes using
an
> inbound route-map and match ip address. You'll find that no matter what
you
> do, both routes will always get the same local preference.
> >
> >I had the same experience as Steve....It appears to me that this rule
only
> >applies to IBGP...Here's what I did:
> >
> >R1-------------R2--------------R3-------------
> > 10.4.2.0/24 10.4.1.0/24
> >
> >I put R1 in BGP AS 1 and R2 and R3 in BGP AS 2
> >R3 is injecting both attached networks into BGP
> >R2 has synchronization disabled
> >
> >First, I created the following route-map on R2 and applied it inbound to
R3
> >(ibgp):
> >route-map cisco deny 10
> > match ip address 1
> >route-map cisco permit 20
> >
> >access-list 1 permit 10.4.1.0 0.0.0.255
> >
> >I expected to see only 10.4.1.0/24 denied, but instead both routes were
> >denied...It appears that the router ignored the match statement (because
it
> >referenced an IP address) and becuase there was no other match statement,
> >both routes matched the first clause and were denied.
> >
> >Then, I removed this route-map from R2 and created the exect same
route-map
> >on R1 and applied it inbound to R2 (ebgp). R1 learned about the
> >10.4.2.0/24
> >network, but not the 10.4.1.0/24 network. When I debug bgp in and debug
> >bgp
> >update, the router indicates that the route-map has filtered the
> >10.4.1.0/24
> >route.
> >
> >I think this is a pretty simple yet effective experiment, and I would
love
> >to know what somebody else sees if they replicate it (maybe I'm missing
> >something).
> >Jack
> >>From: "Sam Munzani" <sam@munzani.com>
> >>Reply-To: "Sam Munzani" <sam@munzani.com>
> >>To: "McNutt, Steve" <Steve.McNutt@ahlcorp.com>, "'Eric Jastak'"
> >><ejastak@gobosh.cc>
> >>CC: <ccielab@groupstudy.com>
> >>Subject: Re: BGP Route-maps
> >>Date: Tue, 7 Nov 2000 13:53:36 -0600
> >>
> >>Not really. Here is my configs and bgp table.
> >>
> >>First is with route-map with filters. Then I removed route-map with
filter
> >>and you will see 192.168.1.0/24 in bgp table.
> >>
> >>Config with route-map inbound filters:
> >>router bgp 1
> >>
> >>no synchronization
> >>
> >>bgp log-neighbor-changes
> >>
> >>neighbor 132.5.5.5 remote-as 1
> >>
> >>neighbor 132.5.5.5 update-source Loopback9
> >>
> >>neighbor 132.5.5.5 route-map inbound in
> >>
> >>neighbor 132.5.6.6 remote-as 1
> >>
> >>neighbor 132.5.6.6 update-source Loopback9
> >>
> >>neighbor 132.5.6.6 route-map inbound in
> >>
> >>neighbor 132.5.129.2 remote-as 4
> >>
> >>!
> >>
> >>!
> >>
> >>access-list 99 deny 192.168.1.0 0.0.0.255
> >>
> >>access-list 99 permit any
> >>
> >>route-map inbound permit 10
> >>
> >>match ip address 99
> >>
> >>
> >>Config without Route-map inbound filters:
> >>
> >>router bgp 1
> >>
> >>no synchronization
> >>
> >>bgp log-neighbor-changes
> >>
> >>neighbor 132.5.5.5 remote-as 1
> >>
> >>neighbor 132.5.5.5 update-source Loopback9
> >>
> >>neighbor 132.5.6.6 remote-as 1
> >>
> >>neighbor 132.5.6.6 update-source Loopback9
> >>
> >>neighbor 132.5.129.2 remote-as 4
> >>
> >>Just do like this and you will see the results
> >>
> >>Sam
> >>
> >> ----- Original Message -----
> >> From: McNutt, Steve
> >> To: 'Eric Jastak' ; 'Sam Munzani'
> >> Cc: 'ccielab@groupstudy.com'
> >> Sent: Tuesday, November 07, 2000 1:43 PM
> >> Subject: RE: BGP Route-maps
> >>
> >>
> >> I can confirm that the rule does apply to IBGP. I ran into this last
> >>night on CCBootcamp lab 12. The rule makes sense given the goal of
IBGP
> >>is to maintain AS consistancy.
> >>
> >> Lab 12 is cool because it gave me an idea of how confusing things can
> >>get when working with confederations. The scoping of some rules are
> >>changed, but some are not, and the confederation makes it harder to tell
> >>if
> >>you are not meeting an AS wide "IBGP" type rule.
> >>
> >> -----Original Message-----
> >> From: Eric Jastak [mailto:ejastak@gobosh.cc]
> >> Sent: Tuesday, November 07, 2000 2:14 PM
> >> To: 'Sam Munzani'
> >> Cc: 'ccielab@groupstudy.com'
> >> Subject: RE: BGP Route-maps
> >>
> >>
> >> I think that rule only applies to iBGP. Was the route-map applied
to
> >>an iBGP or eBGP neighbor?
> >>
> >> - Eric
> >> -----Original Message-----
> >> From: Sam Munzani [mailto:sam@munzani.com]
> >> Sent: Tuesday, November 07, 2000 10:07 AM
> >> To: ccielab@groupstudy.com
> >> Subject: BGP Route-maps
> >>
> >>
> >> Hi Group,
> >>
> >> As everybody might have read it in Halabi and bunch of other
> >>sources.
> >> "Inbound Route-map does not work when used with matching IP
> >>address". Today I experimented and it works inbound also. Violating the
> >>BGP
> >>(or Halabi) rule for route-maps.
> >>
> >> Sam
> >



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:43 GMT-3