From: Scott Morris (smorris@ipexpert.com)
Date: Tue Sep 04 2007 - 16:11:54 ART
Should work....
Configure a pretend BB router:
R2(config)#router bgp 666
R2(config-router)#network 140.101.2.0 mask 255.255.255.0
R2(config-router)#neighbor 140.101.36.1 remote-as 100
R2(config-router)#
Configure your router:
R1(config)#router bgp 100
R1(config-router)#network 140.101.1.0 mask 255.255.255.0
R1(config-router)#neighbor 140.101.36.2 remote-as 200
R1(config-router)#
You don't know the peer's AS, so pick any number (200)
*Sep 4 19:30:37.719: %BGP-3-NOTIFICATION: sent to neighbor 140.101.36.2 2/2
(peer in wrong AS) 2 bytes 029A
R1(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 029A
00B4 8C65 0202 1002 0601 0400 0100 0102 0280 0002 0202 00
R1(config-router)#
Now, look at "029A" in hex... You'll find it's '666' which is what we
configured the BB router as.
If you were looking at the message on the BB router, it would show its own
ASN.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
A Cisco Learning Partner - We Accept Learning Credits!
smorris@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
-----Original Message-----
From: Cecil Wilson [mailto:Cecil.Wilson@flextronics.com]
Sent: Tuesday, September 04, 2007 2:46 PM
To: smorris@ipexpert.com; Greg Wendel
Cc: Joseph Brunner; NET HE; bit.gossip@chello.nl; ccielab@groupstudy.com
Subject: RE: EBGP AS mispatch
Scott
when I tried this, the hex number converted to the AS number on my side
of the peer. Am I reading it wrong, maybe missing one part?
Thanks, Cecil
Cecil G. Wilson
IT Network Services
Office: (901) 215-2710
Cell: (901) 601-6201
cecil.wilson@flextronics.com
-----Original Message-----
From: Scott Morris [mailto:smorris@ipexpert.com]
Sent: Tuesday, September 04, 2007 1:12 PM
To: 'Greg Wendel'; Cecil Wilson
Cc: 'Joseph Brunner'; 'NET HE'; bit.gossip@chello.nl; ccielab@groupstudy.com
Subject: RE: EBGP AS mispatch
In the message that you get when you setup a peer (pick an AS you want), it
will tell you peer in wrong AS:
R2(config-router)#
*Jul 28 13:28:25.977: %BGP-3-NOTIFICATION: sent to neighbor
140.101.68.13
2/2 (peer in wrong AS) 2 bytes 2864
That last part there (2864) is a hex number. Convert that with Windows
calculator and you'll find that the remote AS (in this instance) is AS10340.
So it gives it to you automagically!
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
A Cisco Learning Partner - We Accept Learning Credits!
smorris@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Greg
Wendel
Sent: Tuesday, September 04, 2007 1:23 PM
To: Cecil Wilson
Cc: Joseph Brunner; NET HE; bit.gossip@chello.nl; ccielab@groupstudy.com
Subject: Re: EBGP AS mispatch
There are interesting discussions on this in the archives, but I am pretty
sure the general consensus is that there is no way to get this information.
On 9/4/07, Cecil Wilson <Cecil.Wilson@flextronics.com> wrote:
>
> Hi GS
>
>
>
> - is the EBGP AS peers are mismatch you wil get a message that
>
> includes a hex code, this code is the AS on the near side
>
> What can I use to tell me what the AS is on the far side(peer) if
> I
>
> don't know.
>
> Are there anyway to tell?
>
>
>
> Cecil G. Wilson
>
> IT Network Services
>
> Office: (901) 215-2710
>
> Cell: (901) 601-6201
>
> cecil.wilson@flextronics.com
>
>
>
>
>
> -----Original Message-----
>
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
>
> Joseph Brunner
>
> Sent: Thursday, August 30, 2007 10:22 PM
>
> To: 'NET HE'; bit.gossip@chello.nl; ccielab@groupstudy.com
>
> Subject: RE: nasty redistribution
>
>
>
> Xin He;
>
>
>
> I use tagging to prevent route feedback. This will happen when you are
>
> re-distributing one protocol into another in at least two places and
> the
>
> RECEIVING protocol (like OSPF/RIP) doesn't have a build in mechanism
> to
>
> detect inferior redistributed routes (EIGRP does this pretty well by
>
> default, with EX = 170).
>
>
>
> I use "distance xxx source ACL" when a single path must be preferred
>
> which supersedes what the redistribution decided was the best path on
>
> its own, and the task wont let us touch cost, bandwidth, etc.
>
>
>
> Also you will find yourself touch distance often when preferring two
>
> routes (and two sources) from the same protocol (i.e. two ospf paths
> to
>
> 123.0.1.0/24, etc.)
>
>
>
> If you find you are stuck on redistribution, DRAW it OUT. THINK like
>
> each router at EACH hop. Consider all information available at each
> hop,
>
> prefix length, AD, Metric, and as you pointed out, order of learning
> the
>
> route (what will be in the routing table when the redistribution
> command
>
> looks for the routes to redistribute)
>
>
>
> -Joe
>
>
>
> -----Original Message-----
>
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
>
> NET HE
>
> Sent: Thursday, August 30, 2007 10:24 PM
>
> To: bit.gossip@chello.nl; ccielab@groupstudy.com
>
> Subject: RE: nasty redistribution
>
>
>
> Hi,
>
>
>
> I was under the same inpression as well. I was always using tagging to
>
> prevent routing loop it there were multiple redistrition points
> between
>
> 2 routing domains. Recently I found a solution, but inputs from group
>
> are very
>
>
>
> appreciated.
>
>
>
> Since CCIE lab is small, it's very easy to know th biggest metric in a
>
> routing domain, for example, maximum hops in a rip domain, minimum
>
> bandwidth
>
>
>
> and biggest acummulated delay in eigrp domain, and biggest acummulated
>
> cost in ospf domain. I would put that biggest metric as default-metric
>
> under the routing protocol. When routes are redistributed from another
>
> routing domain,
>
>
>
> all those routes will have the biggest metric at that redistribution
>
> point.
>
> This would simply prevent any routing loop without any tagging.
>
>
>
>
>
> Best Regards,
>
> Net (Xin) He
>
>
>
> >
>
> >Group,
>
> >so far I was under the impression that I could tackle every scenario
> >of
>
>
>
> >simple and mutual redistribution by tagging and filtering at
>
> >redistribution points.
>
> >So I focused and practiced a lot to become proficient and familiar
> >with
>
>
>
> >this technique.
>
> >Until the simple scenario that I describe below shattered all my
>
> >confidence and pushed me back to square 0 :-( Tagging and filtering
> >is
>
> >not enough: in some cases it doesn't work; in some cases admin
>
> >disctance must be manipulated.
>
> >
>
> >The problem with this simple network is the redistribution of R7 lo0
>
> >170.1.7.7
>
> >from RIP to OSPF via 2 distribution points: R5 and R6. In normal
>
> >condition the network is stable in the following status:
>
> >- either R5 or R6, whoever is faster, redistributes 170.1.7.7 from
> >RIP
>
> >to OSPF; let's assume R6 is faster
>
> >- R6 will redistribute 150.1.7.7 into OSPF and keep the original RIP
>
> >route in its routing table R6#show ip route | i 170.1.7.7
>
> >R 170.1.7.7/32 [120/1] via 170.1.200.7, 00:00:23,
FastEthernet0/0
>
> >
>
> >- R5 instead learns 170.1.7.7 via OSPF so that the OSPF route
>
> >overwrites the RIP route due to better admin distance R5#show ip
> >route
>
> >| i 170.1.7.7
>
> >O E2 170.1.7.7/32 [110/20] via 170.1.100.9, 00:17:30, Serial1/0.1
>
> >
>
> >- the tagging that I put in place prevents the route from
>
> ricirculating:
>
> >the
>
> >network is perfectly stable, even if maybe routing is not optimal but
>
> >who cares now.....
>
> >
>
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> >
>
> >The fun starts if I shutdown the OSPF session between R5 and R2, for
>
> >instance putting passive one interface long enogh for R5 to re-learn
>
> >the route via RIP from R7. At this point, if we reestablish OSPF,
> >both
>
> >R5 and R6 try to redistribute the route from RIP to OSPF and
> >170.1.7.7
>
> >ping-pongs for ever between R5 and R6.
>
> >
>
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> >
>
> >The first nasty thing here is that I would have not spotted this
>
> >condition at the real lab because in normal condition the network is
>
> >stable and even after a reload the network comes up stable. Only what
> >I
>
>
>
> >described above can trigger the instability.
>
> >The second nasty thing is that now I am back to the original
question:
>
> >when should I use tagging? When admin-distance? When both?
>
> >In this case I guess both are needed!
>
> >
>
> >The reason why I tried to avoid manipulating admin distance so far is
>
> >the
>
> >following:
>
> >
>
> >Let's say that to solve the instability here I increase the admin
>
> >distance of OSPF external to 121: the problem of 170.1.7.7 is solved
>
> >because both R5 and
>
> >R6 will prefer the RIP route and only R2 will see the O E2 But while
> >I
>
> >solved the problem in the direction RIP -> OPSF, now I have create
> >the
>
> >same potential problem in the opposite direction; so, if R2 were to
>
> >redistribute its loopback as connected, I am exactly in the same
>
> >situation as I was at the beginning but in a mirrored form. I have
> >not
>
> >solved the problem but just thrown in over the fence !
>
> >
>
> >I think that the only way out here is to increase the admin distance
>
> >only of specific selected routes when redistributed; in this case
> >only
>
> >170.1.7.7 shold be changed from O E2 [110/20] to O E2 [121/20]
>
> >
>
> >Am I completely out of track?
>
> >PS: sorry for the long post!
>
> >
>
> >
>
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> >
>
> > _____ R5 _|
>
> > / | rip
>
> > / |
>
> > / |
>
> >R2(ospf) |--- R7 - lo0 170.1.7.7
>
> > \ |
>
> > \ |
>
> > \_____ R6 _ |
>
> >
>
> >
>
> >~~~~~~~~
>
> >
>
> >hostname R2
>
> >!
>
> >interface Serial1/0
>
> > no ip address
>
> > encapsulation frame-relay
>
> > serial restart-delay 0
>
> > no frame-relay inverse-arp
>
> >!
>
> >interface Serial1/0.5 point-to-point
>
> > ip address 170.1.100.9 255.255.255.252
>
> > frame-relay interface-dlci 205
>
> >!
>
> >interface Serial1/0.6 point-to-point
>
> > ip address 170.1.100.13 255.255.255.252
>
> > frame-relay interface-dlci 206
>
> >!
>
> >router ospf 1
>
> > log-adjacency-changes
>
> > network 170.1.100.0 0.0.0.255 area 0
>
> >
>
> >~~~~~~~~
>
> >
>
> >hostname R5
>
> >!
>
> >interface FastEthernet0/0
>
> > ip address 170.1.200.5 255.255.255.224
>
> > duplex full
>
> >!
>
> >interface Serial1/0
>
> > no ip address
>
> > encapsulation frame-relay
>
> > serial restart-delay 0
>
> > no frame-relay inverse-arp
>
> >!
>
> >interface Serial1/0.1 point-to-point
>
> > ip address 170.1.100.10 255.255.255.252
>
> > frame-relay interface-dlci 502
>
> >!
>
> >router ospf 1
>
> > log-adjacency-changes
>
> > redistribute rip subnets route-map RO
>
> > network 170.1.100.0 0.0.0.255 area 0
>
> >!
>
> >router rip
>
> > version 2
>
> > redistribute ospf 1 metric 2 route-map OR
>
> > passive-interface default
>
> > no passive-interface FastEthernet0/0
>
> > network 170.1.0.0
>
> > no auto-summary
>
> >!
>
> >route-map RO deny 10
>
> > match tag 96 115 116 125 126
>
> >!
>
> >route-map RO permit 20
>
> > set tag 125
>
> >!
>
> >route-map OR deny 10
>
> > match tag 96 115 116 125 126
>
> >!
>
> >route-map OR permit 20
>
> > set tag 115
>
> >
>
> >~~~~~~~~~~
>
> >
>
> >hostname R6
>
> >!
>
> >interface FastEthernet0/0
>
> > ip address 170.1.200.6 255.255.255.224
>
> > duplex full
>
> >!
>
> >interface Serial1/0
>
> > no ip address
>
> > encapsulation frame-relay
>
> > serial restart-delay 0
>
> > no frame-relay inverse-arp
>
> >!
>
> >interface Serial1/0.1 point-to-point
>
> > ip address 170.1.100.14 255.255.255.252
>
> > frame-relay interface-dlci 602
>
> >!
>
> >router ospf 1
>
> > log-adjacency-changes
>
> > redistribute rip subnets route-map FROM-RIP
>
> > network 170.1.100.0 0.0.0.255 area 0
>
> >!
>
> >router rip
>
> > version 2
>
> > redistribute ospf 1 metric 2 route-map FROM-OSPF
>
> > passive-interface default
>
> > no passive-interface FastEthernet0/0
>
> > network 170.1.0.0
>
> > no auto-summary
>
> >!
>
> >no ip http server
>
> >no ip http secure-server
>
> >!
>
> >!
>
> >!
>
> >logging alarm informational
>
> >!
>
> >!
>
> >!
>
> >route-map FROM-OSPF deny 10
>
> > match tag 96 115 116 125 126
>
> >!
>
> >route-map FROM-OSPF permit 20
>
> > set tag 116
>
> >!
>
> >route-map FROM-RIP deny 10
>
> > match tag 96 115 116 125 126
>
> >!
>
> >route-map FROM-RIP permit 20
>
> > set tag 126
>
> >!
>
> >~~~~~~~~~
>
> >
>
> >hostname R7
>
> >!
>
> >interface Loopback0
>
> > ip address 170.1.7.7 255.255.255.255
>
> >!
>
> >interface FastEthernet0/0
>
> > ip address 170.1.200.7 255.255.255.224
>
> > duplex full
>
> >!
>
> >router rip
>
> > version 2
>
> > network 170.1.0.0
>
> > no auto-summary
>
> >!
>
> >~~~~~~~~~~~
>
> >R5#debug ip routing
>
> >IP routing debugging is on
>
> >R5(config-router)#passive-interface s1/0.1 R5(config-router)# *Aug 30
>
> >21:07:49.147: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
>
> >Serial1/0.1 from FULL to DOWN, Neighbor Down: Interface down or
>
> >detached *Aug 30 21:07:54.651: RT: del 170.1.100.12/30 via
> >170.1.100.9,
>
>
>
> >ospf metric [110/128] *Aug 30 21:07:54.655: RT: delete subnet route
> >to
>
> >170.1.100.12/30 *Aug 30 21:07:54.659: RT: NET-RED 170.1.100.12/30
> >*Aug
>
> >30 21:07:54.667: RT: del 170.1.7.7/32 via 170.1.100.9, ospf metric
>
> >[110/20] *Aug 30 21:07:54.671: RT: delete subnet route to
> >170.1.7.7/32
>
> >*Aug 30 21:07:54.675: RT: NET-RED 170.1.7.7/32 R5(config-router)#
>
> >R5(config-router)# *Aug 30 21:08:07.395: RT: add 170.1.100.12/30 via
>
> >170.1.200.6, rip metric [120/1] *Aug 30 21:08:07.399: RT: NET-RED
>
> >170.1.100.12/30
>
> >R5(config-router)#no passive-interface s1/0.1 <<<<<<<<<<< let's
the
>
> show
>
> >begin !
>
> >R5(config-router)#
>
> >*Aug 30 21:08:18.071: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
>
> >Serial1/0.1 from LOADING to FULL, Loading Done *Aug 30 21:08:18.363:
>
> >RT: add 170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30
>
> >21:08:18.367: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.111: RT:
> >closer
>
>
>
> >admin distance for 170.1.100.12, flushing
>
> >1
>
> >routes
>
> >*Aug 30 21:08:33.115: RT: NET-RED 170.1.100.12/30 *Aug 30
21:08:33.119:
>
>
>
> >RT: add 170.1.100.12/30 via 170.1.100.9, ospf metric [110/128] *Aug
> >30
>
> >21:08:33.123: RT: NET-RED 170.1.100.12/30 *Aug 30 21:08:33.127: RT:
>
> >closer admin distance for 170.1.7.7, flushing 1 routes *Aug 30
>
> >21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.127: RT: add
>
> >170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
>
> >21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.279: RT: del
>
> >170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
>
> >21:08:33.279: RT: delete subnet route to 170.1.7.7/32 *Aug 30
>
> >21:08:33.279: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.515: RT: add
>
> >170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30
21:08:45.519:
>
> >RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: closer admin
>
> >distance for 170.1.7.7, flushing 1 routes *Aug 30 21:08:45.615: RT:
>
> >NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: add 170.1.7.7/32 via
>
> >170.1.100.9, ospf metric [110/20] *Aug 30 21:08:45.619: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:08:50.751: RT: del 170.1.7.7/32 via
>
> >170.1.100.9, ospf metric [110/20] *Aug 30 21:08:50.751: RT: delete
>
> >subnet route to 170.1.7.7/32 *Aug 30 21:08:50.751: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:14.455: RT: add 170.1.7.7/32 via
>
> >170.1.200.7, rip metric [120/1] *Aug 30 21:09:14.459: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:14.599: RT: closer admin distance for
>
> >170.1.7.7, flushing 1 routes *Aug 30 21:09:14.603: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:14.607: RT: add 170.1.7.7/32 via
>
> >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:14.611: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:19.699: RT: del 170.1.7.7/32 via
>
> >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:19.699: RT: delete
>
> >subnet route to 170.1.7.7/32 *Aug 30 21:09:19.699: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:43.395: RT: add 170.1.7.7/32 via
>
> >170.1.200.7, rip metric [120/1] *Aug 30 21:09:43.399: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:43.527: RT: closer admin distance for
>
> >170.1.7.7, flushing 1 routes *Aug 30 21:09:43.531: RT: NET-RED
>
> >170.1.7.7/32 *Aug 30 21:09:43.535: RT: add 170.1.7.7/32 via
>
> >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:43.539: RT: NET-RED
>
> >170.1.7.7/32
>
> >
>
> >_____________________________________________________________________
> >__
>
> >Subscription information may be found at:
>
> >http://www.groupstudy.com/list/CCIELab.html
>
>
>
> _________________________________________________________________
>
> Get Cultured With Arts & Culture Festivals On Live Maps
>
> http://local.live.com/?mkt=en-ca&v=2&cid=A6D6BDB4586E357F!2010&encType
> =1
>
> &sty
>
> le=h&FORM=SERNEP
>
>
>
> ______________________________________________________________________
> _
>
> Subscription information may be found at:
>
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> ______________________________________________________________________
> _
>
> Subscription information may be found at:
>
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> Legal Disclaimer:
>
> The information contained in this message may be privileged and
> confidential. It is intended to be read only by the individual or
> entity to whom it is addressed or by their designee. If the reader of
> this message is not the intended recipient, you are on notice that any
> distribution of this message, in any form, is strictly prohibited. If
> you have received this message in error, please immediately notify the
> sender and delete or destroy any copy of this message
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Gregory Wendel Springfield VA, 22153
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:09 ART