From: Sam Munzani (sam@xxxxxxxxxxx)
Date: Tue Nov 07 2000 - 18:34:31 GMT-3
Sounds like that's the concusion. Let's burry this thread and move on to new
topics.
Frame-Relay Traffic Shaping.
Anybody have working example?
Sam
> That would make sense...I'm using 12.07t
>
>
> >From: "Sam Munzani" <sam@munzani.com>
> >Reply-To: "Sam Munzani" <sam@munzani.com>
> >To: "Jack Heney" <jheneyccie@hotmail.com>, <Steve.McNutt@ahlcorp.com>,
> ><ejastak@gobosh.cc>
> >CC: <ccielab@groupstudy.com>
> >Subject: Re: BGP Route-maps
> >Date: Tue, 7 Nov 2000 15:24:18 -0600
> >
> >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